| name | persona-designer |
| category | role |
| description | プロダクトのペルソナ/ユーザー像を、仮説と根拠（観察・調査・制約）で組み立て、意思決定に使える形へ整形する。※会話口調のペルソナ（にゃんこ）とは別物。 |
Persona Designer Skill
発火条件（適用タイミング）
- 依頼が「ペルソナ」「想定ユーザー」「ターゲット」「JTBD」「課題仮説」「利用シーン」の整理なら適用する。
doc/rdd.mdの「想定ユーザー像」「ユースケース」が未確定/曖昧な場合は優先適用する。
このSkillの基本方針（整理軸）
- 基本方針: ペルソナは“キャラ作り”ではなく、設計判断のための「仮説モデル」。
- 根拠重視: 推測で断言しない。事実（観察/既存ログ/ヒアリング/競合）と仮説を分けて書く。
- 運用可能性: 作って終わりではなく、検証と更新ができる形にする。
思想（判断ルール）
- ペルソナは「代表例」であって「全員」ではない。どこまでを代表させるかを明示する。
- 行動・目的・制約（時間/予算/スキル/環境）を中心に据える。属性（年齢等）は必要最小限。
- 競合や代替行動（いまどうやって解決しているか）を必ず含める。
- “痛み”と“価値”を同時に持つ（何が困り、何が嬉しいか）。
- 検証可能な仮説に落とす（次に取るべき調査が決まる形）。
進め方（最初に確認する問い）
- 誰が使う？（利用者/購入者/管理者の分離は必要？）
- 何を達成したい？（目的/JTBD）
- どんな制約がある？（時間/頻度/環境/端末/権限）
- いまの代替手段は？（競合/手作業/Excel等）
- 成功/失敗は何で判断する？（KPI/体験/業務）
出力フォーマット（必ずこの順）
- 前提（事実/仮説/不明点）
- ペルソナ候補（1〜3名）
- 各ペルソナの「目的/状況/制約/代替/痛み/価値」
- 優先順位（どれをMVPで優先するか）
- 検証計画（次に聞く/見る/測る）
よくある落とし穴
- 属性だけで作って、設計判断に使えない
- “理想ユーザー”しか描かず、現実の制約が抜ける
- 仮説と事実が混ざり、検証できない