プラクティス名（別名）
ユーザーストーリーマッピング (USM)
プラクティスの目的・狙い
- ユーザ行動と機能の関係を可視化し、関係者の共通認識を形成する
- プロダクトのMVPを特定し、リリースロードマップを策定する
- プロダクトバックログ（PBL）作成のインプットにする
MVP（Minimum Viable Product）:
プロダクトとして成立するための必要最小限の機能群（≒1stリリースの対象）
どんな時に使うか
- 製品ビジョンや個々のユーザーストーリーはあるものの、プロダクトの全体像が見えない時
- 色々とやりたいアイデアはあるが、どこから作るべきか優先順位が分からない時
実施手順
USMの横軸は時系列の行動フロー、縦軸は詳細化したストーリーとその優先度
- 関係者を集め、まずはユーザと課題の理解からはじめる
- 時系列にユーザ行動を書き出し、今回の検討範囲を定める
- ユーザ行動毎に対話しながらストーリーを洗い出し、優先順に並び替える
- ストーリーが大きすぎる場合は適宜ストーリーを分割する
- プロダクトにとって最初に必要な機能群を特定し、MVPラインで区切る
- 次に優先度の高い機能を特定し、2ndリリースラインで区切る
- 以降、同様にリリースラインを決め、ロードマップに落とし込む
アレンジ例
- USMが巨大な行動フローになりそうな時はムリに1枚にまとめず、ユーザタイプなどで分割する
- ユーザ行動を洗い出す際、「利用シーン」やそこで解決したい「ユーザ課題」を明示すると解像度が上がり、整理しやすくなる
- USM作成前に、以下の情報を整理/共有しておくと進めやすい
| USMのインプット情報（例） | 説明 |
|---|---|
| ペルソナ | プロダクトのユーザ像、ターゲット層 |
| ユーザインタビュー結果 | 現状課題、プロダクトへの期待、ニーズ |
| ユーザアンケート結果 | 既存プロダクトの評価、マーケティング |
| CJM（カスタマージャーニーマップ） | ユーザの行動分析、プロダクトの使われ方 |
| 製品ビジョン | ユーザに提供したい価値、基本コンセプト |
アンチパターン
- 誰かが一人でUSMを作成し、関係者に説明する（共通認識が生まれない）
- 壁一面に広がった巨大なUSM（詳細化しすぎて誰も全体像が掴めない）
- 初期作成後、誰も更新しない（状況やニーズの変化が反映されない）
- そもそもユーザ行動が軸ではないプロダクトに対してUSMを行う（システム内部のバッチ処理等）
参考情報
USMの考案者Jeff Pattonの原著
定番AgileStudioさんの解説（もっと詳しくやり方を知りたい人向け）
アジャイルコーチKoki_jpさんのバズったQiita記事（もっと詳しくやる意味を知りたい人向け）
こぼれ話（私的コメント）
ユーザーストーリーマップ（成果物）を描くための手法が「ユーザーストーリーマッピング」。書籍のタイトルを 「～マップ（名詞）」ではなく「～マッピング（動詞）」 にしているところにJeff Pattonの想いが込められています。誰かが作ったUSMを説明するだけでは効果は薄いです。関係者が集まり、対話を通じてコンテキストを共有し、USMを一緒に書き上げていく、その過程にこそ意味があります。
なので一期開発が終わって、二期開発～三期開発～と初期メンバーがいなくなるにつれて、USM放置されがち問題が発生します。後から合流したメンバーにとっては「過去の遺物」の１つであり、なんならPBLは別にあるから、USMは更新しなくても困らない。というか正直に言えば二重メンテ面倒くさい、まであります（泣）。それはプロダクトの全体像とユーザ価値を見失い始めたサインかもしれません。
そんな時こそ今一度「マップ」と「マッピング」の違いを思い出して対話してみましょう。