Event Stormingとは?進め方・メリット・DDDとの関係を解説

Event Stormingは、付箋を使って業務の流れを関係者と一緒に探るワークショップ手法です。準備から探索、記録へと進み、最後に評価を行います。

準備では、まず開催前に対象業務と参加者、探索したい論点を決めます。そのうえで、進行役と記録の残し方も決めておきます。

  • ドメインイベントを時系列に並べ、業務の流れ、規則、境界、疑問を参加者で探索するワークショップです。
  • イベント・コマンド・アクター・集約・ポリシー・外部システムを洗い出し、不明点や重複語を話し合います。
  • 複雑な業務を関係者で共有し、要件・モデル・サービス境界の理解をそろえたい場合に適しています。

Event Stormingの定義と役割

Event Stormingを中心に、ドメインイベント、業務の流れ、規則、境界を示す図解
時系列のイベントから業務を探索する

Event Stormingは、ドメインイベントを付箋などで時系列に並べ、業務の流れ、規則、境界、疑問を参加者で探索するワークショップ手法です。付箋にドメインイベントを書いて発生順に並べると、業務の流れについての関係者の認識を、同じ場で確認できます。そのうえで、規則や境界、疑問を話し合います。

Event Stormingの仕組み|計算と判断の流れ

Event Stormingの仕組みを3層で示し、定義、学習・推定、意思決定への変換を表す図解
可視化と記録を次の検証へつなげる

1. 目的とデータの単位の定義

まず、イベント・コマンド・アクター・集約・ポリシー・外部システムを洗い出し、重複語や不明点を話し合います。見つけた境界は、仮説として記録しておきます。

2. 候補設定の学習・推定

議論で見つかったことは記録として残し、次の検証や設計で使えるように引き継ぎます。

3. 結果を意思決定できる形への変換

評価では、参加者が業務の理解を共有できたかを確認します。さらに、未解決点や境界の仮説を次の検討へ引き継げたかも見ておきます。

ポイント

探索で出た内容を記録に残し、次の検証や設計へ引き継げているかを、進め方が機能しているかを見る目安にします。記録が手元に残らないと、議論の結果は次へ渡りません。

Event Stormingの使い方|実務での適用場面

小さな検証からの開始

この手法は、複雑な業務を共有し、要件・モデル・サービス境界の理解をそろえる用途に向きます。意思決定者と実装者も同席させます。

評価期間と利用者のそろえ方

評価記録には、参加者・発見・未解決点・境界・合意・後続設計への反映を残しておきます。

本番運用への移行

ワークショップのあとには、未解決点や境界仮説の検証状況を確認します。そのうえで、更新担当と次の議論を決めておきます。

ポイント

複雑な業務で要件、モデル、サービス境界の理解をそろえたいかを、適用の目安にします。試したあとは、更新担当と次の議論を決めておくと、本番運用へ移しやすくなります。

Event Stormingと関連手法の違い

UMLとEvent Stormingを左右に並べ、形式化と発見・対話の違いを示す図解
目的に応じて問いへの答え方を使い分ける

UMLは構造や振る舞いを形式化するのに対し、Event Stormingは発見と対話を重視します。完成図を作るより、仮説と未解決点を残すことを優先します。

手法を比べるときは、同じデータ分割・目的・評価期間・前処理・計算予算をそろえます。

手法ごとに答えられる問いが違う場合は、単純な順位付けを避け、精度・安定性・説明・費用・保守性を並べた判断表を作ります。

Event Stormingの評価方法|数値以外の観点

主要指標と不確実性

評価では、数値を見るだけでなく、参加者が業務の流れを共有できたか、発見した規則や境界、残った疑問を振り返ります。

診断と再現性

結果は、平均値に加えて、期間別、グループ別、極端なケース別にも確認します。

さらに、設定を変えた感度分析や別データでの確認、複数シードでの再実験も行い、結論が一つの偶然に依存していないかを点検します。

ポイント

数値の良し悪しだけで判断せず、業務の流れを共有できたか、未解決点や境界の仮説を次の検討へ渡せたかを、評価の目安にします。

Event Stormingで起きやすい失敗と対策

データと前処理の問題

議論の結果に加えて、未解決点や境界の仮説も記録します。また、後から内容を見直せるよう、記録の更新担当を決めておきます。

指標と問いの混同

特定の参加者の発言に偏ったり、付箋の内容を完成品とみなしたりすると、業務の認識や未解決点を十分に捉えられません。そのため、完成図を作ることより、仮説と未解決点を記録し、後から更新できる状態にすることが大切です。

運用条件の変化の見落とし

業務ルールや参加者の認識が変わったときは、イベントや境界の記録を更新します。

ポイント

特定の参加者の発言に偏っていないか、未解決点や境界の仮説が記録されているかを、失敗を避けるための目安にします。付箋を完成品とみなしていないかも、合わせて見ておくとよいでしょう。

Event Stormingを採用する判断基準

業務の理解が関係者ごとにばらついていて、モデルや境界を探る必要があるときに採用します。そのうえで、進行役と次の検証を用意しておきます。

採用したあとは、議論で出た要素を記録に残します。要素には、イベント、コマンド、アクターのほか、次の項目があります。

  • 集約
  • ポリシー
  • 外部システム
  • 境界仮説
  • 未解決点

ポイント

業務の理解が関係者ごとにばらつき、モデルや境界を探る必要があるときは、採用を考える目安になります。進行役と次の検証を用意できるかも、採用を考える際の一つの目安になります。

Event Stormingまとめ|目的・前提・評価の要点

Event Stormingは、付箋を使ってドメインイベントを時系列に並べ、業務の流れや規則、境界、疑問を探る手法です。

成果を活かすには、対象・時間・入力・出力・仮定を定義しておき、基準となる手法と同じ条件で評価することが重要です。

まずは小さく検証してから適用範囲を広げ、設定・データ・評価結果を再現できる形で保存します。精度や有意性に加えて、誤りのコスト・説明可能性・運用負荷・影響を受ける人への公平性も含めて判断してください。

よくある質問(FAQ)

Q. Event Stormingとは何ですか?

ドメインイベントを付箋などで時系列に並べ、業務の流れ、規則、境界、疑問を参加者で探索するワークショップ手法です。

Q. Event Stormingはどのような場面で使いますか?

業務イベントを時系列に並べ、参加者間で流れや境界を発見するときに使います。

Q. Event Stormingを使うときの評価指標は何ですか?

参加者・発見・未解決・境界・合意・反映を確認します。

Q. Event Stormingで起きやすい失敗は何ですか?

技術先行・偏り・付箋の完成品化・急ぎすぎ・更新不足に注意します。

Q. Event Stormingと似た手法はどう使い分けますか?

形式化を目的とするUMLより、Event Stormingは対話による発見を重視します。

参考資料

定義と実務上の注意は、次の公式資料をもとにしています。

www.eventstorming.com公式資料、DDD公式資料を参照しています。利用時は該当バージョンの資料を確認します。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。