カスタマージャーニーマップをプロダクトの要件に落とすユーザーストーリーマッピングとは

カスタマージャーニーマップを作ったのはいいけど

デジタルトランスフォーメーションは顧客体験を起点に、ということでUXデザインやサービスデザインのアプローチを取り入れてDX推進に取り組みたいと考える企業が増えてきました。
デザインファームやUXデザイン会社などからコンサルティングを受けながらカスタマージャーニーマップ（To-Be）を描くまではよいのですが、それを活かしてDXをなし得るプロダクトやシステムに至るまでにギャップを感じることはないでしょうか。

参考記事：効果的な施策立案に役立つ、カスタマージャーニーマップの作り方と活用法

「ペルソナがこのようなフローで体験することによって喜び、プロダクトの価値を感じる！」とみずみずしく思いが詰め込まれた仮説がTo-Beのカスタマージャーニーマップとなりますが、この情報をインプットして具体的なサービス、システムへと落とし込む際には、「要件定義書」や「設計書」などの形に変わってしまうことで、当初のユーザーのコンテキストや成し遂げたいジョブ、得られる価値や感情についての情報が削がれ、実装目線での事務的な内容に集約されてしまいます。

そのことによって、システムやサービスの設計者、実装者が当初の顧客の思考に思い巡らすことがなく、せっかく描いた当初の顧客起点が欠けた状態になってしまう恐れがあります。

そこで、UXデザイン、サービスデザインの過程で得られたサービスやシステム、プロダクトなどにやりたいこと、仕様に落とし込みたいことなどの「要求」を、実装工程に橋渡ししていくため、「ユーザーストーリーマッピング」という手法を用いて可視化・具体化・詳細化していく手法をご紹介いたします。

これは、アジャイル開発で用いられている手法ですが、分かりやすくソフトウェア開発のV字プロセス（下記）で例えるならば、要求分析をUXデザインで行い、要件定義をユーザーストーリーマッピングで行う感じです。

ちなみに、「画面設計」はソフトウェア開発プロセスでは「基本設計」フェーズになりますが、UXデザインのプロセスではプロトタイピングを初期から行って、サービスの顧客体験のシミュレーション精度を高めていくため、既にある程度カタチにしているものとします。

ユーザーストーリーマッピングとは？

ユーザーストーリーマッピングとは、一言でいえば「ペルソナ（ユーザー）がやることを時系列で整理し、必要な機能を可視化する手法」です。

UXデザインの過程では、ペルソナ、サービスブループリント、ユーザージャーニーマップなどのアウトプットによって作るべきもののイメージを曖昧な状態から具体化していきますが、システム開発やサービス実装のために詳細な設計をしていくためには、どんな要件があるのか？を抜け漏れなく、矛盾なく記載していく必要があります。

ユーザージャーニーマップはユーザー観点での体験の流れなので、そこではプロダクト観点でのシステムやサービスがどんな振る舞いをするのか、詳細な記載が網羅的な観点でカバーされることはありません。

要件定義書ではダメなのか？

では、なぜ従来のWordやExcelによる要件定義書ではダメなのか？ということですが、典型的な要件定義書のフォーマットでは、ユーザージャーニーのそれぞれのステップやフェーズがどこに記載されているのか、ユーザーがなぜこの要件が必要なのか、コンテクストの情報が分解されてなくなってしまい、全く別の資料になってしまいます。
これだと、極端な話だとビジネス（クライアントやオーナー）組織、デザイン（コンサルティング）組織、エンジニアリング組織との断絶が起こってしまうこともあります。

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

ユーザーストーリーマッピングとカスタマージャーニーマップの違いとは？

混同されがちな「カスタマージャーニーマップ（CJM）」と「ユーザーストーリーマッピング」の違いを明確にしておきましょう。両者はユーザーの体験を可視化する点で似ていますが、目的と役割が異なり、連携させて使っていくものです。それぞれの違いを理解することで、両者を効果的に使い分けることができます。

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

端的に言えば、ユーザーストーリーマッピングは「プロダクトの機能設計図」であり、カスタマージャーニーマップは「顧客とブランドの長期的な関係性の地図」です。目的に応じて使い分け、時には連携させることが、ビジネスの成功につながります。

参考記事：BtoB企業のカスタマージャーニーマップとは？BtoCとの違いやお役立ちツールを紹介

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

そこでユーザーストーリーマッピングなのですが、アジャイル開発の手法をバックグラウンドに、簡単に言えば「ペルソナがやること」を時系列で整理していく手法になります。

サービスブループリントやステークホルダーマップで抽出した、ユーザーのロール（役割）ごとに、ユーザージャーニーマップのように左から右へ、ユーザー視点のストーリーを細分化して時系列に並べていきます。
アジャイル開発手法のカンバンと親和性が高く、実装対象になぜ取り組むのか？どんな目的をもたらすのか？どのような優先度でやるのか？を可視化していきます。

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

まず、カスタマージャーニーマップで設定したペルソナを再確認します。「誰が、何を達成するためにこのWebサイト/プロダクトを使うのか」というゴールをチーム全員で明確に共有することが、すべての土台となります。

