shrimp-brainstorming

Shrimp Brainstorming

概要

このスキルを使うと、初期段階のプロジェクトやビジネスのアイデアを、画一的なインタビューに無理に当てはめることなく、十分に検討された方向性へと導けます。このプロセスは、調査を重視し、ユーザー主導で進めます。ユーザーはいつでも質問したり、調査結果に異議を唱えたり、制約を追加したり、方向性を変えたりできます。

目的は、確実性を作り出したり、ありきたりなアイデアのリストを生成したりすることではありません。最も有望な突破口を見つけ、弱い前提を明らかにし、役に立つ最小コストのテストを特定することです。また、求められた場合は、結論とそこに至った経緯の両方を説明する、自己完結した final-spec.md を作成します。

使用するタイミング

次のような場合に使用します。

• ユーザーが、漠然とした製品、サービス、スタートアップ、クリエイター事業、ツール、またはビジネスのアイデアを提示した場合。
• そのアイデアについて、市場、競合、価格設定、実現可能性、収益化、流通、または顧客に関する調査を求めている場合。
• アイデアを検証、改善、方向転換、または断念したい場合。
• プロジェクトやビジネスの方向性について、完全に文書化された引き継ぎ資料を求めている場合。

次の場合は使用しないでください。

• プロジェクトやビジネス上の意思決定を伴わない、単純な事実確認。
• 製品と範囲がすでに決まっている、確定済みの実装作業。
• 1つのアイデアを調査する意図がない、ランダムなスタートアップアイデアを多数求める一般的な依頼。

会話モデル

これは、必須の質問フローではなく、ユーザー主導の探究です。

基本の流れ：

User raises an idea or question
→ research and return a useful, opinionated response
→ user reacts, redirects, or asks the next question
→ update the working record after a material change

本当の曖昧さがあり、それによって調査の対象分野、顧客、または課題を誤る可能性がある場合にのみ、確認の質問をしてください。何度も許可を求めて中断するより、前提を明示して有用な作業を進めてください。

一度に1つずつ質問する尋問形式を、標準の進め方にしないでください。ユーザーは、質問したり、調査を依頼したり、前提に異議を唱えたり、目的地を変更したりして、会話を主導できます。

作業モデル

検討を通じて、次の概念を維持してください。

概念	意味
目的地	意思決定、検証計画、引き継ぎ用の仕様書など、この検討で明確にする必要があることです。
現在の仮説	機会と突破口について、現時点で最も妥当な説明です。変更される可能性があります。
意思決定の境界	次に解決する価値のある、明確な問いやテストです。
未解明領域	対象範囲内にあるものの、正確に調査できるほど明らかになっていない不確実性です。
対象外	この取り組みでは、意識的に先送りまたは除外する作業です。
却下した方向性	検討したうえで、理由とともに却下した代替案です。

これらは整理のためのツールであり、課題チケットや強制的なワークフローではありません。

ワークフロー

1. 方向づける

最初のアイデア、目指す目的地、ユーザーがすでに示している重要な制約を把握します。

• 必要に応じて前提を明示します。
• 既知のこと、推測、未知のことを区別します。
• 具体性に見合う根拠が得られる前に、漠然としたアイデアを詳細な仕様に仕立てないでください。

完了条件： 簡潔な現在の仮説と、初期の意思決定の境界が明らかになっていること。

2. 実情を調査する

そのアイデアに取り組む価値があるかどうかを左右する事実を調査します。

アイデアに応じて、次の内容を調べます。

• 直接的な競合、隣接する製品、代替手段、参考になる事例。
• 顧客、購入者の課題、支払意思、既存の支出。
• 市場のタイミング、流通、プラットフォーム上の制約、技術的な実現可能性。
• 価格設定、ビジネスモデル、リスク、信頼できる代替案。

主張には、根拠、推論、または前提のいずれかを明記します。「直接的な競合が見つからない」ことを「良いアイデアである」ことと混同しないでください。

完了条件： 最も重要な主張に出典があるか、未検証であることが明示されていること。

3. 突破口を見つける

広範な目標を、最初の具体的な一歩に落とし込みます。

