AWSさんにイベントストーミングワークショップを開催して頂きました 第2弾
第1弾ではスポットバイトルでイベントストーミングを行いましたが、
今回は本体プロダクトである バイトル での実施となりました。
私ごとですが、以前スポットバイトルのチームに所属していたため、今回が2回目の参加です。
貴重な機会を再びいただけたことに感謝しています。
今回のイベントストーミングは、全6日間にわたって実施されました。
Day1
初日は、現場で感じている業務のもやもややボトルネックをとにかく付箋に書き出しました。
「普段言語化されない課題が見える化される」という体験は、ワーク全体のスタート地点としてとても意味がありました。
このフェーズの目的は、現場のリアルな課題をチーム全体で共有することでした。
業務改善やシステム設計の議論を始める前に、共通の土台を築くための重要な話し合いに感じられました。
Day2
DDDの座学に加えて、コーヒーショップを題材にした演習を実施しました。
座学では、
DDDの思想・マインド、モデリング原則、実装パターンを学びました
この日は、DDD(ドメイン駆動設計)の基本思想を学び、その後にコーヒーショップを題材にした演習を行いました。
座学
座学では、DDDの3つの要素を学びました。
-
思想・マインド:
- タスク思考から脱却し、「なぜそれを作るのか?」という価値と向き合い続ける
- タスクをこなすのではなく、価値の変化を見続ける姿勢が重要
-
コラボレーション:開発者・企画者・デザイナーなど関係者全員で共創し、背景や想いを共有する
- 共通言語(ユビキタス言語)を定義することで、誤解なく認識を合わせられる
-
モデリング原則:
- 複雑な現実をシンプルに整理し、本質だけを抜き出す
- 複雑さには「本質的な複雑さ」と「余計な複雑さ」があり、後者は積極的に削ぎ落とす
ワークショップでは、
「顧客がコーヒーを注文する」というシンプルなシナリオを使い、イベントの流れを貼り出していくことで、実際のイベントストーミングの感覚を掴むことができました。
テーマ:コーヒー屋台の業務の可視化
- メニューは1種類のみ(サイズも1つ)
- 支払いは現金のみ
- 商品はすぐに渡す
🪶 Step 1:業務ストーリーを書く
まずは、屋台でのやり取りを物語として書き出します。
DDDで言うと、業務イベントを洗い出し、時系列に並べていきます。
例:
客がコーヒーを注文する
客は代金を支払う
店員がコーヒーを作る
🧩 Step 2:概念収穫(名詞・動詞・制約を整理)
次に、業務イベントの中から、業務ロジックを生み出すようなキーワードを洗い出します。
洗いだしたキーワードの定義を行なっていきます。
これを 「概念収穫」 と呼びます。ユビキタス言語を定義する土台にもなるため、重要なステップになります。
概念収穫 例
名詞 客、店員、注文、支払い、コーヒー
動詞 注文する、支払う、提供する
制約 メニューは1種類のみ、支払いは現金のみ
🧱 Step 3:責務でグルーピングする
DDDにおける「責務」とは、業務イベントを洗い出した後、それぞれの登場人物や概念がどの行動や判断を担うか、何をしないかを明確にすることです。
この段階ではまだ集約などは決まっていないため、「誰がこのイベントを起こしたのか」「何を決定したのか」「どんなルールを守る必要があるのか」を言葉で整理します。責務を定義することで、後のモデリングで概念の境界や関係を明確にできます。
役割 責務
客 コーヒーを注文する/現金で支払う/コーヒーを受け取る
店員 注文を受け付ける/支払いを受け取る/コーヒーを提供する
実際の業務でイベントストーミングを行う際も上記のステップで進めていくため、
初めてイベントストーミングを導入する際の良い練習になり、
社内での導入前に非常に使いやすいテーマだと感じました。
Day3
2チームに分かれて Big Picture を作成。
実際に業務イベントを洗い出そうとすると、新規の場合はこのフロー、既存の場合はこのフローと多くのパターンが出てきてしまい、時系列に並べることが難しくなってしまいました
講師の方にアドバイスいただき、まずはシンプルに進めていくため、1パターンのみの正常フローのみの業務イベントを洗い出すことになりました。
💡 ポイント
- Big Pictureとは、業務全体を俯瞰し、関係者間で共通認識を作るための図。
- 初期段階では「正常フローのみ」に絞るのが推奨。
Day4
Day4ではチームを統合し、Big Pictureで洗いだしたイベントそれぞれの概念収穫を考え、大枠のコンテキスト分割を行いました。
さらに、各コンテキストの集約・エンティティを整理する設計に入りました。
🗺 コンテキスト分割の考え方
イベントをグルーピングしていくと、自然に「業務のまとまり(コンテキスト)」が見えてきます。
例
- 注文コンテキスト:注文の受付・金額の確定
- 決済コンテキスト:支払いの実行と確認
- 提供コンテキスト:コーヒーの準備と引き渡し
それぞれが独立した責務を持ちつつも、全体の業務フローとしては密接に関係しています。
⚙️ 集約(Aggregate)の整理
次に、各コンテキストの中でどんな集約(Aggregate)が存在するかを考えました。
「状態を持ち、振る舞いを担う単位」として、どこまでをひとつの集約とみなすかを議論します。
例として、注文コンテキストで考えると:
- 注文(Order) … コーヒーの数量・金額・状態を保持
- 顧客(Customer) … 注文を起点にイベントを発生させるアクター
- 支払い(Payment) … 現金支払いの完了状態を管理
🧩 責務と制約の整理(補足)
各コンテキストの中で、再度「誰が何を担い」「どんな制約があるのか」を明確にしました。
以下はその一部です。
例 コンテキスト 主な責務 主な制約
注文 注文を受け付ける/金額を確定する メニューは1種類のみ
決済 現金の受け取り/支払い完了の記録 支払い方法は現金のみ
提供 コーヒーの準備/顧客への引き渡し 提供は支払い後すぐに行う
ここまで整理すると、
それぞれの責務・制約がどのコンテキストに属するかが明確になり、
ドメインの境界がよりはっきりしてきます。
Day5・Day6
システムと直結する業務にフォーカスし、コンテキストの分割をさらに深掘りしていきました。
開発者視点と業務視点の両方をぶつけ合うことで、より現実的な切り方に近づいていきました。
最終日は、システムに関わる業務イベントの洗い出しをブラッシュアップしつつ、責務・ポリシーの定義を整理しました。
特に印象的だったのは、「どの領域から先に手をつけるべきか」という優先度の議論。現場の課題感と技術的観点の両方から意見が出て、次の一歩が見える形になりました。
社内でのイベントストーミングの開催
AWSさんとのイベントストーミングでは主に toB側の業務領域 を中心に進めていたため、
toC側の業務理解を深める目的で、社内で独自にイベントストーミングを実施しました。
2時間のセッションを4日間にわたって開催し、
これまでの2回のイベントストーミング参加で得た知見を活かしながら、
今回は自分がチームのファシリテーター役として進行を担当しました。
実際にリードしてみると、「場を回しながらアドバイスをする」講師のような立ち回りの難しさを強く実感しました。
議論の方向性を見極めながら進行するのは、想像以上にエネルギーを使う作業でした。
AWSさんの講師の方々がどれだけ瞬時に課題を整理し、次の一手を導いていたかを身をもって感じました。本当にすごいです。
🧭 まとめ
イベントストーミングに2回参加し、社内でも自ら開催・進行できるだけの知識と経験は少しずつ身についてきたと感じます。
しかし、実際にリードしてみると、講師の方々がその場で「どう考え、どう導くか」という判断力や知識の深さにはまだまだ及ばないことを痛感しました。
「あの場面で講師さんならどう考えただろう?」と感じる瞬間が何度もありました。
💬 議論の価値を再認識
特に印象に残ったのは、コンテキスト分割のフェーズです。
ここでは「正しい答えを出すこと」よりも、
「なぜそう考えるのか」「なぜその境界を引くのか」をチームで対話することに意味があると感じました。
イベントを軸に議論を重ねることで、
- 境界をどこで引くか
- 責務をどこまで持たせるか
- どんな情報を共有し、どこから独立させるか
といった設計上の感覚が少しずつ磨かれていきます。
抽象的な理論を具体的な業務ストーリーに落とし込む──
まさにDDDらしい思考のプロセスを体感できました。
💡 継続する意義
イベントストーミングに参加するたびに感じるのは、
単に業務理解が深まるだけでなく、チーム全体の思考の解像度が上がっていくということです。
ドメインに関する知識が増えるほど、対話の質も自然と高まっていくのを実感します。
💬 “Good design is a byproduct of good conversations.”
─ Alberto Brandolini(イベントストーミング提唱者)「良い設計は良い対話から生まれる」──まさにそれを体感した6日間でした。
おまけ
AWSさんのオフィスに招待いただいたため、ここぞとばかりに社食をいただきました
肝心の写真がありませんが、バナナジュースが100円で安い上に絶品でした!!
忘れられない味です。。。
Discussion