参考記事：BtoBマーケティングはペルソナ設定が重要！作成手順とテンプレートを紹介

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

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

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

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

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

この「ストーリー」のボリュームは大きくなりすぎてもいけません。
一文で記述し、実装者が「見積もれる」レベルが好ましい単位だと思います。実装者が見積もれる基準として、「CRUD」単位で記載することです。

例えば、「会員登録」のアクティビティで、「プロフィールを入力する（登録）」というユーザーストーリーがあった場合、自ずと「プロフィールを編集する（更新）」「プロフィールを確認する（参照）」などのユーザーストーリーも必要になるはずなので、それらも一緒に記載します。

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

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

書き出したストーリーを、ステップ2で並べたアクティビティの下に積んでいくのですが、このとき、縦軸が優先順位になります。

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

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

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

下方向は、Must（必須）で実装するもの、Nice to Have（あったほうがいい）なもの、Wish（希望）なもの、であったり、リリースするタイミングによって分けるなど、セクションを区切ったりもします。
このように優先度で整理することで、どこまでを最初のリリースに含めるべきかが明確になります。

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

最後に、マップの上から水平に線を引くことで、リリースするタイミングによって開発範囲を区切ります（これをスライシングと呼びます）。

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

• リリース2以降： 次に「Nice to Have」の機能を追加…というように、段階的なリリース計画を立てます。

ユーザーストーリーマッピングを成功させるポイント

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

ユーザーストーリーマッピングを記載するのにオススメのツールがMiroです。
ユーザーストーリーマッピングのテンプレートがあり、簡単にステージ毎にユーザーストーリーを記載していけます。ただユーザーストーリーマッピングの欠点として、例えば「会員情報」にまつわるストーリーが、それぞれのステージやアクティビティに分散されて記載されてしまいます。

実装者としては、「会員情報」というデータのエンティティ単位で設計していくことが多いので、必要な要件があっちこっちに飛んでまどろっこしく感じられます。そこで、Miroの「タグ」を上手く使って、データの種類ごとに分類してあげると、Miro上のCSVエクスポートすることで、そのタグ＝エンティティで集約できるようになります。

• プロトタイプへのリンク： ストーリーに対応する画面デザイン（FigmaやXDで作成）のURLをリンクしておくと、UIと要件をセットで確認でき、認識齟齬が激減します。

• タグ機能の活用： 例えば「会員情報」に関するストーリーがマップの各所に分散しても、「会員情報」というタグを付けておくことで、後からタグで絞り込んで一覧化できます。これは実装者にとって非常に助かる工夫です。

• 詳細な仕様の追記： 「メールアドレスで登録する」というストーリーには、「重複アドレスがあった場合の処理」といった細かい仕様が必要です。Miroのカードを展開して、こうした詳細な仕様（ユースケース記述）を追記していくと、このマップだけで要件が完結します。

また、「ストーリー」が１文だけだと、大雑把な要件は分かるのですが、細かい前後の処理や期待するシステムの振る舞いまで記載できません。
例えば、「会員登録」のアクティビティで、「メールアドレスで登録する」というユーザーストーリーの場合、重複するメールアドレスがあった場合の処理などの記載も仕様上定義が必要です。

そこでさらにストーリーの詳細な中身を展開して記述して書けるのですが、そこはUML（Unified Modeling Language/統一モデリング言語：システム、ソフトウェア開発において要素間の関係やシステムの流れ、構造を可視化する設計図）でいうところの「ユースケース記述」のような記載をすると、エンジニアは把握しやすいと思います。

ストーリーに対応する画面プロトタイプをFigmaやXDで作成しているなら、FigmaやXDのURLをリンクしておくと、画面とストーリーをマッピングでき要求を理解しやすくなるのでお勧めです。

その他、UIイメージを作成したらそれを関連するアクティビティに貼ったり、矢印で結線して関連性を示したり、Miroの機能をフル活用して分かりやすく・伝わりやすくしていきましょう。

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

MECEに記載する

MECE（ミーシー）とは「モレなく、ダブりなく」ということです。最初に記載しましたが、要件定義に相当するものなので、「要件がモレてました」というのは好ましくありません。また「ダブり」があると、見積もりに影響します。なのでマッピングを行うストーリーの抽出はMECEである必要があります。

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

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

見積もり基準とするユーザーストーリーをひとつ選び（例えば「メールアドレスで登録する」）、その実装工数をN時間と定義し、そのユーザーストーリーと比べて他のユーザーストーリーはどれぐらい（何倍ぐらいか）重たいか、軽いかをヒューリスティックに見積もっていき、CSVでエクスポートして合算すると全体工数を算出できます。
※時間ではなくストーリーポイントで見積もる、という手法もあります。

まとめ

ユーザーストーリーマッピングは、顧客視点で描いたカスタマージャーニーマップと、開発・実装の世界とをつなぐ、極めて重要な「翻訳」の役割を担います。Webサイト担当者がこの手法を理解し、デザイナーや開発者との共通言語として活用することで、チーム間の認識のズレを防ぎ、「顧客にとって本当に価値のある体験」をブレなくプロダクトに実装していくことが可能になります。

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