初めてイベントストーミングにチャレンジして学んだこと全部まとめます

こんにちは、ギークプラスの今村です！今回から Geekplus Tech Blog として、物流ベンチャーであるギークプラスのソフトウェア事業部より、日々の開発で得られた知見や備忘録など、様々な記事を投稿していきたいと思います。

まず初回となる本記事では、先日社内で実施したイベントストーミングに関してまとめたいと思います。2025/11/10 から 2025/11/12 までの 3 日間、AWS Japan の下川さん、落水さん、林さんに多大なご支援をいただき、社内でイベントストーミングのワークショップを実施することができました。

今回は、組織としてはじめてイベントストーミングにチャレンジしてみて、得られた学びを共有できればと思います。

背景

我々が開発している SCM (Supply Chain Management) ソリューションの "skylaa (スカイラー)" は、大きく 2 種類の機能を持っています。

• 倉庫間オーケストレーション: カスタマーから受けた出荷指示などの物流データを skylaa が接続されている全国の適切な倉庫へルーティングする機能
• サプライチェーンプランニング: カスタマーが保有する商品在庫を各地にどう配分すればよいか需要を予測し計画を立てる機能

1 つ目の倉庫間オーケストレーションは以前から存在する機能で、ソースコードの母体も大きい中で今後の機能拡張に課題を抱えており、どうリファクタしていくかを検討するフェーズにあります。2 つ目のサプライチェーンプランニングは比較的新しい機能で、これからユーザーインタビューなども通じて磨き上げていく段階にあります。また、双方に通ずる課題感として、Biz と Dev のコンテキストの齟齬や、ユビキタス言語の構築に苦戦しているという悩みもありました。

プロダクトとして全く段階が異なる両機能に対してイベントストーミングを実施できたことは、チームとしても大きな経験値となったと感じており、うまくいったと感じた部分もあれば、適用が難しかった部分もありました。こちらは最後の振り返りにて記載します。

プロセスの流れ

イベントストーミングでは「ドメイン」や「コンテキスト」という言葉が多用されます。誤解を恐れずに言えばドメインとはいわば「業務」や「ビジネス領域」のことであり、ドメインをシステムの観点で区切ったものが「コンテキスト」と呼ばれます。たとえば YouTube Live のようなドメインであれば、配信というコンテキストやコメント管理といったコンテキストが考えられます。イベントストーミングは、ドメインに対する理解度を高め、適切なコンテキストの境界を見定めていくことでソフトウェアの設計に活かしていくための試みです。

他のイベントストーミングの記事にもあるとおり、イベントストーミングは大きく以下の 3 つのプロセスを通じて実施していきます。

• Big Picture
• Process Modeling
• Software Design

やり方としては、種類に応じて色分けされた付箋をホワイトボードにどんどん貼っていき、チーム内の理解やコンテキストを揃えていきます。今回はオンサイトでホワイトボードを使い実施していきましたが、慣れてきたら miro などのホワイトボーディングツールを使っていく方がずっと早く完了できるかと思います。

また、イベントストーミングを進めてドメインを見つめ直す中で「ここはどうなんだっけ？」と新たに疑問が浮かぶポイントが出てくることがあります。これらはホットスポットと呼ばれ、目立つ付箋でマークしておくことで、「チームが理解しきれていない、またはリスク・曖昧さ・問題が潜む領域」として後で深掘り、調査、意思決定に活かすことができます。今回のワークショップでは濃いピンクの付箋を使い疑問点をマークしていきました。

Big Picture

対象とするドメインにおいて発生するイベントを洗い出す作業のことを Big Picture と呼び、洗い出されたイベントのことを「ドメインイベント」と呼びます。ドメインイベントとは「何がどうなったか」のことであり、過去形で記載をしていきます。

ドメインイベントの洗い出し

ドメインイベントの洗い出しで重要となるのがドメインエキスパートとの協業です。弊社が担う物流やサプライチェーンといった業界は、エンジニアに限らず多くの方にとって馴染みがない領域です。そのため、ドメインに理解のある Product Manager と密なコミュニケーションを取ることが重要になってきます。また、エンドユーザーの視点で考えることもあわせて重要であり、この段階ではできるだけ具体的に、なるべく幅広いスコープで、ドメインエキスパートとともにイベントを洗い出していきます。

映画の予約システムを例に考えると、「映画を公開した」や「映画館を選択した」あるいは「映画の予約をキャンセルした」などは、ドメインイベントと言えます。ここでは「誰が」という実行の主体を書く必要はなく、誰がそのイベントを引き起こすかは後の Process Modeling で整理されます。また、参照系は業務の状態を変えないことから、重要でないかぎりは、基本的にドメインイベントとして洗い出さなくても良いものとされています。

ドメインイベントの整理とスイムレーンの検討

洗い出したドメインイベントは、ブレストしていると内容が重複することもあるため、同じ内容と考えられるものは一つにまとめて整理します。整理が終わったら、今度はこれらをイベントが発生する時系列順に並び替えていきます。

