EventStormingとUserStoryMapping、どう役立ってる？

「10X アドベントカレンダー2022」の12/11担当 @tae124m です🎄。

この記事では、EventStormingとUserStoryMappingをどのように開発現場で利用しているか？について書きます。これらは比較して語られることがあると思いますが、それぞれのどのように役に立ったのかを語ってみます。

なお、EventStormingやUserStoryMapping自体の説明はしません。この記事最後に参考文献を添付しておきます。

LIFE大好き。推しはBIO-RALごはん

本編に入る前に、10Xアドベントカレンダー2022のお作法に則って、私の推しをお伝えします。

前日のエントリーMikityと同じく、私もLIFE好きです。6年以上毎日の食卓はLIFEにお世話になっています。どれをオススメするか迷ったのですが、今回は我が家のロングBUYであるBIO-RALごはんを選びました。健康志向に目覚めた面倒くさがり屋さんも、玄米を手軽に美味しく食べれます。ちなみに私は玄米ごはん派で、夫と息子は玄米と十六穀ごはん派です。

20年運用したネットスーパーシステムをStailerにリプレイスしたい

本題に戻ります。今年の春から、とある企業様のネットスーパーシステムを、Stailerに移行するプロジェクトをPdMとして担当しています。現行システムは既に20年運用している実績があり（凄いです）、リプレイスの面白さと同時に難しさを感じています。

Stailerと現行システムの差分が大きく、追加開発する機能がめっちゃある
中でも、Stailerが提供してきた物流と違う仕組みを提供する必要がある
事業上の課題解決するために移行するので、現在と変える必要があるが、変え過ぎる失敗リスクや開発コストと天秤にかける必要がある

共通認識を持つことが大事であり、難しい

リプレイスに向けて、様々な組織やチームを巻き込みながら進めています。

現行事業に詳しい人、Stailerに詳しい人、物流に詳しい人、ネットスーパー事業に詳しい人など、知識と関心事が異なるメンバーが集まる中で、何のために、何を、どう作るか？について、必要な共通理解を持った上で議論されることが大切になってきます。が、難しい（笑）。

UserStoryMappingで俯瞰的に捉えられた

PJメンバー内で共通認識を持ち議論するため、As is調査を一通り終えた段階で、パートナー企業様と一緒にUserStoryMappingを作成しました。

ローカルルールとしてFitをグレー、Gapをブルーで表現。
ユーザー視点での全体可視化に役立った。Gap多いよ〜！

開発初期の計画づくりの段階でユーザー視点で全体感を把握し、ユーザー視点で何を変えて何を変えないのか？何をどのぐらい開発する必要があるのか？優先順位は？を検討する材料としてこのマップが役立ちました。UserStoryMappingの見方自体はシンプルです。ユーザーストーリーは左から右に流れていき、上の方が優先度が高いというルールさえ押さえておけば、システム開発に関わるのが初めてという方にも内容を把握頂けるようでした。

また、このUserStoryMappingのアウトプット副産物として、チームのOnboardingにも役立ちました。この記事執筆時点で、このプロジェクトで開発するアプリケーション仕様書が30以上あります（汗）。開発途中でJOINした方に、仕様書で全体像をお伝えするのは難しく、UserStoryMapが役立ちました。

EventStormingで知を集結する

Stailerは金銭に関わる機能、業務システムとしての機能を提供します。そのため、システムの振る舞いも含めた詳細なイベントの整理が必要であり、UserStoryMappingで全て表現するのは困難です。これら詳細分析にはEventStormingを活用しています。

まずは、PdMがヒアリング内容を元に大まかにイベント（オレンジ色）をマッピング。現行業務に詳しい方、現行事業に詳しい方、配送ドメインに詳しい方、Stailerに詳しい方が集まり、認識合わせをしながら、イベントを追加、修正して作成しています。EventStormingは、今回が要件定義に関わるのが初めてという方も参加可能で、詳細も含めてWhy, What, Howをクリアにすることに役立ちました。

Tipsを１つ紹介させてください。チームのローカルルールで、開発側の観点で知りたいことを紫色で添付し、解決したら赤色に変えるという運用をしています。数多い論点を確実に潰し、記録に残す作業にとても役立っています（発案したishida-sanに感謝！）。

As is&To be整理の両方に適用した

EventStormingとUserStoryMappingは以下のような流れで適用しました。

As is整理でEventStorming
1のInputを元にTo beをUserStoryMapping
1, 2をInputとして、仕様書にUserStory（テキスト）形式にまとめる
1, 3をInputとして、To beのEventStormingを行う

現場での運用上大事なことは、EventStormingやUserStoryMappingのお作法・ルールに拘り過ぎず、達成したいことを満たせれば良いという姿勢で、参加者の経験・リソース・物理的な制約等に合わせて柔軟に対処することだと感じました。

（もちろん原理原則を理解しておくことは超大事で、リスペクトしている前提です！）

最後に

30個の仕様書について絶賛開発中で、まだ要件定義フェーズです。他チーム含めて10Xは一緒に働く方を求めています。

少しでも興味があったら採用ページを見てみて頂けると嬉しいです！

10x.co.jp

open.talentio.com

明日12/12のアドベントカレンダー担当はMurai-sanです。お楽しみに！

tae’s notebook

ちょっと調べたり考えたこととか、気軽にメモしていく場所です。所属組織とは関係なく個人の意見です。