☁️
AWSさんにイベントストーミングワークショップを開催して頂きました

ディップ株式会社
2025/04/17に公開
こんにちは！ディップ株式会社スポット開発部で、スポットバイトルの開発を担当している町永俊介です。
本日は、ドメイン駆動設計（DDD）を学ぶために、AWSの金森さん、福井さんにイベントストーミングのワークショップを開催していただきました！ DDDを学びながら、実際の業務課題を整理する貴重な機会となりましたので、その内容をレポートします。

 スポットバイトルとは？まず簡単に、私たちが開発している「スポットバイトル」についてご紹介します。
スポットバイトルは、スキマ時間で「働きたい」と「働いてほしい」をつなぐ求人マッチングサービスです。

独自機能「Good Job ボーナス」により、企業から「Good」評価を受けると、時給にボーナスが上乗せされる仕組みが特徴です！

 開発の課題とDDDへの期待2024年11月にサービスインしたスポットバイトルですが、いくつかの構造的な課題を抱えています。
スポットバイトルは、大きく以下の3つのシステムとチームから構成されています。
ワーカー（求職者）用
クライアント（雇用者）用
カスタマーサポート用
それぞれのシステムで、フロントエンドとAPIが1対1の関係で存在し、すべてのAPIが1つのデータベースを参照・更新する構成となっています。

システムとチームの境界は「対システム利用者」に基づいていますが、実際の業務ルールはこの境界をまたぐものが多数存在しており、次のような課題が生じていました。
同様のビジネスルールを含むロジックが複数システムに分散している
1つのデータベースに複数の業務モデルが混在し、実装が複雑化している
たとえば、給与の計算ロジックが複数システムに実装されていたり、機能追加の度にテーブルのカラムが増殖を続けてカラムの用途が曖昧になったりといった具合です。
これらの課題を解決するために、DDDのアプローチでのリアーキテクチャを検討していました。しかし、開発スピードを優先する必要から着手しづらい状況と、そもそもDDDの十分なノウハウを保有していなかった事もあり、現行のアーキテクチャのまま拡張を続けてきました。
今回リアーキテクチャを推進するために、AWSさんにヘルプを求めたところ、今回のワークショップをご紹介いただき、開催が実現しました！

 ワークショップの概要ワークショップは2日間にわたり、AWSさんのオフィスにお邪魔して開催して頂きました。

ドメインエキスパートを含むPO（プロダクトオーナー）とエンジニア合計13名の都合をなんとか調整し、非常に濃密な時間をすごしました。
僭越ながら開会の挨拶をする私。しっかりろくろを回しています。

 座学初日は、AWSの金森さんによるDDDの講義からスタート。

DDDの概要と、今回のワークショップで実践するEvent Stormingの概要について以下のようなことをお話頂きました。

DDDとは

業務を素直にシステムに落とすための設計手法である。
DDDでないシステムで起こる問題
DDDの戦略が解決するもの
業務とシステムの壁を低くし、エンジニアと業務担当者のコミュニケーションを円滑にする



戦略的DDDと戦術的DDD
戦略的DDD: 業務をモデリングする設計理論
戦術的DDD: モデリングされた業務をシステムに落とす手法


Event Storming
DDDの実践は難しい
境界づけられたコンテキストとモデルを簡単に抽出するための手法

非常にわかりやすく、参加者全員がうんうんと頷く場面が多々あったことを覚えています。
ところで、質疑応答にて弊社エンジニアからこんな質問が飛びました。
「DDDのデメリットとして挙げられるものは何でしょうか？」
これに対する金森さんの回答（「いい質問ですね」と言ってくれた気がする！）は、「モデリングを行い開発を進めるため、開発工数がかかる。小規模なものや、中核事業にあたらない業務領域のシステム化には、DDDが最適解でない可能性がある。」との事でした。

 Event Stormingさて、いよいよEvent Stormingの実践です。Event Stormingは先の座学で学んだところの戦略的DDDにあたるところで、スポットバイトルの業務から境界づけられたコンテキストとモデルを抽出していきます。
Event Stormingは次のステップを繰り返し行うことで進行していきました。
Big Picture
Process Modeling
Software Design

 １．Big PictureStep1: Eventの洗い出しと時系列化最初に、業務におけるイベントの洗い出しを行います。
ユーザー視点で
過去形の動詞で
洗い出すのがポイントとのことです。
黙々とイベントを書き出しています
続いて、洗い出したイベントをホワイトボードに貼り、時系列に並び替えます。

各々が思い思いに貼った付箋が、金森さんの進行により綺麗に整理されていきます。
カオスな状態の付箋が綺麗に並び替えられていきます
Step2: Pivotal Eventのマークイベントを洗い出し、時系列に並べることが完了したら、Pivotal Eventというイベントをマークします。Pivotal Eventは、分割点となるイベントのことで、後戻りが難しくなるイベントや、主体が切り替わるイベントにつけていくそうです。

