イベントストーミングの概要

イベントストーミングとは？

イベントストーミング(以下では、ESと略)は、
複雑なビジネスドメイン（業務領域）を素早く、かつ深く理解するためのコラボレーション・ワークショップの手法です。

特に、ドメイン駆動設計（DDD）やマイクロサービスアーキテクチャのコンテキストで強力なツールとして利用されます。

一言でいうと、

ビジネスで実際に何が起きているか？（イベント）という真実を時系列に並べることで、システムが本当に扱うべき問題領域を可視化

する手法です。

開発者と、その業務に精通した専門家（ドメインエキスパート）が一堂に会し、大きな模造紙やホワイトボードに付箋を貼りながら進めるのが特徴です。

なぜイベントストーミングが有効なのか？

共通理解の醸成

開発者とビジネスサイドの間に存在する「言葉の壁」や認識のズレを解消し、チーム全体でビジネスプロセスに対する共通の理解を築くことができます。

開発者が業務の全体像を素早く理解することって、アーキテクチャを決定する際にも
マジで重要ですもんね。

ドメインエキスパートに昇華できる

たとえ業務全体像を理解したドメインエキスパートがいなくても、
これを実践することによって、徐々に自分たち自身でドメインエキスパートになることができます。

ドメイン知識の発見

普段は語られない暗黙のルールや、見過ごされがちな業務の流れが明らかになります。
（この業務の流れの見落としって、めっちゃ怖いんですよね。
後で気づいて、大幅な手戻り、、、、、メテオフォール級です💦）
ドメインエキスパート自身も、イベントを並べる過程で新たな気づきを得ることがあります。

要求仕様の具体化

「〇〇管理システム」といった超曖昧な要求や命名ではなく、
「注文が確定された」「商品が発送された」といった具体的なイベント（事実） をベースに議論するため、本当に必要な機能が明確になります。
それだけでなく、システム境界含む、コンテキスト境界の定義とか、
その境界への命名も行いやすくなります。

設計へのスムーズな連携

ワークショップの結果は、
マイクロサービスの境界（どこでサービスを分割すべきか）や、
モジュラーモノリスの境界（どこが強い整合性の集約の範囲か）
といった、システムの中心となる概念の発見に直結し、具体的なソフトウェア設計の土台となります。

イベント駆動やイベントソーシングと相性が良き

イベントストーミングで、
どんなイベントがあり、どこで分割すべきか を考えたら、それをもとにして、イベント駆動やイベントソーシングで実装しやすくなります。

イベントストーミングでビジネスを分析し、
その結果をイベント駆動（アーキテクチャ）という柔軟な連携スタイルで、
イベントソーシング（データの状態変化のすべての永続化）を用いて実装する

という流れで繋がります。

ビジネスロジック飲みにしか使えないわけではない

メインの関心事であるビジネスロジック部分で語られがちですが、
決してその領域にしか使えない手法ではないです。

セキュリティログなどのイベントの流れという、セキュリティ文脈でも使えます。
これはわたしが過去にいたセキュリティカオスの業務を考える案件で証明済です。

ESと従来のモデリング手法の違い

従来のユースケース駆動のモデリング手法では、
どちらかというと、１つの論理的なコンテキスト境界内部の概念モデリングに特化しています。

対して、イベントストーミング手法では、
１つの論理的なコンテキスト境界内部の詳細な概念は見ないことにして、
異なるコンテキスト境界の文脈同士の連携という、ビジネスプロセス全体に着目したモデリング手法です。

そのため、どちらか一方をやればそれでいいってことではないです。

抽象マクロをESで行い、１つのコンテキスト内部という具体は、従来のモデリング手法を。

ようは、ミクロな範囲とマクロな範囲、それぞれに適したモデリング手法って違い

前提の境界位置を常に見張る

そうやって行きながら、具体での概念モデリングの結果と、ESの抽象の成果物との一貫性を常に見張ってください。
常にモデルという成果物を通して見張っていれば、
「あれ？　今回の仕様変更で微妙に境界範囲が変わったくさいぞ」
という、コンテキスト境界範囲への不吉な臭いにもすぐに反応しやすくなります。

ツールなどで支援してもらうことも重要ではありますが、
私個人としては、この継続モデリングで定性的に「におうぞ」という感性を養うことの方が重要かなって思ってます。

どんな場面でESを行うべきか？　

単刀直入に言うと、モジュラーモノリスのように論理境界で分割することが求められる
くらいまでビジネスが大きくないうちにESをやっても、大した恩恵はないです。

ESの効果は、以下のような順で効果が増大します。

モジュラーモノリスが求められるビジネス＜＜
マイクロサービスが求められるビジネス＜＜＜
システムオブシステムズが求められるようなビジネス

システムオブシステムズの説明

ここで、システムオブシステムズ というワードを出しましたが、
凄く雑に言うと、異なるそれぞれ独立して動くシステムを複数連携させて業務を成立させるようなものです。

