第7章: イベントストーミング — ドメイン発見ワークショップの実践

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

イベントストーミング（Event Storming）は、イタリアのソフトウェア設計者Alberto Brandoliniが2013年に考案したワークショップ手法です。 大量の付箋を使い、ドメインイベントを起点にビジネスプロセスを可視化するという、シンプルかつ強力なアプローチです。

従来のモデリング手法（UML図、ER図など）が技術者中心になりがちだったのに対し、 イベントストーミングはドメインエキスパートと開発者が同じ場で協働することを前提に設計されています。 特別なツールや記法の知識は不要で、「ビジネスで何が起きるか」という共通の問いから始められます。

付箋の色分けルール

イベントストーミングでは、付箋の色によって要素の種類を区別します。 この標準化されたカラーコードにより、誰もが一目で構造を把握できます。

3つのレベル — 俯瞰から実装へ

イベントストーミングは3つのレベルに分かれています。 各レベルは独立して実施でき、段階的に詳細度を上げていきます。

graph LR
  BP[Big Picture\n全体俯瞰] --> PL[Process Level\nプロセス詳細化] --> DL[Design Level\n実装設計]
  BP ---|参加者: 10〜20名\n所要: 2〜4時間| BP
  PL ---|参加者: 5〜10名\n所要: 2〜3時間| PL
  DL ---|参加者: 3〜6名\n所要: 2〜4時間| DL

  style BP fill:#f97316,stroke:#ea580c,color:#fff
  style PL fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style DL fill:#8b5cf6,stroke:#6d28d9,color:#fff

レベル1: Big Picture — ビジネスドメイン全体の俯瞰

Big Pictureは、ビジネスドメイン全体を俯瞰するための最初のレベルです。 10〜20名の多様な参加者（開発者、ドメインエキスパート、プロダクトオーナー、デザイナー等）が集まり、 ビジネスで「何が起きるか」をオレンジの付箋に書き出します。

Big Pictureの進め方

1. Chaotic Exploration（カオスな探索）: 参加者全員が思いつくドメインイベントをオレンジの付箋に書き、壁に貼る。順番は気にしない。「重複OK、批判禁止」がルール
2. Timeline（時系列の整理）: 貼り出したイベントを左から右へ時系列順に並べ替える。ここで矛盾や重複に気づく
3. Pivotal Events（重要イベントの特定）: ビジネスフェーズの区切りとなるイベントに印を付ける（例: 「注文が確定された」はフェーズの転換点）
4. Swimlanes（スイムレーン分割）: 関連イベントをグループ化し、Bounded Contextの候補を見つける
5. Hot Spots（ホットスポットの記録）: 議論が白熱した箇所、意見が分かれた箇所に赤い付箋を貼る

レベル2: Process Level — 特定プロセスの詳細化

Process Levelでは、Big Pictureで特定したプロセスのうち重要なものを選び、詳細化します。 参加者は5〜10名に絞り、当該プロセスに詳しいドメインエキスパートを必ず含めます。

Big Pictureではオレンジの付箋（イベント）のみでしたが、Process Levelでは以下の要素を追加します。

• コマンド（青）: イベントを引き起こすアクション
• アクター（黄色・小）: コマンドを実行する人またはシステム
• ポリシー（黄色・大）: あるイベントに反応して自動的に実行されるビジネスルール
• リードモデル（緑）: アクターが判断に使う情報・画面
• 外部システム（ピンク）: 自分たちが制御できないシステム

sequenceDiagram
  participant A as アクター\n（顧客）
  participant RM as リードモデル\n（商品カタログ画面）
  participant CMD as コマンド\n（カートに追加する）
  participant AGG as 集約\n（ショッピングカート）
  participant EVT as ドメインイベント\n（商品がカートに追加された）
  participant POL as ポリシー\n（在庫確認ポリシー）
  participant EXT as 外部システム\n（在庫管理）

  A->>RM: 商品を閲覧
  A->>CMD: カートに追加
  CMD->>AGG: 処理
  AGG->>EVT: 発行
  EVT->>POL: トリガー
  POL->>EXT: 在庫確認

レベル3: Design Level — 実装可能なモデル設計

Design Levelは、Process Levelの成果物をもとに実装可能なモデルを設計する段階です。 参加者は3〜6名の開発者中心のチームで、ドメインエキスパートも参加します。

このレベルでは以下を明確にします。

• 集約（Aggregate）の境界: どのコマンドとイベントが同じ集約に属するか
• 集約のビジネスルール: コマンドを受け付ける条件（不変条件）
• 集約間の連携: イベントとポリシーによる結果整合性の設計

Design Levelからコードへの変換