我々の場合は、以下のようなイベントがPivotal Eventとしてマークされました。
主要なPivotal Event
ここでは主要なものをピックアップしましたが、これだけでおおよその業務フローとビジネスモデルが把握できる情報量となっていることが見てとれます。
Step3: スイムレーンを引く続いて、並列で実行されるフローや分岐するフローを見つけ、スイムレーンを引きます。時系列化の時点ですでに金森さんが並行処理や分岐処理を意識して付箋を整理してくださっていたので、ここではほぼ線を引くだけでした。
スイムレーンによって、業務フローがよりわかりやすく可視化されます。
Step4: 関係者、外部システムを洗い出す関係する人々と外部システムの洗い出しを行い、付箋を貼り出します。

我々のシステムの場合、主な登場人物は以下の通りです。
ワーカー
クライアント
弊社営業
弊社カスタマーサポート
登場した外部システムとしてはつぎのようなものが挙げられました。
SendGrid
Auth0
LIQUID eKYC
自社他システム
ここまででこんな感じになりました
Step5: ナレーション、ウォークスルー最後に、整理した業務フローを、順に読み上げて検証をします。

声に出して人に説明することで、理解が一段深まり、曖昧な点が明らかになります。
ナレーションウォークスルーをする私。厳しいチェックの目にさらされます

 2.Process Modelingここまでで、おおよそイベントと関係者の時系列化がされました。

ここから先のProcess ModelingとSoftware Designは、これまでに整理したBig Pictureからモデリング箇所を選出して繰り返し行なっていきます。
Big Pictureに、さらに次の付箋を足してフローを再整理します。
コマンド
何かを起こしたという意思決定。イベントはコマンドの結果として発生している。

リードモデル
ユーザーの意思決定をサポートするための情報を表す。

システム
コマンドが受け取って、イベントを発行するシステム

ポリシー
イベントとコマンドの間に存在し、暗黙/明示的に行われるアクション。自動化されていることも手動のこともある。
ポリシーは名前付けにこだわる必要はない。

今更ながら付箋の色とルール。「アクション」はコマンドを意味します

 3.Software DesignSoftware Designでは、いよいよ集約と境界づけられたコンテキストを見つけていきます。

イベントとコマンドを論理的なグループにわけ、間に集約（システム）の付箋を貼り付けます。

そのあと、集約に、名詞で名前づけを行います。
1日目はBig Pictureから選出した1箇所を整理したところで終了となりました。
2日目は1日目で整理しきれなかったフローのProcess ModelingとSoftware Designを繰り返し行いました。
グルーピングと名前付けがなかなかに難しく、付箋が行き来したり、名前が二転三転することもありましたが、最終的に、我々の業務は境界づけられたコンテキストによって9つにわけられそうだという整理が行えました。
境界づけられたコンテキストと集約
コンテキストマップ
この後、福井さんから戦術的DDDについての講義をして頂き、リアーキテクチャの実践フェーズに移行する為のネクストアクションを確認してワークショップは終了。
実は、2日目の業務フローで整理に時間を要した影響で、福井さんの講義はかなり駆け足での進行となってしまいました。 実践フェーズでもAWSさんにはサポートをお願いしているため、戦術的DDDについてはあらためての講義などをお願いする事としました。

 ワークショップを終えて想像以上に有意義な時間を過ごす事ができ、本当にお願いして良かったなという感想です。
ドメイン駆動設計についての理解を深められた
これはもちろんなのですが、有識者のもとでワークショップを行なったことで、境界と集約の発見のコツを掴めた気がします。

ドメイン知識が強化された
POを交え、全業務領域の担当者が集うことで、おのおの不足領域の知識を補完しあう良い機会となりました。ドメイン知識の有無は仕事の品質に直結しますので、今後の品質向上にもつながるもののはずです。
また、意外と自分の担当領域でも把握できていないという場面もあり、そういった気付きを得られたのも良かったと思います。

リアーキの方向性がみえた
コンテキスト境界と集約を見つけたことで、参加者全員でリアーキの方向性に共通認識を形成できた事を大きな成果と感じています。これがなければ手探りでリアーキを進めて、あらぬ方向に向かってしまっていたかもしれません。

全体を通じて、金森さん、福井さんの進行に非常に助けられました。

我々だけでは、考え込んでしまうような場面において、都度気付きの問いかけをしたりと、我々を導いてくださいました。

お二方のおかげて適切な議論と、納得感のある成果をだせましたので本当に感謝です。
また、多くの方の時間を頂戴し、良いワークショップを実施できましたので、リアーキの実践もしっかり推進しなければと身の引き締まる思いです。

今後のリアーキの進捗についてもあらためて本ブログでお伝えできればと思います。

 付箋の剥がし方ちなみになのですが、付箋は上にめくるように剥がすと良くないということを学びました（丸まって扱いづらくなる）

下に引っ張るか横方向に剥がすのが良いそうで、地味に有用な学びなので、ブログにも記載しておこうと決めました。
2日間ワークショップを実施してくださった金森さん、福井さん、そしてサポートしてくださった古川さん、德永さん、堀田さん、坂本さん、本当にありがとうございました！
最後に記念撮影。スポバのCMポーズをみんなでして頂きました