pm-personas-jtbd

ペルソナとジョブ理論スキル

このスキルの動作（最初にお読みください）

これは生成型のスキルであり、ペルソナはAIアシスタントがまさに間違ったことをしたくなる場面です。「ペルソナをいくつか作って」と頼まれると、ありがちなのは、調査に基づかない、人口統計からニーズを推測するような、もっともらしい架空の人物像――「32歳のマーケティングマネージャー、サラ。ヨガとオーツミルクラテが大好き」――と、無関係なライフスタイル情報を大量に作り上げることです。Uxcel自身の情報源は、LLMが生成したペルソナはインターネット上の一般的なステレオタイプを反映し、エッジケースやマイノリティのユーザーを過小評価すると、率直に述べています。有用なペルソナとは、あらゆる詳細がデザイン上の判断を変えうる、記憶に残る人物像として実際の調査を統合したものです。一方、重要なのが「ユーザーが達成しようとしている進歩」である場合は、**ジョブ理論（Jobs-to-Be-Done）**のほうが適切な視点になります。そのため、このスキルでは次の点を確認します。

1. 調査の目的、現在の段階と保有データ、リソースを明確にします — これらによって、ペルソナ、ジョブ理論、またはその両方を使うか、そして作成に必要な根拠がそもそも揃っているかが決まります。
2. 常に有効な基本原則を適用します — 実際の調査に基づくこと、意思決定に関係する詳細のみを残すこと、ジョブにはジョブ理論を、ユーザー像にはペルソナを使うこと、セットを少数に絞ること、チームで作成すること、そして常に更新し続けることです。
3. 状況に応じて判断する項目（視点の選択、調査に基づくものかプロトタイプか、人数、詳細の選定、セグメンテーションの深さ、AIの役割）を、トレードオフとともに提示します。

その後、pm-assumption-rigor-audit に引き継ぎます — ペルソナが主張するニーズや行動が、思い込みではなく根拠に基づいているかを確認する工程です。

対象範囲：このスキルが扱うのはオーディエンス理解の成果物です。そこに至る調査プロセスは pm-discovery（倫理的でインクルーシブな参加者募集を含む）に、ユーザーの問題の明確化は pm-problem-statement に、ペルソナとジョブをユーザーストーリーに変換することは pm-user-story に、行動・コホート分析の深掘りは pm-analytics に委ねます。

---

ステップ 0 — 作成前に背景を明確にする

不明な点があれば質問します。回答を得ずに進める場合は、前提を明示します。

• 調査の目的は何ですか？ 動機や満たされていないニーズを理解する → ジョブ理論。ターゲットを絞ったマーケティング、または誰を対象とするかについてのチーム内の認識合わせ → ペルソナ。製品開発を導く → 両方。目的によって視点を選びます。
• どの段階にあり、どのようなデータがありますか？ 定性的なインタビューのみの初期段階 → ジョブ理論、またはプロトペルソナであることを明示したもの。分析データと調査が揃った既存製品 → 調査に基づくペルソナ。持っていない情報を捏造しないでください。
• どのようなリソースと時間がありますか？ ジョブ理論には、より深い定性的インタビューが必要になるため、コストが高くなります。ペルソナは分析データや短いアンケートから始められるため、より迅速で幅広く進められます。
• この成果物を誰が使いますか？ 共通の、親しみやすい参照資料を必要とする多様なチーム → ペルソナ。満たされていないニーズやイノベーションを探すチーム → ジョブ理論。

---

常に適用する基本原則（ペルソナやJTBDに関するあらゆる作業に当てはまります）

