ユーザーストーリーマッピング

基本的な意味と視覚的な構造

Jeff Patton が提唱した、ユーザーの行動(体験)を起点に、必要な機能やコンテンツを整理するフレームワーク。主にアジャイル開発で活用される。

横軸(背骨)：ユーザーの行動を時系列で並べる(例:「商品を検索する」→「カートに入れる」→「決済する」)。
縦軸(詳細)：各行動に対して必要な機能を、優先度が高い順に上から下へ並べる(例:検索の下に「キーワード検索」「絞り込み機能」「サジェスト機能」など)。

これにより、サービス全体のユーザー体験を俯瞰しながら、要件を整理できる。

現場における核心：「MVP 思考」と関係者調整の武器

核心は、これが単なる要件定義書ではなく「MVP(実用最小限の製品)思考の道具」だという点。プロジェクト初期には、営業や経営層から「あれもこれも全機能載せてからリリースしろ」という無茶な要求(あれもこれも病)が必ず出る。その際、このマップを使って「ユーザーのコアな行動フローを回すために、この高度な検索機能は『リリース直後』に本当に必要ですか?」と視覚的に問い直し、最小限の機能セット(MVP)だけを抽出する最強の防衛策・説得材料となる。

実務における運用プロセス(ワークショップと計画化)

共通認識の形成：担当者が 1 人で作るのではなく、「Miro」「FigJam」などのオンラインホワイトボードや、リアルの「付箋(ふせん)」を使い、エンジニア・デザイナー・ビジネス側(ステークホルダー)全員で議論しながら作るのが鉄則。
優先度付けと計画：抽出した機能を MoSCoW 法(Must:必須、Should:推奨、Could:任意、Won't:今回は見送り)などで優先度付けし、開発のスプリント計画に落とし込むところまで進めて初めて価値が出る。

Web 担当者が陥りやすい落とし穴とリアルな対策(NG 事例)

「作って満足」の罠：マップを綺麗に作ること自体が目的化し、その後の優先順位付けやスプリント計画への落とし込みが行われない。マッピングの後の「何を捨てるか(削るか)」の意思決定こそが肝。
担当者の孤独な作業：Web 担当者がエクセル等で 1 人で作ってしまい、開発チームやステークホルダーとの「対話・合意形成」というストーリーマッピング本来の最大の価値を失ってしまうこと。

言葉をよく利用する人

プロデューサー
Web 担当者(発注側)
ディレクター
マーケター

会話上での使用例

新規サービスで機能が多すぎて着手順に悩んでいる場面

プロデューサー
やりたい機能が多すぎて、正直どこから作ればいいのか分からなくなってきた。
Web担当者(発注側)
ユーザーストーリーマッピングで一度整理しましょう。利用者がまず何をして、次に何をするかを時系列で並べて、その流れを支える機能だけを第一弾に絞れば、最小限のセットが見えてきます。
プロデューサー
なるほど、全部を一気にじゃなくて、コアな流れから出すんだね。

抽出した機能の優先度の付け方をマーケターと相談している場面

マーケター
機能の優先度って、結局どう決めればいいんですか?
Web担当者(発注側)
ユーザーストーリーマッピングで並べた機能を、必須・推奨・任意の三段階に振り分けるといいですよ。そこまでやってスプリントに割り当てて初めて意味が出るので、マッピングして満足、で終わらせないのがコツです。