執筆者
M.N.
イベントストーミング
PHPカンファレンス2025の振り返り、第8回です。
今回は「イベントストーミング図からコードへの変換手順」というセッションについてです。登壇者はコドモンのCTOの方でした。
イベントストーミングという言葉は聞いたことがなく、完全に初耳の状態で聴講しました。
設計の話、ということはタイトルからなんとなくわかりましたが、何の図なのかは聞いてみるまでわかりませんでした。
イベントストーミングとは
ビジネスプロセスを関係者全員で可視化するためのワークショップ手法です（セッションでは「ビジネスプロセスモデリング図」とも呼ばれていました）。
付箋を使ってドメインイベントや登場人物、コマンドなどを洗い出し、業務の流れを図にしていきます。
セッションでは、この図を構成する要素として以下が説明されていました。
イベントストーミング図の構成要素
・アクター
コマンドを実行する主体（人やシステム）
・コマンド
何らかのアクションを実行する要求
・集約
コマンドを処理するオブジェクト（メソッドを持つオブジェクト）
・イベント
ビジネス上で発生した重要な出来事や事実
・リードモデル
データの読み取りに最適化されたデータ構造やビュー
・ポリシー
自動化された判断ロジック（空欄のポリシーは「必ず」という意味
・外部システム
対象システムの境界外にあるシステム
付箋の色や種類によって要素を区別し、特定の付箋からしか繋げられないというルールがあるそうです。
イベントストーミング（図と進め方）
図の読み方——2つのパターン
イベントストーミング図には、大きく2つの流れのパターンがあると説明されていました。
◆パターン1
リードモデルから始まるパターン。アクターがリードモデルを確認し、コマンドを実行する
◆パターン2
ポリシーが中継するパターン。あるイベントの発生を受けて、ポリシーが次のコマンドを自動的にトリガーする
起点はどこからでも始められますが、よくある起点はアクター、イベント、リードモデルとのことでした。
実際の進め方
セッションでは、イベントストーミングを実際に進める方法として「ワーキングセッション」と「ヒアリング」の2種類が紹介されていました。
◆ワーキングセッション
チームで集まって一緒に図を作る方法
◆ヒアリング
ステークホルダーへの聞き取りをもとに図を起こしていく方法
どちらの場合も、開発者だけでなく業務担当者も交えて進めることで、認識のズレを早期に発見できる、という点が強みとして挙げられていました。
イベントストーミング（図→コード→AI）
図からコードへ——そしてAIへ
セッションのタイトルにある「コードへの変換」という部分ですが、登壇者の方がとった実際のアプローチは「設計図をAIに渡して書かせた」というものでした。
これには会場からも笑いが起きていましたが、登壇者の方は真剣な話として話されていました。
イベントストーミング図という構造化されたドキュメントがあれば、AIへの指示として使える、という実践的な話です。
カンファレンス全体を通じて感じましたが、このセッションでも生成AI利用の話が自然な形で出てきました。
設計ドキュメントをAIへのインプットとして使う、という発想は、設計の価値が「コードを書くため」だけでなく「AIに書かせるため」にも広がってきているということだと思います。
イベントストーミングの付き合い方
セッションの最後に、イベントストーミングとの付き合い方として以下のコメントがありました。
✓ 従来的なプログラム設計でもある程度役に立つ
✓ 図で全てを表現することは目的ではなく、役立つドキュメントとして活用するのがおすすめ
「完璧な図を作ることが目的ではない」という言葉は、ツールや手法に振り回されがちなエンジニアとしてはすっと腑に落ちました。
振り返ってみての所感
イベントストーミングは、このセッションで初めてきちんと概念を学びました。
ビジネスとエンジニアが共通の言語で話せる図を作る、という発想は④のBDDのセッションとも通じるものがあります。
「開発者以外にも伝わる設計」というテーマが、カンファレンス全体を通じた一つの流れになっていた気がします。
実際に業務に導入できるかというと、BDDと同様にすぐには難しいとは思いますが、「設計の段階でビジネス側と共通の図を作る」という文化はいずれ持ちたいな、と感じました。
次回は最終回として、カンファレンス全体の所感をまとめたいと思います。
お読みいただきありがとうございました。
