PART 02 — スコープ定義
プロジェクト憲章 汎用フレームワーク

なぜスコープ定義が必要か

プロジェクトが失敗する原因として最も多く挙げられるものの一つが「スコープの曖昧さ」だ。スコープとは「今回のプロジェクトで何をするか・しないか」の境界線であり、この境界が不明確なままプロジェクトが進むと、メンバーそれぞれが異なる完成イメージを持ち始める。

ウォーターフォール開発でもアジャイル開発でも、スコープの合意は出発点だ。アジャイルではスプリントごとにスコープを見直すが、「今スプリントで何をするか」の合意は毎回必要になる。スコープ定義のスキルはどのような開発手法でも普遍的に役立つ。

2-1. インスコープ（作るもの）

今回のプロジェクトで必ず作る機能・対応範囲の確定リストを作成する。「何を作るか」の合意なしにプロジェクトは動かない。

インスコープはユーザー視点で書くことがポイントだ。「ログイン機能を実装する」ではなく「登録済みユーザーがメールアドレスとパスワードでログインできる」のように書くと、誰が何をできるかが明確になり、実装者との認識齟齬が減る。

また、インスコープには品質・性能の基準も含める。「ログイン画面を作る」だけでなく、「3秒以内にレスポンスを返す」「パスワードはハッシュ化して保存する」といった非機能要件をスコープに明示しておくと、後からの追加要求を防げる。

2-2. アウトオブスコープ（作らないもの）

今回は対応しない機能・範囲を明示する。インスコープと同じくらい重要な定義で、後から「聞いていない」と言われないための予防策になる。

アウトオブスコープを書く際は「なぜ今回は対応しないか」の理由も添えると説得力が上がる。「コストオーバー」「優先度が低い」「Phase 2 以降に対応予定」など、一言でも理由を書いておくことで、ステークホルダーが「除外された理由がある」と納得しやすくなる。

典型的なアウトオブスコープの例を挙げる。ECサイト構築プロジェクトであれば、「スマートフォンアプリ版（Webのみ対応）」「多言語対応（日本語のみ）」「定期購入機能（単品購入のみ）」などが初期リリースで除外されやすい項目だ。これらを明記することで、「アプリがないのか」「英語には対応しないのか」という問い合わせを事前に防げる。

2-3. 将来候補（Phase N）

今は作らないが将来的に検討する機能のリストを設ける。要求を「NG」ではなく「将来やる」として記録する重要なバッファ。

将来候補リストは「ゴミ箱」ではなく「積み残しの可視化リスト」として機能させることが重要だ。ステークホルダーが持ち込んだ要求を即座に却下するのではなく、「将来候補として記録した」という形にすることで、交渉の場を穏やかに保てる。

将来候補には優先度や実装する想定フェーズも記録しておくとよい。「Phase 2（2027年度上半期）で検討予定」のように時期を添えると、ステークホルダーの期待値管理にもなる。

分類	目的	効果	記載例
インスコープ	今回必ず作るものを合意する	開発・設計の方向統一	「管理者が商品情報を登録・編集・削除できる管理画面」
アウトオブスコープ	今回作らないことを明示する	追加要求を断る根拠になる	「スマートフォンアプリ版（理由：予算・期間不足、Phase 2 で検討）」
将来候補	否定せず記録する	関係者の納得とロードマップ	「多言語対応（Phase 2 候補）」「定期購入機能（Phase 3 候補）」

スコープクリープとその防ぎ方

スコープクリープとは、プロジェクト進行中に合意なしで機能が追加・変更され、スコープが際限なく膨らんでいく現象だ。多くの場合、悪意はなく「ちょっとこれも追加できない？」という善意の要求から始まる。

スコープクリープが危険な理由は、個々の追加が小さくても積み重なると工数・コスト・品質に深刻な影響を与えるからだ。「1時間で終わる小さな修正」が10件重なれば1.5〜2日のロスになり、テストも追加で必要になる。

