イベントストーミングのやり方｜付箋の色・進め方・システム開発の例

イベントストーミング（EventStorming）は、業務で起きる出来事（ドメインイベント）をオレンジの付箋に過去形で書き、壁に貼った紙の上に時間の順に並べて、業務の流れと問題点をみんなで見つけるワークショップです。 考案者の Alberto Brandolini は「複雑な業務の領域を、協力して探るための柔軟なワークショップの形式」と説明しています。

確認環境：定義は eventstorming.com と、Brandolini の書籍『Introducing EventStorming』（Leanpub）の紹介ページ、Brandolini のブログ記事「Introducing Event Storming」（2013年）の原文で確かめました。付箋の色は、DDD-Crew が公開している「EventStorming Glossary & Cheat sheet」（CC BY 4.0）の原文と、同リポジトリの図「Software design Picture that explains "Almost" Everything」で確かめています。記事の図は Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0、Linux）で描画できることを確かめました（確認日 2026年10月13日）。

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

ドメインイベント（業務の専門家にとって意味のある出来事）を中心に、業務の流れを壁一面に描き出す方法です。 DDD-Crew の用語集では、ドメインイベントを「イベントストーミングの主要な概念」とし、「過去形の動詞」で書くとしています。

• 生まれ：もとはドメイン駆動設計（DDD）の集約を設計するためのワークショップとして考えられ、今は業務全体の把握から、ソフトウェアの設計までに使われています（DDD-Crew の用語集の説明）。
• 良さ：Brandolini は2013年のブログで、モデルが「数週間ではなく数時間で」できると書いています。
• 必要なもの：同じブログでは、静かで広い部屋と、書き込める面（IKEA の紙のロール「MÅLA」）を挙げています。DDD-Crew の用語集では、6〜8 m ほどの書く面、材料を置く机、見える場所に貼った凡例を挙げ、椅子は置かないとしています。
• 人：2013年のブログでは「質問を知っている人と、答えを知っている人」がそろった 6〜8人 の部屋を理想としています。

DDD の基本と、ドメインイベント・集約などの言葉は、関連記事「ドメイン駆動設計入門｜DDDの基本と小さく始める手順をJavaで解説」で扱っています。

付箋の色と意味（くわしく）

イベントストーミングの付箋の色は、DDD-Crew の用語集で「公式の色（official colour）」として決められています。 色の意味を凡例として壁に貼り、新しい種類の付箋を使い始めるときに凡例に足していきます。

付箋の色は、時代によって少し違います。 Brandolini の2013年のブログでは、基本の道具を「薄い黄色の長方形と、オレンジ・青・紫の正方形」とし、紫を外部システムや時間の経過で起きるイベントに使っていました。今の用語集では、紫（ライラック）はポリシー、外部システムは横長のピンクです。昔の資料と今の資料で色が違うのは、このためです。

ホットスポットと外部システムは、どちらもピンク系です。 混ざらないように、ホットスポットは濃いネオンピンクを傾けて貼り、外部システムは横長の付箋を使います。手に入る付箋の色が違うときは、凡例に「この色は何か」を書いておけば伝わります。

付箋どうしのつながり

DDD-Crew のリポジトリの図「Software design Picture that explains "Almost" Everything」の矢印を、そのまま日本語にしたものです。

flowchart LR
  A["アクター"] -- "決める" --> C["コマンド<br>（アクション）"]
  C -- "呼び出す" --> S["外部システム<br>／制約"]
  S -- "生み出す" --> E["ドメインイベント"]
  E -- "起動する" --> P["ポリシー"]
  P -- "発行する" --> C
  E -- "結果として1つ以上の" --> R["リードモデル<br>（情報）"]
  A -- "見る" --> R
  classDef evt fill:#FFA94D,stroke:#C26A00,color:#000
  classDef cmd fill:#74C0FC,stroke:#1C7ED6,color:#000
  classDef act fill:#FFF35C,stroke:#B5A800,color:#000
  classDef pol fill:#D0A9F5,stroke:#7B3FB8,color:#000
  classDef sys fill:#F49AC2,stroke:#C2255C,color:#000
  classDef rm fill:#B5E48C,stroke:#5C940D,color:#000
  class E evt
  class C cmd
  class A act
  class P pol
  class S sys
  class R rm

左から右へ、時間が流れます。 アクターがリードモデルを見て判断し、コマンドを出します。コマンドが外部システムや制約にかかり、ドメインイベントが生まれます。イベントがポリシーを起動し、ポリシーが次のコマンドを出します。

