Persona Designer

---
name: persona-designer
category: role
user-invocable: false
description: プロダクトのペルソナ/ユーザー像を、仮説と根拠（観察・調査・制約）で組み立て、意思決定に使える形へ整形する。※会話口調のペルソナ（にゃんこ）とは別物。
---

# Persona Designer Skill

## 発火条件（適用タイミング）
- 依頼が「ペルソナ」「想定ユーザー」「ターゲット」「JTBD」「課題仮説」「利用シーン」の整理なら適用する。
- `doc/input/rdd.md` の「想定ユーザー像」「ユースケース」が未確定/曖昧な場合は優先適用する。

## このSkillの基本方針（整理軸）
- 基本方針: ペルソナは“キャラ作り”ではなく、設計判断のための「仮説モデル」。
- 根拠重視: 推測で断言しない。事実（観察/既存ログ/ヒアリング/競合）と仮説を分けて書く。
- 運用可能性: 作って終わりではなく、検証と更新ができる形にする。

## 思想（判断ルール）
1. ペルソナは「代表例」であって「全員」ではない。どこまでを代表させるかを明示する。
2. 行動・目的・制約（時間/予算/スキル/環境）を中心に据える。属性（年齢等）は必要最小限。
3. 競合や代替行動（いまどうやって解決しているか）を必ず含める。
4. “痛み”と“価値”を同時に持つ（何が困り、何が嬉しいか）。
5. 検証可能な仮説に落とす（次に取るべき調査が決まる形）。

## 進め方（最初に確認する問い）
- 誰が使う？（利用者/購入者/管理者の分離は必要？）
- 何を達成したい？（目的/JTBD）
- どんな制約がある？（時間/頻度/環境/端末/権限）
- いまの代替手段は？（競合/手作業/Excel等）
- 成功/失敗は何で判断する？（KPI/体験/業務）

## 出力フォーマット（必ずこの順）
1. 前提（事実/仮説/不明点）
2. ペルソナ候補（1〜3名）
3. 各ペルソナの「目的/状況/制約/代替/痛み/価値」
4. 優先順位（どれをMVPで優先するか）
5. 検証計画（次に聞く/見る/測る）

## よくある落とし穴
- 属性だけで作って、設計判断に使えない
- “理想ユーザー”しか描かず、現実の制約が抜ける
- 仮説と事実が混ざり、検証できない