UXってなんだろう⑦〜ペルソナを動かし体験を可視化する「ジャーニー」と「ストーリー」〜

こんにちは。デザイナーのスギヤマです。

前回の第6回では、リサーチ（事実）に基づいた「ペルソナ」を作りました。

「ペルソナを作った。で、次は何するの？」

綺麗なペルソナシートを作って壁に貼っておくだけでは、システム開発には役立ちません。そのペルソナが「時間軸」の中でどのように行動し、どこでつまずき、どう感情が動くのかを可視化し、チームで共有するための「地図」を作る必要があります。

今回はそのための代表的な手法を整理します。UXの世界には「ジャーニー」や「ストーリー」といった、似たような名前の地図がたくさんあって混乱しやすいので、まずはその違いから確認していきます。

UX用語多すぎ問題

UXやアジャイル開発の用語は似たようなものが多いです。たとえば、「ジャーニー」と「ストーリー」「マッピング」などなど。どれもこれも「地図を作る」という共通のアクションをしていますが、その役割は少しずつ異なります。

チームで「ユーザーの地図を作りましょう」と言っても、エンジニアは「機能の優先順位を決める地図」をイメージし、デザイナーは「ユーザーの感情を見える化する地図」をイメージしていて、齟齬が生まれてしまいます。

「ジャーニー」と「ストーリーマッピング」の決定的な違い

UXの「地図」づくりにおいて、よく迷う2つの代表的な手法があります。この2つは名前が似ていますが、目的が異なります。

カスタマージャーニーマップ（感情と課題の地図）

ユーザーの「感情の起伏」や「思考」を中心に描き、現在の体験のどこに課題（ペイン）があるかを発見するためのマップです。

時間軸に沿って「ユーザーがサービスとどのように接触するのかを可視化」します。その過程で、ユーザーがいつ満足し、いつ不満を感じるのかを見える化することが目的です。時間軸に沿って行動、感情、チャネル、タッチポイント、インサイトなどを明確にしていきます。

「このポイントで、ユーザーは不満になりそうだな」という課題を発見できるため、改善すべきポイントがどこなのかが明確になります。つまり「課題を見つけるための地図」です。

簡易なユーザージャーニーマップのイメージ

ユーザーストーリーマッピング（行動と開発優先度の地図）

ユーザーストーリーマッピングは、ユーザーの「行動（タスク）」を時系列に並べ、システムとして「どんな機能を、どの順番で開発すべきか（優先順位）」を決めるためのマップです。

「ユーザーがこのサービスを使う時の行動って、何を何を何をしてるんだっけ？」という一連の行動を、タスク単位に細かく分け、その行動を実現するために必要な機能を可視化していきます。

その結果、「この機能は絶対に必要だけど、あの機能は後でもいいかな」という優先順位（MVP）の判断が可能になります。つまり「開発の優先順位を決めるための地図」です。

簡易なユーザーストーリーマッピングのイメージ

2つの違い

カスタマージャーニーマップ	ユーザーストーリーマッピング
ユーザーの「感情」	ユーザーの「行動」
課題（ペイン）を発見する	開発優先度を決める
「何が問題なのか」を知りたい時	「何を作るべきか？」と決めたい時
感情を表す折れ線グラフになりやすい	タスクを並べるグリット型になりやすい

ちなみに「ユーザーストーリー」とは、このUSMに貼っていく
付箋1枚1枚に書かれている要求の最小単位のことです。

「〈誰〉として、〈どんな機能〉が欲しい。なぜなら〈何のため〉だから」というフォーマットで書きます。例えば「新規ユーザーとして、ステップ数が見えるプログレスバーが欲しい。なぜなら迷わず登録を完了したいから」といった形です。

USMを作ってみてわかった「つまずき」

いざ会議室に集まって付箋を貼りながらユーザーストーリーマッピングを作ろうとすると、よく陥る罠があります。

過去の記事「ユーザー体験をデザインしてみてのつまずき」でも紹介しましたが、「あれ？ ペルソナのコンディションによっては、こっちのルートにも分岐するぞ？」と、ストーリーが複数に分かれてしまい、マップがまとまらなくなる現象です。