3つの種類：Big Picture・Process Modelling・Software Design

イベントストーミングは、目的に応じて3つの種類に分かれます。 書籍『Introducing EventStorming』の目次でも、Big Picture（第4章など）、Process Modeling（第13・14章）、Design-Level（第17章など）が別の章になっています。

• Big Picture は、DDD-Crew の用語集で「既存の事業の健全さを評価する、または新しいスタートアップの事業モデルの実現性を探る」ものとされています。1本の紙のロールに10〜30人以上で書けるとしています。
• Process Modelling は、「今のプロセスの現状を共有し、ボトルネックを見つけ、今のソフトウェアから切り離す部分を見つける」ものです。
• Software Design は、「1つの境界づけられたコンテキストの中で、問題を解く共有のモデルを作る」ものです。

順番は Big Picture → Process Modelling → Software Design が基本です。 ただし、業務の流れがすでに分かっていて、作るソフトウェアの設計だけをしたいときは、Process Modelling や Software Design から始めることもあります。

進め方（Big Picture）

DDD-Crew の用語集の「Cheat Sheet」の手順は、次の4ステップです。 その前後に、チェックイン（気持ちを場に向ける短い声かけ）とチェックアウト（感想の共有）を置いています。

flowchart LR
  s0["準備<br>招待・材料・部屋"] --> s1["1 混沌とした探索<br>各自がイベントを書いて貼る"]
  s1 --> s2["2 時系列をそろえる<br>重複を消し、順に並べる"]
  s2 --> s3["3 ホットスポット<br>対立・疑問を貼る"]
  s3 --> s4["4 概念を足す<br>アクター・システム・価値など"]
  s4 --> s5["ピボタルイベントで区切り、<br>コンテキストの候補を探す"]

1. 混沌とした探索（Chaotic Exploration）：各自が思いつくドメインイベントを、ひとりで書いて貼ります。ほかの人の考えに引っぱられないよう、このあいだは声に出して話し合いません。 用語集は「ここを急がない。イベントストーミング全体でいちばん大事な部分」としています。
2. 時系列をそろえる（Enforce the Timeline）：重複を取り除き、正しい時間の順に並べます。同じ言葉で別のことを指していないかも話し合います。用語集は、テープで区切りを入れるのは早すぎないように、と注意しています。
3. ホットスポット：意見が分かれたところ、答えの出ない疑問、痛みのあるところにピンクの付箋を貼ります。この段階では司会が貼ります。 議論を長引かせず、付箋にして先に進むためです。
4. 必要に応じて概念を足す：アクター・システム・価値・機会などを、凡例に足しながら使い始めます。

ピボタルイベントと境界

ピボタルイベント（Pivotal Events）は、流れの中でとくに大事な、少数のイベントです。 用語集では EC サイトの例として「商品がカタログに追加された」「注文が確定した」「注文が出荷された」「支払いを受けた」「注文が配達された」を挙げ、多くの人が関心を持つイベントであることが多いとしています。ピボタルイベントで流れを区切ると、境界づけられたコンテキストの候補（Emerging Bounded Contexts）が見えてきます。

時間配分の例

原典は、それぞれのステップの時間を決めていません。 以下は、半日（4時間）で Big Picture を行うときの配分の例です。

準備の目安：用語集は、知識を持つ人と知識が必要な人（多くは業務の専門家とエンジニア）を招待し、招待状にワークショップの目的とイベントストーミングの説明を書くことを勧めています。会議の進め方は、関連記事「会議ファシリテーションの進め方 アジェンダ設計とフレーズ集」で扱っています。

システム開発の例：受注業務

卸売の会社の受注業務（見積もりから入金まで）を例にします。 内容は説明のための仮のものです。

Big Picture：受注から入金まで

flowchart LR
  e1["見積を依頼された"] --> e2["見積書を送った"] --> e3["注文を受け付けた"]
  e3 --> e4["与信が承認された"] --> e5["在庫が引き当てられた"] --> e6["出荷を指示した"]
  e6 --> e7["商品が出荷された"] --> e8["請求書を発行した"] --> e9["入金を確認した"]
  a1["営業担当"] -.- e2
  a2["経理"] -.- e4
  a3["倉庫"] -.- e7
  x1["会計システム"] -.- e9
  x2["配送業者のシステム"] -.- e7
  h1["与信の基準が<br>部署で違う？"] -.- e4
  h2["在庫が足りないとき<br>誰が顧客に連絡する？"] -.- e5
  h3["入金の消し込みが<br>手作業で月末に集中"] -.- e9
  classDef evt fill:#FFA94D,stroke:#C26A00,color:#000
  classDef pivot fill:#FFA94D,stroke:#000,stroke-width:4px,color:#000
  classDef act fill:#FFF35C,stroke:#B5A800,color:#000
  classDef sys fill:#F49AC2,stroke:#C2255C,color:#000
  classDef hot fill:#FF3D8B,stroke:#A61E4D,color:#fff
  class e1,e2,e4,e5,e6,e8 evt
  class e3,e7,e9 pivot
  class a1,a2,a3 act
  class x1,x2 sys
  class h1,h2,h3 hot