Design Levelの成果物は、そのままコードに変換できる構造になっています。 付箋の色と配置がそのままコードの構造に対応します。

// Design Levelの付箋からコードへの変換例

// 黄色の付箋 → 集約
class Order {
  private status: OrderStatus;
  private items: OrderItem[];
  private events: DomainEvent[] = [];

  // 青の付箋 → コマンド（パブリックメソッド）
  confirm(): void {
    // 赤の付箋で特定したビジネスルール
    if (this.items.length === 0) {
      throw new Error('商品がない注文は確定できません');
    }
    if (this.status !== OrderStatus.DRAFT) {
      throw new Error('下書き状態の注文のみ確定できます');
    }

    this.status = OrderStatus.CONFIRMED;

    // オレンジの付箋 → ドメインイベント
    this.events.push(new OrderConfirmed({
      orderId: this.id,
      confirmedAt: new Date(),
      totalAmount: this.calculateTotal(),
    }));
  }
}

// 黄色の付箋（ポリシー）→ イベントハンドラ
class InventoryReservationPolicy {
  // 「注文が確定されたら在庫を引き当てる」というポリシー
  handle(event: OrderConfirmed): void {
    this.inventoryService.reserve(
      event.orderId,
      event.items
    );
  }
}

リモートイベントストーミング

COVID-19以降、リモートでのイベントストーミング実施が増えました。 MiroやMuralなどのオンラインホワイトボードツールが主に使われます。

ただし、Brandolini自身はリモート実施の制約を指摘しています。

リモート実施の対処法

• 参加人数を減らす: 対面の半分（5〜8名）が目安。10名を超えると議論が分散する
• 時間を短くする: 90分を上限とし、複数回に分けて実施する
• ブレイクアウトルームを活用: 3〜4名のグループで並行して探索し、全体で統合する
• テンプレートを用意する: Miro上に付箋の色分けガイドとエリアを事前に配置する
• ファシリテーターを2名配置: 1名がMiro操作、1名が議論をリードする
• 明確なタイムボックス: 各フェーズに時間制限を設け、テンポよく進める

失敗パターンと対処法

イベントストーミングは手法としてはシンプルですが、ファシリテーションの質によって成果が大きく変わります。 ここでは、よくある失敗パターンとその対処法を整理します。

実践的なファシリテーションのコツ

事前準備

• 壁を確保する: 最低8メートルの壁面が必要。会議室のホワイトボードでは狭い
• 付箋は大量に用意する: 1セッションで200〜300枚は消費する
• 太いマーカーのみ使用する: 細いペンで書くと遠くから読めない。1枚に1〜3語が理想
• 参加者への事前説明は最小限: 「イベント＝ビジネスで起きたこと」だけ伝えれば十分

ワークショップ中のポイント

• 最初の10分は沈黙を許容する: 全員が書き始めるまで待つ。ファシリテーターが最初の例を1つだけ示すのは有効
• 「それは正しいか？」ではなく「他に何があるか？」: 評価ではなく探索にフォーカスする
• ホットスポットを歓迎する: 意見の対立は宝の山。赤い付箋を積極的に貼る
• 技術用語を避ける: 「APIが呼ばれた」ではなく「注文が確定された」というビジネスの言葉を使う

graph TB
  subgraph BP[Big Picture]
    E1[商品が出品された] --> E2[注文が作成された] --> E3[支払いが完了した] --> E4[商品が発送された] --> E5[商品が届けられた]
    E3 --> HS1[🔴 在庫切れ時の\n対応が不明]
  end
  subgraph PL[Process Level - 注文プロセス]
    A1[顧客] --> C1[注文を確定する]
    C1 --> AG1[注文集約]
    AG1 --> EV1[注文が確定された]
    EV1 --> POL1[在庫引当ポリシー]
    POL1 --> EXT1[在庫管理]
  end
  subgraph DL[Design Level]
    AGG[注文\n集約ルート] --> CMD1[確定する]
    AGG --> CMD2[キャンセルする]
    CMD1 --> EVT1[注文確定イベント]
    CMD2 --> EVT2[注文キャンセルイベント]
    AGG --> RULE[不変条件:\n商品が1つ以上\nステータスがDRAFT]
  end
  BP --> PL --> DL

  style BP fill:#1e1e2e,stroke:#f97316,color:#fff
  style PL fill:#1e1e2e,stroke:#3b82f6,color:#fff
  style DL fill:#1e1e2e,stroke:#8b5cf6,color:#fff
  style HS1 fill:#ef4444,stroke:#dc2626,color:#fff
  style AGG fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style RULE fill:#f59e0b,stroke:#d97706,color:#000