フレームワーク活用ガイドひとことで言うと#
イベントストーミングは、ビジネスプロセスで起きる「出来事（イベント）」を付箋で時系列に並べ、関係者全員でシステムの全体像を可視化するワークショップ手法で、技術者とビジネス側の共通理解をつくるために使います。
用語の定義#
押さえておきたい用語
- ドメインイベント（Domain Event）：ビジネス上で発生した重要な出来事。オレンジ色の付箋に過去形で記述する（例：「注文が確定された」）
- コマンド（Command）：イベントを引き起こすアクション。青色の付箋に記述する（例：「注文を確定する」）
- アグリゲート（Aggregate）：コマンドを受けてイベントを発生させるエンティティ。黄色の付箋で表す
- ホットスポット（Hotspot）：参加者間で意見が割れる箇所や不明点。赤い付箋でマークし、後で重点的に議論する
- ポリシー（Policy）：あるイベントが発生したときに自動的に次のコマンドを実行するビジネスルール。紫色の付箋で表す
全体像#
ドメインイベントを洗い出す
過去形で付箋に書き出す
→過去形で付箋に書き出す
時系列に並べる
壁一面に左→右で配置
→壁一面に左→右で配置
コマンド・アクターを追加
因果関係を構造化
→因果関係を構造化
ホットスポットを議論
境界とルールを明確化
境界とルールを明確化
こんな悩みに効く#
- エンジニアとビジネス側で業務フローの認識がずれていて、手戻りが多発する
- 複雑なドメインの全体像を誰も把握しておらず、部分最適の実装が続いている
- 要件定義書が分厚いのに、肝心な業務ルールが漏れている
基本の使い方#
ドメインイベントを書き出す
参加者全員がオレンジ色の付箋に「ビジネス上で起きた出来事」を過去形で書きます。「注文が確定された」「請求書が発行された」「在庫が引き当てられた」のように、システムの状態が変わった瞬間を捉えます。この段階では順番や正しさを気にせず、とにかく量を出します。
時系列に並べて整理する
書き出したイベントを壁一面に左から右へ時系列順に並べます。重複を統合し、抜けているイベントを追加します。この過程で「この後に何が起きる？」「この前に必要なことは？」という対話が自然に生まれ、業務フローの全体像が見えてきます。
コマンド・アクター・ポリシーを追加する
各イベントの原因（コマンド）を青色付箋で、それを実行する人（アクター）を小さな人型の付箋で追加します。さらに「Aが起きたら自動的にBを実行する」というポリシー（紫色付箋）を特定します。この構造化により、因果関係とビジネスルールが明確になります。
ホットスポットを議論し境界を定める
参加者間で意見が割れた箇所に赤い付箋（ホットスポット）を貼り、集中的に議論します。ホットスポットはドメインの複雑さが集中する場所であり、ここを解決することでシステム設計の品質が大きく向上します。最後にイベントのまとまりからバウンデッドコンテキスト（システムの境界）を特定します。
具体例#
ECサイトリニューアルの要件定義
年商50億円のアパレルECサイトのリニューアルプロジェクトで、旧システムの業務フローを把握するためにイベントストーミングを実施。エンジニア5名、MD（マーチャンダイザー）3名、CS（カスタマーサポート）2名が参加し、4時間のワークショップで180枚のイベント付箋を作成。ホットスポットとして「返品時の在庫戻し入れタイミング」に3つの認識違いが発覚し、これが旧システムの在庫不整合バグの原因だったことが判明。従来の要件定義書では見つからなかった業務ルールを12件追加で特定でき、リニューアル後の在庫不整合は月15件→0件になった。
SaaSプロダクトの請求ドメイン設計
BtoB SaaS企業が従量課金モデルを導入するにあたり、請求ドメインの設計にイベントストーミングを活用。プロダクトマネージャー、エンジニア、経理の8名で3時間のセッションを実施した。「使用量が記録された」→「月次集計が実行された」→「請求書が生成された」→「決済が完了した」の基本フローに加え、「プラン変更が適用された」「日割り計算が発生した」「クレジットが付与された」など47件のイベントを洗い出した。ホットスポットは「プラン変更のタイミングと請求反映の関係」で、ここにポリシーを4つ定義したことで、開発中の仕様確認が激減。見積もりの**30%だった仕様確認コストが8%**に圧縮された。
物流スタートアップのマイクロサービス分割
物流マッチングプラットフォームが、モノリスからマイクロサービスへの移行計画にイベントストーミングを利用。CTO、テックリード3名、ドメインエキスパート2名で2日間のワークショップを実施し、230枚のイベントを整理。イベントの密度と依存関係から「配車」「追跡」「請求」「ドライバー管理」の4つのバウンデッドコンテキストを特定。当初は「配車と追跡を1つのサービスに」という案があったが、イベントストーミングの結果、両者の間のイベント連携が3件しかなく独立性が高いことが判明し、分離を決定。移行後のサービス間結合度が低く保たれ、独立デプロイによるリリース頻度が週1回→週4回に向上した。
やりがちな失敗パターン#
| 失敗 | 原因 | 対策 |
|---|---|---|
| エンジニアだけで実施する | ビジネスルールを知る人が不在で、技術的な構造だけが出来上がる | ドメインエキスパート（業務担当者）を必ず参加させる |
| 最初から正しい順序で並べようとする | 完璧主義で付箋が出てこず、ワークショップが停滞する | まず量を出し、後から並べ替える。間違いは歓迎する |
| ホットスポットを放置する | 議論が紛糾するのを避けて、赤い付箋を貼ったまま次に進む | ホットスポットこそ設計の核心。時間を区切って集中討議する |
| 成果物をデジタル化せずに終わる | ワークショップの壁一面の付箋が写真だけで残り、活用されない | 当日中にMiroやFigJamに転記し、チーム全体で参照可能にする |
まとめ#
イベントストーミングが強力なのは、「技術者の言葉」でも「ビジネスの言葉」でもない「出来事の言葉」で全員が対話できる点にあります。「注文が確定された」は誰にでも理解できるため、職種を超えた共通言語として機能します。付箋と壁だけで始められる手軽さも魅力で、複雑なドメインを全員が理解するための最短経路として多くのプロダクトチームに採用されています。