• 太い枠のオレンジが、ピボタルイベントです。「注文を受け付けた」「商品が出荷された」「入金を確認した」で区切ると、受注・出荷・請求の3つのまとまりが見えます。
• ピンク（濃い色）がホットスポットです。「与信の基準が部署で違う？」は、言葉や決まりがそろっていない、というしるしです。

Process Modelling：注文の受け付けから在庫の引き当てまで

flowchart TB
  a["営業担当"] --> r1["在庫の一覧<br>顧客の与信枠"]
  r1 --> c1["注文を登録する"]
  c1 --> k1["注文"]
  k1 --> e1["注文を受け付けた"]
  e1 --> p1["注文を受け付けたら<br>与信を確認する"]
  p1 --> c2["与信を確認する"]
  c2 --> x1["与信管理システム"]
  x1 --> e2["与信が承認された"]
  x1 --> e2n["与信が否決された"]
  e2 --> p2["与信が承認されたら<br>在庫を引き当てる"]
  p2 --> c3["在庫を引き当てる"]
  c3 --> k2["在庫"]
  k2 --> e3["在庫が引き当てられた"]
  k2 --> e3n["在庫が不足した"]
  e3n --> h1["分納か、待つか<br>誰が決める？"]
  classDef evt fill:#FFA94D,stroke:#C26A00,color:#000
  classDef cmd fill:#74C0FC,stroke:#1C7ED6,color:#000
  classDef act fill:#FFF35C,stroke:#B5A800,color:#000
  classDef pol fill:#D0A9F5,stroke:#7B3FB8,color:#000
  classDef sys fill:#F49AC2,stroke:#C2255C,color:#000
  classDef rm fill:#B5E48C,stroke:#5C940D,color:#000
  classDef con fill:#FFF9B0,stroke:#B5A800,color:#000
  classDef hot fill:#FF3D8B,stroke:#A61E4D,color:#fff
  class e1,e2,e2n,e3,e3n evt
  class c1,c2,c3 cmd
  class a act
  class p1,p2 pol
  class x1 sys
  class r1 rm
  class k1,k2 con
  class h1 hot

• ポリシー（ライラック）は「〜したら、〜する」のルールです。人が判断している場合も、システムで自動にする場合もあります。用語集は、ポリシーには「最初に思うより多くのことがある」としています。
• 失敗のイベント（与信が否決された、在庫が不足した）も、オレンジの付箋で書きます。失敗の先にホットスポットが出やすくなります。

Software Design：制約（集約）を見つける

用語集では、Software Design で使う大きい黄色の付箋を「制約（Constraint）」と呼び、以前は「集約（aggregate）」と呼んでいたとしています。業務の担当者に「集約」という言葉を使わないためです。設計の段階では、制約の付箋が DDD の集約の候補になります。

集約・境界づけられたコンテキストへのつなぎ方

付箋は、そのままコードや設計の部品に対応させられます。 以下は、よく使われる対応のさせ方です。

flowchart TB
  subgraph JC["受注コンテキスト"]
    O["注文（集約）"]
  end
  subgraph ZC["在庫コンテキスト"]
    I["在庫（集約）"]
  end
  subgraph SC["請求コンテキスト"]
    B["請求（集約）"]
  end
  O -- "注文を受け付けた" --> I
  I -. "在庫が引き当てられた" .-> O
  O -- "商品が出荷された" --> B
  classDef con fill:#FFF9B0,stroke:#B5A800,color:#000
  class O,I,B con

• コンテキストの間は、イベントでつなぎます。 受注コンテキストは「注文を受け付けた」を出すだけで、在庫の引き当て方は知りません。
• 同じ言葉が別の意味で使われているところ（例：受注の「顧客」と請求の「請求先」）は、コンテキストの境界の候補です。
• コンテキストの間をイベントでつなぐと、書き込みと読み出しを分ける設計や、イベントの記録から状態を作る設計につながります。関連記事「CQRSとは｜イベントソーシングとの違いをSQLとコードで解説」で扱っています。コンテキストをサービスに分けるかどうかは、関連記事「マイクロサービスとは｜モノリスとの違い・採用判断・移行の進め方」で扱っています。

