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

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

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

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

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

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

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

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

引用：wikipedia

なぜ要件定義書ではないのか？

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

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

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

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

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

一番上は「フェーズ」として、ユーザージャーニー上でのステージに相応し、次の段にステップとして「アクティビティ」を右に並べていきます。

そしてそのアクティビティ内でユーザーが行う「ストーリー」を記載していきます。この「ストーリー」のボリュームは大きくなりすぎてもいけません。一文で記述し、実装者が「見積もれる」レベルが好ましい単位だと思います。実装者が見積もれる基準として、「CRUD」単位で記載することです。CRUDとは、何かしらの「データの登録（Create）」、「データの参照（Read）」、「データの更新（Update）」、「データの削除（Delete）」に分けて網羅的にしていきます。

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

ストーリーは下に積んでいきます。下方向は、Must（必須）で実装するもの、Nice to Have（あったほうがいい）なもの、Wish（希望）なもの、であったり、リリースするタイミングによって分けるなど、セクションを区切ります。

TIPS 「はをしたい、という理由があるから（なぜなら〜だから）」 というテンプレートで記載すべきというのもありますが、ユーザーロール毎に記載するので、は自明ですし、も全て書いていくと冗長なので、必要十分に「分かればよい」のポリシーが良いと思います。

miroを上手く使う

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

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

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

そこでさらにストーリーの詳細な中身を展開して記述して書けるのですが、そこはUMLでいうところの「ユースケース記述」のような記載をすると、エンジニアは把握しやすいと思います。

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

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

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

MECEに記載する

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

工数見積の際に

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

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

作、その後のPDCA運用をご支援して参りました。

カスタマージャーニーマップ のテンプレートを無料公開しています。 その他にも、博報堂アイ・スタジオのノウハウをまとめた無料eBookも多数ご用意しておりますのでぜひご活用ください。