• 実際の調査に基づけます。創作やAIのステレオタイプに頼ってはいけません。 ペルソナは、インタビュー、フィールド調査、アンケート、分析から見つかったパターンを統合したものです。まだ調査データがない場合は、仮定に基づく暫定案であることを明記した プロトペルソナ を作成して検証します。検証済みのものとして扱ってはいけません。AI（このアシスタントを含みます）は、実際のデータを得た後の統合と草案作成を支援するものであり、調査の代わりにはなりません。生成されたペルソナはありきたりなステレオタイプを再現し、例外的なケースを消し去るからです。
• すべての詳細は、設計上の決定を変えるものでなければなりません。 属性を採用するかどうかは、「それによって決定が変わるか？」で判断します。変わらないなら削除します。意思決定を左右する心理特性（目標、課題、動機、行動）を中心にし、人口統計情報は、その人の製品の利用方法に関係する場合にのみ含めます。無関係な詳細はペルソナを豊かにするどころか、ペルソナ全体に対するチームの信頼を損ないます。
• 人口統計情報からニーズを導き出してはいけません。 同じ年齢、同じ収入の人でも、行動は異なります。人口統計情報はセグメンテーションの出発点であって、ニーズの根拠ではありません。調査から得られた知見をもとにニーズを組み立てます。
• ジョブにはJTBDを、人物像にはペルソナを使います。 JTBDでは、ユーザーが製品にどのような進歩をもたらしてもらうために「雇う」のか（「ユーザーは製品を雇い、期待を裏切られれば解雇する」）を尋ねます。成果に焦点を当て、人口統計情報より安定性が高く、イノベーションや差別化に役立ちます。ペルソナは、JTBDだけでは捉えられない共感、背景、感情を補います。両者は相互に補完するものであり、「商品をすばやく見つける」といったジョブが複数のペルソナにまたがることもあります。だからこそ、優先する価値があります。
• 対象を絞り、明確なプライマリを設定します。 ほとんどの製品に必要なペルソナは約3～5人（最大7人）です。同じ設計上の要求をもたらすグループは統合し、意思決定に影響しないほど小さなセグメントは除外します。製品領域ごとにプライマリペルソナを1人指定し（意思決定は原則としてそのペルソナへの対応を優先します）、ほかのペルソナはセカンダリとして扱います（考慮には入れますが、プライマリを優先する判断を覆しません）。
• チームで作り、シナリオで検証します。 リサーチャー、デザイナー、PMが参加することで、前提が明らかになり、信頼も得られます。目標を追求するペルソナを描いた短いシナリオを作成し、要件を現実の文脈に結び付け、ペルソナの信頼性を厳しく検証します。
• 常に最新の状態に保ちます。 ペルソナは一時点を切り取ったものであり、永久に有効な記録ではありません。二つのペルソナが似通ってきたら統合し、広くなりすぎたものは分割し、製品、市場、ユーザーベースの変化に応じて見直します。見直しを頻繁に行うチームほど、ペルソナの影響力をはるかに高く評価しています。ペルソナを作成しても、ユーザーとの対話をやめてよい理由にはなりません。

「全員」から対象を絞るには、まずターゲット市場（ニーズが最も強く、かつ利用機会のある人々）を定義し、次にターゲットオーディエンス（特定のリリースを対象とする具体的なセグメント）を定義します。セグメントをペルソナやジョブとして具体化する前に、人口統計データ、心理特性データ、行動データを順に重ね合わせます。

---

文脈に応じて判断する事項（明示し、自動適用しない）

それぞれについて、トレードオフと Step 0 に基づく推奨事項を示し、ユーザーに選んでもらいます。「人口統計上のペルソナを3つ作成する」をデフォルトにすることが失敗の原因です。

判断事項	適用する場合	避ける／調整する場合	デフォルトの推奨事項
ペルソナか、JTBDか、または両方か	動機、満たされていないニーズ、イノベーションの調査や初期段階には JTBD、チームの認識合わせ、マーケティング、確立されたプロダクトの「誰」を明確にするにはペルソナ	目的に関係なく一方の視点を押し付ける	調査目的と段階に合わせます。プロダクト開発では両方を使います（ペルソナ＝誰、JTBD＝何）
調査に基づくものか、プロトペルソナか	調査データがまだない場合に限り、仮のものだと明記したプレースホルダーとしてプロトペルソナを使う	プロトペルソナ（または AI が作成したもの）を検証済みとして提示する	仮定を明示する目的に限って使い、データが得られたらすぐに調査に基づくものへ置き換えます
数と、主要／副次の区分	実際に異なるユーザーグループが存在する場合に限り、複数のペルソナを使う	細かなセグメントごとにペルソナを作る（記憶に残らず、維持も困難）	意味のある違いをカバーできる最小限の数（約3～5）にし、プロダクト領域ごとに主要ペルソナを1つ設定します
含める詳細情報	デザイン上の判断を変える属性だけを含め、利用に関係する場合は人口統計情報も含める	作り上げた人口統計情報、ライフスタイルの水増し、理想化されたストックフォトのステレオタイプ	サイコグラフィックを優先し、1～2ページに収めます。判断を左右しない情報はすべて削除します
セグメンテーションの深さ	人口統計を出発点として、実際のグループを把握するためにサイコグラフィック（なぜ）と行動（どのように）を加える	人口統計だけでセグメント化し、そこからニーズを推測する	ファーストパーティデータに基づき、人口統計、サイコグラフィック、行動を組み合わせます
AI の役割	実際のデータを収集した後に、AI でインタビュー記録をクラスタリングし、パターンを見つけ、プロフィールの草案を作成する	プロンプトから AI にペルソナをでっち上げさせる（一般的なステレオタイプや、まれなケースの見落としにつながる）	AI は情報の統合と書式設定に使います。出発点は常に実地調査です