並び替えていく中で、並列に実施されるイベントや、条件分岐で実施されるイベントが見つかることがあります。これらはスイムレーンと呼ばれ、ホワイトボードに横線を引いて分割し整理します。

ピボタルイベントの検討

通り過ぎると後戻りができないドメインイベントを「ピボタルイベント」と呼びます。たとえば映画の予約システムでは、「チケット代を支払った」というイベントは、おそらく後戻りがしづらいと考えられます。このようなイベントはコンテキストの境界になりやすいため、マークをしておくことで、後にコンテキストを切り出すときの目安として考えられることができます。

弊社の場合だと、カスタマーの出荷指示に対して、出荷実績と呼ばれる「出荷の結果」が返却されるのですが、一度出荷実績を返却すると後戻りが難しいため、ここがピボタルイベントとしてマークされました。ピボタルイベントは、そのイベントに対してホワイトボード上で縦線を引いてマークします。

Process Modeling

Big Picture の結果をもとに、ソフトウェアの詳細な流れをモデル化していくプロセスを Process Modeling と呼びます。整理されたドメインイベントが、どういった起因をもとに、どのような実行主体が発生させたのかを記載していきます。

コマンドの明確化とアクターおよびポリシーの特定

コマンドとは「ドメインイベントを引き起こす原因」のことで、ここまで過去形で記載してきたドメインイベントを現在形になおしたものがコマンドとなります。たとえば「映画館を選択した」がドメインイベントとすると「映画館を選択する」がコマンドですので、ここは機械的に出していくことができるかと思います。

コマンドを一通り作成し終わったら、今度はそのコマンドを誰が実行しているのかを洗い出していきます。実行主体となるのは、以下の 2 種類に分けられます。

• アクター: いわゆる「人」のことで、ユーザーが意図的にコマンドを実行する場合はアクターとする。
• ポリシー: 業務ルールのことで、なんらかのドメインイベントの発生に伴い、アクターを介さずにコマンドが自動で実行される場合はポリシーとする。

弊社を例とすると、アクターは「物流事業者」などがあり、ポリシーは「欠品していた在庫が補充された」などが考えられます。アクター、ポリシー、コマンド、ドメインイベントまで整理ができると、「誰が何をしてどうなるか」が決定できます。

リードモデルの抽出

アクターやポリシーがなんらかのコマンドを実行するには、多くの場合、そのコマンドを実行するに至った判断基準となるデータが必要です。特にアクターは、何も考えずにコマンドを実行するということは基本的になく、何も判断基準がなくコマンドを実行できるならアクターは不要なはずです。たとえば予約する映画館を選択するには、「見たい映画を公開している映画館の一覧」がデータとして必要になります。このようなデータをリードモデルと呼びます。

リードモデルは、時系列順で前に存在するドメインイベントから生成されます。たとえばさきほどの「見たい映画を公開している映画館の一覧」は、「見たい映画を選択した」というイベントがあってはじめて得られるはずです。

弊社の場合、サプライチェーンプランニングの機能では、需要予測などの結果をもとに、メーカーなどに発注指示を出す業務があるのですが、skylaa で自動算出された発注リストを参考にしつつカスタマーは手動で発注数を調整する必要があります。このとき、「自動算出された発注リスト」はリードモデルといえます。

集約と外部システムの特定

コマンドとドメインイベントの間には、それを実際に実行する何らかのシステムが存在するはずです。たとえば「映画館を選択する」というコマンドを受けて「映画館を選択した」というドメインイベントを発生させるのは、映画館の予約システムと言えるでしょう。

次に、そのシステムが自身で管理する対象にあるものか、管理外のものかを特定していきます。このとき、自身で管理できるものを「集約」、管理外のものを「外部システム」と呼び、外部システムにあたるものには何らかの名前をつけておきます。たとえば、倉庫間オーケストレーションの機能では、対向システムとなる倉庫管理システム (Warehouse Management System) は管理外となるため、外部システムとして WMS など名前を付与しておきます。

集約および外部システムは、コマンドとドメインイベントの間に付箋を貼って管理していきます。今回は薄いピンクの付箋を使いました。

Software Design

Process Modeling の成果を受けて、実装に入るためのソフトウェアの設計図を構築するのが Software Design です。このフェーズは突き詰めるとかなり奥が深いのですが、弊社では今回、コンテキストマップの整理を行うところまでをゴールとしました。

集約が持つビジネスルールの定義

Process Modeling で集約と外部システムを分離しましたが、その中で集約は自身で管理する対象となるため、その集約がどのようなビジネスルールで動作するのかを記載していきます。ビジネスルールは大きく 4 種類の内容を書いていきます。

• ロジック: コマンドにより実行される内容のこと。もっとも自明になりやすいので、悩んだときはロジックから書き始めるとよい。
  • 例: 「商品の在庫数を減少させる」
