新しいモデリング手法: EventStorming (イベントストーミング) をはじめるための準備
EventStorming (イベントストーミング) というモデリング手法があります。
EventStorming is a flexible workshop format for collaborative exploration of complex business domains.
EventStormingは、複雑なビジネスドメインを協同的に探求するための柔軟なワークショップ形式のひとつです。（意訳）
考案者はAlberto Brandolini氏で2013年にはブログに最初の投稿がされています。 海外での認知度は高く*1、Eric Evans氏のプレゼンテーションの中でも強力な手法であると言及*2されています。
近々、この手法を試せる機会が来そうなので、そのやり方について（私見を交えつつ）まとめてみるエントリです。
注意
現在進行系で勉強中です。 また、私の英語力の問題により本家と異なる解釈をしてしまっている可能性があります。 現時点で私の理解が足りていない部分には注釈を付けています。 必要に応じて原典等をご参照ください。*3
前置き: ソフトウェア開発の大きな嘘
Alberto Brandolini - 50,000 Orange Stickies Later - YouTubeのなかで氏はソフトウェア開発の大きな嘘について言及しています。
- ビジネスを理解して動くコードに翻訳する
- 要件があって、その要件をコードに翻訳する
は、完全に悪質である。 ビジネスサイドの人間はビジネス（全体）のことを知っていると仮定しているが、それは誤りで、よく理解しているのは自分の領分（ビジネスの一部）のことだけである。 （意訳）
ビジネスはいくつもの領域があり、それらが複雑に関与しあって織りなされています。 このとき、それぞれの知見やアイディアを統合・活用し、一貫した Narrative/Story を構築する手法としてEventStormingがあります。 同じ部屋に集まってイベントを順番に並べていくと、仕事の関連が見え始め議論が始まり、お互いのタイムラインの違いが可視化されます。
Brandolini氏の著書*4（以降、"書籍"とはこれを指します。）のなかで、「我々が暮らす世界は互いに影響を与えあう相互依存のネットワークであり、そのため予期せぬ振る舞いをするが、インセンティブや付加的ポリシー*5を並び替えることでシステムレベルで人々の振る舞いを変えられる可能性がある（意訳）」とも紹介されています。
行動の結果（成果）に着目してモデリングを行うことで、トップダウンにものごとを分解していく*6静的な構造の分析からはじめるモデリングよりも相互の関連がわかりやすくなりプロセス上の問題を発見しやすくなる効果があります。
最後に得たい結果（ゴール）をイベントとして置き、それはどういう行動や決断によって起きるものかを逆算していくことで、領域を跨いだ骨子となるプロセス（フロー）をすばやく見つけることに主眼があるように思います。
そうすることでコアドメインを見つけ出し、また、重要な問題・ボトルネックを可視化することにつながっていきます。
LeanやUXなどの考え方を跨いだ共通の言語としても機能することが期待され、コラボレーション（共創）を促進することが新たな洞察をもたらします。
やり方
というわけで、ようやく本題です。
EventStormingは、よくあるワークショップのようにいくつかの色の付箋と大きな壁を使って行います。 簡単であることは重要なポイントです。 UMLやBPMNのように表記法を覚える必要がなく、（作業を順番に行う）単純なルールであることで、どんな人でも気軽に議論に参加できる余地があります*7。
0. 準備
まず、ワークショップの目的を確認します。 なぜこのワークショップを行うのかが分かっていないと、効果的な人を集めることも何を起点にすればよいのかもわかりません。 後述しますが、パースペクティブに合わせてモデリングスコープや道具が変わってくるため、ここは整理した方が良いでしょう。
そして、適切な人を集めます*8。 「適切な」とは、先述のように複数のビジネス領域のキーとなる人たちを指しているようです*9。 また、ドアは常にオープンにしておくべきかなと思います。
スムーズに進行するためにファシリテーターも一人求められます。 議論が重視される手法であるため、フォーカスすべきことを見失わないようガイドを設けた方が良いでしょう。
EventStormingは、大きな作業エリアを使うワークショップです。 書籍などでは、壁一面にロール紙を貼って付箋を並べていくことが推奨されています。 こうすることで、全体を俯瞰して可視化することができます。
オンラインツールで代用できるか？
EventStormingは、異なる関心の人を集めて共創を促進することがメリットの一つです。 これは、各人が自分のタイムラインをつくることを文字通り Storming できることが必要です。 自分で書き出していくことで、参加者となり、賛同者となります。
自分たちの問題（ペイン）を吐き出すことで、他者に伝えることができるとともに多くの問題のある箇所が明白になります。 それは、新たな洞察を得ることにもつながっていくと考えられます。
そのため、オンラインツールでは次の要素が必要とされるでしょう。
- 複数人で一斉に操作できる（待たない）
- 議論にすばやく参加できる（リアルタイムに同じものを見れる）
- 参加者が十分に慣れている
1. キーイベントをタイムラインに並べる
対象となるスコープのなかで起きるイベントを付箋に書いて、発生順*10に並べていきます。 このとき、次のことに注意します。
イベントは過去に起きた出来事です。 これが過去形にならない場合は、何かが間違っている（複雑さが隠れている）シグナルと捉えることができます。 ただし、そこで作業は止めません。 その付箋を斜め45度に傾けるなどしてマークするのみにしておきます。
タイムラインを書き出すことを最優先にします。 ドメイン実務者に詳細を説明してもらう前にプロセスを先にモデリングしきります。 言葉探しもこの時点では極力しないようにします。 言葉探しをしてしまうと、スローダウンすることになってしまいます。
手が止まりがちな場合は、次のようなことで促します。
- ビギナーとして質問する
- とりあえず一つイベントを置く
イベントで考える利点として、何かひとつ起点があれば自然と前後が繋がりだすことにあります。 また、過去に起きた出来事として考えるため、何かしらのとっかかりを持つことができます*12。
タイムラインを書き出していると、いくつかクリティカルな問題*13や疑問が見つかる（思い出す）ことがあります。 ただし、タイムラインを出すことが最優先であるため、問題にフォーカスしすぎたり、解決策をそこで探すことはしません。 紫色の付箋に問題を書いてイベントの近くに置くことで忘れないようにします。 この付箋の数が多いところほどペインポイントとして可視化されていきます。
付箋の色は固定でなければいけない？
基本的には同じ色を使うことが推奨されます。 それは次の効果をねらってのものです。
- 異なる色を使うことによる混乱を防ぐ
- 慣れてくると色の並びからパターンを文字通り視覚的に見つけることができるようになる
この後に出てきますが、色の他にサイズで見分ける部分もあるため、準備が少し大変かもしれません。 まず試してみたいということであれば有り物で始めて、良さそうな感触を掴んだら本格的に準備するでも良いでしょう。
2. 議論、議論、議論
タイムラインを書き出したら、詳細を確認したり、問題として残しておいたこと*14について議論を深めていきます。 議論によって、コンテキストのなかで明瞭な意味を持つ言葉が出てきたら、その定義を特別な付箋にしてフローの上に置いておきます。
開発者の目線からも質問や発見があるでしょう。
ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。
ー ドメイン駆動設計 p.27
ドメイン実務者と開発者は、お互いにチェックし合うことでお互いの理解を深めることができます*15。 沢山のWhyを議論することで、良い気づきを複雑な領域に対して得られるはずです。
議論のなかでドメイン実務者が「たぶん」「よくわからない」（no idea）と言うことがあれば、それはまだ十分な情報が無いとか、システムの重要な要件である可能性があります。 先述したようにドメイン実務者もすべてを知っているわけではないため、色々な視点から探索することも必要です。 新しい問題を見つけたのなら、紫色の付箋を追加しておきます。
3. 外部システム（組織やサービスなど）との連携を可視化する
すでに外部システムに依存していることが分かっているのであれば、大きめのピンクの付箋に書いて残しておきます。 これは、（このモデリングで検討している）新しいシステム（ソフトウェア）とやり取りがあることを残すためのものです*16。
4. （ビジネス）フローの特定のエリアにラベルを付けておく
全体の出来事のタイムラインができてきたら、"顧客登録" や "クレーム" や "詐欺検査" といったようなラベルをある程度のエリアにつけていきます。 これは、次のような範囲です。
- 独立して実装できる範囲
- （比較的）目的がよく定義される範囲
後でまた見直すことになる*17ため、この段階では正確さやクリーンな境界である必要はありません。
5. 作ったモデルを見直す
ここまで議論をしていれば、最初の時点よりも理解が進んでいるはずです。 付箋をより正確にしたり、ものによっては捨ててもよい*18ことが見つかるため、これを反映します。
場合によっては、複数のコンテキストの接合点において、重要なキーとなる情報が何であるかを見つけるかもしれません。
6. イベントを起こすコマンドを探す
ユーザーのintention, action, decisionを示すものとしてコマンドを青色の付箋として加えていきます*19。
イベントの前に現れるものではありますが、先の外部システムがあれば、それを呼び出すこともコマンドです。 この場合、コマンド→外部システム→イベントというタイムラインになります。
基本的にはイベントの対となる言葉があてられるように思います。 たとえば、イベントがXxxReservedであれば、コマンドはReserveXxxのようになるでしょう。
7. コマンドを起こすアクターを出す
ここでいうアクターは、主に現実世界の人のことを指しているように思います*20*21。 薄黄色の付箋にどんな人かを書いてコマンドの前に置きます。
そして、アクターは何故そのステップを踏むのか考察します。 コマンドを起こす理由を知ることで、新たな気づきにつながる可能性があります。
8. アクターがコマンドを起こす際の判断材料を出す
どうやって、そのアクターはコマンドを出せるのか、その判断材料が何であるかを次に検討します。 これはRead Modelと呼ばれ、緑色の付箋を使って書き出します。
ただのデータという観点ではなく、アクターが決断するために必要な材料という観点で考えます。 それはUXにも関連するものであり、心や思考の変化を汲み取るものでもあります*22*23。
9. イベントに対するリアクション（反応）を見つける
「〜するときには〜（whenever）」という言葉に注目すると、イベントに対してリアクティブに起きるコマンドを見つけることができます。 例えば、「しきい値を超えたら通知する必要がある」というようなことです。
これをポリシーと呼び、薄紫色の付箋に書いてタイムラインに追加します。 基本的には、イベントと次のコマンドの間に必要となるものです。
それは、
- 暗黙的（同意を得ずに行われる）かもしれない
- 明示的（誰かが行う）かもしれない
- 自動*24かもしれない
ですが、必ずイベントと次のコマンドの間に現れてくるものです。先の手順でアクターを見つけていれば、そのアクターが明示的に手動で行うこととポリシーを見つけることができます。 仮にポリシーが見つけられないのであれば、何か見落としがあるシグナルと考えることができます。 議論のなかで、アクターが手動で行う必要がなく自動的に適用できるポリシーであると発見できれば、それはシステムの新たな価値につながると考えられます。
早期にpolicyを見つけられることは有益です。 それは、次の理由から、実装するかの判断を遅らせられるためです。
- 顧客が十分獲得できるまでは払い過ぎのコストになる恐れがある
- 手動のものを自動化するのは成長とフィードバックを待てる
何かを発見するためにソフトウェアを開発するよりも、先にこれらの情報を獲得できる方が有益でしょう。
10. Aggregateを探す
EventStormingはDDDの考えを取り込んでいるため度々DDDの用語が登場しますが、Aggregateもその一つです。 これは、コマンドとイベントをグループ化したもので、淡黄色の付箋で表します。
Aggregateはビジネスフローのなかで、ローカルの小さな意思決定をすることが役割（状態に応じて、コマンドを受け付けるのか、Rejectするのか）です。 つまり、ステートマシンのようにもみることができます。
責務駆動で、データではなく、振る舞いに着目して名前を見つけていくことが肝要です。 そのため、ここまでの手順のなかでAggregateを見つけたとしても、すぐに名前を付けることは後回しにすることが推奨されます。 名前を最初に付けてしまうとデータに注目してしまうため、振る舞いがはっきりしてから、もっともと思う名前を付けるようにします。
Aggregateは複数のコマンド＆イベントのペアをとる可能性があります。 そのため、この作業を行うとタイムラインを崩すことになるかもしれません。 責務でまとめていくことは、タイムライン順であることとは異なる見方であるからです。
11. スコープを狭めて、新しい事前条件にフォーカスしていく
ここまでで大きな絵（Big picture）ができました。 参加者の間で知識の共有が行われ、重要な問題やボトルネックが紫の付箋でひと目で分かる状態になっていれば成功といえるでしょう*25。
重大な問題にフォーカスしてスコープを狭めながら、名前を書き換えたり、バリエーションを探求したり、より正確な表現に更新したりすることで次のアクションが見えてくると思います。 それを要件に落とし込んでいくことで、明確な理由または仮説をもって開発に取り組むことができるでしょう。
なぜ大きな絵が必要なのか
書籍のなかにある次の文がよく言い表しているかと思います。
People won't self organize around a system they don't understand
People won't self organize around a system they can't influence
大きな絵のどこが重要なフローといえるのか、どこでペインが溜まっているのかを俯瞰できるということは、参加者の視座を引き上げる効果がありそうです*26。 もし、ドメイン実務者と離れて仕事することになっても、自分で判断できることが増える点もメリットに思います。
全体像
書籍ではコマンドまでを出すと、次のような全体の関心（付箋）の関連を表す図が提示されます。 コマンドを出した次は、より洗練させていくフェーズ*27であるため、なぜさらなる作業を行うかの事前知識としてコンパクトにまとまっています。
EventStormingに初めて取り組んでみる際には、最初にこのような図を提示しても良いですが、Incremental notationの考えに則り（最初から全体を見せず）順番にステップを踏むこともできます。 参加者の傾向に応じて検討した方が良いでしょう。
ドメインイベントを見つけるヒント
ドメインイベントは、何らかの結果です。
- コマンドにより発生
- 外部システムから発生
- 時間経過で発生
- 何かのイベントの成り行きで発生（whenever）
「それから何が起きるだろう？」という質問を繰り返すことによって新しいパスが見つかっていくでしょう。 たとえば、ReserveSeatがあれば、CancelReservationもあるよね、という議論も可能です。
EventStormingはパースペクティブごとに使い分けられる
ここまでのものはベースの考え方があって、プロジェクトのキックオフや、バリューストリームマッピング、ふりかえりなどに応用することができるとされています。
| Level | Base | Topping | Discovery |
|---|---|---|---|
| Big picture | Events | Hot spots, Systems, People | Conflicts, Goals, Blockers, Boundaries |
| Process modeling | Events | + Policies, Commands, Read models | Value proposition, Policies, Personas, Individual goals |
| Software design | Events | + Aggregates | Aggregation, Policies, Read models, IDs |
たとえば、設計のためにEventStormingを使うのであれば、「事前条件となるコマンド」と「期待する成果イベント（やRead model）」を先に定義しスコープを限定して取り組みます。
Event-driven architectureであるべきか
Event-Driven architectureと相性が良いのは事実です。
しかし、それはimplementの一つの選択肢であるだけで、そうではないアプリケーションアーキテクチャにも適用可能と思います。 たとえば、イベントはドメインオブジェクトの振る舞いの結果の値（返り値）と読み替えれば、その値をどう使うかというポリシーはアプリケーションサービスとして実装することができそうです。 人（アクター）が登場するまでの間のプロセスが、そのままアプリケーションのユースケースに相当するイメージです。 アプリケーションはそのユースケースに何らかの情報処理フローを持つものであるため、EventStormingで見つけたフローを適用することは自然でしょう*29。
ユビキタス言語はいつ定まるか
ユビキタス言語を早く定義するということは、むしろ意図的に避けているようにも見えます。 このモデリングワークショップを進めていくと、然るべきタイミングで考える機会が与えられます。
早すぎる名前決めは、早すぎる最適化と同じで、データに着目しがちになってしまうなどの弊害が懸念としてあがりますし、エンタープライズ規模でユビキタス言語を先に決めようとしても決まらないことの方が普通でしょう*30。 それなら、同じ箱に入れてしまってぶつけ合うことで、合成を始めるということが現実的であると動画のなかでも触れられています。 これは、徐々に一貫性を導入するアプローチであり、総当たり方式に名前を決めることを避けます。
所感
EventStormingは システムの振る舞いファースト でモデリングする手法だと感じました。 ここでいうシステムとは、ITシステムよりももっと広義の社会や会社などの相互作用・まとまり全体を指しています。 書籍のなかでも名詞やデータファーストで考えてはいけないという論調があり、人々がより関心をもつプロセスや結果に主軸を置いています。
また、Complex systemへの問題意識が高く、システム思考の色合いが強いなと感じます。 本家サイトのトップページに "Improve your organization" とあるように、自己組織化の話題が織り交ぜられるなどITシステムに限らず色々なパースペクティブにおいても使うことができる手法であることが分かります。
参考
- EventStorming
- GitHub - mariuszgil/awesome-eventstorming: Awesome EventStorming
- Event Stormingを実践する
- Event Storming Summit 2018 - Wojtek Ptak - Medium
*1:Wikipediaのページがあったり Event storming - Wikipedia
*2:Explore DDD 2018基調講演 Eric Evans - Keynote: DDD Isn't Done: A Skeptical, Optimistic, Pragmatic Look - YouTube
*3:間違いを見つけたら是非教えてください :bow:
*5:これは手順のなかにある「ポリシー」のことを指していると思われます。
*6:EventStormingはトップダウン的なアプローチのため訂正
*7:一つのラウンドずつ参加者の合意を促し、直前のラウンドの成果を新しいインサイトとして次のラウンドに活かすことを、Incremental notationとして紹介されています。
*8:動画のなかで35人は経験があるということが話されていましたがすごいですね……。
*9:FIXME: 原文ではright personとなっています。安直にはステークホルダーという言葉が浮かびますが、そもそもステークホルダーをどう決定する？という点で正しい答えではありません。一般には「この人は関連する」ということはなんとなく（暗黙も含め）存在するかと思いますが、「適切であるか」という点ではやってみないと分からないなという感じがあります。
*10:左から右に進行が推奨
*11:余談ですが「ドメインエキスパート」という言葉は最近では避けられる傾向にあるように思います。海外の記事などをみていると practitioner という言葉が使われつつあるように感じています。
*12:FIXME: その点では未来を想像するようなことにこの手法は使いにくい感じがします。ただ、新規ビジネスといっても既存の何かを背景として興ることも多々あると思うため、適用範囲はかなり広いのではないかなと思います。
*13:エラーがよく起きる、時間がかかる、滞留しがちなどなど
*14:紫の付箋
*15:FIXME: 開発者の観点からは、特に語られるストーリーのなかで論理がつながっているかという視点やタイムラインが正しく合流するかなどはシステムを考えるうえで重要なポイントかなと思います。ドメイン実務者の観点からは、開発者の言う言葉の訂正や外部制約などによるギャップ分析などがあげられるかと思います。
*16:FIXME: このタイミングで「この範囲はアウトソースしよう」という判断を行う可能性もあるかもしれません。コアドメイン、重要なビジネスフローをアウトソースすることは現実的ではありませんが、すべてを自分たちで賄うのかという観点も時には必要です。ただ、そのためにはある程度モデリングが進んでいる必要があるとも考えられるため、このタイミングは時期尚早かもしれません。
*17:FIXME: あくまで目安として、パッと見たときに見やすくすることが目的のように思います。タイムラインはイベントの単位で構成されているため、詳細度が高く、また（作業スペースも）広大になりがちと予想されます。そのため、小まとめを作っておくことは、人間の脳にとっても優しくなるといえるでしょう。
*18:FIXME: 単純な間違いであったり、重複した概念であったり、通るはずのないものであったり、組織的なシステムとして取り組むべきでないものであったりするケースかなと思っています。何かしらのチェックポイントがあると良いかもしれません。
*19:FIXME: ここまで進んでからでないとコマンドを探してはいけないのか、という点にはまだ理解が及んでいません。まずはイベントの流れが正しいか、それに参加者が合意できるのかがあるべきだとは思いますが、それであれば外部システムのことを考えるのもこの付近である方が自然に思えます。この辺りは書籍を深く読み込めていないため、解釈を誤っている恐れがあります。ただ、こうしなければいけない類いのものではないため、そこは適宜テーラリングすれば良い話でしょう。
*20:FIXME: 後述のポリシーなどにも関連しますが、システムが自動的にイベントに応じてコマンドを起こすこともあり得ます。ポリシーを出していけばコマンドを誰が起こすのかは分かってきますが、その前に人に着目することでUXの観点を加えたいのではないかと推測しています。どこに人が関与するのかが可視化されることで、そのビジネスフローがより鮮明になるはずです。
*21:動画のなかではActorではなく、Userとして出てきます。
*22:FIXME: 人が何か行動を起こすためのモチベーションは、与えられたロールが同じであっても皆同じように考えるとは限りません。ただ、背後にある理由が異なっても、同じ決断・行動を起こせるようなInputとして何が必要かを考えることはプロダクトを考えるうえで重要でしょう。
*23:個人的には羽生章洋氏の「はじめようプロセス設計」などの話と関連しており興味深いところです。
*24:Listener, Saga, Process Managerなど
*25:FIXME: 成功は最初に整理した目的次第ではありますが、システムを何かしら改善（improve）したいことがモチベーションであると想定しています。
*26:FIXME: 自分たちの属するシステムのことを知らなくてはサイロに閉じこもるばかりです。書籍のなかでは自己組織化についても触れられていますが、部分を見ていては全体の最適化は叶わないことを示唆しているのでしょう。
*27:FIXME: WhoやWhyに移っていくものと思えます。
*28:Alberto Brandolini著 書籍「Introducing EventStorming」"What does EventStorming look like? - Day two" 掲載の図を元に筆者が手を加え作成
*29:FIXME: Read modelのような考え方はCQRSを知っている方が理解がスムーズではあると思います。
*30:FIXME: 十分な情報が足りていないリスクは後になるほど低減されます。知識が共有され、議論によって洞察が深まることで本当に使える言葉が見つかるということと思います。