集約の中の構造（どのエンティティを持つか、多重度はどうか）は、ドメインモデル図で描くと整理できます。関連記事「ドメインモデル図の書き方｜クラス図との違いと例」で扱っています。

業務フロー図・ユースケースとの違い

イベントストーミングの結果は、業務フロー図やユースケース記述の材料になります。 壁の写真から、レーンを決めて業務フロー図に清書する、ポリシーとコマンドからユースケースを書き出す、という流れです。業務フロー図は関連記事「業務フロー図の書き方｜記号一覧・スイムレーン例とMermaidテンプレート」で、ユースケース記述は「ユースケース記述の書き方｜テンプレートと記入例（基本・代替・例外フロー）」で扱っています。

オンラインで行う場合

オンラインでは、ホワイトボードのツールに付箋の色の凡例を先に作っておきます。 Avanscoperta（Brandolini の会社）の説明では、オンラインは「分散したチームが参加しやすい」利点があるとし、まず対面のやり方を試しておくと、オンラインで仕組みがうまく働かなくなったときに気づける、としています。書籍『Introducing EventStorming』にも「Big Picture in remote mode」「Remote Event Storming」の章があります。

Avanscoperta のページでは、Process Modelling をオンラインで行うための無料の Miro のテンプレートを案内しています。DDD-Crew の用語集では、Web ブラウザで使えるオープンソースの「DDD Toolbox」が紹介されています。

よくある誤り

よくある質問

Q. 付箋の色が手元にそろいません。 A. 用語集が「公式の色」としているのは、オレンジ（イベント）・青（コマンド）・黄色（アクター・制約）・ライラック（ポリシー）・ピンク（システム・ホットスポット）・緑（リードモデル・機会）です。そろわないときは、凡例に「この色は何か」を書いて貼っておくと、参加者の間で意味がそろいます。

Q. ドメインイベントの書き方の目安はありますか。 A. 用語集では「過去形の動詞」で、「業務の専門家にとって意味がある」ものとしています。「ボタンを押した」「レコードを更新した」のような画面やデータベースの操作は、業務の言葉に言い換えます（例：「注文を受け付けた」）。

Q. ユーザーストーリーにはどうつなげますか。 A. コマンドとアクターの組み合わせが、ストーリーの候補になります。「営業担当として、注文を登録したい。与信の確認を自動で始めるためだ」のように書けます。書籍の目次にも「From EventStorming to UserStories」の章があります。書き方は、関連記事「ユーザーストーリーの書き方と例30選｜受け入れ基準Given-When-Then」で扱っています。

Q. 状態遷移図とはどう使い分けますか。 A. イベントストーミングで出た「注文を受け付けた」「商品が出荷された」などのイベントは、注文の状態が変わるきっかけです。1つの集約の状態の移り変わりを正確に描くときは、状態遷移図が向いています。関連記事「状態遷移図と状態遷移表の書き方｜テスト設計とMermaid・PlantUML」で扱っています。

まとめ

• イベントストーミングは、オレンジの付箋に過去形でドメインイベントを書き、時間の順に並べるワークショップ
• 公式の色は、イベント＝オレンジ、コマンド＝青、アクター＝小さい黄色、ポリシー＝ライラック、システム＝横長のピンク、リードモデル＝緑、ホットスポット＝ネオンピンク、制約（旧称：集約）＝大きい黄色
• 種類は Big Picture・Process Modelling・Software Design の3つ
• Big Picture の手順は 混沌とした探索 → 時系列をそろえる → ホットスポット → 概念を足す
• ピボタルイベントで区切ると、境界づけられたコンテキストの候補が見える。制約の付箋は集約の候補になる

参考・出典

確認日はいずれも 2026年10月13日です。

• EventStorming（Alberto Brandolini）：https://www.eventstorming.com/
• Leanpub『Introducing EventStorming』（Alberto Brandolini）：https://leanpub.com/introducing_eventstorming
• Alberto Brandolini「Introducing Event Storming」（2013年）：https://ziobrando.blogspot.com/2013/11/introducing-event-storming.html
• DDD-Crew「EventStorming Glossary & Cheat sheet」（CC BY 4.0）：https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet
• Avanscoperta「EventStorming」：https://www.avanscoperta.it/en/eventstorming/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。