防ぎ方としては以下の3点が効果的だ。

まず変更管理プロセスを事前に定義することだ。「スコープへの追加は変更管理票を起票し、PM・ステークホルダーが承認した場合のみ受け付ける」という合意を、プロジェクト開始時に全員で共有する。

次にスコープ定義書を「生きたドキュメント」として管理することだ。変更が承認された場合はスコープ定義書を更新し、バージョン管理する。これにより「いつ・何が・なぜ変わったか」の履歴が残る。

最後にスプリントレビューや定期報告でスコープを確認することだ。進捗報告の際に「インスコープに変更がないか」を確認するアジェンダを設けることで、小さな逸脱を早期に発見できる。

実践テンプレート

以下は実際のプロジェクト憲章で使えるスコープ定義のテンプレートだ。Markdownやドキュメントツール（Confluence・Notion等）に貼り付けて使える形にしている。

## スコープ定義

### インスコープ（今回必ず作るもの）
| No | 機能 | 対象ユーザー | 概要 | 備考 |
|----|------|------------|------|------|
| S-01 | ユーザー登録 | 一般ユーザー | メールアドレス＋PW で新規登録できる | メール認証あり |
| S-02 | ログイン/ログアウト | 登録済みユーザー | セッション管理あり | JWT 使用 |
| S-03 | 商品一覧表示 | すべてのユーザー | カテゴリ・価格帯でフィルタリングできる | ページネーションあり |

### アウトオブスコープ（今回作らないもの）
| No | 機能 | 除外理由 |
|----|------|--------|
| X-01 | スマートフォンアプリ | 予算・期間不足。Phase 2 で検討 |
| X-02 | 多言語対応 | 初期ターゲットは国内のみ。Phase 2 で検討 |
| X-03 | サブスクリプション決済 | 単品購入のみ対応。定期購入は Phase 3 以降 |

### 将来候補（Phase N）
| No | 機能 | 想定フェーズ | 優先度 |
|----|------|-----------|------|
| F-01 | スマートフォンアプリ（iOS/Android） | Phase 2 | 高 |
| F-02 | 多言語対応（英語・中国語） | Phase 2 | 中 |
| F-03 | 定期購入機能 | Phase 3 | 中 |

スコープ定義チェックリスト

プロジェクト憲章のスコープ定義が完成したら、以下のチェックリストで品質を確認する。

チェック項目	OK の基準
インスコープが「機能名」だけでなく「誰が何をできるか」で書かれている	主語（ユーザー種別）＋動詞（操作）＋目的語（対象）の形式になっている
アウトオブスコープに除外理由が記載されている	「なぜ今回対応しないか」が一文でも書かれている
将来候補が設けられている	今回は対応しないが要求のあった機能が記録されている
全ステークホルダーがスコープ定義に署名・承認している	口頭合意だけでなく書面（または承認記録）が残っている
変更管理プロセスがスコープ定義書に明記されている	変更申請方法・承認フローが記載されている

スコープ定義でよくある失敗パターン

スコープを定義したつもりでも、書き方の甘さが後になって問題を引き起こす。以下のパターンに注意したい。

失敗パターン	何が起きるか	防止策
インスコープを機能名だけで書く	「ログイン機能」とだけ書かれていると、SNSログイン・多要素認証まで含むと解釈する人が出て、開発中に追加要求が発生する	「〇〇ユーザーがメールアドレス＋PW でログインできる（SNSログインは除く）」のように主語・手段・除外を明記する
アウトオブスコープに除外理由を書かない	「なぜ今回対応しないのか」が不明で、ステークホルダーが「どこかでやってもらえると思っていた」と後から言い出す	「Phase2対応予定」「予算不足のため除外」など理由を一文添える
変更管理プロセスを定義しない	インスコープへの追加要求が口頭で積み上がり、スコープクリープが静かに進行する	スコープ変更の申請方法・承認権限・影響評価のプロセスをプロジェクト開始時に文書化する