こんにちは。Woven Payment Solution開発グループの小野です。
私達のチームは Toyota Woven City で使われる予定の決済プラットフォームの開発を行っています。少し古い内容ですが、私達のやっていることについてはこちらをご覧ください。 20220422 Woven City Tech Meetup Tech Talk by Rie Ono

今回は私達の決済システムを設計する際に利用したDDDのモデリング手法の一つ EventStorming を使っています。まだ研究途中なのですが、現時点で分かったことをご紹介しようと思います。

EventStorming とは

Alberto Brandolini さんが提唱したシステムをモデリングするためのワークショップ形式の手法です。
EventStormingのサイトを参照すると、以下のように書かれています。

EventStorming is a flexible workshop format for collaborative exploration of complex business domains.
(意訳）Eventstormingとは複雑なビジネスドメインを協業的に探求するための柔軟なワークショップフォーマットです。

また、 Learning Domain-Driven Design のChapter 12.EventStorming には以下のように書かれています。

EventStorming is a low-tech activity for a group of people to brainstorm and rapidly model a business process. In a sense, EventStorming is a tactical tool for sharing business domain knowledge.
(意訳）EventStormingはメンバーからアイデアを引き出し素早くビジネスプロセスのモデルを形作るためのローテクなアクティビティです。もう一方ではEventStorming はビジネスドメインの知識を共有する戦術的なツールです。

つまり、以下のような目的のためのワークショップです。

• 難しくないやり方でドメイン知識を有識者から引き出す
• ステークホルダーへドメイン知識を共有する
• ドメインモデルを設計する

EventStormingのための準備

誰に参加してもらうのか？

上記の Learning Domain-Driven Design には参加者の人数は10人以下が望ましいと書かれています。人数が多すぎると発言に躊躇したり、意見をまとめにくかったりするかもしれません。
また異なったバックグラウンドの人を集めることでいろいろな発見があるかもしれない、と書かれています。それらを踏まえると、参加する人を選ぶのが最初の難しい課題になるかもしれません。

ファシリテーター

フェーズごとに時間を区切ったり、途中で話が広がりすぎたりしないように調整するファシリテーターがいると良いです。私達の場合は、設計を行うエンジニア自身が担当しました。

エンジニア

アプリケーションを設計・開発するエンジニア。
私達の場合は当チームのメンバーに加え、ネイティブアプリを開発するアプリチームのメンバーにも、ドメイン知識を共有する目的で参加していただきました。

ドメインエキスパート

ドメインエキスパートは対象のドメインについて深い知識を持つ人です。既存のシステムや他社のビジネス、その分野に詳しい人を集めましょう。EventStormingの目的としてはソフトウェアの設計のための他に、ドメインエキスパートの人たちから知識を吸い出すことにもあります。
私達の場合、幸いなことにビジネスチームには決済業務に携わってきたメンバーが多く在籍しており、協力していただけることになりました。
また、私達のチームをリードしている亀井は過去に決済分野に携わっており、決済とエンジニアリングの両方の視点から指摘ができる方です。

UI/UXデザイナー、QAエンジニア

今回は実現できなかったのですが、できればアプリケーションの開発に関わるUI/UXデザイナーとQAエンジニアも含まれていると良いと思います。業務知識を共有してUI/UXやQAの設計の効率化が図れます。

準備するもの

EventStormingは時間がかかります。事前の準備をすることでスムーズに進行できるようにしましょう。

• 参加者のスケジュール確保
  • 参加者の時間をできれば1日か半日は抑えたいところです。いろいろなチームから人を呼ぶので、全員が参加できるスケジュールを押さえるのが困難とおもいますが、重要です。
• 場所
  • やはりオフラインだと発言がしやすい気がします。
• いろいろな色の付箋
  • 図のような色の付箋を準備します。
    
• ホワイトボード・マーカー
  • 付箋を貼っていく大きいホワイトボードとマーカーを準備しましょう。
• リラックスのためのお菓子や飲み物
  • を準備…したかったのですが、感染症対策のため断念しました。
• 前提の知識
  • EventStormingを開始する前や、事前のテキストコミュニケーションとして、今回作ろうとしているシステムの目的、前提、すでに決まっている事項など、を共有し、ある程度の前提知識を持ってもらいました。
  • また、初対面同士の参加者が発言しやすいように、それぞれの簡単な自己紹介時間を用意しました。
  • 今回は英語でEventStormingを行ったので、ファシリテーションのやり方やドメイン知識についての英単語を事前に調べておきました。

感染症予防のため対面時間を短縮する方法を考えてみた

Alberto BrandoliniさんはRemote EventStormingで、リモートで行うのは難しいという旨を書かれています。ですがこのご時世なので、オンラインでもできないか試してみました。

• オフラインで実施する場合は、感染症対策のために、密にならない程度に広く、それでいて集中できる会議室や広場を準備しましょう。
• オンラインで実施する場合はMiroが便利でした。
  • 使いやすいテンプレートがあります。 Judith Birmoser's Event Storming template | Miroverse
• 対面時間を短くするために、少人数メンバーで後述のPhase2までたたき台をつくっておきました。実施時には全参加者にレビューしてもらい、足りない箇所を追加してもらったり、間違っている箇所を指摘してもらいます。

やってみた

ここからはEventStormingをどのように進めたかを書いていきます。

Phase1 : Big picture

まずはビジネスプロセス全体を明らかにするため、Big Pictureをつくっていきます。
ブレインストーミングしながらドメインイベントをオレンジ色の付箋に書き出していきます。例：「決済が行われた」
各ドメインイベントについて意見を出した人に説明してもらい、重複したものを取り除いたり、正しい理解かをドメインエキスパートに確認したりして、リファインメントし、時系列に並べなおしていきます。

Phase2: Process Modeling

次に、Event間のプロセスをモデリングしてきます。
洗い出したEventに以下の付箋を追加していきます。
Actorを黄色で追加します。 誰が、または何がコマンドを実行するのかを考えます。
Eventの原因となるコマンドを青色で追記します。
View modelができるならばを緑色に書き出します。
Policyを紫色で書き出します。このPolicyの考えが私としては難しいと感じています。コマンドの前提や条件を書き出すみたいです。
なにか疑問やリスクになりうる事項があれば、赤色の付箋に書き出しておきます。
ドメインエキスパートには、イベントの内容や時系列が正しいかチェックしていただいたり、質問に答えていただきます。

Phase3: Software Design

次に、まとめられそうなコンテキストについて詳細に考えて行き、コーディングが始められる状態にしていきます。
ビジネスドメインとしてデータの整合性が保てる範囲としてまとめられそうな箇所をAggrigate（山吹色）としてまとめてみます。
外部システムを介す場合はピンク色で追加します。
サブドメインとしてひとまとまりにできそうな箇所を区切ってみます。
この時点でUIが定義できそうならば、ペーパープロトタイプを作ってみるのも良いと思います。
だいたい出来上がって来たら、赤色の付箋について詳細にディスカッションしてみるか、すぐに結論が出せないならば、そこを別の機会に深堀りEventStormingします。

その後

ここまできたら、抜け漏れがないか、逆順にたどっていきます。
Software design as a cooperative game with EventStorming
また、私達の場合は全体のドメインを洗い出したあと、スコープを絞って更にEventStormingを行ったりしました。

やってみた感想

以下は、EventStormingをやってみてよかった点です。

• 業務を知っているであろう人に、個々にヒアリングに行って要求や仕様を作成するよりも網羅的、偏らない、事業把握ができる。かえって時間がかからないかもしれません。
• いっぺんで数人のメンバーへ知識の共有・確認ができるのも良い点だと思いました。
• 一度やってみて、ゼロから何かを作るときにやると効果が大きいだろうな、と思ったのですが、考えているものの答え合わせという効果もあると感じました。
• 副産物として、
  • モデリングをするうちに、忘れていた・見えなかった課題が見つかった
  • その業務内容を初めて知るメンバーによる初心者目線での疑問が課題提起となる場合があった
  • 普段、あまり顔を合わせることのないメンバー間でのつながりを作ることができた

以下は難しかった点です。

• 時間がかかるので、メンバーのスケジュールを抑えること、加えて、集中力を持続させるのが難しいと感じました。
• ファシリテーションが難しい。これは慣れの問題であるので、回数を重ねていけば解決するかもしれません。
• また、自分としては英語でファシリテーションをしたりディスカッションをするのも大変で、練習していきたいと思っています。特にドメインエキスパートの方々は日本の商習慣に特化した決済についての説明を英語で行うのは、かなり大変だったと思います。

これからの課題

これからもEventStormingができる機会があれば、回数を重ねてエンジニアメンバーがEventStormingをファシリテートできるようになれば良いと思っています。
また、このEventStormingで洗い出せたドメインを実際のコードに落としていくステップをもう少し研究したいです。
例：

• ドメイン記述ミニ言語に落としてみる
• イベントソーシングへの応用

以上、EventStormingをやってみた感想でした！