結論
- イベントストーミングは、仕様決定、業務フロー図の作成、チーム内での知識の共有、オンボーディングに使える
- イベントストーミングの成果物のドキュメントは、開発、外部への説明、オンボーディングに使える
自己紹介
2019年、大手SIer企業でソフトウェアエンジニアとしてキャリアをスタートしました。複数のWebアプリケーションのプロトタイプ開発に携わり、設計から実装まで幅広く経験を積みました。
2024年に医療系ITスタートアップであるSave Medical社に転職し、現在はフルスタックに開発を行っています。ここでアサインされたプロジェクトで、初めてドメイン駆動設計に出会いました。
イベントストーミングをやってみた背景
プロジェクトの概要
従業員向けのアンケート作成・配信および集計管理を行うWebアプリケーションを開発するプロジェクトです。
また本プロジェクトでは、ドメイン駆動設計を採用するという挑戦をしました。試行錯誤しながらドメインに基づいた設計をすることで、要件の整理や実装の明確化を有効的に行うことができました。
プロジェクトの状況・課題
- MVP作成までの開発期間7か月のうち、5か月目
- 主要な機能は実装できていたが、実装していくうちに出てきた仕様の疑問や、実行権限を整理できていなかった
- 途中から参画したメンバーに対して、プロダクトの業務フローや価値観を共有しきれていなかった
イベントストーミングとは？
イベントストーミング（Event Storming）は、ドメイン駆動設計の手法の1つで、ビジネスプロセスやシステムの挙動を視覚化・共有するためのワークショップ形式のモデリング手法です。
実施の流れ
参加者
参加者は、以下の5名です。プロダクトにかかわる全員が参加しました。
- ファシリテータ 1名
- PdM 1名
- デザイナー 1名
- エンジニア 2名（著者を含む）
時間
3時間程度
使用したツール
FigJamを使用しました。物理的な紙で行う場合もありますが、リモートでの参加者がいたためと、デジタルデータで保存したいためです。
用意した付箋
FigJamで以下の付箋を用意しました。各要素の詳細な説明は割愛します。
イベントストーミングの流れ
書籍「ドメイン駆動設計をはじめよう」（Vlad Khononov）の12章「イベントストーミング」に沿って行いました。詳細は、本書をご参照ください。
ステップ1: 発散的に探索する
業務イベントを発散的に洗い出します。
業務イベントは、他のメンバーとかなり重複しますが、気にせず進めます。
ステップ2: 時系列に並べる
ステップ1で洗い出した業務イベントを、業務で発生する順番に並べます。
足りない業務イベントに気づくので、このステップで追加します。
また、重複した業務イベントの付箋は、このステップで削除しました。
ステップ3: 問題点を洗い出す
プロセス全体で注意が必要な箇所を特定します。
私たちのチームでは、例えば「サーベイプランの開始を、現状手動で開始している。開始日来たら自動で開始にしたい」のような問題点が挙げられました。
ステップ4: 転換イベントを見つける
文脈やフェーズの変化を示す重要な業務イベント（転換イベント）を見つけ、垂直線を引きます。
このステップで文脈やフェーズが区切れたことで、今まで煩雑にイベントが並んでいたものが整理できたように感じました。
ステップ5: コマンドを見つける
イベントを指示するコマンドと、そのコマンドを実行するアクターを追加します。
私たちのプロジェクトでは、アクターは、「システム管理者」「チーム管理者」「メンバー」の３種類となりました。
本プロジェクトのこの時点で、コマンドのアクターは、チーム内で曖昧になっていました。
ここの議論に時間をかけることで、どのコマンドでどのアクターが実行するかを決定し、チーム内で認識を合わせることができました。
ステップ6: ポリシーを定義する
アクター以外に、コマンドを実行する「自動化ポリシー」を洗い出します。
私たちのプロジェクトでは、「開始日がきたら、サーベイプランを開始する」などの自動化ポリシーが見つかりました。
アクターが実行しないコマンドを探すと、自動化ポリシーを見つけやすかったです。
ステップ7: 読み取りモデルを見つける
読み取りモデル（read model）は、アクターがコマンドを実行するかどうか判断するために使う、対象領域の状況を表現するデータのビューです。
私たちのチームでは、読み取りモデルとして「質問集一覧」「従業員情報を記載したCSV」などが挙がりました。
読み取りモデルの洗い出しには初めは少し苦戦しましたが、実際にはデジタルデータであっても、アナログな業務をするときにどんな情報を元にするかを考えると、洗い出しやすかったです。
ステップ8: 外部システムを追加する
業務領域の外側に存在するシステム（外部システム）を追加します。
本プロジェクトのこの時点では、外部システムとの連携は無かったため、該当項目が無いことを確認し、本ステップは飛ばしました。
ステップ9: 集約を見つける
すべてのイベントとコマンドを洗い出したら、関連する概念を集約として整理します。
なお、本ステップを実施しやすくするために、業務イベントとコマンド以外の付箋は削除しました。
私たちのチームでは、集約5つという結果になりました。モデリングを行っていたエンジニアとしては、集約はこんなに少なくていいんだという感想を持ちました。
ステップ10: 区切られた文脈に分割する
区切られた文脈に分割します。
私たちのチームでは、「Save Medicalの文脈」「顧客企業の文脈」の2つの文脈に分けるという結果になりました。
結果
成果物
ステップ8までの成果物として、時系列に並んだ業務フロー図ができました。
ステップ10までの成果物として、集約・文脈を考慮したモデル図ができました。
ふりかえり
イベントストーミング実施後、ふりかえりを行いました。以下、参加者５名の意見をまとめています。
よかったこと
仕様が曖昧であった箇所を固めることができた
ステップ5でアクターを考えたことで、曖昧であったロールや権限を整理することができました。
例えば、「システム管理者」と「チーム管理者」がどちらが行うか曖昧なイベントがありました。ここでは、MVPであることを考慮し、プロダクト全体で1イベントにつき1アクターと絞る決定をしました。
チーム内での理解を合わせることができた
- 対話の中で、PdMの、プロダクトに対する価値観を共有することができました
- プロジェクトの途中から参画したメンバーに対して、価値観や業務フロー全体を共有することができました
- チーム内で統一できていない用語（ユビキタス言語）を洗い出すことができました
成果物が有用である
成果物がそのままドキュメントとして使えることはとても有用だと感じました。
以下のようなときに使えると思っています。
- プロジェクトメンバーが業務フローやモデルを振り返る
- 新しく参画するメンバーへのオンボーディング
- プロジェクト外部への説明
よくなかったこと
現在の実装に引っ張られてしまう
特にエンジニアは、現在の実装に引っ張られてしまうと感じました。例えば、コマンドをどのアクターが実行するかです。
その際は、PdMやファシリテータに、このプロダクトがどうあるべきか(to be)の議論に戻してもらい、最終的に決定することができました。
逆にas isはエンジニアが一番よく知っていることが多いと思うので、そこは役割分担すべきところかなと思います。
時間がかかる
プロトタイプレベルで合計3時間かかりました。イベントストーミングは、そもそも時間のかかるワークショップのようです。
今回イベントストーミングのやり方を一から説明しながら進めたため、参加者がやり方を理解していれば、時間はもう少し短縮できると思います。
一方、機能が増えたらさらに時間がかかると思われるため、部分的に実施するなど工夫は必要そうです。
今後やってみたいこと
プロジェクトの開始時にやってみたい
今回はプロジェクトの途中に開催しましたが、プロジェクトの開始時に開催したら、より有用だと思います。イベントストーミングを通じて、業務フローやモデリングを決定することができるからです。
機能追加するときは再度行いたい
今後、仕様変更や機能追加するときは、またイベントストーミングを実施して、仕様決定やモデリングを行いたいです。
その際は、集約や区切られた文脈は今回とは異なるように区切ることになるかもしれません。
オンボーディングにも使えそう
プロジェクト全体の理解をチーム間で深めることができるので、新しくプロジェクトへ参画する人に対する、オンボーディングに使えそうだと感じました。
おわりに
今回はじめてイベントストーミングをやってみましたが、とてもよい体験でした。
挙げられた改善点を反映して、また実施したいです。
参考文献
イベントストーミング実施と記事作成にあたり、書籍「ドメイン駆動設計をはじめよう」（Vlad Khononov）の12章「イベントストーミング」を参考にしました。
Discussion