EventStormingの進め方：返品業務を題材にしたワークショップ

返品の流れは、フローチャートにすると単純に見えます。申請、承認、受領、返金という順序です。ところが、サポート担当者、倉庫担当者、開発者に「承認」の意味を尋ねると、三通りの答えが返ってくるかもしれません。顧客が商品を返送してよいという意味、商品が検品に合格したという意味、決済への指示が受け付けられたという意味です。

EventStorming（イベントストーミング）のワークショップでは、業務上意味のある出来事を一つの物語として並べ、このような認識の違いを見つけます。この記事では、架空の小売業者の返品業務を例に、食い違う説明を、実際の担当者と検討できるモデルへ整理する方法を紹介します。

プロセスモデリングで扱う範囲を決める

Alberto BrandoliniによるEventStormingのProcess Modelling形式は、既存の業務を理解したり、新しい業務を設計したりするためのものです。特定の業務の流れを検討するときに適しています。Big Pictureはより広い業務領域を見渡し、Software Designは実装に関わる検討へ踏み込みます。短い会議で三つすべてを終えようとしないことが大切です。

返品の例では、範囲を「顧客が購入した商品を一つ返品し、返金を受けるか、返品が認められない理由を知らされるまで」と書きます。交換、仕入先からの補償、不正の調査は、最初の検討には含めません。業務との接点には印を付けつつ、それらの話題でボード全体が埋まらないようにします。

サポート、返品処理、決済、開発など、この流れを異なる立場から説明できる人を招きます。返品方針を決める権限のある人も重要です。開発者だけで集まると、ソフトウェアの動きは正確に説明できても、その前後で従業員が行っている仕事を見落とすことがあります。

担当者が具体的に説明できる業務イベントから始める

最初から順序を統一しようとせず、まず参加者がイベントを追加する時間を取ります。ドメインイベントは、「返品が申請された」「商品が検品された」のように、業務上意味のある、すでに起きた事実を表します。オレンジ色の付箋に過去形で書きましょう。「商品を検品する」はこれから行う行動、「商品が検品された」はその結果です。DDD Crewの用語集には、この表記とプロセスモデリングで使う他の概念が説明されています。

各担当者に、自分の業務から具体例を挙げてもらいます。倉庫担当者は「荷物が受領された」、サポート担当者は「返品ラベルが送付された」を追加するかもしれません。どちらも開発者の最初の説明にはなかった出来事です。同じような付箋があっても、本当に同じイベントか確認するまでは残します。

画面の表示名やデータベースの項目名を、そのまま使う場合は注意が必要です。「ステータスが更新された」だけでは、業務上何が変わったのか分かりません。顧客や担当者にとって、何が事実になったのかを尋ねます。「返金が完了した」も、指示の送信、決済事業者による受付、精算の確認のどれなのかを定義しましょう。それぞれの後で異なる判断をするなら、別のイベントに分けます。

返品の流れを一緒にたどる

イベントを一つの流れとして並べ、参加者に声に出して説明してもらいます。この例の最初の案は、「返品が申請された → 返品が承認された → 荷物が受領された → 商品が検品された → 返金が依頼された → 返金が確認された」となります。

これは例題について話し合うためのモデルであり、すべての小売業者に共通する返品方針ではありません。実際のチームが商品の受領前に返金するなら、その順序を描きます。検品と別の作業を独立して進められるなら、別々の列に置き、一方が必ず他方を待つように見せないようにします。

BrandoliniのConversational Systemパターンも、同時に進む処理や順序が変わり得る振る舞いに、固定の順序を無理に当てはめないよう注意を促しています。重要なのは付箋をきれいに並べることではなく、何が何に依存しているかです。

意見が食い違ったら、そのイベントの近くに鮮やかなピンク色のHot Spotを置きます。「方針の問題」ではなく、「返品の承認は返金を保証するのか？」のように疑問として書くと、検討しやすくなります。周辺の流れが見えるところまで進めてから、必要な担当者とその疑問に戻ります。

イベントに行動と判断材料を結び付ける

イベントの流れが理解できたら、それを起こす行動を追加します。コマンドや行動は青い付箋に書き、誰、またはどのシステムが始めるのかを示します。判断に必要な情報も、振る舞いを説明するために役立つ場所だけに加えましょう。最初からすべての記号を導入すると、業務を話し合う場が記法の講習になってしまいます。

