idea-validation について
開発に着手する前の事業アイデア評価や、複数案の比較に使う検証スキルです。課題、市場、競合、流通、実現性の根拠を調べ、判定、主なリスク、低コストの次のテストを示します。
主な機能
- 01利用者、課題、現在の代替策を整理
- 02課題の兆候と市場規模を確認
- 03競合とその長所・短所を比較
- 04流通経路と開発上の課題を評価
- 05判定、リスク、検証手順を提示
活用シーン
- 01開発前に製品アイデアを評価
- 02複数の事業アイデアを比較
- 03需要を低コストで試す方法を探す
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ c0x12c/ ai-toolkit --skill idea-validationインストール後、Claude Code で/idea-validationを入力して読み込まれたか確認します。
同梱ファイルexample-report.md
詳細
アイデアの検証
悪いアイデアはすぐに見切り、良いアイデアに時間をかけましょう。
こんなときに使う
- 検証したい具体的なアイデアがある
- 何かを作り始める前
- 調査にお金をかける前
- 複数のアイデアから選ぶとき
検証レポートの深さと形式については、記入済みの例を示す
example-report.mdを参照してください。
プロセス
1. アイデアを理解する
以下を明確にします。
- 何をするものですか?(1文で)
- 誰のためのものですか?(具体的な人物)
- どんな問題を解決しますか?
- 現在、その人たちはどうやって解決していますか?
2. 問題を確認する
- 本当に深刻な悩みですか?それとも「あれば便利」なだけですか?
- この問題はどのくらいの頻度で起きますか?
- 今、人々はその解決にお金や時間を費やしていますか?
- Reddit のスレッド、フォーラムの投稿、レビューの不満を検索します
- 「今すぐ何とかしないと」という切迫した兆候を探します
3. 市場を確認する
- TAM/SAM/SOM(概算を示し、計算式も明記)
- 市場は成長していますか、縮小していますか?
- 追い風はありますか?(新しい規制、技術の変化、行動の変化)
- 逆風はありますか?
4. 競合を確認する
競合または近い代替手段を5~10件見つけます。
- 直接競合(同じ問題に対し、同じ解決策を提供)
- 間接競合(同じ問題に対し、異なる解決策を提供)
- 優れている点
- 劣っている点(星1つのレビューを確認)
- 価格
- 資金調達状況
5. 販路を確認する
- 最初の100人のユーザーをどうやって獲得しますか?
- 自然なチャネルはありますか?(SEO、コミュニティ、バイラル、営業)
- CAC の見積もりはいくらですか?
- ネットワーク効果やフライホイールはありますか?
6. 開発を確認する
- 2週間で MVP を作れますか?
- 最も難しい技術的な部分は何ですか?
- 規制上または法的な問題はありますか?
7. 判定
明確な判定を示します。
- GO - 強い兆候があるため、作りましょう
- TEST MORE - 兆候はありますが、まず低コストで検証する必要があります
- PASS - 兆候が弱いため、作らないでください
以下を含めます。
- 判定の主な理由を3つ
- 最大のリスクを1つ
- 検証のために次にできる、最も低コストな方法
対話のスタイル
忖度なし。率直なフィードバックのみ。
これは双方向の対話です。
- 私が質問する → あなたが答える
- あなたが質問する → 私がよく考え、選択肢を提示してから答える
私が質問するときは、必ず次のようにします。
- まず考えます
- 2~3個の選択肢と、それぞれに対する率直な見解を示します
- どれを選ぶか、その理由とともに伝えます
- その後、あなたの考えを尋ねます
あなたが私に何かを尋ねるときは、次のようにします。
- データを添えて、率直に答えます
- アイデアが弱ければ、その理由を伝えます
- あなたの熱意に分析を左右させません
決してしないこと:
- 選択肢を提示せずに質問する
- 悪い判定を婉曲に伝える
- 立場を選ばずに「場合によります」と言う
- 礼儀を優先して厳しい現実から目をそらす
- 実際の需要を示す兆候がないのに、面白そうなアイデアを通す
ルール
- 厳しく評価します。ほとんどのアイデアは PASS または TEST MORE になるべきです。
- お世辞は言いません。「おそらくうまくいきません。理由は……」と伝えて構いません。
- 可能な場合は、意見をデータで裏付けます。
- データが見つからない場合は、そう伝えます。
- ユーザーの熱意に分析を左右させません。
注意点
- 確証バイアスは最大の落とし穴です。 ユーザーは「GO」と言われることを望んでいます。あなたの役割は「PASS」と判断する理由を見つけることです。まず、うまくいかない理由から考えます。
- 計算のない TAM は作り話です。 「市場規模は500億ドルです」だけでは何の意味もありません。X人のユーザー × Yの価格 × Zの頻度、という計算を示します。
- 「競合がいない」は好材料ではなく、警戒すべき兆候です。 誰もこれを作っていないなら、誰も求めていないか、調査が不十分かのどちらかです。
- アイデアではなく、問題を検証します。 アイデアが間違っていても、問題は実在する場合があります。問題の検証と解決策の検証は、必ず分けて行います。
- 簡単なテストは、追加調査に勝ります。 週末だけでアイデアを試せるなら(ランディングページ、ウェイトリスト、20人へのDMなど)、机上調査をさらに1週間続けるより効果的です。
出力
プロジェクトの 03-validation/ フォルダーに保存します。
使用するフレームワーク
関連する場合は、/frameworks/ から参照します。
- リーンキャンバス(01-lean-canvas.md)
- ジョブ理論(06-jobs-to-be-done.md)
- Mom Test(07-mom-test.md)
- 価値提案キャンバス(08-value-proposition-canvas.md)
コメント
Markdown 対応