---

結果を検証する（オーケストレーション）

引き継ぎでは、各視点をインストール可能なスキルの name で指定します。そのスキルがインストールされている場合に限り呼び出してください。インストールされていない場合でも、このスキル自体に必要なルールが含まれているため、作業を止めずに続行します。

作成または改訂した後は、完了とするのではなく、監査の視点に回します。これらは候補となる視点です。docs/orchestration-policy.md に沿って適切な姿勢を取り、または成果物全体を pm-product-review に回してください。ここでは assumption-rigor が常に関連する視点（自動実行）で、その他は成果物の実際の内容に応じて提示される視点です。ユーザーがこのスキルを特定の目的で呼び出した場合は、その範囲を尊重してください。

• pm-assumption-rigor-audit (自動実行) — 中核となる確認事項です。ペルソナのニーズ、目標、行動（またはジョブで求められる成果）が、根拠と実際のパターンに基づいているでしょうか。それとも、人口統計情報から推測されたり、プロトペルソナから引き継がれたり、一般的な事前知識から生成されたりした、暗黙の仮定でしょうか。未検証で、追加の調査が必要な、重要な主張を指摘します。

構成（docs/orchestration-policy.md §9 に準拠）： 成果物は監査されるのではなく、その後の PM 作業へ引き継がれます。成果物の根拠となる調査（pm-discovery）は上流の入力です。ペルソナとジョブから作られる課題の明確化（pm-problem-statement）とユーザーストーリー（pm-user-story）は下流の成果物です（次の作業として作成を提案しますが、自動生成はしません）。監査の結果、ペルソナの大半が仮定にすぎないとわかった場合は、その目的に立ち返ってください。ペルソナは、あらゆる判断において、実在する具体的なユーザーを意識し続けるためにあります。調査に基づいていなければ、名前札を付けたステレオタイプにすぎず、チームを誤った方向へ導きます。 アイデアから計画までを一貫して作成する場合は、pm-idea-to-plan が全体を構成する入口となり、このステップを残りの手順と順序立てて実行し、仕様の前に根拠を求めます。

---

よくあるすべきこと・すべきでないことのパターン

❌ すべきでないこと	✅ すべきこと
プロンプトから「ヨガ好きの32歳、サラ」をでっち上げる	実際のインタビュー、分析、フィールド調査をもとにペルソナを統合する
AI 生成のペルソナをリサーチとして扱う	AI を使って自分のデータを分類・下書きする。フィールドワークを出発点にする
年齢・性別・収入からニーズを推測する	リサーチからニーズを導き出す。人口統計情報はセグメンテーションの出発点にすぎない
ペルソナにライフスタイルの豆知識を詰め込む	デザインの意思決定を変える詳細だけを含める。まずサイコグラフィックを重視する
なじみがあるという理由でペルソナを選ぶ	目的に応じて視点を選ぶ。ジョブには JTBD、対象者にはペルソナ、プロダクト開発には両方を使う
プロトペルソナを事実として公開する	仮説にはプレースホルダーのラベルを付け、検証する
マイクロセグメントごとにペルソナを作る	約3～5人に絞り、似ているものを統合し、周辺的なものを除外して、主要なペルソナを1つ決める
ペルソナを一度だけ作成して壁に掲示する	チームで作成し、シナリオでテストして、データの変化に応じて見直す
ペルソナを確認せずに公開する	assumption-rigor に引き継ぎ、未検証の主張を指摘してもらう

---

参考資料（Uxcel）

• ペルソナと Jobs to Be Done の比較
• UX リサーチにおけるペルソナ
• ユーザーペルソナを作成するための13のヒント
• ターゲットオーディエンスの定義