• 大きな市場カテゴリの主張よりも、具体的な購入者、課題、成果を優先します。
• 差別化されている点、汎用品である点、模倣が難しい点を特定します。
• 弱い前提を率直に指摘します。
• 手の込んだ計画よりも、小規模で迅速、低コストな検証を優先します。

完了条件： 現在の仮説に、誰を対象とするのか、まず何をするのか、その最初の一歩がなぜ実現可能なのかが示されていること。

4. Shrimp Verdictを示す

十分な証拠があれば、率直なVerdictを示します。新たな証拠が出てきた場合は、Verdictを見直せます。

• Shrimp-Yes： 現在のウェッジを進めます。その理由を示し、次のテストを挙げます。
• Shrimp-Maybe： 有望ですが、具体的な未解決の問いや検証ステップに左右されます。
• Shrimp-No： 現在の枠組みでは、追求する価値がありません。その理由を説明し、信頼できるピボット案がある場合に限り提示します。

根拠のない精密さは避けてください。Verdictは意思決定を支援するものであり、保証ではありません。

完了条件： ユーザーが推奨内容、その根拠、そして何があれば判断が変わるのかを理解できること。

5. 継続的に記録を更新する

簡単な応答を超えて検討を続ける場合は、軽量なアイデアフォルダーを維持します。

idea-name/
├── concept-brief.md       # Current source of truth
├── research-ledger.md     # Findings, sources, confidence, implications
├── brainstorm.md          # Optional raw transcript, preserved unchanged
└── final-spec.md          # Complete clarified handoff, created on request

重要な調査、制約、ピボット、判断の後に、コンセプト概要とリサーチ台帳を更新します。

却下した仮説を、何も言わずに消してはいけません。判断が変わった理由とともに Rejected paths に移します。

ユーザーから brainstorm.md としてトランスクリプトが提供された場合は、変更せずに保持します。完全なトランスクリプトがない場合は、捏造せず、要約であることを明記して作成します。

完了条件： チャット全体を読み直さなくても、現在の仮説、判断の分岐点、判断理由を再確認できること。

6. 最終引き継ぎ資料を作成する

ユーザーが最終引き継ぎ資料を求めた場合、または方向性が文書化できるほど固まったことを明確に示した場合に限り、final-spec.md を作成します。

final-spec.md は、最終案をまとめただけのものではありません。検討の経緯を、単独で読める形で記録したものです。会話を見たことがない読者にも、最初のひらめき、何がどう変わったのか、なぜ変わったのか、何を却下したのか、次に何をすべきかが伝わる必要があります。

templates/final-spec.md のテンプレートを使用します。

完了条件： 引き継ぎ資料に、判断の経緯、証拠、残る不確実性、具体的な次のステップまたは実装計画が含まれていること。

よくある落とし穴

1. 支援する代わりに質問攻めにする。 調査を行い、役立つ情報を持ち帰ります。次の有効なステップに進むために本当に必要な質問だけをします。
2. 早まって確信する。 証拠によって解決されるまで、前提を明示しておきます。
3. 競合調査が一般論に終わる。 競合を直接競合、隣接、代替、着想源、無関係に分類し、その分類が意味することを説明します。
4. 早まって範囲を広げる。 狭いウェッジや手動テストで中核となる主張を証明できるなら、プラットフォーム全体を設計してはいけません。
5. 検討の経緯を忘れる。 最終引き継ぎ資料には、洗練された結論だけでなく、そこに至った過程も記載する必要があります。
6. 競合がいないことを妥当性の証明とみなす。 顧客の課題、既存の支出、代替手段、流通、行動を変える意思を確認します。

検証チェックリスト

ブレインストーミングを終えるとき、または最終引き継ぎ資料を提出するときは、以下を確認します。

• 現在の仮説で、ユーザー、課題、妥当な最初のウェッジが特定されている。
• 重要な事実に関する主張に出典があるか、前提として明記されている。
• 関連する場合、直接競合、代替手段、隣接する選択肢を検討している。
• 却下した案と判断理由が記録されている。
• Shrimp Verdictが率直で、次のテストまたは中止する理由を含んでいる。
• 要求された場合、最終仕様書が元の会話を参照せずに理解できる。