• 前提条件: ロジックが実行されるために満たしていなければならない条件のこと。
  • 例: 「商品の在庫数が 1 以上であること」
• 完了条件: ロジックを実行完了とみなす条件のこと。
  • 例: 「商品の在庫数が減少していること」
• 不変条件: ロジックの実行前後で変わらない恒常的な条件のこと。値オブジェクトにおけるバリデーションルールなどに用いられる。
  • 例: 「商品の在庫数が 0 未満でないこと」

これらのビジネスルールは、さきほどのプロセスで貼った集約の付箋にそれぞれ記入していきます。

集約の命名

ここまで完了したら、作成した内容について時系列を崩し、同じデータを取り扱う集約をまとめてひとつの集約にします。整理した時系列はあとで参照したいこともあり得るので、miro などのホワイトボーディングツールを使っているときは、バックアップを取っておくとよいかと思います。まとめてひとつの集約としたものは、同じデータを取り扱っていることから、1 つあるいは少数のテーブルと対応しやすく、データモデリングにおいてもヒントになり得ます。また、トランザクションの単位にもなりやすいと言えるでしょう。

集約をまとめたら、それに対して適切な名前を付けていきます。ここで付けられた名前は、ドメインエキスパートと会話する際のユビキタス言語として使うことができると、互いのコンテキストに齟齬が生じづらくなるかと思います。

集約のグルーピングとコンテキスト境界の決定

以下のような基準をもとに、集約をグルーピングします。

• データの整合性を保たなければいけない範囲
• 集約を取り扱う開発チームの組織構造
• 機能追加など変更が発生する際に影響を与える範囲

モノリシックなシステムだからといって、コンテキスト境界が 1 つになるというわけではないという点には注意が必要です。コンテキスト境界が分かれていれば複数サービスに分割できる余地はあるかもしれませんが、それをモノリシックに作るかどうかはアーキテクチャ選定の問題です。

コンテキストマップの作成

コンテキスト境界を決定したら、互いに依存関係があるかどうかを書き出していきます。

たとえば、たびたび例として出している映画の予約システムにおいて、なにかを予約するには映画が必要といえるため、予約と映画には互いに依存があると考えられます。加えて、予約を行う際には映画の情報を参照するため、予約は映画がないと存在できませんが、映画は予約がなくても存在することができます。つまり、予約 -> 映画という依存関係が成立します。

このようなコンテキスト境界間の依存関係を矢印でマッピングしたものが、コンテキストマップです。コンテキストマップができてくると、その間を API で連携するのか、イベント駆動で疎結合にするのか、あるいはデータベースを共有する形にしてしまうのかなど、連携方式を検討することができます。

今回のワークショップでは、このコンテキストマップの作成までを完走しました。

振り返り

イベントストーミングを、ある程度成熟した機能と発展途上な機能という 2 種類に試す機会が得られたことで、様々な学びが得られました。

成熟している倉庫間オーケストレーションの機能については、比較的バッチの処理が中心ということもあったことや、すでに存在する機能を前提に考えてしまうことで、エンドユーザーの視点から業務をあらためて見直すことが難しく感じました。また、発展途上であるサプライチェーンプランニングの機能では、Product Manager から見てもまだ業務に曖昧な点があることで、後続のモデリングに落としていくことの難しさがありました。

いずれにせよ、イベントストーミングという思考プロセスにある程度慣れていく必要や、技術に明るくないドメインエキスパートとワークショップを行う場合はエンジニアが議論をリードしていかなければならないなど、チームとしてレベルアップしていかないと使いこなすことは難しいかなと感じました。

一方で、既存の開発プロセスに対し、小さく徐々に取り入れていくという戦略も有効だと思っています。たとえば、Big Picture をドメインエキスパートとともにブレインストーミングしつつ、ホットスポットを見つけて互いの疑問点を解消していく活動は、コンテキストの認識齟齬を無くしていくために非常に有効だと思います。また、カッチリしたドキュメントを作るのではなく、付箋をもとにディスカッションしていく形式なので、デジタルなツールを使っていれば後の変更が容易という点も気に入っています。特にスタートアップでは、要求がかなり曖昧な時点からプロダクト開発が始まることも多く、変更容易性をどう保てるかも開発プロセスを考えるにあたって重要なポイントになります。

生成 AI により開発のスピードが飛躍的に向上しても、現実にあるビジネスを俯瞰し実装に落とし込むことは代替できないため、ビジネスと実装を繋ぐイベントストーミングというプロセスは今後より注目されてくるのではないかと思っています。

いずれにせよ銀の弾丸はないと思うので、良いと思ったプラクティスを柔軟に取り入れて、自社に適した開発プロセスに磨き上げていきたいですね。

末筆になりますが、あらためてご協力いただいた AWS Japan の皆様に感謝を申し上げたいと思います！

↓↓↓ 実施したイベントストーミングの模様 ↓↓↓