フレームワーク活用ガイドひとことで言うと#
システムの振る舞いを時系列のイベントとして並べ、「誰が」「何をして」「何が起き」「何が見えるか」を1枚の図で設計する手法。エンジニアだけでなくビジネス側も一緒に参加でき、システムの全体像を全員が同じ解像度で共有できる。Adam Dymitrukが2019年に提唱した。
押さえておきたい用語#
- イベント（Event）
- システム内で起きた事実の記録。「注文が作成された」「支払いが完了した」のように過去形で表現する。イベントは不変（イミュータブル）で、後から変更しない。
- コマンド（Command）
- ユーザーやシステムがイベントを発生させるために行うアクション（意図）。「注文する」「支払う」のように命令形で表現する。
- リードモデル（Read Model / View）
- イベントから組み立てた表示用のデータ。UIの画面やAPIレスポンスに対応する。「注文一覧画面」「ダッシュボード」など。
- スイムレーン（Swimlane）
- イベントモデル図の横方向の行。ユーザー操作・コマンド・イベント・リードモデルをそれぞれ別のレーンに配置する。
- ブループリントタイムライン（Blueprint Timeline）
- 全イベントを左から右に時系列で並べた図全体のこと。システムの全ライフサイクルを1枚で俯瞰できる。
イベントモデリングの全体像#
こんな悩みに効く#
- 要件定義書はあるが、エンジニアとビジネス側でシステムの理解が食い違う
- マイクロサービスの分割境界がわからない
- イベント駆動アーキテクチャを導入したいが、どう設計すればいいかわからない
- ウォーターフォール的な要件定義で見落としが多く、開発後半で手戻りが頻発する
基本の使い方#
システムで発生するすべてのイベントをオレンジ色の付箋に書き、時系列で左から右に並べる。
- イベントは過去形で書く（「注文が作成された」「在庫が減った」）
- 最初は順番を気にせずブレインストーミングで出し、後から並べ替える
- ビジネス側のメンバーにも参加してもらう（「何が起きるか」はビジネスが一番知っている）
- この段階では網羅性より発散を重視する。漏れは後のステップで補完できる
各イベントを引き起こす「アクション（コマンド）」と「画面（UI）」を追加する。
- コマンド（青い付箋）: 「注文する」「支払う」のように命令形で書く
- UI（白い付箋）: コマンドが実行される画面やフォームをスケッチまたはキャプション
- コマンドとイベントの間にはビジネスルールがある（「在庫があれば注文が作成される」）
- 自動化されたプロセス（バッチ、スケジューラー）もコマンドとして記載する
イベントから組み立てられる「表示データ」を定義する。
- 各イベントの下にリードモデル（緑の付箋）を配置
- 「このイベントが発生した結果、ユーザーに何が見えるか」を考える
- ダッシュボード、一覧画面、詳細画面、通知メールなどが該当
- リードモデルの設計はCQRS（コマンドクエリ責務分離）の「クエリ側」に直結する
タイムラインを縦に切り、イテレーション単位の開発タスクに変換する。
- 1スライス = 「コマンド → イベント → リードモデル」の1セット
- 各スライスが独立してデプロイ・テスト可能であることを確認
- 依存関係の少ないスライスから着手し、段階的にシステムを組み上げる
- スライスごとに受入テスト条件を定義する（「このイベントが発生したら、この画面にこう表示される」）
具体例#
美容室チェーン（30店舗）向けの予約管理システム開発プロジェクト。従来のウォーターフォールで要件定義書を作成した前回のプロジェクトでは、開発後半に「想定していなかった業務フロー」が8件見つかり、2か月の遅延が発生していた。
ワークショップの実施: 参加者: エンジニア4名、PM1名、美容室のオーナー1名、店長2名
Step 1 — イベント洗い出し（2時間）: オレンジ付箋で67個のイベントを書き出した。「予約が作成された」「施術が開始された」「会計が完了した」など。美容室オーナーから「指名変更が発生した」「当日キャンセルが発生した」など、エンジニアだけでは思いつかないイベントが14個出た。
Step 2 — コマンドとUI（1.5時間）: 各イベントにコマンドとUI画面を紐づけた。「予約する」→「予約が作成された」→「予約確認画面」のように。
Step 3 — リードモデル（1時間）: 「本日の予約一覧」「スタイリスト別スケジュール」「月次売上ダッシュボード」など12個のリードモデルを定義。
Step 4 — スライス分割: 67イベントを8スライスに分割し、2週間スプリントで順次開発。
結果:
- 要件の見落としは0件（前回は8件）
- 開発期間は当初見積もりの**85%**で完了
- 美容室オーナーから「自分の業務がそのまま図になっているので、完成形が想像できた」というフィードバック
モノリスECサイト（月間注文8万件）のマイクロサービス移行。DDDのバウンデッドコンテキストで分割しようとしたが、チーム間で境界の認識が合わず、3か月間設計が確定しなかった。
イベントモデリングで解決: タイムラインに全イベントを並べた結果、自然なクラスタが見えてきた。
| クラスタ | 主なイベント | 独立性 |
|---|---|---|
| 商品カタログ | 商品が登録された、価格が更新された | 高（他に依存なし） |
| カート | 商品がカートに追加された、数量が変更された | 中（商品情報を参照） |
| 注文 | 注文が作成された、注文がキャンセルされた | 中（カート・在庫を参照） |
| 決済 | 支払いが完了した、返金が実行された | 高（注文IDのみ参照） |
| 在庫 | 在庫が引き当てられた、入荷が登録された | 高（商品IDのみ参照） |
| 配送 | 出荷指示が作成された、配達が完了した | 高（注文IDのみ参照） |
イベントの流れを見ると、クラスタ間の依存は「IDの参照のみ」で済むケースがほとんどだった。これをそのままマイクロサービスの境界にした。
成果:
- 3か月停滞していた設計が2日で確定
- サービス間はイベントバス（Kafka）で非同期連携する設計に
- 各チームが独立してデプロイ可能な構成を実現
- 移行開始から6か月で、最初の3サービス（商品カタログ・決済・配送）の分離が完了
損害保険会社のデジタル化プロジェクト。紙ベースの保険金請求フローをシステム化する要件定義に4か月かけたが、開発着手後に「査定の分岐条件が足りない」「書類差し戻しのフローが抜けている」が次々に判明し、手戻りコストが**全体の35%**を占めていた。
イベントモデリングワークショップ: 参加者: エンジニア3名、査定担当者2名、コールセンター担当1名、PM1名
3時間のワークショップで洗い出したイベント:
- 請求フロー: 「請求が受付された」→「書類が確認された」→「書類不備が検出された」→「差し戻しが通知された」→「書類が再提出された」→「査定が開始された」→「追加調査が必要と判定された」→ …
- 合計43イベント、18コマンド、9リードモデル
査定担当者から出た重要な洞察:
- 「書類不備の差し戻しは全件の**32%**で発生するので、システム上は例外ではなくメインフロー」
- 「査定の自動承認ルール（10万円以下は自動）が要件書に含まれていなかった」
これらは従来の要件定義書では4か月かけても拾えなかった情報だった。
スライス分割: 43イベントを6スライスに分割。第1スライス（請求受付→書類確認→査定）を最初の2スプリントで開発し、査定担当者にデモ。「これで十分使える」という確認を得てから残りのスライスに着手。
最終的に手戻りコストは前回の**35%→8%に減少。開発期間も当初見積もりの90%**で完了した。
やりがちな失敗パターン#
- エンジニアだけでワークショップをやる — イベントモデリングの最大の価値は、ビジネス側の知識をシステム設計に直接反映すること。ドメインエキスパートの参加なしでは、従来の設計手法と変わらない
- 最初から完璧を目指す — 最初のワークショップで全イベントを網羅しようとすると疲弊する。80%の精度で十分。残りは開発中に発見して追加する
- イベントとコマンドを混同する — 「注文する」はコマンド、「注文が作成された」がイベント。イベントは起きた事実であり、失敗もありうる。この区別が曖昧だとシステムのエラーハンドリングが設計から漏れる
- モデルを作って放置する — イベントモデルはシステムの「生きた設計図」。開発が進むにつれて新しいイベントやリードモデルが出てくるので、スプリントごとに更新する
まとめ#
イベントモデリングは、システムの振る舞いを「時系列のイベント」として並べ、コマンド・イベント・リードモデルの4レーンで設計する手法。ビジネス側とエンジニアが同じ図を見て議論できるため、要件の見落としが大幅に減る。タイムラインを縦に切れば実装スライスになるため、設計がそのまま開発計画に変わる。イベント駆動アーキテクチャやCQRSの導入にも直結する、実用性の高い設計手法である。