journey-mapping

ジャーニーマッピング

摩擦を明らかにし、チーム間の認識をそろえ、機会を特定するジャーニーマップとサービスブループリントを作成します。スタックに依存しません。ツールにも依存しません。

このスキルは体験をマッピングするためのものです。特定のタッチポイントをテストするには、usability-testingを使用してください。より広範な探索的リサーチには、ux-researchを使用してください。コンバージョンを分析するには、cro-optimizationを使用してください。

---

使用するタイミング

• 部門ごとに顧客体験について異なる認識を持っている
• タッチポイント間で顧客体験に一貫性がない
• 特定の摩擦や離脱ポイントの原因を特定する必要がある
• 戦略計画に、ユーザーに対する共通認識が必要である
• サービスデザイン（フロントステージとバックステージ）の認識をそろえる必要がある
• 新しい製品や機能を、より広い体験の文脈で設計する必要がある

使用しないタイミング

• 単一のタッチポイントやページをテストする場合（usability-testingを使用）
• ジャーニーマッピング前の探索的リサーチを行う場合（ux-researchを使用）
• ユーザーが関与しない業務プロセスをマッピングする場合
• ファネルを最適化する場合（cro-optimizationを使用）

---

必要な入力

• マッピング対象として特定されたユーザーペルソナまたはセグメント（セグメントごとにマップを1つ作成）
• そのセグメントに関する既存の調査とデータ
• 部門横断での協力体制（オペレーション、サポート、エンジニアリングから情報を得られなければ、バックステージをマッピングできません）
• 時間とステークホルダーのコミットメント（本格的なジャーニーマップ作成はプロジェクトであり、午後の数時間で終わるものではありません）

---

フレームワーク：3つの成果物

1. カスタマージャーニーマップ

ユーザー視点で体験を表したものです。

構成（行／レーン）：

• フェーズ。 ジャーニーの主要な段階（例：認知、検討、オンボーディング、利用開始、継続、推奨）。フェーズは製品の種類によって異なります。
• ステップ。 各フェーズでユーザーが行う具体的なこと。
• タッチポイント。 ユーザーが製品、ブランド、サービスとやり取りする場所（ウェブ、アプリ、メール、サポート、ソーシャルメディア、対面）。
• 目標。 このステップでユーザーが達成しようとしていること。
• 思考。 ユーザーが考えていること。
• 感情。 ユーザーの感情状態（曲線で可視化されることがよくあります）。
• ペインポイント。 問題や摩擦、フラストレーションが生じる箇所。
• 機会。 体験を改善できる箇所。

形式：

通常は、各行を縦のレーンで表した横長のタイムラインです。上部にフェーズを並べ、その下にタッチポイント、思考、感情などを配置します。

2. サービスブループリント

顧客向けの体験を支える、バックステージの視点を示します。

ジャーニーマップの下に、次のレイヤーを追加します：

• フロントステージのアクション。 ユーザーから見える従業員の行動（営業電話、サポートチャット、店舗での接客）。
• バックステージのアクション。 舞台裏で行われること（注文の履行、データ処理、社内の引き継ぎ）。
• 支援プロセス。 システム、ベンダー、インフラ（CRM、決済処理業者、フルフィルメントパートナー）。
• 可視性の境界線。 フロントステージ（ユーザーに見える領域）とバックステージ（ユーザーには見えない領域）の境界線。

サービスブループリントを使うと、顧客向けの問題がバックステージの不備にどこから起因しているかがわかります（例：「配送が遅い」というユーザーの体験は、ベンダーへの引き継ぎの問題に行き着きます）。

3. 統合された機会マップ

マッピング作業の成果です。

次の内容をまとめます：

• 主な摩擦ポイント。 体験が継続的にユーザーの期待に応えられない箇所。
• 未開拓の機会。 体験を通じて、ユーザーを驚かせ、喜ばせられる場面。
• 不整合。 フロントステージとバックステージの連携が取れていない箇所。
• 戦略的なギャップ。 競合にはあるがブランドにはないもの（またはその逆）。
• すぐに実施できる改善。 労力が少なく、効果が大きい改善。
• 戦略的な取り組み。 より大きな労力を要する変革。

意思決定につながる成果物です。ジャーニーマップとサービスブループリントは入力であり、機会マップは行動を促す出力です。

---

製品タイプ別の一般的なフェーズ

ほとんどの製品

Awareness → Consideration → Decision → Onboarding → Active use → Renewal/Repurchase → Advocacy

SaaS

Trigger → Discovery → Evaluation → Trial → Onboarding → Activation → Habit → Expansion → Renewal → Advocacy

Eコマース

Need recognition → Discovery → Research → Decision → Purchase → Wait/Anticipation → Receive → Use → Reorder/Recommend

サービス

Awareness → Inquiry → Quote → Decision → Service delivery → Resolution → Follow-up → Repeat business

医療／購入リスクの高い製品

Trigger → Research → Provider selection → Appointment → Treatment → Recovery → Follow-up → Long-term outcome

フェーズは必須ではありません。ユーザーの実際の体験から始め、ステップをもとにフェーズを導き出してください。

---

