ユーザーストーリーマッピングとは？作り方5ステップとカスタマージャーニーマップ連携のコツ

なぜ「従来の要件定義書」では断絶が起こるのか？

典型的なWordやExcelによる要件定義書では、ユーザージャーニーのステップやフェーズがどこに記載されているのか、ユーザーがなぜその要件を必要としているのかというコンテキストが分解されて消えてしまいます。これでは、ビジネス（クライアント）組織、デザイン（コンサルティング）組織、エンジニアリング組織との間に深刻な断絶が起こってしまうこともあります。

その点、ユーザーストーリーマッピングは、ユーザーの体験の流れ（ジャーニー）と必要な機能の全体像を、一枚のマップで俯瞰できるのが最大の特長です。ユーザーの体験の流れに沿って機能が整理されるため、「この機能は、ユーザーのどの体験を良くするためにあるのか」という目的意識をチーム全体で共有し続けることができます。

ペルソナ設定の重要性 ユーザーストーリーの精度を高めるには、土台となるペルソナ設定が不可欠です。BtoB特有のペルソナ作成手順については「BtoBマーケの成果に直結するペルソナ設定。作成手順とBtoCとの違いを解説」で詳しく解説しています。

【比較】カスタマージャーニーマップとの決定的な違い

混同されがちな両者ですが、目的と役割は明確に異なります。両者を効果的に使い分けるために、以下の違いを理解しておきましょう。

つまり、カスタマージャーニーマップで描いた「理想の顧客体験」という目的地に対し、そこに至るための具体的な機能や実装の道のりを詳細に描くのがユーザーストーリーマッピングの役割です。

そもそも効果的なカスタマージャーニーマップの作り方を再確認したい方は、こちらの記事「カスタマージャーニーマップの作り方とは？効果的な施策立案のステップと活用事例」も参考にしてください。

【実践】ユーザーストーリーマッピングの作り方 5ステップ

アジャイル開発手法のカンバンと親和性が高く、

実装対象になぜ取り組むのか？
どんな目的をもたらすのか？
どのような優先度でやるのか？

を可視化していきます。

ステップ1：ペルソナとゴールの再確認

まず、カスタマージャーニーマップで設定したペルソナを再確認します。「誰が、何を達成するためにこのWebサイト/プロダクトを使うのか」というゴールをチーム全員で明確に共有することが、すべての土台となります。
サービスブループリントやステークホルダーマップで抽出した、ユーザーのロール（役割）ごとに、ユーザージャーニーマップのように左から右へ、ユーザー視点のストーリーを細分化して時系列に並べていきます。

BtoB企業におけるジャーニーマップの活用例や、BtoCとの違いについては「BtoB企業のカスタマージャーニーマップとは？BtoCとの違いやお役立ちツールを紹介」の記事が参考になります。

ステップ2：骨格となる行動（アクティビティ）を洗い出す

ペルソナがゴールを達成するために行う一連の行動を、大きな括りで時系列に並べます。これをマップの背骨となるアクティビティと呼びます。
一番上はフェーズとして、ユーザージャーニー上でのステージに相応し、次の段にステップとしてアクティビティを右に並べていきます。

• 例：ECサイトの場合
  「会員登録する」→「商品を検索する」→「商品を比較検討する」→「購入手続きをする」→「購入履歴を確認する」

ステップ3：具体的な行動（ストーリー）を書き出す

各アクティビティの中で、ユーザーが実際に行う具体的な行動＝ストーリーを書き出していきます。ストーリーは「（ユーザーとして）～したい」という形式で、ユーザーの要望として記述するのが基本です。

【現場視点：実装者が見積もれる単位で書く】
このストーリーのボリュームは大きくなりすぎてもいけません。一文で記述し、実装者が見積もれるレベルが好ましい単位です。具体的には、CRUD単位（登録・参照・更新・削除）で記載することをお勧めします。
例えば、会員登録アクティビティの下に「プロフィールを登録する」というストーリーがあれば、自ずと「編集する（更新）」「確認する（参照）」も必要になるはずですので、セットで記載します。

例：商品を検索するアクティビティの下に積んでいく
・「キーワードで検索したい」
・「カテゴリから探したい」
・「価格帯で絞り込みたい」

ステップ4：マッピングと優先順位付け

書き出したストーリーを、アクティビティの下に積んでいきます。このとき、縦軸が優先順位になります。下方向は、Must（必須）で実装するもの、Nice to Have（あったほうがいい）なもの、Wish（希望）なもの、であったり、リリースするタイミングによって分けるなど、セクションを区切ったりします。

• 上段（Must）： これがなければサービスが成り立たない必須機能。

• 中段（Nice to Have）： 顧客体験をより向上させる、あったほうがいい機能。

• 下段（Wish）： 将来的に実装したいアイデアや希望。

このようにセクションを区切ることで、どこまでを最初のリリースに含めるべきかが可視化されます。

ステップ5：リリース計画を立てる（スライシング）

最後に、マップの上から水平に線を引くことで、開発範囲を区切ります。これを「スライシング」と呼びます。

• リリース1（MVP）： まずは「Must」のストーリーを横断するように線を引きます。ユーザーが最低限の目的を達成できる「最小限のプロダクト」で、素早く市場に投入するための範囲です。

• リリース2以降： 次に「Nice to Have」を追加していく、段階的なロードマップを策定します。