例えば、新規ユーザーと既存ユーザーでは行動が異なるし、時間に余裕がある時とない時でも違う。そうした分岐を全部書きたくなってしまい、結果として「何が本体なのか」が曖昧になってしまいます。

「ハッピーパス」を1本通す

欲張ってすべての分岐を1枚のマップに書くと混乱してしまいます。

そこで、まずは一番優先順位の高い「理想的なメインストーリー（ハッピーパス）」を太い背骨として1本通します。別のルートは、別のマップとして分けて考えます。

「新規ユーザーのメインストーリー」「既存ユーザーの分岐パターン」というように、ペルソナやコンディションごとにマップを分けることで、複雑さを整理できます。

完璧を目指さず、まずは「一番大事なストーリー1本」を貫く。その方が最後までまとまったものが完成します。

AIを「優秀な書記」として活用する

前回の第6回で「AIにペルソナ作りを丸投げしてはいけない」とお話ししましたが、USMにおける「タスクの洗い出し」においては、AIは非常に強力なサポートツールになります。

過去の検証記事「ChatGPTと作ったユーザーストーリーマッピングが結構使えるかも」では、ペルソナの情報と大まかなシーンをAIに渡し、「この行動を達成するためのタスクを箇条書きにして」と指示すると、数秒から数分でたたき台となる付箋を出力してくれました。

ただし、AIが出すのはあくまで「中庸な（よくある）回答」です。

実際のワークショップでは、人間のチームから「ペットにGoProを取り付けて散歩する」といった細かい独自のアイデアが飛び出しました。こうした独自の発想は、人間の脳からしか生まれません。

そのため、AIの出力を「たたき台」にして、人間が独自性を足していくのが正しい使い方ではないかと考えます。AIに完成系を期待するのではなく、「優秀な書記」として手伝ってもらう。その上で、チーム独自の工夫を加えると良いのではないでしょうか。

裏側まで描く「サービスブループリント」

「ユーザーの体験だけでなく、裏側で動くシステムや、社員（間接ユーザー）の動きも可視化したい」という複雑な業務システムなどの場合は、「サービスブループリント」というさらに多層的なフレームワークを使います。

例えば「社員が経費申請する」という体験を描く場合、

● フロントステージ：申請フォームの画面
● バックステージ：上長の承認作業、経理の確認作業
● サポートプロセス：会計システムとの連携

といった形で、表と裏を同時に可視化できます。

BtoBのシステム開発などでは、ユーザーが見える「フロントステージ」と、バックエンドで動く「バックステージ」を一緒に描くことで、システムの限界（技術的な制約）とユーザー体験の妥協点を見つけるのにも役立ちます。これにより、サービス全体の設計精度が大きく向上します。

その他のフレームワーク

UXデザインのプロセスには、ここまでご紹介したもの以外にも、様々なフレームワークやアプローチがあります。

● 体験のモデル化段階

• ジャーニーマップ
• KA法

● 体験価値の探索段階

• 上位・下位関係分析
• タスク分析
• ワークモデル分析
• メンタルモデル・ダイアグラム
• グラウンデットセオリーアプローチ
• SCAT
• シナリオ法

● アイデア発想・コンセプト作成段階

• UXDコンセプトシート
• 構造化シナリオ法

● ユーザー体験の視覚化段階

• ストーリーボード
• 体験型バリューストーリー
• ９コマシナリオ
• アウティングアウト
• ビデオビジュアライザーション

など、プロジェクトの性質や目的に応じて、これらを組み合わせます。今回は深掘りしませんが、興味のある方は調べてみてください。

おわりに

これらのフレームワークの目的は、実際に手を使って行うことであり、綺麗な地図＝成果物を完成させることではないと考えます。

ステークホルダーや、エンジニア、PMと一緒になって付箋を動かし、「ユーザーはここでこう感じるはずだ」「じゃあこの機能は後回しにしよう」と、同じ時間を共有し、認識を合わせることこそが最大の価値です。

汚くても、未完成でもよく、最も大切にしたいのは、チーム全員でユーザーに向き合う時間を共有することです。地図作りを通して、チーム全員が同じ方向を向いて開発を進められるようにしたいものです。

参考：丸善出版「UXデザインの教科書」