ユーザーストーリーマップ（体験設計のアウトプット）｜現場のユーザーリサーチ全集

ユーザーストーリーマップ（ユーザーストーリーマッピング）とは、ユーザーフローごとに発生する課題や要望をマップ上に整理して、開発フェーズごとのMVP（Minimum Viable Product/実用的で最小限の機能）を導き出すアウトプットです。

Jeff Patton/ジェフ・パットン氏により考案され、UXを重視するプロダクトマネジメント（開発計画）シーンでよく使用されています。非エンジニアから見た時の成果物のイメージは、「エンジニア版のカスタマージャーニー」のような趣きです。

実際、カスタマージャーニーとユーザーストーリーマップは作成時の背景や情報に共通点が多いのですが、前者は施策の立案や接点の開拓を志向しているのに対し、後者はバックログに起票する初期のアイテムを見積もることを志向しています。

本図は単体で使用して開発計画の討議に役立てる使い方も良いのですが、同じテーマのユーザーテストやエキスパートレビューの分析成果物を用意して、アプリ・サイトのキャプチャ画面と対応させながら討議を進める方法もおすすめです。

ユーザーストーリーマップの構成要素は以下のようになります。

・ユーザーストーリーの背景となるユーザー像

・ユーザーストーリーのフェーズ（大見出し）
（複数のナラティブフローから成るグループ）

＜記入例＞
・アプリをダウンロードする
・アプリを起動する

・ユーザーストーリーのステップ（小見出し）
（開発計画の単位）

＜記入例＞
＊アプリをダウンロードする
・ユーザーはアプリ版の存在を認識できる
・ユーザーはアプリ版のメリットを認識できる
＊アプリを起動する
・ユーザーはサービスにアクセスできる
・ユーザーはサービスを利用できる

・ユーザーの行動変容をカード化したもの
・「（ユーザーは）〜ができる（ようになる）」の形式で書く

＜記入例＞
＊アプリを起動する
・ユーザーはサービスにアクセスできる
┗使用端末のホーム画面からアプリを起動できる
┗ブラウザからアプリを起動できる
┗プッシュ通知からアプリを起動できる
┗ウィジェットでアプリの特定機能を素早く起動できる

※ユーザーストーリーのカードの書き方には様々な方法論が存在しています。ユーザーの立場や課題、あるいはプロダクトの機能を書く方法が主流ではありますが、前者だとカードの文章が長くなってしまったり、後者だと逆に単語で意味が通じづらくなったりするため、私自身は本稿の書き方で対応しています。

「新企画が構想ばかりでプロダクトへの落とし込みまで至らない…」
⇒この悩みに一枚で答えるためのアウトプット

リブランディングや新コンセプトなどの企画会議では、討議のほとんどをビジョンのすり合わせに使ってしまい、プロダクトまで話が至らないことが珍しくありません。この展開だと制作や開発を担う担当者に多大な負担がかかります。

特に足元の売上やその対策などビジネス的な観点でのリリースが優先されると、期日までに公開するのが精一杯で品質が犠牲になるケースも多くあります。リリースを乗り切ったとしても退職者予備軍を増やしてしまう悪手と言えます。

事業部門と開発部門の間では、カスタマージャーニーが共通理解用のフォーマットとしてよく用いられます。しかしこの資料は担当者の想像で書かれることも多く、ユーザーに提供しようとするサービスが無限に盛り込まれがちです。

かくして「鳴り物入りのプロジェクト」と「蓄積されてきた開発計画」の綱引き合戦となります。この状態でそのままバックログ上で優先度を討議してしまうと、領域や粒度が異なる話題を同列に扱う無理が生じて議論が行き詰まります。

・調査対象とするアプリ・サイトの画面をユーザーに提示する
・ユーザーがどのように使用するか操作と会話で明らかにする
・発話を書き起こして情報を整理する
※デプスインタビューの情報からこの成果物を作成するのは難しいので注意。

・プロジェクトに対応するペルソナを設定する
（ペルソナが無い場合はN1インタビューの個票などで対応する）
・ペルソナに付随するシナリオからマップのスコープを揃える
（ユーザーの行動があまりに複雑だと作成のハードルが上がるため）

＜インプット＞
・ペルソナのステータス（プライマリ・セカンダリの要件など）
・マーケティング観点のユーザーステータス（新規・既存など）
・ユーザーテストの提示画面（アプリ・ウェブ）
※上記の分類を参考に基本となるシナリオを決定する

・ユーザーのワークフロー（行動のステップ）に沿って見出しを作成する
・バックボーン（大見出し）とナラティブフロー（小見出し）は、行き来しながらそれぞれの見出しの粒度を調節する
・ワークフローが横に長くなってしまう場合、適度に区切れるポイントを模索する。その際、エキスパートレビューの結果（UX体験軸に基づく区切り方）やユーザーテストの設計（スタートとゴールのシナリオ設定）が参考になる。

＜インプット＞
・エキスパートレビュー
・カスタマージャーニー

・各ステップにおけるユーザーの行動変容をカード形式で連ねていく

・ユーザーストーリーを縦列の中で優先順位を並び替える
・優先順位はユーザー観点、ビジネス観点から吟味する

・ワークフロー（横軸）の段階ごとに実現可能なリリース範囲を水平方向にスライスし、MVP（開発範囲）を定める

ユーザーストーリーマップを使うと、プロジェクトの討議で上がった施策や機能の企画案をプロダクトベースで捉え直すことができます。開発する対象物や関連する箇所をナラティブフロー（ステップ・小見出し）に沿って確認します。

その結果、真に開発対象とすべき初期のリリース範囲（＝MVP）を可視化できます。残りのリリース候補もまたスコープに入って見えているのがミソで、初期対応後も次のリリースを考える成果物として継続して使うことができます。

ユーザーストーリーマップは事前に行うユーザーテストで得た自然なユーザー行動を論拠としており、Must（あるべきもの）とNice to have（あったら良いもの）をユーザーのワークフローに沿って見極める議論の進行を可能にします。

言い換えると、ペルソナを使って設定したシナリオ（例：新規・既存、アプリ・ウェブ）に沿って、全体の中で個々の表示や機能の優先度を相対的に判断し、そのまま開発対象のバックログアイテムも整理できる優れもののツールです。