イベントストーミングについてまとめてみた①
1：イベントストーミングの概要
– イベントストーミングとは？
イベントストーミング (以下では、ESと略) は、複雑なビジネスドメイン（業務領域）を素早く、かつ深く理解するためのコラボレーション・ワークショップの手法です。
特に、マイクロサービスアーキテクチャ含む分散アーキテクチャのコンテキストで強力なツールとして利用されます。
一言でいうと、
ℹ️ ビジネスで実際に何が起きているか？（イベント）という真実を時系列に並べることで、システムが本当に扱うべき問題領域を可視化
する手法です。
開発者と、その業務に精通した専門家（ドメインエキスパート）が一堂に会し、大きな模造紙やホワイトボードに付箋を貼りながら進めるのが特徴です。
– なぜイベントストーミングが有効なのか？
共通理解の醸成
開発者とビジネスサイドの間に存在する「言葉の壁」（※これが認知の歪みを生み出し、サイロに繋がります）や認識のズレを解消し、チーム全体でビジネスプロセスに対する共通の理解を築くことができます。
（開発者が業務の全体像を素早く、共通理解することって、アーキテクチャを決定する際にも非常に重要です。）
ドメインエキスパートに昇華できる
かの有名な、エリックエヴァンス氏のドメイン駆動設計に登場する、
業務を深く理解した【ドメインエキスパート】という人材なんて、なかなか現実にはいません。（少なくとも私の過去にアサインされた案件ではいませんでした。）
たとえ業務全体像を理解したドメインエキスパートがいなくても、このイベントストーミングを周辺関係者たちと地道に実践することによって、徐々に自分たち自身でドメインエキスパートになること。
この方が、最早現代においては重要です。
ドメイン知識の発見
普段は語られない暗黙のルールや、見過ごされがちな業務の流れが明らかになります。ドメインエキスパート自身も、イベントを並べる過程で新たな気づきを得ることがあります。
（このような業務の流れの見落としは、非常にハイリスクです。 だいぶ後工程で気づいて、大幅な手戻り、、、という実にメテオフォール級です💦）
要求仕様の具体化
「顧客管理システム」といった超曖昧な要求や命名ではなく、
あらかじめユビキタス言語として概念名を定義された、【商品(モノ名)】【発送(コト名)】
などを用いて、「商品注文が確定された」「商品が発送された」といった具体的な
イベント（事実） をベースに議論するため、本当に必要な機能が明確になります。
それだけでなく、システム境界含む、様々な粒度のコンテキスト境界の定義、その境界名の命名（例：サービス名やシステム名の命名）も行いやすくなります。
設計へのスムーズな連携
ワークショップの結果は、マイクロサービスの境界（どこでサービスを分割すべきか）や、モジュラーモノリスの境界（どこが強い整合性の集約の範囲かを表す境界）といった、システムの中心となる概念の発見に直結し、具体的なソフトウェア設計の土台となります。
イベント駆動やイベントソーシングと非常に相性が良い
イベントストーミングで「どんなイベントがあり、どこで分割すべきか」を考えたら、それをもとにして、イベント駆動やイベントソーシングで実装しやすくなります。
ℹ️ イベントストーミングでビジネスを分析し、その結果をイベント駆動（アーキテクチャ）という柔軟な連携スタイルでイベントソーシング（データの状態変化のすべての永続化）を用いて実装する
という流れに繋がります。
ビジネスロジック部分以外にも使えるモデリング手法
メインの関心事であるビジネスロジック部分で語られがちですが、決してその領域にしか使えない手法ではないです。
セキュリティログなどのイベントの流れという、セキュリティ文脈でも使えます。
また、インシデント対応中の復旧シナリオとしても、使うことができます。
ちなみにこれは、わたしが過去にいたセキュリティカオスの業務を考える案件で証明済です。
– ESと従来のモデリング手法の違い
従来のユースケース駆動のモデリング手法では、どちらかというと、１つの論理的なコンテキスト境界内部の概念モデリングや、個々のマイクロサービス内部のモデリングに特化しています。
対して、イベントストーミング手法では、１つの論理的なコンテキスト境界内部の詳細な概念は見ないことにして（※情報隠ぺいのため）、異なるコンテキスト境界の文脈同士の連携という、ビジネスプロセス全体に着目したモデリング手法です。
そのため、「どちらか一方をやればそれで十分」ということではないです。
抽象マクロをESで行い、１つのサービスコンテキスト内部という具体な領域は、従来のモデリング手法を、という風にハイブリッドで使い分けましょう。
ℹ️ ようは、ミクロとマクロな範囲、それぞれに適したモデリング手法は違うということです。
※ただし、同期通信であり、かつ結果整合性の連携部分に関しては、注意しましょう。 まだ、「どのようなイベントで連携すべきか？」が定まり切っていないので、基本は一緒に協同モデリングしつつも、「非同期に進化させたらどんなイベントが必要だろうね」ということは、常に議論に出しながらモデリングしましょう。
– 前提の境界位置を常に見張る
具体での概念モデリングの結果と、ESの抽象の成果物との一貫性を常に見張ってください。
常にモデルという成果物を通して見張っていれば、「あれ？ 今回の仕様変更で微妙に境界範囲が変わったくさいぞ」という、コンテキスト境界範囲への不吉な臭いにもすぐに反応しやすくなります。
逆にこのミクロとマクロの一貫性を担保しないと、この不吉な臭いに気づけないです。
ツールなどで支援してもらうことも重要ではありますが、私個人としては、この継続モデリングで定性的に「におうぞ」という感性を養うことの方が重要であると断言します。
2：どんな場面でESを行うべきか？
モジュラーモノリスのように論理境界で分割することが求められるくらいまでビジネスが成長していないうちにESをやっても、大した恩恵はないです。その頃は、従来のICONIXのようなモデリングのみで十分です。
ESの効果は、以下のような順で増大します。
ℹ️ モジュラーモノリスが求められるビジネス ＜＜ マイクロサービスが求められるビジネス ＜＜＜ システムオブシステムズが求められるようなビジネス
– システムオブシステムズの説明
ここで、システムオブシステムズというワードを出しましたが、凄く雑に言うと、それぞれ独立して動く異なるシステムを複数連携させて業務を成立させるようなものです。
マイクロサービスでは、下図のように各サービス量子は、仮に非同期通信であっても、物理的に同じインフラ基盤であるということはあります。
このような状態は、インフラチーム内部のコミュニケーションパスは、図の点線部分のように疎結合な状態になってはいるものの、物理的には同じ１つのインフラであるため、まだシステムオブシステムズではまだありません。
しかしながら、ここからさらに、耐障害性などを高めたいなどの要求により、インフラ基盤まで物理的に分割したいというフェーズが来ると、下図のようになります。
⚠️ マイクロサービスアーキテクチャに似ていますが、より独立して運用されるため、
マイクロサービスアーキテクチャ以上にやっかいなものです。
最初から連携することが前提で、徐々に組織の拡大に合わせて膨らんでいく過程で、分裂して全体をつなぐという思想ですが、システムオブシステムズの場合には、もともと独立していたものを後から連携するという、マイクロサービスとは少し違ったパラダイムです。
よく見かけるのは、大きめの組織の部署ごとに個別最適に構築されたシステムとか、または企業の枠を超えたサプライチェーンを構成する要素として登場します。
3：どんな場面ではESを使わない方が良いか？
ビジネスの規模によっては、イベントストーミングが不要なこともあります。そんな時に無理にやるだけコストの無駄です。物は試しの学習目的ならいいですが。
ESは、基本的にサービスコンテキスト境界の文脈を超えた協同モデリング手法のため、以下のような面倒なことが起きます。
⚠️
- モデリングに割ける時間やお金の制約
- 誰をいつ参加させるべきか？など含む、利害関係者のスケジュール調整コスト
- それに伴う、その人々の任されたタスクの遅延リスク
- そのリスクの先にいる間接的利害関係者への理解促進活動が必要になる
- 従来のモデリングに慣れた文化の人からの反発
- 社内業務オペレーション全体を把握してる神的なドメインエキスパートなんていない。そんな人はハッキリ言って幻想です。
- モデリング当日のファシリテーションが従来モデリングよりも難しい（油断すると、詳細に入り込みすぎてしまうなど、具体と抽象のコントロールが難しい）
ケース① – 社内理解を得られない場合 –
受ける恩恵は非常に大きいものの、やるまでが本当に大変です💦 そこは組織の文化にもよります。
上記の社内理解が得られる前には、イベントストーミングを無理に進めるよりも、
従来のモデリング手法ではそろそろ太刀打ちできないかも💦という演出をしてあげた方がいいかもです。その時に「実はこんなものがあるんだけどやってみます？」的にもっていかないと、
「は？新しい手法？学習コストかかるから嫌だな」と反発を食らいかねない、、、。
こういう反発を食らわないようなステークホルダーマネジメントスキルも必要だったりします。
従来のモデリングが好きでESに抵抗感を出す人や、自分の所の業務だけを見ていたいっていう人々には、無理にESを推奨せずに、各コンテキスト境界内部のモデリングに集中していただきましょう。
具体の範囲のモデリングという細部を得意とする人々にしか正確にできないことを演出してあげましょう。
ケース② – ビジネスがまだ軌道に乗っていない –
以下のプロダクトライフサイクル曲線を見てください。
スタートアップビジネスなどが該当する導入期や成長期序盤では、無理にESワークショップを行う価値は高くないです。そもそもESをやるだけ、ビジネスが大きくなっていないのだから。お金の無駄になってしまうことが多いでしょう。
だって、どうせその頃なんて、境界の位置が仕様変更でごろごろ変わって安定していないフェーズ。モデリングしたところで、明日にはその成果物が変わってしまってるってなったら、呼び出されて巻き込まれてる人からしたら「ざけんな(# ﾟДﾟ)」ってなってしまうもの💦
よって、負債が徐々に溜まってきて、「境界でモジュール分割したいな」「モジュラーモノリスにしたいな」となってきてから徐々にトライしましょう。
ケース③ – プチアンチパターン –
間違っても、分散化して、認知できないほど負債がたまってから、やっとこさESワークショップを開始するなんてやめましょう。
強制はしないけども、その頃になってからESを行った場合、モジュラーモノリス時からESワークショップを継続的にやってた時と比較して、大幅にコストがかかることは自明です💦
比較するとしたら、大幅な手戻りコストやコミュニケーションコスト、障害の起きやすさ、
障害が起きてからの復旧の素早さ、一度起きたインシデントがまた繰り返される率、など
あらゆる面で非常に脆い組織の完成です。
4：ESワークショップのフレームワーク
ESといっても、細かく見れば世の中には、いろんなES手法があります。
どれが正解ということはないが、何も体験したことがないのなら、以下の「ドメイン駆動設計を始めよう」の書籍がオススメです。
⚠️ ただ、別にこの本の通りに実践しなくても大丈夫です。あくまでも観点の抜け漏れ予防のために、参考にするくらいでもいいと思います。一番いいなと思ったのは、ICONIX手法の良い所と、ESを良しなに組み合わせた、モノタロウさんでやられているES手法です。
また、ファシリテーションも非常にコツが必要なため、以下のような書籍でそのコツを吸収しつつ、社内勉強会やミーティングなどで積極的にファシリテーションをする練習を積みましょう。
その際には、論点を常に握っておかないといけないです。
どの抽象度の論点に戻るべきなのか？ コンテキストは多面的に見ても揃っていると言えるか？
モデラーは「あ、今出てきたイベントは、抽象度が急に詳細になったな」といったことを頭の中で常に描きながら、ワークショップ参加者をファシリしないといけません。
その際に有効なのは、以下の書籍の思考です。設計の基礎にもなりますので、必読です。
これ以外にも必要な思考やらはありますが、今回はここまでにしておきましょう。