アジャイル事業部の山岸です。
私のプロジェクトでは、作るもの（開発するもの）を決めていくときにユーザーストーリーマッピングのワークショップを開発チームでやっています。ユーザーストーリーマッピングはシンプルな手法であるため、導入のハードルが低く、様々なプロジェクトで活用できるところが特に気に入っています。
今回は、ユーザーストーリーマッピングをよりプロジェクトで有効に機能させるために、なぜユーザーストーリーマッピングが必要なのか、何に利用するのかを説明したいと思います。今回の記事では、ユーザーストーリーマッピングそのものの説明や用語については、書籍や記事などで詳しい解説がされていることもあり、省略させていただきました。
なぜユーザーストーリーマッピングが必要なのか
プロジェクトの開始時点では、MVP(Minimum Viable Product)を意識して開発の計画を立てていたが、気付くと開発したい機能がどんどん増えていき、当初予定したリリースに全然収まりきらなくなったといった事態が発生することがあります。
こういった事象は開発当初のゴールを見失い、全体像がみえなくなってしまったときに起きることが多いように感じています。プロジェクトの目標である、作るものを最小限にして最大限の成果を実現するためには、成果が発生するまでの（全体の）流れとそこに辿りつくまでに必要な活動について、プロジェクトに関わる人たちと認識を合わせていくことが重要だと思います。
このような共通の理解を築くためにユーザーストーリーマッピングという手法が有効だと考えています。
ストーリーマップを作る前に
私はユーザストーリーマッピングからストーリーマップを作成する前に、参加者とユーザーストーリーマッピングから得られる結果の期待値を合わせるようにしています。
ストーリーマップを作ったとしても、すぐに開発可能な粒度でのユーザーストーリーが洗い出されるわけではありません。参加者が会話によってプロダクトの理解を深め、全体像が把握でき、ゴールが明確になることが重要であり、そこに重点を置いて取り組むのがよいと考えています。
ユーザーストーリーのはじまり
ユーザーストーリーマッピングは、ストーリーの開始地点を決めて、そこからユーザーストーリーを書き出していきます。まずは利用者の人物像を決めて、プロダクトが実現したい成果に向けてその利用者や関係者のアクティビティを書き出していきます。
例えば開発するプロダクトが新規のサービス（Webサイト）だった場合、ストーリーの開始時点では、利用者がプロダクトを認識していないことを前提とします。そして、利用者がどのようにして（どのような経路で）サイトを訪れるのか、それを実現するには何が必要か、などを話し合いながらストーリーを開始します。
プロジェクトによっては、機能要件が先行して洗い出していたりすることがありますが、その内容に引っ張られて、「ユーザーが〇〇サイトで会員登録する」などのプロダクトの利用シーンからストーリーを開始してしまい、ストーリーの前後関係を理解しないまま、機能の詳細に話が偏ってしまうことは避けるようにしています。
ユーザーストーリーマッピングの次は
ユーザーストーリーマッピングで書き出されたユーザーストーリーは粒が大きく、開発可能な状態とはなっていないため、ストーリーワークショップと呼ばれる、個々のストーリーの細部を詰めていく作業が必要になります。ここでは開発する機能の完成イメージを共有し、受入基準などを会話しながら確認していきます。開発に着手可能な粒度へ分解できると、見積もりや開発計画を立てることができるようになります。
ストーリーマップに立ち戻る
プロジェクトが進んでいくと開発の優先順位が変わりリリース計画を見直す必要がでてくることがよくあると思います。その場合でも一度ストーリーマップに戻って、リリースに必要なユーザーストーリーを並び替えをすることで、依存関係を視覚化し、開発チームで認識を共有することができます。
また、並び替えたユーザーストーリーは、記載された内容が同じでもあっても文脈が変わっていることがあるため、開発を着手する前には完了条件を改めて話し合う必要があります。
最後に
短いサイクルで開発とリリースを繰り返すアジャイル開発においても、開発チームが全体像と現在地を把握しながらゴールを目指す難しさが存在すると思います。ユーザーストーリーマッピングはその問題を解決する手助けをしてくれると私は考えています。
最後にこれからユーザーストーリーマッピングを学びたい方は書籍「ユーザーストーリーマッピング」をおすすめします。私はこの書籍でユーザーストーリーマッピングを学び、開発プロジェクトで取り組むときはいつも参考にさせていただいています。
