before-you-build

構築する前に

実装の前に、簡潔な事前検証（プレモーテム）を実行してください。目的は構築を妨げることではなく、最もリスクの高い前提、最小の検証ステップ、そして証拠が改善されるまで遅らせるべき構築スコープを特定することです。

使用する場面

ユーザーが以下を構築またはリリースしたいと依頼したときに、このスキルを使用します。

• 新しい製品、MVP、プロトタイプ、ランディングページ、SaaS アプリ、マーケットプレイス、コンテンツサイト、エージェントワークフロー、社内ツール
• 導入、収益、リテンション、信頼、流通への影響が不明確な大規模機能
• 弱いポジショニングが開発やプロモーションの労力を無駄にする可能性がある公開リリース資産

このスキルは、タスクが限定的な実装修正、リファクタリング、テスト修復、依存関係の更新、または明確な受け入れ基準を持つすでに検証済みの変更である場合はスキップしてください。

リスクチェックリスト

以下のリスクについてアイデアを検討してください。

• 需要: 特定の買い手またはユーザーがこれを緊急に求めているという証拠はありますか？
• ポジショニング: 対象ユーザーは、それが何であり、なぜ重要かを一文で理解できますか？
• マネタイズ: 支払い、予算、または戦略的価値への信頼できる道筋はありますか？
• リテンション: ユーザーが最初の試行の後に戻ってくる理由はありますか？
• 信頼: その製品は、ユーザーが抵抗するかもしれない信頼性、データアクセス、統合、または行動変容を必要としますか？
• 流通: 対象ユーザーにリーチする再現可能な方法はありますか？
• 機能の導入: 機能開発の場合、その機能はユーザーの行動を変えるのか、それとも単に接点を増やすだけですか？

判断が明確でない場合は、より深い質問のために references/risk-checklist.md を使用してください。

出力形式

回答は短く、意思決定志向に保ってください。

1. リスク判定: 低、中、または高リスクで、その理由を一文で説明します。
2. 主な前提: プロジェクトを最も壊しそうな単一の前提。
3. 最初に見つけるべき証拠: さらに構築する前の最小の有用なシグナル。
4. 次に行うこと: 1 つの具体的な検証ステップ、または縮小した構築スコープ。
5. 遅らせること: まだ構築すべきでないもの。

ガイダンス

• 弱い証拠については率直に伝えつつ、ユーザーのアイデアを否定することは避けてください。
• 大規模な調査計画よりも、小さな検証ステップを優先してください。
• 製品リスクとエンジニアリングの難しさを切り分けてください。
• アイデアがすでに検証済みであれば、どの証拠がリスクをより低くしているかを述べ、最小の実装スライスを提案してください。
• 事実が不足している場合は、市場に関する主張をでっち上げるのではなく、不足している証拠を指摘してください。