イベントストーミングとは?

ドメインイベントや、イベントの発生条件、集約、外部システム依存などを明らかにするためのワークショップ。 DDDの戦略的設計に使われるようだ。

Miroのテンプレートがある。 https://miro.com/miroverse/event-storming/

ざっくりやり方

ドメインエキスパートを含めた関係者を集めてまとまった時間を取る
ドメインイベントをひたすら書き出す
- ドメインイベントは、「過去形」で書き出す
- 時系列順に並べる
参加者に各イベントの意味を確認していく
イベントが起こるための条件を書き出していく
- ユーザーのアクション、コマンド
- 外部システム
- 時間や条件
- 他のドメインイベント
グルーピングを行ったり、整合性を保ちたいまとまり（集約）を探す

こちらの記事が詳しいです https://qiita.com/tsukmr/items/91f5be9ba1004c19ec26

ユーザーストーリーマッピングとは?

プロダクトのユーザー体験を最初から最後まで俯瞰して確認できるドキュメント。アジャイル開発でのワークショップによって作られる。 ユーザーストーリーを集めたもの。

Miroにテンプレートがあります。 https://miro.com/ja/templates/user-story-map/

ユーザーストーリーとは

ユーザー体験を最小作業単位に分割したものであり、ユーザーにどのような価値を与えるかを言語化したもの。

【ペルソナタイプ】は、【利益】になるように【行動】できる。

のようなことを記述する。例えば、

プログラマーは、仕事中に手軽に記録するため、デスクトップアプリから学びを投稿できる。

のような形。ユーザーが得たい体験が含まれている。

ざっくりやり方

プロジェクトの関係者を集めてまとまった時間を取る
参加者はユーザーの気持ちになって、付箋に一日の最初から最後までのストーリーを貼りだしていく
見落とした細部を埋める
別のケースを探る
ストーリーを整理する
同じようなストーリーをアクティビティとしてまとめ、バックボーンを抽出する
- バックボーンは大まかな流れを掴むための概要であり、バックボーンだけを読むと概要を掴むことができる
目標を実現する単位を切る。リリース単位となる

こちらの記事などが詳しいです https://lucidspark.com/ja/blog/the-ins-and-outs-of-user-story-mapping

それぞれの特徴・違い

イベントストーミング - システムのふるまいに焦点をあてている - 外部システムとの依存関係や、整合性、発動条件など、実装に基づいて設計する - 技術的視点がまあまあ必要

ユーザーストーリーマッピング - ユーザー体験にフォーカスしている - ユーザーから見えないところは含まれていない - リリース単位のスライス

やり方は似ていますが、全く別のものでした。

どのように使い分けるか

イベントストーミングではシステムの設計について、エンジニア以外と会話できます。設計の精度が上がるとともに、依存コンポーネントやリスクについても会話できるのはとても良いです。「ここはこのシステムに依存する作りになっているけど、リスクが大きいから後で変えられるようにしましょう。」みたいな会話ができます。イベントストーミングだけだとUXの考慮が無いため、バックエンドを設計する！みたいなイメージです。

一方、ユーザーストーリーマッピングは、ユーザー体験を中心にした計画を行います。これをやることで、フロントを含めた体験を考えることができます。リリースをどの単位で行っていくとユーザーの体験が一通り実装できるかの判断も行えます。

使い分けることを考えましたが、できるなら両方やる! でも良さそうです。

合体

イベントストーミングと、ユーザーストーリーマッピングはプロセスが似ているため、合体させることもできるのではないでしょうか。DRYってやつです（絶対によくないDRY）

こちらのページに https://www.qlerify.com/post/from-event-storming-to-user-stories

ドメインイベントとコマンドからユーザーストーリーを考えることを始める

的な感じのことが書いてあります。イベントストーミングで、システムのふるまいを設計し、ふるまいの中でユーザー体験に関係しそうなコマンド、ドメインイベントを、ユーザーストーリーマッピングの「バックボーン」に設定して引き継ぐということができる?（本当か?）

本当でした 実際にやってみたんですが不思議と違和感なく繋がりました

イベントストーミングのアウトプットに当たり障りないユーザー登録などのイベントがあるとして

合体例

User/ActorとCommandだけを抽出して、ユーザーストーリーマッピングのバックボーン(User tasksのところ)として時系列に並べてみると

引き継げました

結果・感想・考えたこと

イベントストーミングは初挑戦でした
まずはプロダクト全体の大枠の設計と体験を見通すところを優先し、イベントストーミングはSTEP3までしかやっていません
STEP3で、ユーザー/アクターやトリガー、外部依存などを考えるところで、エンジニアだと作るものが事前にある程度見える。設計の意思統一効果高いです
ある程度コードに落とし込むまでは、イベントストーミングをメンテナンスして深めていくのも良さそうだと感じました
イベントストーミングに時間をかけたぶんだけ、ユーザストーリーについての予測がしやすくなり、ユーザーストーリーマッピングはいつもより短い時間で終わりました
ある程度の実装が見えた形でマッピングに入れるので、MVPラインを引くときに工数感が想像できる感覚がありました
外部依存を明示して、リスクあるところの実装を後回しにするような実装は、ゼロイチでの開発と相性が良さそうです
- まずは大事なドメインをちゃんと作って、外部依存は取り替え可能で早く作れるものを選択してしまえると、早い上に、変更容易性が高そうで、最強か!?と錯覚しそうになります
すべてをクリーンに作るのが理想かもしれませんが、まずは最低限、外部依存に注目するだけでも効果がありそうです
dmmf を読みつつ実践しているので関数型も取り入れたいなぁ