Purpose
「気づいたらスコープが広がっていた」「どこまでが自分の責任か」が曖昧なまま進むリスクを防ぐ。 スコープの内側・外側・境界を明示し、今何に集中すべきかを確定する。
Use When
- 設計・実装の開始前にスコープを確定したい場合
- 「これもやった方がいいか」という追加要求が出てきた場合
- 複数のシステム・チームにまたがる機能を設計する場合
- assumption-audit の後にスコープの境界を明確にしたい場合
- 施工AIへ渡す前に「やること」「やらないこと」を確定したい場合
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 対象: スコープを確認する設計・機能・施策
- 目的: これを実現する本来の目的
- 現時点の想定スコープ: 何をやると思っているか(箇条書きで)
- フェーズ: 現在どのフェーズか(優先度・段階)
- 関係する他システム: 隣接するシステム・機能・チーム
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: このスコープで最も曖昧な境界はどこか
- 根拠: その論点をそう判断した理由
- 境界マップ: やること / やらないこと / 後回し(後述フォーマット)
- 含意: 境界の引き方が示す中長期の意味(何を後回しにするコストか)
- 改善案: 境界を引き直すことで品質・コストが改善できる観点
- 代替案: 別のスコープの切り方(縮小案・拡大案)
- 判断材料: 境界の確定に必要な人間の意思決定事項
境界マップ フォーマット
## スコープ境界マップ
### やること(In Scope)
- (具体的な機能・処理・責任)
### やらないこと(Out of Scope)
- (明示的に除外するもの・理由)
### 後回し(Deferred)
- (将来フェーズで対応するもの・条件)
### 境界が曖昧な箇所(要確認)
- (どちらに入るか確定できていない項目)
Review Lens
- 目的妥当性: 引いた境界が本来の目的と整合しているか
- 範囲の過不足: 必要なものを削りすぎていないか。不要なものを含んでいないか
- 中長期リスク: 「後回し」にしたものが後で大きなコストにならないか
- LAB全体との整合性: LMS / 自動化 / B2B 展開のフェーズ分けと矛盾しないか
- 非エンジニア理解可能性: 境界マップが非技術者にも説明できる形か
- 他LLM移植耐性: 境界の判断基準が Claude 固有の解釈に依存していないか
Instructions
- 現時点の想定スコープを読み、各項目を「In / Out / Deferred / 要確認」に分類する
- 分類の根拠を各項目に1行添える
- 「要確認」は推測で解決しない。人間が決めるべき境界として明示する
- 「やらないこと」は「なぜやらないか」の理由を必ず添える
- 「後回し」は「どの条件が満たされたら着手するか」を明示する
- スコープクリープの兆候(「これもついでに」という追加)を指摘する
- 境界確定後は Handoff Notes を使って施工AI へ渡す準備をする
Guardrails
- スコープを自分で決定しない。「要確認」は人間が判断する
- 「ついでにやっておく」を提案しない(スコープクリープの原因)
- 「後回し」にするものは消えるのではなく記録に残す(Deferred として明示)
- コスト(追加スコープの工数)を省略しない
- 施工AIへの handoff 前にスコープが曖昧な状態で進めない
LAB Cross-Check
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化スコープの境界が明確か |
| データ / 認証 / ログ | — | DB・Auth・ログのスコープが確定しているか |
| 実装 / 運用フロー | — | 実装範囲と運用責任の境界が明確か |
| 非エンジニア理解可能性 | — | 境界マップが非技術者に説明できる形か |
| 会員共有 / 再利用耐性 | — | この境界設計が他ケースにも転用できるか |
| 他LLM移植耐性 | — | 境界判断が Claude 固有の解釈に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
- 要件: 確定した In Scope の一覧
- 成功条件: スコープ内の全項目が完了した状態の定義
- 失敗条件: スコープ外の作業が発生した場合の検知方法
- 実行範囲: 触ってよいファイル・機能・DB(スコープ内のみ)
- 影響範囲: スコープ内の変更が波及するシステム・機能
- ロールバック方針: スコープ内の変更が失敗した場合の戻し方
- コスト比較: 現在のスコープ vs 縮小案 / 拡大案のコスト差
Further Reading
issue-framing— スコープ確認前の論点整理assumption-audit— スコープの前提を洗い出すscope-designskill(lab-strategy-design)— 戦略的なスコープ設計implementation-gateskill(lab-implementation-flow)— 実装前の最終スコープ確認- docs/DECISIONS.md — フェーズ分けの過去決定