入力情報の収集方法

優れたジャーニーマップは、複数の情報源を組み合わせて作成します。

ユーザーから

• 詳細なインタビュー。 ユーザーに実際の体験を順を追って話してもらいます。最近の事例について具体的に尋ねます。
• 日記調査。 ユーザーにジャーニーの期間中、体験を記録してもらいます。
• アンケート。 大規模な定量的な傾向を把握できますが、深さはあまりありません。

ビジネスから

• 社内インタビュー。 営業、サポート、カスタマーサクセス、オペレーションなどの担当者に話を聞きます。プロダクトやデザインの担当者とは異なる視点から体験を捉えています。
• 業務データ。 ファネルデータ、サポートチケットのカテゴリ、NPS の回答、解約理由などです。
• システムの一覧。 どのタッチポイントが存在し、それらをどのツールが支援し、データがどこへ流れるかを確認します。

相互検証

• ユーザーが説明する体験
• ビジネスがユーザーの行動について持つデータ
• 社内チームが捉える体験

この3つの視点は、しばしば食い違います。その食い違い自体が調査結果となります。

---

ワークフロー

1. 範囲を定めます。 1つのペルソナ、1つのジャーニー、1つの期間に絞ります。すべてのユーザーを1つのマップにまとめようとすると、収拾がつかなくなります。
2. 入力情報を集めます。 ユーザーインタビュー、社内インタビュー、業務データを集めます。情報収集には2〜4週間を見込みます。
3. ジャーニーの草案を作成します。 フェーズ、ステップ、タッチポイントを整理します。まずはすばやく作業用の草案を作り、反復して改善します。
4. 各レイヤーを追加します。 目標、考え、感情、問題点を加えます。
5. サービスブループリントを作成します。 表舞台、裏舞台、支援プロセスを整理します。
6. 機会を特定します。 摩擦点や連携の断絶を活用します。
7. ユーザーと検証します。 実際の体験と一致しているか確認し、改善します。
8. 関係者とワークショップを行います。 チームにマップの内容を説明し、共通理解を確保します。
9. 具体的な行動に落とし込みます。 具体的なプロジェクト、担当者、スケジュールを決めます。
10. 継続的に更新します。 ジャーニーマップは継続的に更新されるドキュメントです。毎年、または大きな変更の後に見直します。

---

失敗のパターン

• 調査なしでマッピングする。 社内の思い込みだけで作ったジャーニーマップは、ユーザーではなく思い込みを反映します。
• すべてのユーザーを1つのマップにまとめる。 ミッドマーケットの購入者とエンタープライズの購入者では、ジャーニーが異なります。統合しないでください。
• 裏舞台のレイヤーがない。 マップには症状しか示されず、原因が見えません。
• 見栄えのよいマップを作っても、行動につながらない。 意思決定を犠牲にして、制作物の品質に投資しています。
• マップをツールではなく成果物として扱う。 Figma に保存したまま、二度と開かれません。
• 感情のレイヤーを無視する。 「何が起きたか」だけで「どう感じるか」がなければ、ジャーニーマッピングの要点を見失います。
• 問題点が曖昧。 「オンボーディングが不満」では不十分です。具体的に何が、いつ、なぜ起きるのでしょうか？
• すぐにできる改善策を特定しても、実行しない。 公開されない調査結果と同じです。
• 毎年実施しても、その後の対応がない。 1年前のジャーニーマップは、1年前のユーザーを表しています。

---

出力形式

標準的な出力：

1. ジャーニーマップ（通常は Figma／FigJam／Miro で作成するビジュアルと、Markdown 形式の説明文）
2. サービスブループリント（ビジュアル。通常は同じツールで作成）
3. 機会マップ（Markdown 形式の優先順位付きリスト）

ジャーニーマップの Markdown 形式の説明文：

# [Persona] journey map

## Phase 1: [Phase name]

### Step: [Step name]
- **Touchpoint:** [Where this happens]
- **Goal:** [What the user wants here]
- **Thoughts:** [What they're thinking]
- **Emotion:** [State on the emotional curve]
- **Pain points:** [Friction]
- **Opportunities:** [Improvement potential]

### Step: [Step name]
[Same structure]

## Phase 2: [Phase name]
[Repeat]

## Service blueprint additions

### Phase 1
- **Front-stage actions:** [What employees do user-visibly]
- **Back-stage actions:** [What happens behind the scenes]
- **Supporting processes:** [Systems involved]

[Repeat per phase]

## Opportunity map

### Critical friction
1. [Specific issue, with evidence]
2. [Specific issue, with evidence]

### Quick wins
1. [Specific opportunity, with effort/impact]

### Strategic bets
1. [Specific opportunity, with effort/impact]

### Cross-team disconnects
1. [Specific disconnect, with implication]

---

必要なデータが入手できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、データソースが利用できない、または検証できない場合に認められる出力は、その不足を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを記載します。成果物を完成させるために必要な数値を捏造、推定、補間することは、決して認められません。不足を明記すれば、回答として成立します。

---

参考ファイル

• references/journey-map-template.md - 記入式のジャーニーマップとサービスブループリントのテンプレートです。