ユーザーストーリーマッピングを成功させる現場の知恵

ここからは、実務においてエンジニアやデザイナーと円滑に連携するための、さらに踏み込んだ工夫を紹介します。

Miroの機能をフル活用して「伝わる」マップを作る

弊社ではオンラインホワイトボードのMiroを使用しています。Miroにはユーザーストーリーマッピングのテンプレートもあり便利ですが、ひとつ欠点があります。それは、例えば「会員情報」にまつわるストーリーが、各ステージのアクティビティに分散して記載されてしまう点です。

Miro公式の紹介記事もご参考ください。→ユーザーストーリーマップ テンプレート

実装者（エンジニア）としては、本来「会員情報」というデータのエンティティ単位で設計していくことが多いため、要件が飛散していると、まどろっこしく感じられます。そこで、以下の工夫が有効です。

• タグ機能の活用： 「会員情報」というタグを付けておくことで、マップの各所に分散したストーリーを後からタグで絞り込んで一覧化できます。CSVエクスポート時にも、このタグ＝エンティティで集約できるため、実装者にとって非常に助かる工夫となります。

• ユースケース記述レベルの追記： ストーリーが1文だけでは、前後の細かい処理やシステムの期待される振る舞いまでは伝わりません。例えば「E-mailで登録する」場合、重複アドレスがあった際の処理などの定義が必要です。Miroのカードを展開し、UML（Unified Modeling Language：統一モデリング言語）でいうところのユースケース記述のような詳細を追記していくことで、このマップだけで要件が完結するようになります。

• プロトタイプへのリンク： ストーリーに対応する画面プロトタイプをFigmaやXDで作成しているなら、FigmaやXDのURLをリンクしておくと、画面とストーリーをマッピングできます。UIと要件をセットで確認でき、要求を理解しやすくなるし、認識の違いも少なくなるのでお勧めです。
  その他、UIイメージを作成したらそれを関連するアクティビティに貼ったり、矢印で結線して関連性を示したり、Miroの機能をフル活用して分かりやすく・伝わりやすくしていきましょう。

MECE（モレなく・ダブりなく）に記載する

MECE（ミーシー）とは「モレなく、ダブりなく」ということです。ユーザーストーリーマッピングは要件定義そのものなので、要件がモレていたというのは好ましくありませんし、ダブりがあれば開発見積もりに悪影響を与えます。ストーリーの抽出は常にMECEであることを意識してください。

開発工数の見積もりに活用する

MECEなストーリーが記載できていれば、根拠のある見積もりが可能です。見積もりはそれ自体がエンジニアリング上難しいタスクですが、MECEなユーザーストーリーが記載できていたら、ある程度の根拠をもつ見積もりが可能になります。

【見積もりの具体例】
基準とするストーリーを1つ選び（例：E-mailで登録する）、その実装工数をN時間と定義します。それと比べて他のストーリーが何倍重たいか、あるいは軽いかをヒューリスティックに見積もり、CSVエクスポートして合算することで、全体工数を算出できます。
※時間ではなくストーリーポイントで見積もる、という手法もあります。

まとめ：顧客視点を翻訳し、ブレない開発を

ユーザーストーリーマッピングは、顧客視点で描いたカスタマージャーニーマップと、開発・実装の世界とをつなぐ、極めて重要な翻訳の役割を担います。

Webサイト担当者がこの手法を理解し、デザイナーや開発者との共通言語として活用することで、チーム間の認識のズレを防ぎ、顧客にとって本当に価値のある体験をブレなくプロダクトに実装していくことが可能になります。

博報堂アイ・スタジオでは、UXデザインのアプローチから具体的なシステム開発まで、一気通貫でご支援いたします。ユーザーストーリーマッピングを用いた要件定義やプロジェクト推進にお困りの際は、ぜひお気軽にご相談ください。

よくあるご質問

Q1. ユーザーストーリーマッピングとカスタマージャーニーマップの決定的な違いは何ですか？

A1. 大きな違いは「目的」と「視点」です。カスタマージャーニーマップは、顧客の感情や思考の変化を可視化し、改善の機会を見つけるための「戦略の地図」です。対して、ユーザーストーリーマッピングは、理想の体験を実現するために必要な機能を洗い出し、開発の優先順位を決めるための「戦術の設計図」と言えます。 カスタマージャーニーマップで「何をすべきか（目的）」を定め、ユーザーストーリーマッピングで「どう作るか（手段）」に落とし込むという連携が、プロダクト開発を成功させる王道です。

Q2. ユーザーストーリーマッピングには誰が参加すべきですか？

A2. プロダクトマネージャーだけでなく、エンジニア、デザイナー、さらにはビジネスサイドの担当者など、多職種が参加するワークショップ形式が理想です。異なる視点が混ざることで、実装の難易度やビジネス価値、ユーザー体験の整合性がその場で確認でき、後の手戻りを最小限に抑えられます。

Q3. 小規模な機能改善でもユーザーストーリーマッピングは有効ですか？

A3. はい、有効です。大規模な新規開発だけでなく、既存機能の改善でも「その修正がどのユーザー体験に紐づいているか」を確認することで、場当たり的な改修を防げます。小規模な場合は、全てを細かく書き出すのではなく、影響範囲に絞った簡易的なマッピングを行うことでスピード感を持って進められます。