Boundary check

Purpose

「気づいたらスコープが広がっていた」「どこまでが自分の責任か」が曖昧なまま進むリスクを防ぐ。 スコープの内側・外側・境界を明示し、今何に集中すべきかを確定する。

Use When

• 設計・実装の開始前にスコープを確定したい場合
• 「これもやった方がいいか」という追加要求が出てきた場合
• 複数のシステム・チームにまたがる機能を設計する場合
• assumption-audit の後にスコープの境界を明確にしたい場合
• 施工AIへ渡す前に「やること」「やらないこと」を確定したい場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象: スコープを確認する設計・機能・施策
• 目的: これを実現する本来の目的
• 現時点の想定スコープ: 何をやると思っているか（箇条書きで）
• フェーズ: 現在どのフェーズか（優先度・段階）
• 関係する他システム: 隣接するシステム・機能・チーム

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: このスコープで最も曖昧な境界はどこか
2. 根拠: その論点をそう判断した理由
3. 境界マップ: やること / やらないこと / 後回し（後述フォーマット）
4. 含意: 境界の引き方が示す中長期の意味（何を後回しにするコストか）
5. 改善案: 境界を引き直すことで品質・コストが改善できる観点
6. 代替案: 別のスコープの切り方（縮小案・拡大案）
7. 判断材料: 境界の確定に必要な人間の意思決定事項

境界マップ フォーマット

## スコープ境界マップ

### やること（In Scope）
- （具体的な機能・処理・責任）

### やらないこと（Out of Scope）
- （明示的に除外するもの・理由）

### 後回し（Deferred）
- （将来フェーズで対応するもの・条件）

### 境界が曖昧な箇所（要確認）
- （どちらに入るか確定できていない項目）

Review Lens

• 目的妥当性: 引いた境界が本来の目的と整合しているか
• 範囲の過不足: 必要なものを削りすぎていないか。不要なものを含んでいないか
• 中長期リスク: 「後回し」にしたものが後で大きなコストにならないか
• LAB全体との整合性: LMS / 自動化 / B2B 展開のフェーズ分けと矛盾しないか
• 非エンジニア理解可能性: 境界マップが非技術者にも説明できる形か
• 他LLM移植耐性: 境界の判断基準が Claude 固有の解釈に依存していないか

Instructions

1. 現時点の想定スコープを読み、各項目を「In / Out / Deferred / 要確認」に分類する
2. 分類の根拠を各項目に1行添える
3. 「要確認」は推測で解決しない。人間が決めるべき境界として明示する
4. 「やらないこと」は「なぜやらないか」の理由を必ず添える
5. 「後回し」は「どの条件が満たされたら着手するか」を明示する
6. スコープクリープの兆候（「これもついでに」という追加）を指摘する
7. 境界確定後は 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-design skill（lab-strategy-design）— 戦略的なスコープ設計
• implementation-gate skill（lab-implementation-flow）— 実装前の最終スコープ確認
• docs/DECISIONS.md — フェーズ分けの過去決定