イベントストーミングとは - 付箋でドメインを可視化するワークショップ手法
イベントストーミングとは、ドメインエキスパートと開発者が付箋でビジネスプロセスをドメインイベントとして可視化するワークショップ手法。付箋の色の意味、3 つの型の使い分け、境界づけられたコンテキストの発見方法を解説。
イベントストーミングとは
イベントストーミング (EventStorming) は、Alberto Brandolini が公開したワークショップ手法で、ドメインエキスパートと開発者が付箋を使ってビジネスプロセスをドメインイベントとして可視化する。DDD の境界づけられたコンテキストの発見や、マイクロサービスの分割境界の特定に使われる。
「2013 年に生まれた手法」と紹介されることが多いが、正確には命名と普及がこの年である。原型は Brandolini が 2012 年の Italian Agile Day で発表した Event-Based modelling workshop で、EventStorming という名前が付いたのは 2013 年の夏前、手法を解説した最初の記事の公開が 2013 年 11 月である。考案者本人は現在 EventStorming と 1 語で綴る。
なぜイベントストーミングか
従来の要件定義は、ドキュメントを書く人と読む人が分離し、認識のズレが生じやすい。イベントストーミングは全員が同じ壁の前に立ち、リアルタイムで議論しながらモデルを構築するため、暗黙知が表出しやすい。
付箋の色と意味
広く使われている色の対応を以下にまとめる。
| 色 | 要素 | 例 |
|---|---|---|
| 🟧 オレンジ | ドメインイベント (過去形) | 「注文が確定された」 |
| 🟦 ブルー | コマンド (アクション) | 「注文を確定する」 |
| 🟨 イエロー | アクター (人/システム) | 「顧客」「決済システム」 |
| 🟪 パープル | ポリシー (ルール) | 「在庫がある場合のみ」 |
| 🟩 グリーン | リードモデル (参照データ) | 「在庫一覧」 |
| 🟥 レッド | ホットスポット (課題・疑問) | 「ここの仕様が不明」 |
| 🩷 ピンク | 外部システム | 「決済ゲートウェイ」 |
ただしこの対応は慣例であって、規格ではない。考案者自身、最初の記事では紫を「外部システムや時間経過が起点になったイベント」に、小さい黄色を人物像に割り当てており、参加者に合わせて記法を変えたと書いている。つまり同じ紫でも文献によって意味が違う。実施前に「この色は何を指すか」を壁に書き出して合わせておかないと、後から付箋を読み返した人が別の意味で解釈する。
色をいくつ使うかも固定ではない。公式サイトは、必要になった時点で記法を足す進め方 (Incremental notation) を勧めている。最初に 7 色すべてを説明すると参加者は覚えることに気を取られるので、まずオレンジ 1 色でイベントを出し、コマンドやポリシーの話題が出てから色を足す方が手が止まらない。表に無い要素を扱うときも、その場で 1 色足せばよい。
ワークショップの流れ
イベントストーミングには単一の決まった形式がなく、目的ごとに使い分ける型 (flavour) がある。公式サイトが挙げる代表的な 3 つが、ビッグピクチャー、プロセスモデリング、ソフトウェアデザインである。
ビッグピクチャー (Big Picture)
参加者: 部門をまたいだ関係者を広く
→ ドメインイベントを時系列に並べる
→ ホットスポット (不明点) を洗い出す
プロセスモデリング (Process Modelling)
参加者: 対象プロセスの当事者 + 設計する人
→ コマンド、アクター、ポリシー、リードモデルを追加
→ イベント間の因果関係を明確化
ソフトウェアデザイン (Software Design)
参加者: 実装するチーム
→ 集約 (Aggregate) の境界を特定
→ 境界づけられたコンテキストを発見
粒度と参加者が違うので、この 3 つは 1 回のワークショップの 3 工程というより、別々のセッションとして選ぶものである。全体像の把握だけが目的なら、ビッグピクチャーで止めてよい。逆に対象プロセスが 1 つに絞れているなら、プロセスモデリングから始めても構わない。
所要時間に公式の定めはない。実務では 1 回を 2〜4 時間で区切り、日を分けて続ける方が集中力が保てる。ただしビッグピクチャーは参加者が多く再招集のコストが高いので、1 日押さえて一気に終わらせる判断もある。
境界づけられたコンテキストの発見
イベントストーミングで並べたイベントを眺めると、「注文」「在庫」「決済」「配送」のようにイベントのクラスターが見えてくる。このクラスターが境界づけられたコンテキストの候補であり、マイクロサービスの分割境界になる。
実施のコツ
- 広い壁とロール紙を用意する。オンラインなら Miro や FigJam を使う
- ドメインエキスパート (業務を知っている人) の参加が必須。開発者だけでは業務の暗黙知が出てこない
- 最初は「正しさ」を求めず、とにかくイベントを出す。整理は後から
- ホットスポット (赤い付箋) を恐れない。不明点の可視化こそがイベントストーミングの価値
DDD の関連書籍も参考になる。
よくある質問
- イベントストーミングとユーザーストーリーマッピングの違いは?
- どちらも付箋で協働するワークショップだが、イベントストーミングは「ドメインイベント (過去形の出来事)」を軸にビジネスプロセスと境界づけられたコンテキストを発見する DDD 由来の手法、ユーザーストーリーマッピングは「ユーザーの行動」を軸にリリース計画を作るアジャイル由来の手法である。目的が異なるため併用できる。
この記事は役に立ちましたか?
関連用語
ドメイン駆動設計 (DDD)
ビジネスドメインの知識を中心に据え、ドメインエキスパートと開発者が共通言語で協働しながらソフトウェアを設計する手法
境界づけられたコンテキスト
ドメインモデルが一貫した意味を持つ範囲を明確に区切り、モデルの曖昧さを排除する DDD の戦略的パターン
イベントソーシング
状態の変更をイベントとして記録し、イベントの再生で現在の状態を復元する設計パターン
イベント駆動アーキテクチャ
イベントの発行と購読を中心にシステムを構成し、サービス間の疎結合と非同期処理を実現するアーキテクチャスタイル
Saga コレオグラフィ
各サービスがイベントを発行 / 購読し、中央のオーケストレーターなしで分散トランザクションを実現する方式
EventBridge
AWS のサーバーレスイベントバスで、イベント駆動アーキテクチャの中核を担う