この記事はCommune Advent Calendar 2024、シリーズ1の18日目の記事です。
こんにちは近藤です。
コミューンという会社でグローバルチームで、サービス開発をしています。
はじめに
2024年11月28日に参加したMF2024ワークショップ②『Event Stormingワークショップ』にて、Event Stormingを用いたビジネスモデリング手法を実践的に学ぶ機会がありました。講師はエキスパートである成瀬さん。朝10時から夕方17時までの濃密なセッションで、単なる理論にとどまらず、現場での実践ノウハウまで深く掘り下げることができました。この学びを整理し、特に印象深かったポイントを共有します。
Event Stormingとは
Event Stormingは、付箋を使ってビジネスの流れ（ドメイン）を「イベント（起きた出来事）」として時系列で可視化し、関係者間で共通理解を醸成する手法です。「BIG PICTURE」から「PROCESS MODELING」を経て、最後に「SOFTWARE DESIGN」へと至るプロセスを踏むことで、ビジネス要件やドメインモデルが自然と浮き彫りになります。
ワークショップでの流れ
ワークショップはおおまかに以下の3段階で進みました：
1. BIG PICTURE：
業務で起きている出来事（イベント）を時系列に並べ、全体像を俯瞰します。この時点では実装技術や細かい仕様に踏み込みすぎず、「何が起きているか」を共有することに注力します。
2. PROCESS MODELING：
イベントが起きる背景やトリガーとなる条件、関与するアクター（人・システム）を明らかにします。付箋の色分けや位置関係を使いながら、「誰が」「何に基づいて」「どのように行動するのか」を整理します。
3. SOFTWARE DESIGN：
最終段階では、イベントやポリシー、アクターが自然なまとまりを形成する領域（バウンデッドコンテキスト）を見出します。これにより、システム設計やチーム分割のヒントが得られます。
学びと気づき
1. イベントとポリシーの違いを明確にする
「在庫が不足したら通知する」という処理をどう表現すべきか、という議論がありました。「在庫不足」は状態や条件であり、それに応じて「通知する」ことはポリシーです。一方、「在庫が補充された」は明確な「起きた出来事」であり、イベントに該当します。
ポイント：イベントは「既に起きた確定事項」、ポリシーは「起きたことに対する反応やルール」として整理します。
2. 時間経過の表現手法
時間を契機とする処理（例：「3日経過したら自動キャンセル」）は扱いが難しい要素です。ここで成瀬さんは、地球のマークから着想を得て、現実世界の経過時間を「丸い円」で表す独自手法を紹介しました。「3日が経過」という現実世界で確実に発生する事象を“イベント”としてモデル化し、その後に「キャンセルされた」といったイベントが発生する流れを表すことで、時間要件を自然に組み込めます。
3. 人間の柔軟性を前提にしたモデリング
システムで全てを厳密に定義しようとすると、現場運用との乖離が生まれがちです。人間はモデル化されていないイレギュラーな状況にも柔軟に対応できます。そのため、全てをポリシーやイベントで網羅せず、ある程度は人間の判断に委ねることで、現場に即したシンプルなモデリングが可能になります。
4. リードモデル（読み取りモデル）の柔軟な活用
リードモデルは、ビジネス上の状態をわかりやすく示すためのビューやサマリー的な存在です。ワークショップでは、「注文」という大きな括りで捉えるのではなく、「未出荷注文」や「キャンセル注文」といった、もう少し具体的な粒度でリードモデルを表現するアイデアが示されました。
こうすることで、巨大な「注文」モデルを精緻化し続ける必要がなくなり、必要な観点ごとに異なるリードモデルを柔軟に用意できます。データベーススキーマや実装構造と1対1で対応させる必要はなく、「ビジネスが何を必要としているか」を明らかにするガイドとして活用することで、後からでも細分化や統合が容易になります。
5. チーム構造と境界設定の現実的アプローチ
理想的なドメイン境界を先に描き、それに合わせて組織を再編することは理論上は有効ですが、現実には難しい場合がほとんどです。既存のチーム構造や人員配置を踏まえた上で、最善の境界を定める現実路線のアプローチが有用です。必ずしも「完璧な」ドメイン設計を目指す必要はなく、今ある資源や組織構造を生かしつつ、徐々に改善していく考え方が成功の近道となります。
実務知の共有と説得力
ワークショップ中に紹介されたプロジェクト事例は、理論を実務へとブリッジする役割を果たしました。「いつ、誰を巻き込むか」「イベントをどの粒度で定義するか」といった、書籍だけでは掴みきれない「肌感」を得ることで、今後のプロジェクト運用に具体的な指針が得られました。
今後に向けて
今回得た知見は、単なる理論的理解を超えています。正しいイベント定義やポリシー分解、現実世界を反映した時間要件の扱い、リードモデルの柔軟な使い方などを組み合わせることで、より自然で実務にフィットしたモデル設計が可能となります。これらは、今後のプロジェクトにおいて、ドメイン理解の深化とステークホルダー間の合意形成をスムーズにする強力なツールとなるでしょう。
追記
本記事は、あくまで私個人の理解に基づいた要約・考察であり、誤解や不正確な点が含まれている可能性があります。また、Event Stormingには「正解」と呼べる明確な手法が存在するわけではなく、プロジェクトやチームの状況に合わせて手法を変え、実践を通じて学びを深めていくことが重要です。
今回、成瀬さんというエキスパートの指導のもと、ワークショップ形式で実際に体験できたことに大変感謝しています。ご指導くださった成瀬さん、そして主催してくださったUMTPの皆さま、誠にありがとうございました。来年も同様の機会があれば、ぜひまた参加したいと思います。
追記の追記
チームでも実践したいのだけれど、私の語学力では英語でやるのは難しすぎる。どうしたもんかなあと。
Discussion