体験価値を高めるカスタマージャーニー設計【PDFテンプレート付き】

1.【前提整理】なぜ今、改めてプロダクト設計に『ペルソナ』が必要なのか？

結論：ペルソナは、チームの意思決定を「センス」から「ロジック」へと変え、0→1の手戻りを防ぐための「最強の共通言語」です。

スタートアップの新規事業やBtoB SaaSの開発において、「30代男性・IT企業勤務」といった大まかなターゲット設定（デモグラフィック）だけでは不十分です。
ライフスタイルが多様化した現代では、同じ属性でも抱える課題や行動パターンは大きく異なるからです。

本記事では、MVPの画面設計を控えた責任者や、離脱率に悩むPMの方々に向けて、「ただの空想」で終わらせない、実務で使えるペルソナ設計の具体的な手法を公開します。

2.【課題】なぜ、あなたのペルソナは「動かない」のか？

せっかくペルソナを作っても、実際の設計に活かされないのには理由があります。
現場でよく陥る「3つの落とし穴」を、具体例と一緒に見ていきましょう。

1. 「自分ならこうする」という思い込み
ペルソナが不明確だと、作り手の「僕ならこう使う」「普通はこうでしょ」という個人的な感覚（センス）で設計が進んでしまいます。た「企業の願望」

2. 「都合のいい架空の友人」を作ってしまう
自分たちのサービスを完璧に使いこなしてくれる「理想のユーザー」を妄想で作ってしまうパターンです。これを、場面によって性格が伸び縮みする「ゴムのユーザー」と呼びます。

3. プロフィールを「盛りすぎ」てしまう
「細かく設定しよう！」と意気込むあまり、サービス設計に全く関係のない「裏設定」まで作り込んでしまう失敗です。

問題の本質：なぜこれらが起きるのか？

これらの失敗が起きる理由は、大きく2つです。

1. 「本当の姿」を調べていないから
自分たちの脳内だけで完結させ、「調査（リサーチ）」に基づいた事実からペルソナを構築していないことが原因です。

2. チームの「判断基準」がバラバラだから
ペルソナの役割は、「この人なら、このデザインを喜ぶかな？」とチーム全員が同じモノサシで判断できるようにすることです。

この共通言語がないと、声の大きい人の意見やその場のノリで設計が決まってしまい、プロダクトの軸がブレてしまいます。

「本当のユーザー」を正しく知り、チーム全員で「この人のために作ろう」という合意形成を行うこと。

これが、成功するプロダクト設計の第一歩です。

3.【事例】同じ「チャットツール」でもこれだけ違う：Slack vs Microsoft Teams

優れたプロダクトが必ずしも選ばれるとは限りません。成功している企業に共通するのは、「こう使ってほしい」という自社の願望を捨て、顧客が抱える「負の感情」をカスタマージャーニーで見抜いている点にあります。機能の羅列ではなく、顧客の躓きを解消することに全力を注ぎ、組織一丸となって「一貫した体験」を届けた2つの成功事例を見ていきましょう。

ペルソナ設計がいかにプロダクトのUI/UXや機能要件を変えるか、BtoB SaaSの代表的な事例で比較してみましょう。

Slackの設計：現場の「熱量」と「スピード」を最大化する設計
Slackが描くペルソナは、「現場のボトムアップで導入し、フランクな雑談や開発スピードを求めるスタートアップ・アジャイル開発チーム」です。
この「現場主導」のペルソナに応えるため、UI/UXは以下のように設計されています。

・コミュニケーションの温度感：
カスタム絵文字による気軽なリアクションで、雑談や称賛文化を活性化させる。
・開発効率：
GitHubなどの外部ツールと柔軟に連携し、エンジニアが好むコマンド操作での業務自動化を重視。
・トーン＆マナー：
直感的でカジュアルなUIに加え、ローディング画面のメッセージなどに「遊び心」を持たせることで、使う楽しさを演出。

Microsoft Teamsの設計：組織の「統制」と「資産」を守る設計
対してTeamsのペルソナは、「経営層のトップダウンで導入を決め、権限管理や既存資産の活用を重視する大企業の情シス（情報システム部）」です。
この「管理主導」のペルソナには、Slackとは対照的な機能が求められます。

・既存資産の最大化：
WordやExcelなど、Office製品とのシームレスな共同編集機能。
・セキュリティと統制：
細やかなアクセス権限設定やログ管理など、情シスが安心して導入できる管理画面の充実。
・トーン＆マナー：
カレンダーやWeb会議と強固に統合された、ミスが許されないビジネスシーンに馴染む「堅牢で真面目なUI」。

結論
同じ「社内コミュニケーションツール」でも、ペルソナ（誰が導入を決め、何を最重視するか）が違えば、実装すべき機能の優先順位から画面の雰囲気まで、設計の「正解」は全く異なるものになるのです。

4.【進め方】「失敗しない」ペルソナ設計の5ステップ

ステップ1：必要な「情報の枠」を決める
まずは、プロフィールのうち「画面設計や機能の判断に本当に必要なもの」だけを絞り込みます。

ステップ2：「本音」を拾い上げる（リサーチ）
自分の頭で「たぶんこうだろう」と想像するのは禁止です。
Web検索や実際のユーザーの声を拾い使い、ネット上に落ちている「ユーザーの生の足跡」を徹底的に集めます。

ステップ3：似ている人を集めて「キャラ」を絞る
集まった大量のデータから、似たような悩みや行動パターンを持っている人をグループ分けし、その中から象徴的な1〜3人のキャラクターに絞り込みます。

ステップ4：その人の「背景」と「ゴール」を描く
そのキャラクターに、「なぜその課題を感じているのか」という背景（物語）を付け足し、サービスを使って「最終的にどうなりたいか（ゴール）」をはっきりさせます。

ステップ5：ユーザーの「やる気度（意識レベル）」を見極める
その人が、自分の抱える問題に対してどのくらい熱心か、5段階で評価します。

5.【テンプレート配布】ペルソナ設計用シート

EFが実際に実案件で使用している、BtoB/BtoC両対応の「ペルソナ設計シート」を配布しています。

基本情報： 氏名（愛称）、年齢、居住地、職業、家族構成
心理・行動情報： 1日のスケジュール、よく使うSNS、仕事上の目標、現在直面している悩み
利用時コンテキスト： サービスを知ったきっかけ、導入の決め手、期待する変化

6.【まとめ】この記事の要点

ペルソナは、チームの認識のズレをなくし、判断を高速化するための土台である。
「妄想」ではなく「事実（リサーチ）」に基づいて作成し、定期的にブラッシュアップし続けることが重要。
ペルソナを基にカスタマージャーニーマップを作成することで、より精緻なUX設計が可能になる。

7.【その他】Engineerforceの設計思想

EF（Engineerforce）は、単に「きれいなUI」を作る集団ではありません。
ユーザーの思考プロセスを徹底的に分析し、「なぜこのボタンはこの位置なのか」「なぜこの言葉が響くのか」をロジカルに説明できる設計を重視しています。