私たちがプロジェクトにおいてどのように THE FRUGAL ARCHITECT を活用すれば良いのか考えてみた
こちらの記事はJapan AWS Ambassadors Advent Calendar 2023の7日目の記事になります。
THE FRUGAL ARCHITECT とは
THE FRUGAL ARCHITECT は、2023/11/27 - 12/1 に開催された re:Invent 2023 において Amazon.com CTO Dr.Werner Vogels がキーノートの中で発表したドキュメントです。
コストを意識した持続可能な最新のアーキテクチャを構築するためのシンプルな考え方を７つの規則（それぞれ Law と表現されている）で分類し説明されています。
- LAW 1. Make Cost a Non-functional Requirement. (意訳：非機能要件にコストを加えること）
- LAW 2. Systems that Last Align Cost to Business. (意訳：システムにかけるコストがビジネスにマッチ状況を継続すること）
- LAW 3. Architecting is a Series of Trade-offs. (意訳：アーキテクチャを決断することはトレードオフの連続である）
- LAW 4. Unobserved Systems Lead to Unknown Costs. (意訳：観測できないシステムコストは青天井なコストである）
- LAW 5. Cost Aware Architectures Implement Cost Controls. (意訳：コストを意識したアーキテクチャがコスト管理を実現する）
- LAW 6. Cost Optimization is Incremental. (意訳：段階的なコスト最適化を適用する）
- LAW 7. Unchallenged Success Leads to Assumptions. (意訳：挑戦のない成功は思い込みにつながる）
本記事の内容
実際のプロジェクトにおいて THE FRUGAL ARCHITECT の各規則を適用するためには、どのようにすれば良いのか考えてみたことをメモとして記録しています。
本記事の目次
- THE FRUGAL ARCHITECT とは
- 本記事の内容
- LAW 1. Make Cost a Non-functional Requirement. をプロジェクトに適用するには？
- LAW 2. Systems that Last Align Cost to Business. をプロジェクトに適用するには？
- LAW 3. Architecting is a Series of Trade-offs. をプロジェクトに適用するには？
- LAW 4. Unobserved Systems Lead to Unknown Costs. をプロジェクトに適用するには？
- LAW 5. Cost Aware Architectures Implement Cost Controls. をプロジェクトに適用するには？
- LAW 6. Cost Optimization is Incremental. をプロジェクトに適用するには？
- LAW 7. Unchallenged Success Leads to Assumptions. をプロジェクトに適用するには？
- まとめ
LAW 1. Make Cost a Non-functional Requirement. をプロジェクトに適用するには？
私は LAW 1 を「非機能要件にコストを加えること」と受け止めています。
LAW 1 の詳細に関する原文はこちらを参照ください。
国内のシステム開発プロジェクトでは IPA 非機能要求グレード を用いて非機能要件を整理することが多いかと思います。非機能要求グレードには「コスト」を主体とした大項目は存在せず、各小項目にコストに関する記述が触れられている形となります。 この場合、問題となりえるシーンを想定すると、システム設計と非機能要件の適合状況を確認するフェーズにおいて、コスト軸での適合状況を見分けるのが難しく、不適切なコストをかけていることを見落としてしまう可能性が想定されます。 非機能要求グレードの他、AWS Well-Architected Frameworkを併用し、コスト効率化の柱よりCOST1、COST5、COST6を非機能要件に加えるのが良いと考えます。
LAW 2. Systems that Last Align Cost to Business. をプロジェクトに適用するには？
私は LAW 2 を「システムにかけるコストがビジネスにマッチ状況を継続すること」と受け止めています。
LAW 2 の詳細に関する原文はこちらを参照ください。
LAW 2では、システムによってビジネスにもたらす収益とシステムに係るコストのバランスがとれている状況を維持することが求められます。 一般的にコスト(AWS利用料金の確認)は、コストエクスプローラーなどを用いることが多いと思います。コストエクスプローラーに関する利用計画は、AWS Well-Architected Framework コスト効率化の柱より、COST 3と現状を照らし合わせるのが良さそうです。 ただ、システムに関わるコストはAWS利用料金だけではなく、エンジニアリングコストも含める必要があります。自社サービスの場合はエンジニアの社内コストと稼働時間をもとに算出し、外部委託の場合は委託費用をもとに算出する形となります。
LAW 3. Architecting is a Series of Trade-offs. をプロジェクトに適用するには？
私は LAW 3 を「アーキテクチャを決断することはトレードオフの連続である」と受け止めています。
LAW 3 の詳細に関する原文はこちらを参照ください。
FRUGALはコストの最小化だけではなく価値を最大化する（コストを抑えることは価値を小さくするものではない）と記載されています。 また、アーキテクチャの選定において、コストと緊張関係にある要素を考え、そのトレードオフが選定段階で然るべきものであったかを記録していく必要があります。アーキテクチャの選定において、Architecture Decision Recordsを用いて選定における理由を記録します。その際、コストも含めて記録し、その選定理由を改めて見直す際に参照できるようにしておくのが良いと思います。 技術の変化、コスト構造の変化、ビジネスの変化により、その時に選定したアーキテクチャは最適なものではなくなる可能性を念頭に起くことも大切です。AWS Well-Architected Framework コスト効率化の柱より、COST 11でオペレーションコストの考え方を照らし合わせることも忘れないようにしたいですね。
LAW 4. Unobserved Systems Lead to Unknown Costs. をプロジェクトに適用するには？
私は LAW 4 を「観測できないシステムコストは青天井なコストである」と受け止めています。
LAW 4 の詳細に関する原文はこちらを参照ください。
直訳では、観測できないシステムコストは未知にコストにつながるという意味ですが、未知なコストが存在する以上、コスト試算は不可能だと考えています。気づいたらあらかじめ予算をしていたコストを超えてしまったというシチュエーションになることも十分に想定できます。 そのため、ビジネスの安定性を損なう「青天井なコスト」だと受けてめました。 LAW4は、コストの可観測性を実現すること、さらにエンジニア、ビジネスパートなー(スポンサー、ステークホルダーなど)がいつでも見えるようにしておくことが重要だとしています。 AWS Well-Architected Framework コスト効率化の柱より、COST 3においてコストの可視化方法とともに情報の時間的粒度、誰が可視化されたコストダッシュボードを確認する必要があるのか、など明示することが良さそうです。
LAW 5. Cost Aware Architectures Implement Cost Controls. をプロジェクトに適用するには？
私は LAW 5 を「コストを意識したアーキテクチャがコスト管理を実現する」と受け止めています。
LAW 5 の詳細に関する原文はこちらを参照ください。
システムの構成要素のうち、ビジネスに対する重要度により階層分けし、優先的にコストをかける箇所、コストをかけるべきではない箇所を制御できることという記載があります。システム設計段階において、ユーザージャーニーや業務要件をもとにスプレッドシート化が可能な粒度で実装するビジネスロジックそのロジックがビジネスにどのような影響を与えるか記録しするのが現実的かと考えました。ユーザージャーニーをもとに考えるという意味では、SRO、SRIとも密接に紐づく要素になりそうです。 業務要件の場合は、大きな粒度の階層分け（例えばバッチ種別による重要度分別など）は、非機能要件における業務継続性などからも洗い出しができるかと思います。
LAW 6. Cost Optimization is Incremental. をプロジェクトに適用するには？
私は LAW 6 を「段階的なコスト最適化を適用する」と受け止めています。
LAW 6 の詳細に関する原文はこちらを参照ください。
LAW 6 の詳細には、システムの導入後でもシステムを再検討して段階的に最適化を改善する必要がある。と記載されています。 LAW 6を実現するにはシステムの観測性が実装されていることが前提になります。インスタンスメトリクスからCPU、メモリなど適用しているコンピュートリソースが効率的であるかどうかの見直しを行うこと、Trusted Advisorによるコストの最適化ポイントの確認などは比較的用意に運用可能かと思います。 さらに多くの洞察を得てコスト最適化（価値最大化）につながあえる改善を継続的かつ段階的に加えるには、Amazon X-Ray、New Relicのようなトレーシングサービス、Amazon CodeGuru Profilerなどのプロファイラを用いて改善点や改善適用の効果確認可能な状況にする必要があります。 また、「LAW 5. Cost Aware Architectures Implement Cost Controls.」と組み合わせることで実際に改善を加えるときの影響度も考慮しながら適用を進めることができそうですね。
LAW 7. Unchallenged Success Leads to Assumptions. をプロジェクトに適用するには？
私は LAW 7 を「挑戦のない成功は思い込みにつながる」と受け止めています。
LAW 7 の詳細に関する原文はこちらを参照ください。
「私たちはいつもこのようにしてきた」は英語で最も危険なフレーズの１つと記載されていますが、日本語でも変わりはなさそうです。特に理由はないけど、今までもこうしてきたから今回も・・・という状況は往々にしてあるものだと思います。この結果、盲目的に手段を選択してしまい問題が発生することもあれば、コストにも悪影響を与える可能性を指摘しています。 これまでの慣習などに流されず、疑問を持ち、最適化するためには、プロジェクトにおけるレトロスペクティブを各フェーズで適用することが良さそうです。振り返りの過程で、プロジェクトチーム内で理由を明確にし、そして共有し、検討の余地がないかどうかを確認していくことが必要だと考えます。 レトロスペクティブを活用することは、プロジェクト初期に掲げたビジョンがプロジェクトが進むにあたり希薄になっていくことを防止し、プロジェクトにとって必要なことを継続して意識するというメリットもあります。
まとめ
この記事では、THE FRUGAL ARCHITECT を実際のシステム開発プロジェクトで活用するためにはどのようにすれば良いかを考え、記載しました。あくまでも私個人の経験をもとに書いていますので、みなさんの関わるシステムの種別、業界、立場によって考えに差があるかと思います。ぜひ、コミュニティなどで情報交換ができると嬉しいです。
明日の Japan AWS Ambassadors Advent Calendar 2023 8日目はシアトルで素敵な英語LTを行う実績を解除した山崎さんです。
re:Invent 2022 Amazon.com CTO Werner Vogels の Keynote を振り返る
本記事は「Japan AWS Ambassador Advent Calendar 2022」22日目の記事です。
AWS Ambassadorのアイレット株式会社 高橋 修一 さんからバトンを受け取りました。筋トレ好きな同志エンジニアからのバトンをしっかりと大切に次の方へ繋げたいと思います。
Amazon Web Services が開催する最大のラーニングカンファレンス re:Invent 2022 で発表された Amazon.com CTO Werner Vogels の Keynoteについて振り返りながら、私が感じたことを書いていきます。
re:InventのKeynoteを含むセッションはアーカイブ視聴が可能となっていますので、視聴を希望の方は下記のサイトにアクセスみてください。
Introduction
新型コロナウィルスによる海外渡航制限などの影響があり、3年ぶりにラスベガス現地でre:Inventに参加してきました。 現地参加で見聞きしたことは、体験したこと、オンライン参加の時と比較にならないほど多いと感じています。
これは現地参加することによって、re:Inventにどっぷり浸かれる環境を用意できることが強く影響しています。
オンライン参加の場合、ただでさえ時差のあるセッション配信に通常業務がある中で集中することは難しいこと、セッションの録画アーカイブ公開も見る時間を捻出することをせずに時が過ぎ去ってしまうということがあります。そして、2月、3月と過ぎる時間に比例し熱量も引いていってしまいます。
現地参加でre:Inventに集中できる時間を考えると、その差は想像に難しくないと思います。
今回は、re:Inventの中で最も楽しみにしているプログラムであるAmazon.com VP & CTO Werner Vogles の Keynote に現地参加でどっぷり浸かって感じたことを書いていきます。（アーカイブ視聴も繰り返した見たことも添えておきます）
Werner Vogles の Keynote にフォーカスする理由ですが、re:Capイベント、参加レポートなどアウトプットの多くは発表された新サービスにフォーカスしたものです。
Werner Vogles の Keynote で参加者に伝えられたメッセージは、見る人の立場によって受け止め方がさまざまであると考えています。受け止めた結果、その内容は登壇者が伝えたかった本質と異なるのかも知れませんし、その本質は受け止め方によって形を帰るものかも知れません。
そうであれば、私が受け止めた内容を共有し、フィードバックを得られるのであれば、私だけではなくAWSに関わるエンジニア全てにとって価値のあるアウトプットになるのではないかという考えに基づいたものです。
なお、Werner Vogles の Keynote はいくつかのパートに別れていましたが、この記事では イベント駆動型アーキテクチャ にフォーカスして書いていきます。
前置きが長くなりましたが、最後まで読んで頂ければ幸いです。
Asynchrony（非同期なシステムであることの必要性）
AWSのトレーニングを受けたり、Blackbeltnなどの動画をみたことがある人は良く耳にするキーワードが「非同期」です。 なぜ、非同期なシステムである必要があるのか？ 改めて例を添えて丁寧に説明しているシーンがとても新鮮でした。
要約された根本は下記のように受け止めています。
- 現実の世界は非同期
- 自分に何があっても地球は回り続ける、世界は動き続ける、宇宙は存在し続ける
- 利用する現実世界が非同期であれば、システムも非同期であるべき
- 自分に何があっても地球は回り続ける、世界は動き続ける、宇宙は存在し続ける
- Amazon S3 Design Principles(設計原則) にも Asynchrony が定義されている
Asynchrony と Parallel（並列性）
スループットとレイテンシーを両立させるには、並列処理に関する制御が必要だが、それらは同期処理では実現が困難。（ブロックポイントの存在で破綻する）
Synchroyな状況からスループットの向上とレイテンシーを抑えることを考えてみる。
同期処理：１つずつシーケンシャルに処理が進むため、スループットは１でレイテンシーは処理時間と処理連携に依存する
同期 + 並列処理：同期処理を並列で実行した場合、スループットは上がるかもしれないが、共有リソースなどブロックポイントが存在した場合は遅延がクリティカルになる可能性がある
並列処理だけでは十分ではなく、非同期かつ並列処理でなければ、スループットとレイテンシーを両立させるのは難しい。
Amazon S3 Design Principles では、非同期に加え、並列処理関わる原則も定義されている。Controlled concurrency と Controlled parallelismである。この２つはそのシステムのブロッキングポイントがどこにあるかを考えられていることを意味する。
Asynchrony 実例としてのオペレーティングシステム
OSは本質的には全てのデバイスを管理し、それらを抽象化している。デバイスは決められたタイミングでのみ動作するものではない、そのためOSとデバイスの間は、割り込み・つまりイベントドリブンに動作している。
ただ、元からOSは非同期であったのではない。ディスクへの書き込みなど処理を待たなければいけないものであった、つまり大きなレイテンシーが存在する状態だった。その状態から非同期なシステムに変わっていった。
それは非同期な現実世界で利用されるにあたり、非同期であることが求められているからである。（つまり人間は同期的に使うことの待ち時間にストレスをもつ）
Asynchrony と Decoupled systems(分散システム)
分散システムにおいて同期性は何を意味するか、それは密結合である。
上記の図では、ショッピングカートが後続の処理に密結合している。ショッピングカートの処理が失敗すると...システム全体が失敗となる。つまり、密結合なシステムは１つの処理の失敗がシステム全体の失敗を意味する。
重要なことは非同期であり疎結合であるということは、１つの処理の失敗がシステム全体の失敗を防ぐことだけではなく、それにより機能の追加、すなわちシステムの進化が容易になるということ。システム全体を変更することなく機能を追加できる恩恵を享受できる。
進化的アーキテクチャ（Evolutionary Architechture）
システムを開発する際、最終的な理想系に全て一気に開発できるものではない。（不確実な理想を求めすぎるが故に業務にマッチせず、エンハンスを意識してないため修正も難しいという悪夢のようなシーンを想像してしまった）
継続的なエンハンスがある前提として、小さなシステムから始めて、利用しながら理想的なシステムを作り上げていく。疎結合なシステムの大きなベネフィットは、機能の追加を容易にする進化的アーキテクチャであること。
（超巨大な分散システムの代表格でもある）Amazon S3は、進化的アーキテクチャであり、8つのマイクロサービスから現在は 235以上のマイクロサービスに進化している。その根本はシステムを停止することなく、他のサービスに影響を与えることなく、サービスを追加することができるから。
Appendix: Distributed Computing Manifesto
Amazon.com がアーキテクチャを進化させることができなかった事実にぶつかったとき、それらを解決するための考えをまとめた文書
なぜ、非同期で疎結合なシステムは進化的アーキテクチャなのか
- コンポーネントが独立しているため、機能の追加が容易
世界はイベント駆動である
現実世界は発生した事象（イベント）によって動作する大規模かつ非同期な世界である。（雨が降る、土に水が染み込む、植物が水を吸い込む など）
世界は非同期であり不確実、その不確実性に対処するために最善の方法は、事象（イベント）をトリガーとしたイベント駆動であること。
イベント駆動なシステムはグローバルにスケールするシステムも作ることができる。
DynamoDB グローバルテーブルは 10兆リクエスト/日、レイテンシは1桁ミリ秒をSQSをブローカーにしたイベント駆動型アーキテクチャで実現している。
イベント駆動型アーキテクチャは自動的に疎結合へとつながる
イベント駆動型アーキテクチャは、イベントブローカー/イベントバスを境界にコンポーネント間は独立して動作している。（その効果作用を最大限動作するためには、そのように作るものであるとも言える）
下記の２つの図はいずれもイベント駆動型アーキテクチャを示しているが、イベントブローカー/イベントバスを境界にキューを使った Point-to-point、ファンアウトによるPub/sub、ComsumerによるEventrseamingでコンポーネント間が連携している。
１つのことをうまくやらせる
ゴールの法則
“正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである”
最初から完全なシステムを構築する場合、それは単純なシステムはなく、進化的なシステムでもなくなる。複雑なシステムだからこそ、コンポーネント間が独立し、それぞれのコンポーネントは自分の仕事に集中すべきである。
Amazon の Two Pizza ルールは、１つのチームが１つのコンポーネントに集中し、全体像を意識する必要がないようにするもの。
コンポーネント間をつなぐもの、それがイベント。イベントは構成可能であり、イベントをつなぎ合わせることで大きなアプリケーションを構築できる。
それを体現しているのがUNIXであり、UNIX Pipeが（複数のコンポーネント間すなわちプログラムの入出力を繋ぐことを）とても簡単にしている。４０年、５０年経った現在も非常に協力が概念。
余談 re:Invent 2021 の Werner Vogels の Keynote では、AMが５億リクエスト/秒をさばく分散システムであることが説明された。この説明を受け、私は下記のメッセージを受け取った。
認証認可の鍵、トークン管理、そしてキャッシュなど、シンプルなコンポーネントがうまく繋がることでなりたっているシステムであること、すなわち「１つのことをうまくやらせる」UNIX哲学を実行しているサービスであることを暗に伝えているのだと理解していた。
JAWS-UG CHIBA re:Invent 2021 re:Cap with Werner Vogels's Keynote - Speaker Deck より
昨年に受け取ったメッセージから、今年 Amazon EventBridge Pipe がリリースされた時、UNIXの根幹の１つであるUNIX pipeをAWSがサービスとして提供したという事実に鳥肌がたった瞬間を今も鮮明に覚えている。
閑話休題。
イベント駆動型アーキテクチャによって実現するグローバルスケールなシステム
AWSリージョンは世界に３０、これにより顧客により近い環境でアプリケーションを構築できる。どうやってグローバルスケールで動作するアプリケーションを実際に構築できるのか。もっとも便利に、もっとも簡単に実現するもの、それがイベント駆動型アーキテクチャである。
AmazonはそれをDynamoDBでもそれを実現してきた。
- 1日10兆のリクエスト、レイテンシは1桁ミリ秒。このような規模をグローバルテーブルを含めて、実際にサービスとして展開している
- ローカルリージョンのDynamoDBに書き込むとグローバルテーブルでは自動的の他のリージョンにレプリケートする
- さらにマルチリージョンでマルチアクティブなDBを提供している
- アクティブ・アクティブアーキテクチャで同期性はない
- DynamoDBストリームとSQSがコーディネーターとなってレプリケーターとの非同期なイベント駆動型アーキテクチャを構成できる
宇宙（自然）は最も身近で最大なシステム
※ 宇宙を自然に置き換えた方が個人的に理解しやすかった
宇宙（自然）は私たちの周りに存在する最大のシステムである。宇宙（自然）は非常に壊れやすく、非常に高い耐障害性、弾力性、堅牢性をもっている。
とてもよくできた原理で出来上がっている。宇宙（自然）から原理から学びを得て、コンピューターシステムにそれを適用しない理由はない。
考察
なぜ様々な例を用いてキーノートでイベント駆動型を説明しているのか？
AWSにおける実例の他、ケン・トンプソン、デニス・リッチー、Martin Fowlerらを取り上げてイベント駆動型アーキテクチャは進化的アーキテクチャであることの説明を補強している。より説得性をもって参加者に伝えたいことであったのではないか。
イベント駆動型アーキテクチャは、AWS DevAx::connect の初回テーマとしても取り上げられていた。ワークショップもイベント駆動をテーマにしたものが多い。イベント駆動はこのキーノートで初めて触れられた技術ではない。
なぜ、re:Invent の Keynote で1時間超の時間をとってイベント駆動に触れたのか、いくつかの仮説を立ててみた。
・AWSが提供するプリミティブもイベント駆動での活用を期待するサービスが多いのか？ ・顧客からの相談の多くがイベント駆動型アーキテクチャで解決する課題が多いのではないか？
AWSの提供するサービスはプリミティブであり、それらをつなぐためにStep Functions や EventBridge というサービスが提供されエンハンスされている事実はあるが、いずれの仮説も実証が難しいものである。
Wernerが私たちに伝えたかったことは何か？
重要なことは、Werner Vogels が AWS の最重要イベントである re:Invent の Keynoteで 1時間超を使ってイベント駆動型アーキテクチャ の必要性を説いている事実、そして、私たちが多くのクラウドサービスの中から選択し利用しているAWSはそのサービスを稼働するためにイベント駆動型アーキテクチャを採用しているということである。
システムは自分たちの活動（ビジネス）に必要となり作っていくもの。不確実な世界では活動に求められる要件も変わってくる。 視点を変えると必要なことを実現するためのチャレンジが求められる。この課題とチャレンジはイノベーションの源泉ではないか？
この求められる進化を適用するチャレンジが行えるシステムは何なのか？その１つの答えがイベント駆動型アーキテクチャで構築されたシステムである。
Wernerは、イベント駆動型アーキテクチャが生まれた背景をre:Inventのキーノートで共有することにより、車輪の再発明をせずに、私たちもイノベーションを生み出すチャレンジができるように説いてくれたのだと受け止めた。
イベント駆動型アーキテクチャは万能ではないと理解しているが、これからシステムを構築する際には、意識するアーキテクチャとして頭に刻んでおこうと思う。
最後に
この記事がどなたかの役に立てば幸いです。そしてフィードバックなど、ぜひTwitterで @kinunori まで連絡してもらえると嬉しいです。
さて、明日は AWS Ambassadors を代表する画家 Big Bambooこと日本電気株式会社の大竹 孝昌さんです。お楽しみに！
コミュニティイベントでoViceを利用する時に気をつけたいことと、その教訓
２つの大規模コミュニティイベント（JAWS DAYS 2021、JAWS DAYS 2022 ）でoViceの設計に関わりました。それぞれのイベントにおいてチャレンジしたこと、気をつけていたこと、教訓を記録していきます。
JAWS DAYS 2021とは jawsdays2021.jaws-ug.jp
JAWS DAYS 2022とは jawsdays2022.jaws-ug.jp
oViceとは ovice.in
JAWS DAYS が oVice に求めたこと、チャレンジしたこと
oViceに求めたこと
JAWS DAYS 2021はオンラインイベント、JAWS DAYS 2022はオンライン・オフラインのハイブリッドイベントですが、oViceに求めたことは「オンライン参加者にセッション視聴以外のイベント体験をしてもらったり、参加者同士で交流してもらう」ためのスペースです。
これまでオンラインのコミュニティイベントは、セッション配信など企画側から参加者へ一方向のプログラムがメインでしたが、コミュニティイベントは参加者同士の情報交換もイベント参加のモチベーションになると考えています。これまでのオフラインイベントのような情報交換を行うことが難しく、なかなかうまく実現できていない状況でした。私が実行委員長をつとめたJAWS DAYS 2021では、この状況打破にチャレンジすることを目的に、オンラインに会場を作ることで、オフラインの時に会場の通路で参加者同士のコミュニケーションが行われていたような空間を再現することにチャレンジしました。
全国どこからでも参加できるオンラインのメリットを活かしながら、オンラインの課題を解決することで、JAWS DAYSの新しい形を目指して準備をしました。
つづいて、どのような準備をしてきたか記載していきます。
oVice参加者数の想定
それぞれのイベントで想定したoViceの参加者数は下記のとおりです。想定人数の差分が大きい理由は、イベント自体の参加者数、オンラインとハイブリッドイベントというイベント形式の違い、JAWS DAYS 2021の接続実績を元にした数値であることです。
oViceは１スペースあたりの最大同時接続数や推奨同時接続数が設定されています。oViceのサービス特性上、声が届く「範囲」があるため、狭いスペースに多くの人が接続された場合、最大同時接続数以内であっても混線してコミュニケーションが取れない状況(参加者が不快と感じる状況)になってしまう可能性があるため、推奨同時接続数も配慮が必要です。
用意したスペース数
それぞれのイベントで想定したoViceのスペース数は下記のとおりです。スペース数の差分もオンラインとハイブリッドイベントというイベント形式の違い、JAWS DAYS 2021の実績によるものです。
- JAWS DAYS 2021 想定 oVice参加者数
- 7スペース + 4つの予備スペース
- すべて 4800×2560px のサイズ
- JAWS DAYS 2022 想定 oVice参加者数
- 1スペース
- すべて 4800×2560px のサイズ
JAWS DAYS 2021では、最大同時接続数によりoViceへ参加したいが参加できないという人が出ないように、多くのスペースと予備スペースを用意していました。また、JAWS DAYS 2021では、英語セッションの英語音声配信をoVice上で行うというチャレンジも実施していました。(同時通訳は別途用意した配信サイトを通じて配信)
実施したプログラム
それぞれのイベントで、oViceを活用して実施したプログラムは下記のとおりです。
デザイン
oViceのスペースに来場された方にワクワクしてもらえるような仕組み作りの1つとして、デザインに相当なパワーをかけました。特にJAWS DAYS 2021は、スペース数も多くデザインだけで何十人日という工数をかけて用意しました。(ジョン兼マッツオ、Kohei Otaniに感謝です)
- JAWS DAYS 2021
- JAWS DAYS 2022
JAWS DAYS で oVice を利用するにあたり気をつけていたこと
その他、oViceを用意する際に意識したことが多くあります。その内容を紹介します。
来場してもらう動機付け
場所を用意しましたので、みなさん来てください、という案内では多くの方は参加するに至らないだろうと考え、「oViceに入ってみよう」と思ってもらえるような動機作りを行いました。AWSトリビアクイズ、キーワード集めゲームです。これらのゲームにクリアするとプレゼントをもらえる(抽選など)という特典を設けました。
操作が分からずに離脱してしまう人を防ぐ
避けたかったことの１つとして、oViceに来場したけど操作がわからなくて何をして良いのか分からず離脱してしまうことです。 参加者のほとんどが普段からoViceを使い慣れている方がであれば問題ありませんが、JAWS DAYS 2021/2022では「oViceを使い慣れている」という参加者背景は考えにくいため、初めてoViceを触る方を前提に準備を進めました。
- マニュアルを用意する
- JAWS DAYS 2021/2022専用のoVice操作マニュアルを用意
- ただし、全ての方がマニュアルを読み、理解してoViceに接続することは考えない。あくまでも困った時に読んでもらう程度を前提にする
- チュートリアルを用意する
- 接続した後、そのスペースを見ながら操作を覚えてもらうことがベストと考え、チュートリアル専用のスペースを用意
- 動線
- ヘルプスタッフを用意する
最大同時接続数による接続不可を発生させない
oViceにはプランごとの最大同時接続数(今回は1スペースあたり500名)があり、最大同時接続数を超えると新規接続を受け付けない状態になります。(最大同時接続数を下回るまでの間) 接続しようと思ってくれた方が、最大同時接続数による接続不可により接続できす、諦めてしまうことを避けたいと考えました。想定接続人数に対し、余裕のあるスペース数を用意するこどで、いずれかのスペースには接続できるような準備をしました。
混線しない広さ
oViceのサービス特性上、声が届く「範囲」があるため、狭いスペースに多くの人が接続された場合、最大同時接続数以内であっても混線してコミュニケーションが取れない状況(参加者が不快と感じる状況)になってしまう可能性があります。少人数のグループがスペース常に点在した場合に、混線して会話ができないということを防ぐため、最大サイズの「4800×2560px」を各スペースの基本サイズとしました。
コミュニケーションのきっかけとなるプログラムを用意する
スペースを用意するだけでは、コミュニケーションは発生しないと考え、Ask the Speaker、 Ask an Expert の2つのプログラムを用意しました。(JAWS DAYS 2022では、Ask the Speakerのみ) 専用のスペースとスピーカーの誘導や参加者の声かけをボランティアスタッフにお願いし、スピーカーの入れ替わりや対応をスムースにできる運用に気をつけました。
ワクワクしてもらう仕掛け
oViceに接続された参加者が、もっとこのスペースを探検してみたい、もっと違うスペースにも行ってみたいと思ってもらえるように、スペースのデザインに力を入れています。(デザインに関しては前述) また、街にテレビ中継が訪れた時のワクワク感を演出する狙いで、セッションでoViceの各スペースの様子を配信し、参加されている方が楽しみ、配信を見てくれた方がoViceに訪れてくれるような取り組みも行いました。
JAWS DAYS で oVice を利用することで得られた教訓
実際にoViceを利用してみて想定と異なることや、想定していなかったこともありました。そこから得られた教訓を紹介します。
オフライン会場の課題をオンラインで再現してしまった
オンラインの会場においてもオフラインの繋がりをもとにコミュニケーション形成が再現されます。当たり前ですが、オンラインだから他人同士がなんの前触れもなく、仲良くコミュニケーションを取れるということはあり得ません。オフライン、オンラインに関わらず、何かきっかけがありコミュニケーションが生まれます。
オンラインの会場でコミュニケーションが取られるきっかけの多くは「オフラインの繋がり」です。オフラインで元々知り合いだった人同士が輪を作り、コミュニケーションが行われます。オフライン会場の通路などで小規模な輪が複数できて、それぞれコミュニケーションが取られている状況、その光景がオンラインでも再現されました。
これまで会話することが出来ていなかった知り合い同士がオンライン会場で会話してもらえることはとても喜ばしいのですが、新しい参加者がその輪の中に加わることは、目に見えるきっかけが少ないオンライン会場ではハードルが高く、輪に積極的に加わるように周りの参加者に促してくれる人、新しい輪を作ることに協力してくれる人やスタッフなど、きっかけを作ることに協力してくれる人が必要と考えます。(偶然に期待してはいけない)
プログラムを用意するだけではなく「回す」人が必要
Ask the Speaker、Ask an Expertを開催し、専用のスペースとスピーカーの誘導や参加者の声かけをボランティアスタッフに協力いただき、スピーカーの入れ替わりや対応をスムースにできる運用を実現しました。しかし、人がまばらであったり、近づいても話しかけることなく離れていってしまう人が散見されました。理由は２つあると考えています。
1つ目は、Ask the Speaker、Ask an Expertのスピーカーやエキスパートが1人で質問者を待機する状況を作ってしまったことです。1人で飛び込み質問をするには勇気が必要だと思います。ちょっと質問してみようかなと考えた人も、マンツーマンになってしまう状況を避けて離れていってしまったのではないかと想像してます。帯同してサポートするスタッフを専任で用意するなどの準備ができていれば状況が変わったのではないかと反省しています。
2つ目は、Ask the Speaker、Ask the Speaker、Ask an Expertなどコミュニケーションを活発にすることで盛り上がりをみせるプログラムでは、司会進行のようなプログラムを「回す」人が必要だったという点です。絶え間なく質問が出続ける状況や、質問する方がそれぞれ順番を待って他の方に気を配りながら質問を行えるかというと、全てのケースでは当てはまりません。入れ替えだけではなく、プログラムの中身に関しても進行をスムースにする役割が必要だっと考えています。
ヘルプスタッフは最終手段
多くのヘルプスタッフに協力いただき、初心者向けチュートリアルスペース、コミュニケーションスペースにそれぞれ複数名のスタッフが滞在して、参加者をサポートいただきましたが、実際に参加者から問い合わせが発生することは極めて少なく、ヘルプスタッフの方には手持ち無沙汰な状態を作ってしまいました。中には積極的に参加者に声かけをしてくれたスタッフもいましたが、声をかけられると離れてしまう参加者が多く、最終的には積極的な声かけを控えたようです。おそらく、洋服屋の店員と来店客の心理と同じ状況が発生していたのだと想像しています。
ヘルプスタッフは最小人数で、いざとなった時に問題が発生したところに集合できるようにし、基本的にはスタッフに頼らない案内の仕組みを用意することが重要だと思います。(協力してくれたスタッフの方が不完全燃焼にならないようにするためにも)
滞在し続けてもらうプログラム、コンテンツ
「来場してゲームが終わり、その後に特に何もすることがないで退場してしまった」このようなアンケートがありました。oViceに来場する動機づけとして、AWSトリビアクイズ、キーワード探しゲームを用意しましたが、来場された方がそのまま滞在し続ける仕組み作りが不足していたのだと思います。
JAWS DAYS 2022では、パブリックビューイングを併設することにより、多くの方とセッションを同時に見る雰囲気を味わってもらうプログラムや、サテライト会場の様子をライブ配信するプログラムを用意し、来場者が継続して楽しめる工夫を取り入れました。
スペースは多く・広くしすぎない
JAWS DAYS 2021 では、「最大同時接続数による接続不可を発生させない」、「線しない広さ」を意識し、7スペース + 4つの予備スペース(すべて4800×2560px のサイズ)を用意しました。実際にはスペースの数が多く、来場された参加者がまばらになり、スペースによっては閑散としてるように見えてしまうところもありました。
JAWS DAYS 2022では、この反省を活かし、基本的に2スペースで運用、接続数が多くなった場合はスペースを追加するという対応に切り替えました。結果として賑わっているが、混線するような状況にはならない、とても良いバランスになっていたのではないかと思います。
チャットに頼らない
oViceは、メインのコミュニケーション手段は音声を前提に設計されているサービスです。チャット機能もありますが、音声のコミュニケーションを補助するための機能として捉えることをおすすめします。理由は、(特にoViceを初体験の参加者が)チャットに気づきにくいためです。
例えば、「イベントに関する案内をチャットで周知する」のではなく、「メガフォン機能を使って音声で周知し、あわせてチャットでも周知する」という形でオペレーションを組み立てておくことが大切です。
スペース間の移動は分かりやすく、シンプルに
複数のスペースを用意した場合、スペース間の移動はわかりやすく、シンプルに設計し、スペース間の移動方法が分からずに離脱してしまう参加者が発生しないようにする必要があります。 「〜〜スペースの移動はここをクリックから」と書いたオブジェクトを用意し、オブジェクトにスペースのURLをリンクし、オブジェクトをクリックすることで移動できるような仕組みを用意すると良いでしょう。
また、oViceには各スペースをビルのように階層化する機能もありますが、慣れていない人には気づいてもらえない(マニュアルを見て理解してもらわなければいけない)可能性があるため、オブジェクトを用意することと併用することがオススメです。
デザインは大事
デザインにこだわりましたが、パッとみてワクワクするようなデザインを用意することはとても重要で、力を入れる点として間違っていなかったと感じています。 oViceではあらかじめ用意されているテンプレートもありますが、イベントの特徴を感じてもらえるようなデザインを作成した方が良いでしょう。
まとめ
イベントでoViceを利用する際に気をつけたいことや、実際にチャレンジした結果の教訓をまとめてみました。 コミュニティを運営している方、コミュニティイベントでoViceの利用を考えている方、コミュニティイベントでコミュニケーションツールの利用を考えている方のお役に立てれば幸いです。
