イベントストーミング導入
コラボレーションの必要性
アジャイル的な観点で考えると、人と人とのコラボレーションという非常に価値のあるプロセスである。様々な専門性や視点を持った人がある課題に対して各々の知識を集結させて、解決策や新しい視点・課題の発見につながる大きなメリットがある。有名なあるアフリカのことわざで「早く行きたければ一人で進め、遠くまで行きたければ皆で進め」というものがあり、これはコラボレーションの重要性を説いているのだと思う。
私が働いているソフトウェアの会社然り不確実性が高い業界や市場などで何かしらの成果を出す場合は、コラボレーションを適切に行うことで大きな結果を生むことができると考えられている。
しかし、実際は各々のコラボレーションは結構難しいのが一般的だと思う。自分の専門としない分野とのコラボレーションは未知への恐怖・防御反応や心理的安全性が少ないことからコラボレーションがしにくいなど様々な障害が存在する
意識や目標に置くことによってある程度は改善するものの、そこまでの効果は得られない。
そのため、業務のフローやプロセスにそういった仕組みを取り組むことが有効だと考えている
私たちの会社では実際にいくつかのコラボレーション施策を行っているのだが、今回はその中でもイベントストーミングというドメインモデルを探索・探求する手法を試験的に導入してみたので、それについての気付きなどを書いていければと思う。
イベントストーミングとは？
イベントストーミングとは、Alberto Brandolini氏が考案した協働的にドメインのモデリングをしていく手法である。よくDDDの戦略的設計フェーズでドメインモデリングで使われることが多い。
ざっくりとどういう手法かというと、ドメインイベントというドメイン内で発生するイベント（出来事）を参加者で洗い出し、それがどういった流れで起きるか？やなにから発生するのかを整理していき、境界付けられたコンテキストを特定していく流れとなっている。
特に、ドメインイベントに着目するという出来事ベースで考えることができるので、非エンジニアでも参加しやすいワークショップ形式になっていることが特徴的である。
一般的にはこのドメインに詳しいドメインエキスパートを混ぜて行うのがベストであるが、私達の場合ではそれに加えてコラボレーションを促進し、他の視点を混ぜ込むためにもという目的で行うことにした。
手順
基本的なやり方は下記の3フェーズによって進めていく。
ただし、私達の会社で実際には1フェーズ行って終わるようになっている。
その意図としては、コラボレーションがメインのためであったり、１フェーズ＋αぐらいまでやるだけでも、かなりドメインに関する知識や知見の共通認識が得られるので、効果があると感じたためである。
状況によってどのフェーズまで行うかを決めると良いと思う。（基本はすべてのフェーズを行ったほうが良いと思う）
フェーズは↓の3つのフェーズとなる
- Big Picture
- ドメインイベントの収集
- ドメインイベントの絞り込み
- Modeling processes and services
- イベントトリガーを探す
- Modeling software systems
- アグリゲートの調査
- コンテキストの調査
フェーズ１：Big Picture
このフェーズではドメインイベントを片っ端からアイディエーション的に出していき、フェーズである。少しコツとしては、最初に対象の範囲はどういうものか？について話し、それベースでイベントを出していくと行いやすい。
ドメインイベントは基本的に何か起こった事象（イベント）となる。例えば、ポイントが消費されたやメッセージが投稿されたなど実際に起きることとなる。これをざっと洗い出し、イベントを時系列順にならべていく。このとき、同じようなイベントがあった場合は本当に同じかなどをすり合わせ、違う意味にしたり、同じイベントにしたりなどの重複排除的なプロセスも行う。
このプロセスを行うことによって、ざっくりとコンテキストが見えてくるので、ざっくりとしたドメインモデルとすることも一応可能である。
ただ、このプロセスで一番大事なのはイベントやこのドメインに関する共通認識を揃えることである。実際やってみると、かなり大きく認識が違ったり、ドメインエキスパートの頭の中がよく見えたりなど新しい発見が多いので、そこを目的として置くことが個人的には重要だと考えている。
また、2つのイベントの流れが交差するイベントなどはかなり重要なイベント（Pivotal Event）というものであり、コンテキストの境界になりやすい。
フェーズ２：Modeling processes and services
このフェーズでは、よりBigPictureで作ったモデルを構造的にしていく。具体的にはCorporation Gameというものを行い、イベントしかない不自然な状態からそのイベントが発行されるまでの経緯（プロセス）を明らかにできれば終了となる。
どんなシステム・ステークホルダーがいて、誰がどんなシステムに対してアクション（コマンド）をして、どんなイベントが発行されるのかのような流れを繰り返し協力して書いていき、埋めていくことによって解像度が上がっていく。
Corporation Gameは下記のようなルールで行っていく。
フェーズ３：Modeling software systems
このフェーズでは、基本的なドメインの共通認識は取れている状態として、実際にどうソフトウェアをこのモデルから作るべきかについて最終モデリングするフェーズになる。若干ここに関する情報が少ないので、正しくないことを書いてしまうかもしれないが、下記のようなことを作っていくことが大事である。
- 集約を発見していく
- 外部システムでないものは集約化していく
- 共通するコンテキストを探していく
- システムやドメインイベントの共通そうなものでまとめていくと見つけやすい
サンプルシナリオ：チケット購入での適用
文章だけだと伝わりにくい部分があると思うので、下記のようなユースケースで実際にイベントストーミングを行ってみた。
ポイントを購入し、そのポイントでチケットを購入するようなユースケースである。
サンプルシナリオ：フェーズ１
まず、フェーズ１の初めとしてはドメインイベントを洗い出す。ここでは下記のようなイベントが洗い出された。
出すときのコツとしては、アイディエーション的にあまり深く考えず思ったものを出していくのが良い。例えば↓のように、「ポイントが減少した」や「ポイントを消費した」のような似たイベントが出ることは問題ない。後で精査していくし、もしかしたらここに微妙なニュアンスや認識の違いがありお互いのドメイン知識が深まったり、新しい視点を得られたりする可能性がある。
また、その後はこのドメインイベントを時系列順に並び替えていく。
ここでは並び替えるだけでなく、同じようなイベントは認識を揃えた上で精査もする。
また、別のタイムラインになりそうなものは別の段に書いていくと分かりやすい。
サンプルシナリオ：フェーズ2
フェーズ２のModeling processes and servicesでは、Corporation Gameのルールでドメインイベントの間を埋めていく。これにより、モデルの解像度を上げていく。
実際やってみると割と作業ゲー感がありさくさくと進められていくが、紫の付箋（ビジネスプロセス）が本当にそのコマンドしか発さないのか？について考えながら進めていくと抜け漏れたドメインイベントがあったりする可能性があったりする。
サンプルシナリオ：フェーズ3
フェーズ3のModeling software systemsでは、システムを集約化していき、Bounded Contextを探していく。
最終的に、「Ticket Order」「Credit Card」「Point」「Ticket」「Point Order」のようなドメインが見つかるので、ここからコンポーネントやソフトウェアを設計、実装していくことができる。
実際にやってみて思ったこと
一番良かったことは、エンジニア以外の人でもかなりやりやすかった。ドメインイベントという出来事を並べていき、その間を埋めていくだけなので、特にスキルは必要なく、ワークショップ形式で行えるのは職能横断でのコラボレーションをより加速できるものだと思った。
また、ドメインエキスパートがいない場合といる場合でやったのだが、明らかにいる場合のがやりやすかった。ドメインエキスパートの中に閉じてしまっていて暗黙知になっている部分を引き出せたりして、チーム全体のドメイン知識に関する理解が深まったのも良い点であると思う。
あとは、MiroのTemplateは便利なので、これを利用するとリモートでもできるので非常に便利だと思う。（Event Storming Template | Miroverse）
逆に悪かったり、解像度が低いことはどうソフトウェアまで持ってけばよいのかのパターンやフレームワークがあまり見えていない。ここについてはGraphQLでのやり方だったり、どうドメインオブジェクトを作っていくか？みたいなことに関する資料を見つけたので、そこらへんを読んで解像度を上げていきたい。
Discussion