そのペルソナ、本当にユーザーを見ていますか？
B2Bサービスのプロダクトデザインはますます複雑さを増し、高すぎる市場要求と限られた開発リソースとの間で、多くのデザイナーやプロダクトマネージャーは日々苦労しているでしょう。私も例外ではありません。そんな現場で、「ペルソナがチームの共通認識となり、ユーザー課題の解決に繋がった」という成功体験を語る声を聞くこともあります。確かに、適切に作られ活用されたペルソナは強力な武器となります。
しかし、そうした部分的な成功体験の不完全情報をもとに、未熟なデザイナーやプロダクトマネージャーが見よう見まねで作成した「ペルソナに似た何か」によって、プロダクト開発においてリソースの浪費や負債を生み出している状況を見かけることがあるように思います。決して人ごとではなく、私自身にも身に覚えがあります。
この記事は、それらを反面教師として、私自身のペルソナの理解を文章化し、自分自身を顧みようという試みになります。決して、「ペルソナとはこうあるべき」ということを言いたいわけでない点にご留意ください。
ペルソナと、ペルソナに似た何か
昨今、人間中心設計およびUXデザインの文脈で言及・引用される「ペルソナ」の背景理論は、アラン・クーパーの著書『About Face: The Essentials of Interaction Design、初版1995年』や『The Inmates Are Running the Asylum』（邦題『コンピュータは、むずかしすぎて使えない！』、初版1999年）の中で触れられた概念が源流とされています。
補足として、心理学者カール・ユングが提唱した個人の内面における社会的な「仮面」を指す概念として説明さ れる「ペルソナ」とは異なる概念であり、この記事で言及する「ペルソナ」はあくまでユーザー理解のために外部的に作成される設計上のモデルである点に留意が必要です。
この概念が生まれた背景として、当時のソフトウェア開発現場に対するアラン・クーパーの強い問題意識があり、多くのソフトウェアが、ユーザーのニーズや使いやすさよりも、技術的な機能やプログラマーの都合を優先して設計されているために、非常に複雑で使いにくいものになっているという批判が前提にあります。
アラン・クーパーが提唱したペルソナ法は、曖昧な「ユーザー」像ではなく、実際のユーザー調査に基づいた具体的な行動パターン、目標、動機を持つ架空の人物像（ペルソナ）として定義し、デザインの意思決定の中心に据えるための強力なツールとされます。
したがって、ペルソナとは、エスノグラフィックインタビューや観察といった質的データから抽出された、複数のユーザーに共通する本質的な行動やニーズを体現する「複合的なアーキタイプ」であるはずでした。
しかし、現代のB2Bデザインの現場、特にスピード感が求められる開発プロセスの中で、その本質が見失われがちです。そうした隙から、私たちはいつの間にか「ペルソナに似た何か」を生み出してしまってはいないでしょうか。
「ペルソナに似た何か」が生み出されるプロセス
とくにB2Bの領域は、B2Cに比べてユーザーに会いに行く難易度が高いことがあります。例えば、人事システムなどの幅ひろく企業で使用されるプロダクトにおいては、多様な役割（決裁者、管理者、実務担当者など）が関与するため、顧客に連絡をとりつけてインタビューを行ったとしても、本来話を聞きたかったユーザーが出てこないことも珍しくなく、ユーザー理解の難易度は高い傾向にあります。
加えて、極めて複雑な開発上の折衝とステークホルダーとの交渉が絡むディスカバリープロセスでは、以下のような状況が「ペルソナに似た何か」を生みやすいと考えています。
「架空」であることへの誤解：
ペルソナが架空の人物であるため、「どうせ作り物だろう」と、データに基づかない属性をデザイナーやPMなどの開発者自身の想像で補完してしまう。
調査プロセスの軽視:
時間的制約や予算の都合で、本来不可欠なユーザーインタビューや行動観察といった地道な質的調査を省略し、過去の記録や既存の知識や思い込み、あるいは簡単なアンケート結果だけで作成してしまう。
ステークホルダーの圧力:
「 実際のユーザーの声を聞きたい」というステークホルダーの要望に対し、調査に基づかない即席のペルソナで応えようとしてしまう。
プロビジョナル・ペルソナの乱用:
本格的な調査前の仮説であるはずのプロビジョナル・ペルソナが、検証されないまま「本物のペルソナ」として扱われ続ける。
こうして生み出されてしまった、データに基づかない、あるいは表層的な情報だけで作られたペルソナは、プロダクト開発チームを誤った方向に導きます。以下は、実際に私が「ペルソナに似た何か」を生み出してしまったことで起こった経験も含まれています。
的外れな機能開発:
存在しないニーズに基づいた機能を開発し、ちゃぶ台返し（検討を最初から見直すこと）を頻発したり、リソースを浪費してしまう。
複雑な組織構造やB2Bの課題の無視:
実際の業務フローや組織内の力学、ユーザーが本当に抱えるペインポイントを見過ごし、使われないプロダクトを生み出してしまう。
チーム内の認識齟齬:
根拠の薄い、または人によって解釈が揺れてしまう強度のペルソナは、チーム内での共通理解を醸成するどころか、立場上の意見の対立や混乱を招いてしまう。
これらの極端な結果として、ビジネスゴールを達成できない、ユーザーに価値を提供できないB2Bプロダクトが生まれてしまうこともあるでしょう。
ペルソナに必要なこと
「ペルソナに似た何か」の罠を回避し、真に価値あるB2Bプロダクトをデザインするためには、ペルソナ法 の本来の目的に立ち返る必要があります。
1. 厳密な質的データに基づく調査への回帰
B2Bの複雑な状況を理解するには、表面的なアンケートやアクセスログだけでは不十分です。実際のユーザー（複数の役割を考慮する）へのデプスインタビューや業務観察を通じて、「なぜ」「どのように」彼らが行動するのかを理解することが不可欠です。また、リモート環境であっても、工夫次第で質の高い調査は可能です。現在はAI技術の発展により、大量のデータを解析する労力を圧縮する手法も考えられるでしょう。
ここで、「プラグマティック・ペルソナ」という考え方にも触れておきます。これは、理想的なエスノグラフィック調査が時間的・予算的に困難な場合に、より現実的なアプローチとして提唱されることがあります。既存のデータ（アクセス解析、サポート問い合わせ記録、セールス部門からの情報、既存の市場調査など）の分析、ステークホルダーへのヒアリング、小規模で迅速なユーザー調査などを組み合わせて、実用的な範囲でユーザー像を定義しようとするものです。
重要なのは、プラグマティック・ペルソナも単なる憶測や思い込みであってはならないという点です。「ペルソナに似た何か」との決定的な違いは、限られたリソースの中でも入手可能な根拠（エビデンス）に最大限基づこうとすること、そして、そのペルソナがどのようなデータに基づいており、どのような限界があるのかをチーム内で明確に認識・共有した上で、デザイン上の意思決定に具体的に役立てることを目指す点にあります。
安易な「でっち上げ」ではなく、制約の中で最善を尽くすための、意識的な選択であるべきです。
2. 「行動パターン」の重視
年齢や役職といった表層的な属性情報以上に、ユーザーがプロダクトを使って「何を達成したいのか」、そしてそのための具体的な行動（業務上の役割、目標、タスク、利用ツール、情報ニーズ、抱える課題、意思決定プロセスなど）に焦点を当てます。
例えば、「営業部長、45歳」といった記述だけでは不十分でしょう。「四半期目標に対するチームの進捗をリアルタイムで把握し、迅速な改善指示を出したい（ゴール）。そのために、毎日朝夕にダッシュボードを確認し（行動）、週に一度は詳細レポートを生成して会議で利用する（行動）が、複数システムからのデータ統合に手間取り、最新状況の把握に時間がかかっている（課題）」といったレベルで具体化します。
アラン・クーパーが提唱するゴールダイレクテッド・デザインにおいては、ユーザーのエンドゴール（プロダクト利用を通じて達成したいこと）を深く理解し、可能であればその背景にあるライフゴール（キャリア上の目標など）やエクスペリエンスゴール（効率的に、安心して作業したいなど、利用時の感情的目標）まで洞察することで、より本質的なニーズに迫ることができるとされます。
重要なのは、複数のユーザーデータから共通する意味のある行動パターンや達成したいことを抽出し、それをペルソナとして結晶化させることです。
3. 作成プロセスの透明化
ペルソナが単なる想像の産物ではなく、実際のデータに基づいている ことをチームやステークホルダーに示すことが、信頼と共通理解の鍵となります。
特にB2Bでは、開発チーム、営業、カスタマーサポート、そしてクライアント自身など、多様な関係者が関わるため、透明性は不可欠です。 具体的には、完成したペルソナの記述だけでなく、「なぜこのゴールが設定されたのか」「この課題認識はどのインタビューに基づいているのか」といった根拠を（個人情報に配慮しつつ）示せるようにします。
例えば、ペルソナ定義書に参照元のインタビュー記録（の要約や匿名化された引用）へのリンクを記載する、ペルソナ作成の分析プロセス（グルーピングやパターン抽出の過程）を共有するワークショップを実施する、といった方法が考えられます。
これにより、ペルソナは「誰かが勝手に作ったもの」ではなく、「我々が捉えたユーザーのリアルな姿」としての説得力を持ち、デザイン議論の拠り所となります。これは、設計上の判断が特定のデータに「追跡可能」である状態を目指すことにもつながります。
4. 「ゴールダイレクテッド・デザイン」の徹底
ペルソナの存在意義は、ユーザーのゴール達成を支援するプロダクトを設計することにあります。定義されたペルソナのエンドゴール（例：「人事評価の準備を、最小限の手作業で完了させたい」）が、プロダクトの具体的な機能、情報設計、インタラクション、さらにはUIのルック＆フィールにどのように結びつくのかを明確にします。 これを実践する有効な方法が、ユーザーストーリー（ユーザーシナリオ）の作成です。
「ペルソナAが、ゴールXを達成するために、プロダクトYをどのように利用するか」という具体的なストーリーを描き、その過程でのユーザーの思考や感情、必要な機能や情報を洗い出します。例えば、「人事評価担当者の田中さん（ペルソナ）が、四半期の人事評価の結果分布レポートを評価会議用に提出する（シナリオ）」といった具体的な場面を想定し、必要なレポート機能や操作ステップを設計します。
主要なペルソナの重要なゴールが、プロダクト内の明確な利用シナリオ（ユーザージャーニー）によって満たされているかを確認することで、ゴールダイレクテッド・デザインの具体的なアウトプットとして機能しやすいでしょう。
5. 仮説としての認識と検証
一度作成したペルソナは、完成品ではなく「生きた仮説」として捉えるべきです。特に変化の速いB2B市場においては、ユーザーの置かれた状況、業務内容、利用技術、そして彼らのゴールも変化し得ます。
ここでは、手段のひとつとして、リーンUXの考え方を取り入れ、ペルソナを継続的に検証し、必要に応じて更新していくプロセスを考えてみたいと思います。
例えば、定期的なペルソナの見直し会議（四半期ごとなど）を設定し、最新のユーザーフィードバック、プロダクトの利用状況データ（アナリティクス）、市場動向などを踏まえて、ペルソナの記述（特にゴール、課題、行動）が現状に即しているかを確認します。 特定のペルソナ向けに設計した機能の利用状況を分析したり、A/Bテストの結果をペルソナの行動仮説と照らし合わせたりすることも有効とされます。
もし、ペルソナの行動予測と実際の利用データに乖離があれば、それはペルソナの仮説自体を見直す、あるいはプロダクトの改善が必要であるサインかもしれません。ペルソナは、一度作って終わりではなく、プロダクトと共に進化させていくものといえるでしょう。
ペルソナは検証されて初めて価値を持つ
改めてペルソナについて思いを馳せてみて、現在までに発展した考え方と照らしながら言語化してみましたが、私自身として色々反省する部分も多かったように思います。
B2Bデジタルプロダクトの開発者の皆さまにおかれましては、今一度、自分たちが使っているペルソナを見つめ直してみてください。それは、厳密な調査に基づき、ユーザーのリアルな行動とゴールを捉えたものですか？ それとも、都合の良い想像や、不確かな情報で飾られた「ペルソナに似た何か」になっていませんか？
真にユーザーの課題を解決し、ビジネスに貢献するB2Bプロダク トを創出するために、冷静にペルソナ作成の原点に立ち返り、その質を高めることを改めて考えるタイミングかもしれません。手始めに、次のプロジェクトで関わるステークホルダーに、彼らが認識しているユーザー像について深くヒアリングすることから始めてみてはいかがでしょうか。
