claude/skills/ideation-problem-definition/SKILL.md
JTBD(Jobs To Be Done)とペイン・ゲイン分析を用いて、ユーザーの問題を深掘りし定義する。新規プロダクト企画の初期段階、既存プロダクトの方向性見直し、ターゲットユーザーの理解が不十分な場合に使用。「問題を定義したい」「ユーザーのペインを整理」「JTBDで分析」「誰のどんな問題か明確にしたい」などのリクエストで起動。
npx skillsauth add skanehira/dotfiles ideation-problem-definitionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
対話を通じてユーザーの問題を深掘りし、以下を生成する:
どの領域の問題を定義するか理解する。
AskUserQuestion({
questions: [
{
question: "どのような領域/ドメインの問題を定義しますか?",
header: "領域",
options: [
{ label: "領域を入力", description: "対象となる業界やドメインを記述" }
],
multiSelect: false
},
{
question: "すでに想定しているターゲットユーザーはいますか?",
header: "ターゲット",
options: [
{ label: "いる", description: "具体的なユーザー像がある" },
{ label: "いない", description: "これから特定する" }
],
multiSelect: false
}
]
})
遷移条件: 領域が明確になったらフェーズ2へ
ユーザーが「雇いたい」ジョブを特定する。
ジョブの定義: ユーザーが特定の状況で達成したい進歩や成果
質問パターン:
AskUserQuestion({
questions: [
{
question: "ユーザーはどんな状況で、何を達成しようとしていますか?\n\n例: 「スロークエリが発生したとき、本番に影響を与えずに改善案を検証したい」",
header: "ジョブ",
options: [
{ label: "ジョブを入力", description: "[状況]のとき、[達成したいこと]" }
],
multiSelect: false
}
]
})
AskUserQuestion({
questions: [
{
question: "機能的に何を達成したいですか?(実用的な目的)",
header: "機能的",
options: [
{ label: "機能的ジョブを入力", description: "例: クエリの実行時間を短縮したい" }
],
multiSelect: false
},
{
question: "感情的にどうなりたいですか?(気持ち)",
header: "感情的",
options: [
{ label: "感情的ジョブを入力", description: "例: 自信を持って対応したい、不安を解消したい" }
],
multiSelect: false
}
]
})
遷移条件: ジョブが明確に言語化できたらフェーズ3へ
現状の課題や不満を洗い出す。
質問パターン:
AskUserQuestion({
questions: [
{
question: "現状のやり方で最も困っていること、不満なことは何ですか?(複数可)",
header: "ペイン",
options: [
{ label: "ペインを入力", description: "困っていること、不満、リスクを列挙" }
],
multiSelect: false
}
]
})
| 種類 | 説明 | 例 | | ------------------ | ---------------------------- | -------------------------- | | 機能的ペイン | うまく動かない、時間がかかる | クエリ最適化に時間がかかる | | 金銭的ペイン | コストがかかる | 外部DBAの費用が高い | | プロセスペイン | 手順が面倒、非効率 | 本番で試すしかない | | サポートペイン | 助けが得られない | 専門家がいない |
各ペインについて深掘り:
遷移条件: 主要なペインが3-5個特定できたらフェーズ4へ
ユーザーが本当に得たい価値を明確にする。
質問パターン:
AskUserQuestion({
questions: [
{
question: "問題が解決したら、どんな価値が得られますか?理想の状態は?",
header: "ゲイン",
options: [
{ label: "ゲインを入力", description: "得られる価値、理想の状態を列挙" }
],
multiSelect: false
}
]
})
| 種類 | 説明 | 例 | | -------------- | ---------------------- | ---------------------- | | 必須ゲイン | なければ解決にならない | 改善効果が数値でわかる | | 期待ゲイン | あって当然と思われる | 使いやすいUI | | 望外ゲイン | 期待を超える驚き | AIが自動で改善案を提案 |
遷移条件: ゲインが整理できたらフェーズ5へ
ペルソナを明確にする。
AskUserQuestion({
questions: [
{
question: "このジョブを最も強く持っているのはどんな人ですか?",
header: "ペルソナ",
options: [
{ label: "ペルソナを入力", description: "役職、スキルレベル、組織規模など" }
],
multiSelect: false
},
{
question: "逆に、ターゲットではない人は?",
header: "非ターゲット",
options: [
{ label: "非ターゲットを入力", description: "対象外のユーザー像" }
],
multiSelect: false
}
]
})
遷移条件: ターゲットが明確になったらフェーズ6へ
整理した内容をユーザーと確認する。
## 確認事項
1. ジョブの定義は正確か
2. ペインの優先順位は妥当か
3. ゲインは本当に求めているものか
4. ターゲットユーザーは具体的か
遷移条件: ユーザーが承認したらフェーズ7へ
確認が完了したら以下を生成する。
# 問題定義書
## ジョブ定義(JTBD)
### ジョブステートメント
[状況]のとき、[ターゲットユーザー]は[達成したいこと]したい。
なぜなら[動機/理由]だから。
### ジョブの3層構造
- **機能的ジョブ**: ...
- **感情的ジョブ**: ...
- **社会的ジョブ**: ...
## ペイン分析
| ペイン | 種類 | 深刻度 | 頻度 |
|--------|------|--------|------|
| ... | 機能的 | 5 | 毎日 |
## ゲイン分析
| ゲイン | 種類 | 優先度 |
|--------|------|--------|
| ... | 必須 | 高 |
## ターゲットユーザー
### ペルソナ
- **役職**: ...
- **スキル**: ...
- **組織**: ...
- **課題**: ...
### 非ターゲット
- ...
Write({
file_path: "docs/PROBLEM_DEFINITION.md",
content: problemDefinitionContent
})
生成したドキュメントのレビューをサブエージェントに委譲する。
Task({
description: "問題定義レビュー",
subagent_type: "general-purpose",
prompt: `
以下の問題定義書をレビューし、問題があれば修正してください。
## レビュー対象ファイル
- docs/PROBLEM_DEFINITION.md
## レビュー観点
1. **ジョブの明確さ**: 誰が、どんな状況で、何を達成したいかが明確か
2. **ペインの具体性**: 抽象的すぎないか、深刻度・頻度が妥当か
3. **ゲインの妥当性**: 本当にユーザーが求めている価値か
4. **ターゲットの具体性**: ペルソナが具体的で、非ターゲットも明確か
5. **整合性**: ジョブ、ペイン、ゲイン、ターゲットが一貫しているか
## 出力形式
1. 発見した問題のリスト(問題がない場合は「問題なし」)
2. 各問題の修正内容
3. 修正後のファイル更新(Editツールで修正)
問題がなくなるまでレビューと修正を繰り返すこと。
`
})
tools
ローカルのコミット履歴と差分からDraft PRを作成する。ブランチ未作成・コミット未作成の状態でも、必要に応じてブランチ作成とコミットを行ってからPRを作成する。`.github/` にPRテンプレートがあれば内容を埋めて、なければ作業内容から本文を生成し、`AskUserQuestion`で作成可否を確認してから `gh pr create --draft` を実行する。「PRを出したい」「draft PRを作成」「プルリクを作って」「PR本文を生成」などのリクエストで起動。
tools
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
tools
変更内容を分析し、Conventional Commit形式でコミットする (pushはユーザが手動)
development
React 19 + Vite+ (`vp`) + TypeScript + Tailwind CSS v4 + React Router v7 (HashRouter) でモバイル向け静的SPAデモサイトをTDDで構築し、Cloudflare Workers (Static Assets) へ自動デプロイするまでの標準ワークフローを提供する。テンプレートリポジトリ `skanehira/demo-site-template` を `gh repo create --template` で clone することで scaffold を省略する。`localStorage` でフロントエンドのみ完結する"フロントのみ完結デモ"に特化。デザインコンセプトの確立には `frontend-design` スキルを呼び出して連携する。起動トリガー:「デモサイトを作りたい」「モバイル向け静的デモ」「SPAを作ってCloudflareにデプロイ」「静的プロトタイプを公開」「localStorage でフロントだけ完結」。ユースケース:(1)クライアント提案用のUI/UXたたき台、(2)新機能のプロトタイプ、(3)モバイル向けランディング。ツールチェーンは Vite+ (`vp`) で統合(内部 PM は pnpm)。