idea-refinement

name	idea-refinement
description	漠然とした初期段階のアイデアを「発散→収束」の 2 サイクルで洗練するスキル。Double Diamond 思考フレームに沿って、対象ユーザ・成功条件の明確化、複数案の発散、批判的評価、HMW（How Might We）形式の問題定義への収束までを対話形式で進める。トリガー条件: ユーザが「アイデアを洗練したい」「ブレストしたい」「How Might We を作りたい」「アイデアを練りたい」「企画を考えたい」「サービスのアイデアを発散したい」と依頼したとき。

Idea Refinement

漠然としたアイデアを「発散→収束」の 2 サイクルで HMW 形式の問題定義と推奨方向性へ収束させる。Double Diamond 思考フレームに準拠する。

基本原則

• 発散と収束を分離する: 発散フェーズで批判しない。収束フェーズで肯定だけしない。
• 発散は質より量: 月並みなアイデア（既存解決策の小改善、「○○の AI 化」「○○のサブスク化」だけで終わるもの）は出した上で捨てる。バリエーションの広がりが価値。
• 収束は批判的に: 各方向性に弱点を必ず 2 つ以上明示する。「素晴らしい」「完璧」「画期的」のような無批判表現を使わない。
• フェーズ境界でユーザに確認: Phase 1〜4 の各末で進行可否をユーザに確認する。共感アイデアが 0 件なら Phase 1 に戻る。

適用前提

このスキルは 実装を AI agent（Claude Code 等）にフル委任する ことを前提に、工数・実現可能性・リスクを評価する。人間個人やチーム開発を前提にする場合は工数表が変わるため、本スキルの判断軸はそのまま適用できない。

環境別のユーザ質問ツール

環境	質問ツール
Claude Code	AskUserQuestionTool
Codex	request_user_input

質問は Phase 1 で 1 回（4 観点まとめて）、Phase 3.1 で 1 回（共感アイデアの選択）、各 Phase 末で 1 回（進行確認）を基本とする。

ワークフロー

Phase 1: アイデアの理解（収束的質問）

ユーザの初期アイデアに対して、以下 4 観点を 1 回でまとめて質問する。

1. 対象ユーザ: 誰のためのアイデアか（属性・状況・規模）
2. 成功条件: 何が達成できれば成功か（定量・定性）
3. 機能要件: 必須でやらせたいこと
4. 非機能要件・制約: 予算、期間、技術、法規制、リソースなど

回答が曖昧な場合は次のフェーズに進まず、追加質問で確定させる。確定後、ユーザに「この理解で合っているか」を確認してから Phase 2 へ。

Phase 2: アイデアの発散（10 案、最大 20 案）

references/divergent-techniques.md を読み、6 つの観点（①対象ユーザ変更／②制約無視・スケール／③10 倍簡素／④逆転の発想／⑤既存組み合わせ／⑥異業種転用）を発想のヒントにしながらアイデアを生成する。

• 提示する案数は 10〜20。中央値は 12〜15 案。
• 月並みアイデア（既存解決策の小改善、「○○の AI 化」だけ等）は捨てる。捨てた案は提示時に 1 行触れてよいが、提示案数（10〜20）にはカウントしない（残した案のみカウント）。
• 6 観点はあくまで発想のヒント。何軸使う・何軸にまたがるといった制約は設けない。ただしアイデアが同じ方向ばかりに偏らないよう、観点を見渡してから発想する。
• 提示は番号付き箇条書き。各案 1〜2 文。

提示後、Phase 3.1 へ進む。

Phase 3: アイデアの評価

3.1 共感アイデアの聴取

ユーザに「共感したアイデア（複数可）」を質問する。共感が 0 件のとき、または「どれもピンと来ない」と回答されたときは Phase 1 に戻る。戻り先は 対象ユーザと成功条件の 2 観点に絞って再質問 する（機能要件・非機能要件は前回確定済みのため再確認しない）。再質問後、Phase 2 をやり直す。

3.2 3 方向へのクラスタリング

共感アイデアを 3 つの方向性（テーマ）にクラスタリングする。クラスタリング軸は 1 つだけ選ぶ（複数軸の混在は禁止。3 方向の違いがブレる）。次の選択肢から、共感アイデアの性質に最も合うものを 1 つ採用する。

• アプローチの違い（テクノロジ寄り／コミュニティ寄り／コンテンツ寄り など）
• 価値の出し方（時間短縮／質向上／新しい体験 など）
• 対象セグメント（初心者向け／中級者向け／上級者向け など）

各方向性に「方向性の名前（5〜10 字）」「核心（1〜2 文）」「含まれる元アイデア番号」を付ける。

3.3 批判的評価

references/evaluation-criteria.md を読み、3 視点（実現可能性／ユーザ価値／リスク・トレードオフ）で各方向性を評価する。

• 各方向性に弱点・リスクを 2 つ以上 明示する。
• 過度な肯定表現（「素晴らしい」「完璧」「画期的」）は禁止。
• 評価は表形式が望ましい。

評価後、推奨する方向性を 1 つ選び理由を述べる。ユーザに「この方向性で Phase 4 へ進んでよいか」を確認する。

3.4 セカンドオピニオン取得（任意）

推奨方向性が固まったら、Phase 4 へ進む前にユーザに 「codex-advisor で Codex のセカンドオピニオンを取るか」 を 1 度確認する。

• 取る: Codex に方向性の妥当性・実装リスク・代替案を辛口でレビューさせる。レビュー内容を Phase 3.3 の評価へ反映してから Phase 4 へ進む。
• 取らない: そのまま Phase 4 へ。

特に技術選定や実装難易度に不確実性が残る方向性のときは取得を推奨する（取らずに進むと Phase 4 の「検証すべき内容」「不明点」が手薄になりやすい）。

Phase 4: マークダウン 1 枚への収束

references/output-template.md を読み、以下 5 節を全て含むマークダウンを 1 枚生成する。

1. 問題定義（HMW）: 「私たちはどうすれば <ターゲット> が <達成したいこと> を <制約> の中でできるようにできるだろうか？」形式。
2. 推奨方向性: 名前／核心／なぜ推すか（評価根拠）。
3. 検証すべき内容: 不確実性が高く、判断を左右する仮説。
4. 検証しない内容: スコープ外と判断したもの。理由を 1 行添える。
5. 不明点: 現時点で未解決の論点。空欄禁止（最低 1 件）。

生成後、ユーザに最終確認を取る。修正要望があれば Phase 4 内で再生成する。

運用ルール

• 発散数は 10〜20 の範囲を守る。9 案以下は不足、21 案以上はノイズ。
• 各 Phase 末でユーザに進行確認を取る（特に Phase 1 の理解確定、Phase 3.3 の方向性選定、Phase 4 の最終確認）。
• 共感アイデアが 0 件のとき、無理に進めず Phase 1 に戻る。
• HMW は必ず「私たちはどうすれば〜できるだろうか？」形式で書く。解決策を混ぜない、抽象すぎない、制約を欠かさない。
• 不明点欄は必ず最低 1 件埋める。「なし」と書かない。
• 無批判表現（「素晴らしい」「完璧」「画期的」「最高」「革新的」）を出力に含めない。
• AI agent 委任前提で工数評価する。人間個人やチーム開発を前提にする場合は本スキルの工数感をそのまま適用しない。

参照ファイル

• references/divergent-techniques.md — Phase 2 で読む。発散の 6 観点とアンチパターン。
• references/evaluation-criteria.md — Phase 3.3 で読む。3 視点の評価表と批判的評価のガード。
• references/output-template.md — Phase 4 で読む。最終マークダウンの記入指針と完成例。