返品業務の一部を詳しくすると、次のようになります。

ポリシーは、イベントを受けてどのように反応するかを表します。この例なら、「検品で返品が認められたら、返金を依頼する」というルールを提案できます。該当するイベントと行動の間に薄紫色の付箋で置き、方針の責任者が確認するまでは提案として扱います。線を引いただけで、そのルールを決める権限が得られるわけではありません。

返金の依頼と確認の間にある隔たりにも注目しましょう。同じイベントとして扱うと、応答の遅れや依頼の重複を見落とす可能性があります。その場で決済システムの設計を完成させる必要はありませんが、違いは見えるようにしておきます。

通常と異なる返品を一つ当てはめる

通常の流れを描いたら、検討内容が変わる例外を一つ選びます。例えば、届いた荷物に、あるはずの商品識別情報がない場合です。サポート担当者には顧客の注文が分かっていても、倉庫では中身がその注文の商品か確信を持てません。

参加者に続きを説明してもらいます。「商品が検品された」はすでに起きていますか。それとも「荷物が受領された」だけでしょうか。誰が追加情報を求められますか。どのイベントでサポート担当者は対応が必要だと分かりますか。「誰かがメッセージを送る」という答えなら、送信者、受信者、伝える業務上の事実まで具体化します。

空欄を埋めるために、期限や返金を受ける権利を作り上げてはいけません。未解決の方針上の疑問を、関係する付箋の横に置きます。BrandoliniのRush to the Goalパターンでは、異論や別案を見える状態にしながら、基本となる流れを作ることを説明しています。すべての例外が解決するまで話し合いを止めるよりも、この段階では役立ちます。

業務の振る舞いを理解した後で、別途例外経路のフローチャート（英語）に運用上の分岐を詳しく描けます。その前に、分岐の前提となるイベントの意味を関係者でそろえるのがEventStormingの役割です。

Boardmixで返品業務のモデルを作る

Boardmixを開き、返品業務を話し合うための空白のボードを作成します。横に広い作業領域を取り、その上に検討範囲を書きます。片側には小さな凡例を置き、イベント、行動、ポリシー、Hot Spotを色だけに頼らず区別できるようにします。

付箋を追加する前に、記号の意味を参加者と確認しましょう。色とラベルを併用したホワイトボードの凡例があると、同じ記号を同じ意味で読めます。別のワークショップの色分けを流用せず、ここで使うEventStormingの意味を保ってください。

1. 最初の流れにある六つのイベントを、オレンジ色の付箋で置きます。通話中にも読める文字の大きさにします。
2. イベントの間に、青い行動の付箋を入れる余白を残します。「返金を依頼する」は「返金が依頼された」の前に置き、イベントと置き換えないようにします。
3. 検品結果の横に、提案中の薄紫色のポリシーを加えます。参加者が話し合った関係だけを線で結びます。
4. 「返品が承認された」の横に、ピンク色で「返品承認＝返金保証？」と置きます。未解決の疑問は、その影響を受ける振る舞いの近くに残します。
5. 適切な編集権限を設定してボードを共有します。業務の各担当者に一人ずつ流れを説明してもらい、他の参加者が付箋を補足・修正します。

オンラインでは、誰かが説明している間、全員が同じ部分を見られるようにします。意見の割れている領域を複数人が同時に並べ替え始めたら、編集を一度止め、それぞれの案を説明してもらいましょう。ボードは会話を支える道具です。付箋が素早く動いていても、合意できているとは限りません。

モデルが示すことと、まだ確かめていないことを分ける

見た目が完成していても、ソフトウェアがそのとおりに動くこと、方針が承認されたこと、重要な例外をすべて見つけたことの証明にはなりません。確認できた振る舞いと変更案を分けます。新しい返金の順序を考えたなら、何を変えるのか分かるよう、現在の流れも残しておきます。

この小売業の例でまず得られる成果は、曖昧なイベント名を直す、例外の承認者を確認する、決済結果が不明なときの扱いを調べる、といった具体的なものです。業務担当者と開発者は、同じ疑問から次の検討を始められます。「承認」の意味をもう一度最初から話す代わりに、残されたピンク色の付箋から議論を再開できます。