マイクロサービスアーキテクチャに似ていますが、より独立して運用されるため、
マイクロサービスアーキテクチャ以上にやっかいなものです。

最初から連携することが前提で、徐々に組織の拡大に合わせて膨らんでいく過程で、
分裂して全体をつなぐという思想ですが、
システムオブシステムズの場合には、もともと独立していたものを後から連携する
という、マイクロサービスとは少し違ったパラダイムです。

よく見かけるのは、大きめの組織の部署ごとに個別最適に構築されたシステムとか、
または企業の金を超えたサプライチェーンを構成する要素として登場します。

どんな場面ではESを使わない方が良いか？

ビジネスの規模によっては、イベントストーミングが不要なこともあります。
そんな時に無理にやるだけコストの無駄です。物は試しの学習目的ならいいですが。

基本イベントストーミングって、文脈を超えた協同モデリングのため、以下のような面倒なことが起きます。

・モデリングに避ける時間やお金の制約
・誰をいつ参加させるべきか？など含む、利害関係者のスケジュール調整コスト
・それに伴う、その人々の任されたタスクの遅延リスク
・そのリスクの先にいる間接的利害関係者への理解促進活動が必要になる
・従来のモデリングに慣れた文化の人からの反発
・社内業務オペレーション全体を把握してる神的なドメインエキスパートなんていない。そんな人はハッキリ言って幻といってもいい。
・モデリング当日のファシリテーションが難しい(書記やりながらファシリとか死ぬわ！！)

ケース① -社内理解を得られない場合-

受ける恩恵はめっちゃ大きいものの、やるまでが本当に大変なんですね💦
まあ、そこは組織の文化にもよりますが。

上記の社内理解が得られる前には、イベントストーミングを無理に進めるよりも、
従来のモデリング手法では、そろそろ太刀打ちできないかも💦というシーンを演出してあげた方がいいかもです。
その時に「実はこんなものがあるんだけどやってみます？」的にもっていかないと、
「は？新しい手法？学習コストかかるわ(# ﾟДﾟ)」と反発を食らいかねない、、、。

こういう反発を食らわないようなステークホルダーマネジメントスキルも必要だったりします。

従来のモデリングが好きでESに抵抗感を出す人や、自分の所の業務だけを見ていたい
っていう人々には、無理にESを推奨せずに、各コンテキスト境界内部のモデリングに集中していただきましょう。
具体の範囲のモデリングという細部を得意とする人々にしか正確にできないことを演出してあげましょう。

ケース② -ビジネスがまだ軌道に乗っていない-

以下のプロダクトライフサイクル曲線を見てください。

スタートアップビジネスなどが該当する導入期や成長期序盤では、
無理にESワークショップを行う価値は高くないです。
そもそもESをやるだけ、ビジネスが大きくなっていないのだから。
お金の無駄になってしまうことが多いでしょう。

だって、どうせその頃なんて、境界の位置が仕様変更でごろごろ変わって安定していないフェーズ。
モデリングしたところで、明日にはその成果物が変わってしまってるってなったら、
呼び出されて巻き込まれてる人からしたら「ざけんな(# ﾟДﾟ)」ってなってしまうもの💦

よって、負債が徐々に溜まってきて、「境界でモジュール分割したいな」
「モジュラーモノリスにしたいな」となってきてから徐々にトライしましょう。

プチアンチパターン

間違っても、分散化して、認知できないほど負債がたまってから、
やっとこさESワークショップを開始するなんてやめましょ？

矯正はしないけども、その頃になってから行ったら、
モジュラーモノリス時からESワークショップを継続的にやってた時と比較して、
大幅にコストがかかることが自明なので💦

ESワークショップのフレームワーク

世の中には、いろんなイベントストーミング手法がある。
どれが正解ということはないが、何も体験したことがないのなら、
以下の「ドメイン駆動を始めよう」の書籍がオススメです。

ただ、別にこの本の通りに実践しなくても大丈夫ですよ。
あくまでも観点の抜け漏れ予防のために、参考にするくらいでもいいと思います。

また、ファシリテーションも非常にコツが必要なんで、
以下のような書籍でそのコツを吸収しつつ、勉強会などで積極的にファシリする演習を積みましょう。

その際には、論点を常に握っておかないといけないです。
どの抽象度の論点に戻るべきなのか？
「あ、今出てきたイベントは、抽象度が詳細になったな」といったことを頭の中で
常に描きながら、参加者をファシリしないといけません。

これ以外にも必要な思考やらはありますが、今回はここまでにしておきましょう。

私のおすすめのESワークのやり方

以下では、わたしが実際に案件の中で所々で、イベントストーミング手法を使ってみて、
得られた結果や実際の普段の日常をモデリングする中で、
「この方法が自分の中で腑に落ちた」というものをご紹介します。

ですが、長くなるので、その記事はまた次回。(@^^)/~~~