boundary-checklisted

## Purpose 「気づいたらスコープが広がっていた」「どこまでが自分の責任か」が曖昧なまま進むリスクを防ぐ。 スコープの内側・外側・境界を明示し、今何に集中すべきかを確定する。 ## Use When - 設計・実装の開始前にスコープを確定したい場合 - 「これもやった方がいいか」という追加要求が出てきた場合 - 複数のシステム・チームにまたがる機能を設計する場合 - assumption-audit の後にスコープの境界を明確にしたい場合 - 施工AIへ渡す前に「やること」「やらないこと」を確定したい場合 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **対象**: スコープを確認する設計・機能・施策 - **目的**: これを実現する本来の目的 - **現時点の想定スコープ**: 何をやると思っているか（箇条書きで） - **フェーズ**: 現在どのフェーズか（優先度・段階） - **関係する他システム**: 隣接するシステム・機能・チーム ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: このスコープで最も曖昧な境界はどこか 2. **根拠**: その論点をそう判断した理由 3. **境界マップ**: やること / やらないこと / 後回し（後述フォーマット） 4. **含意**: 境界の引き方が示す中長期の意味（何を後回しにするコストか） 5. **改善案**: 境界を引き直すことで品質・コストが改善できる観点 6. **代替案**: 別のスコープの切り方（縮小案・拡大案） 7. **判断材料**: 境界の確定に必要な人間の意思決定事項 ### 境界マップ フォーマット ```text ## スコープ境界マップ ### やること（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 へ渡す準備をする ## Guardr