scope-designlisted

## Purpose 「あれもこれも」で焦点を失う戦略を防ぐ。 集中する領域と意図的に捨てる領域を明示し、限られた資源を一点に集める判断を支える。 ## Use When - 事業・プロダクトの戦略的な的を絞るとき - 市場・顧客セグメントの選択をするとき - 「手を広げすぎでは」という懸念が出たとき - boundary-check の戦略版として、事業レベルの境界を引きたいとき ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **対象**: スコープを設計する事業・プロダクト・施策 - **狙う成果**: 集中によって得たい成果 - **候補領域**: 検討している市場・顧客・課題 - **資源制約**: 投下できる人員・時間・資金 ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: 集中すべき軸は何か（誰の・どの課題に絞るか） 2. **根拠**: その絞り込みを支持する理由 3. **スコープ境界**: 集中する領域 / 捨てる領域 / 保留する領域 4. **含意**: この絞り込みが生む強み・放棄するもの 5. **改善案**: 焦点をさらに研ぐ余地 6. **代替案**: 別の絞り方（別セグメント・別課題） 7. **判断材料**: スコープ確定のために人間が確認すべき情報 ## Review Lens - **目的妥当性**: 絞り込みが狙う成果に効くか - **範囲の過不足**: 絞りすぎ（機会損失）／広すぎ（焦点喪失）でないか - **中長期リスク**: 捨てた領域が将来の致命傷にならないか - **LAB全体との整合性**: LMS / 自動化 / B2B 展開と整合しているか - **非エンジニア理解可能性**: 戦略の的を関係者に説明できるか - **他LLM移植耐性**: Claude 固有の解釈に依存していないか ## Instructions 1. 候補領域を「集中 / 捨てる / 保留」に分類する 2. 集中領域を選ぶ理由（勝てる根拠・資源適合）を書く 3. 「捨てる」領域は、なぜ今捨てるかの理由を添える 4. 保留領域は、着手の条件（何が起きたら戻すか）を明示する 5. 絞り込みが生む強み（一点突破の効果）を言語化する 6. 不明な前提は推測せず、仮定を明示する ## Guardrails - 「全部やる」を許容しない（捨てる判断を必ず迫る） - 捨てる領域を曖昧にしない（記録に残す） - 絞り込みの機会コストを省略しない - 最終的なスコープ確定は人間に委ねる ## LAB Cross-Check | 観点 | 状態 | 備考 | |---|---|---| | 自動化フロー | — | スコープが自動化方針と整合するか | | データ / 認証 / ログ | — | 対象顧客のデータ要件を確認したか | | 実装 / 運用フロー | — | 集中領域の実装・運用が現実的か | | 非エンジニア理解可能性 | — | 戦略の的を関係者に説明できるか | | 会員共有 / 再利用耐性 | — | スコープ設計が他事業にも転用できるか | | 他LLM移植耐性 | — | 判断が Claude 固有に依存していないか | 状態は OK / 注意 / NG / 対象外 で記入すること。 ## Handoff Notes 施工AI（Claude Code / Cursor 等）へ渡す前に