英語でスコープ管理計画書を作るよう言われたとき、スコープ定義とどう違うのか、何を書けばよいか迷った経験はないだろうか。
スコープ管理計画書（Scope Management Plan）は「プロジェクトのスコープをどのように定義・管理・変更するか」のルールを定めた文書だ。スコープ定義・WBS・変更管理・スコープ検証の4つを押さえれば、英語でも問題なく整備できる。
この記事では、英語スコープ管理計画書に必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のプロジェクト立ち上げで活用できる。
スコープ管理計画書に必要な4つの構成要素
スコープ管理計画書はプロジェクトで「何をやるか・何をやらないか」を定義し、途中で追加が発生したときにどう対処するかを事前に決める文書だ。スコープ管理のルールを最初に定めることで、スコープクリープ（気づかないうちにスコープが膨らむ現象）を防げる。以下の4つが実務で使いやすい構成要素になる。
- スコープ定義（Scope Definition）
- WBSと成果物一覧（WBS & Deliverables）
- スコープ変更管理（Scope Change Control）
- スコープ検証・受け入れ（Scope Verification & Acceptance）
スコープ管理計画書とプロジェクト憲章の違い
プロジェクト憲章はプロジェクトの目的・目標・予算・体制など全体像を定める文書だ。スコープ管理計画書はその中の「スコープ」に特化し、何が含まれ・何が含まれないかのルールと変更手順を詳細に定める。
プロジェクト全体のゴールと体制の定義は英語プロジェクト憲章の書き方でも確認してほしい。
なぜ英語で書くのか
グローバルプロジェクトでは、スコープに関する議論が英語で行われることが多い。英語でスコープ管理計画書を整備することで、「それはスコープ内か外か」「追加要件はどう処理するか」を全員が同じルールで判断できる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | （例：〇〇システム移行プロジェクト） |
| 作成者 | （例：田中（PMO）） |
| 作成日 | （例：2026年1月10日） |
| バージョン | （例：v1.0） |
| 承認者 | （例：鈴木（PM）） |
スコープ定義
スコープ内（In Scope）
| No. | 機能・成果物 | 説明 |
|---|---|---|
| 1 | 〇〇機能の開発 | （例：ユーザー管理画面の新規開発） |
| 2 | 〇〇データの移行 | （例：顧客データのDB移行） |
| 3 | 〇〇ドキュメントの整備 | （例：システム設計書・運用手順書） |
| 4 | UAT支援 | （例：ユーザー受け入れテストの準備・実施支援） |
スコープ外（Out of Scope）
| No. | 除外項目 | 理由 |
|---|---|---|
| 1 | 〇〇システムとの連携 | 別プロジェクトで対応 |
| 2 | 既存データの遡及クレンジング | 工数・コストが不明瞭なため別途検討 |
| 3 | エンドユーザー向けトレーニングの実施 | 運用部門が担当 |
WBSと主要成果物
| フェーズ | 主要成果物 | 担当 | 完了基準 |
|---|---|---|---|
| 要件定義 | 要件定義書・機能一覧 | PM + 開発リード | ステークホルダーの書面承認 |
| 設計 | システム設計書・DB設計書 | 開発リード | レビュー完了・承認取得 |
| 開発 | ソースコード・単体テスト結果 | 開発チーム | コードレビュー完了・CIグリーン |
| テスト | テスト計画書・テスト結果報告書 | QAチーム | 全テストケース合格 |
| 移行 | データ移行計画書・移行結果報告書 | インフラ + 開発 | 本番データ確認完了 |
| リリース | リリースノート・運用手順書 | PM + 開発リード | ステークホルダー最終承認 |
WBSの詳細な作業分解は英語WBSの書き方でも確認してほしい。
スコープ変更管理プロセス
| ステップ | 内容 | 担当 | 期限 |
|---|---|---|---|
| 1. 変更要求の提出 | 変更要求書（Change Request）をJiraで起票する | 要求者 | 随時 |
| 2. 影響分析 | PMOが工数・コスト・スケジュールへの影響を分析する | PMO | 提出後3営業日以内 |
| 3. 審査・承認 | 変更管理委員会（CCB）が承認・否認を決定する | CCB（PM・テックリード・ステークホルダー代表） | 分析後5営業日以内 |
| 4. 実施 | 承認された変更をプロジェクト計画・WBSに反映する | PM + 担当者 | 承認後1営業日以内 |
| 5. 記録 | 変更ログを更新し、ステークホルダーに通知する | PMO | 承認後1営業日以内 |
スコープ変更の判断基準
| 分類 | 基準 | 対応 |
|---|---|---|
| 軽微な変更 | 工数±20時間以内・コスト±50万円以内 | PM単独承認でOK |
| 中規模な変更 | 工数±20〜100時間・コスト±50〜200万円 | CCB審査が必要 |
| 大規模な変更 | 工数100時間超・コスト200万円超 | CCB審査 + ステークホルダー承認が必要 |
スコープ検証・受け入れ基準
| フェーズ | 検証方法 | 受け入れ基準 | 承認者 |
|---|---|---|---|
| 要件定義完了 | ウォークスルーレビュー | 要件定義書に全機能が記載されている | PM・ステークホルダー |
| 設計完了 | 設計レビュー | 要件との整合性が確認されている | テックリード |
| テスト完了 | UAT | 全受け入れ基準を満たしている | ステークホルダー |
| リリース完了 | 本番確認 | 全成果物が納品・動作確認済み | PM・ステークホルダー |
英語版テンプレート（コピペOK）
Basic Information
| Item | Details |
|---|---|
| Project Name | (e.g., [System] Migration Project) |
| Prepared By | (e.g., Tanaka, PMO) |
| Date | (e.g., January 10, 2026) |
| Version | (e.g., v1.0) |
| Approved By | (e.g., Suzuki, PM) |
Scope Definition
In Scope
| No. | Feature / Deliverable | Description |
|---|---|---|
| 1 | [Feature] development | (e.g., New development of user management screen) |
| 2 | [Data] migration | (e.g., Customer data DB migration) |
| 3 | Documentation | (e.g., System design document, operation manual) |
| 4 | UAT support | (e.g., Preparation and support for user acceptance testing) |
Out of Scope
| No. | Excluded Item | Reason |
|---|---|---|
| 1 | Integration with [System] | Handled in a separate project |
| 2 | Retroactive data cleansing | Effort and cost are unclear; to be discussed separately |
| 3 | End-user training delivery | Handled by the operations team |
WBS & Key Deliverables
| Phase | Key Deliverables | Owner | Completion Criteria |
|---|---|---|---|
| Requirements | Requirements document, feature list | PM + Dev Lead | Written approval from stakeholders |
| Design | System design doc, DB design doc | Dev Lead | Review complete, approval obtained |
| Development | Source code, unit test results | Dev Team | Code review complete, CI green |
| Testing | Test plan, test results report | QA Team | All test cases passed |
| Migration | Data migration plan, migration results report | Infra + Dev | Production data verified |
| Release | Release notes, operation manual | PM + Dev Lead | Final stakeholder sign-off |
Scope Change Control Process
| Step | Action | Owner | Deadline |
|---|---|---|---|
| 1. Submit | Log a Change Request in Jira | Requestor | As needed |
| 2. Impact Analysis | PMO analyzes impact on effort, cost, and schedule | PMO | Within 3 business days of submission |
| 3. Review & Approval | Change Control Board (CCB) approves or rejects | CCB (PM, Tech Lead, Stakeholder Rep) | Within 5 business days of analysis |
| 4. Implement | Approved changes are reflected in the project plan and WBS | PM + Owner | Within 1 business day of approval |
| 5. Record | Update change log and notify stakeholders | PMO | Within 1 business day of approval |
Scope Change Thresholds
| Category | Criteria | Approval Required |
|---|---|---|
| Minor | Effort ±20 hours or less; cost ±500K JPY or less | PM approval only |
| Moderate | Effort ±20–100 hours; cost ±500K–2M JPY | CCB review required |
| Major | Effort over 100 hours; cost over 2M JPY | CCB review + stakeholder approval required |
Scope Verification & Acceptance Criteria
| Phase | Verification Method | Acceptance Criteria | Approver |
|---|---|---|---|
| Requirements complete | Walkthrough review | All features documented in requirements | PM, Stakeholders |
| Design complete | Design review | Alignment with requirements confirmed | Tech Lead |
| Testing complete | UAT | All acceptance criteria met | Stakeholders |
| Release complete | Production verification | All deliverables delivered and verified | PM, Stakeholders |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
スコープ外（Out of Scope）の書き方
スコープ外の項目は「何をやらないか」を明確に書くことで、後から「あれはやってもらえるはずだった」という認識のズレを防ぐ。理由も一緒に書いておくと、ステークホルダーに説明するときの根拠になる。
| 日本語 | 英語 |
|---|---|
| スコープ外とする | This is out of scope |
| 別プロジェクトで対応する | This will be handled in a separate project |
| 今回の対応範囲に含まない | This is not included in the current scope |
| 次フェーズで検討する | This will be considered in the next phase |
| 別途合意が必要 | This requires separate agreement |
スコープ変更管理の運用ポイント
変更管理で重要なのは「承認なしに勝手にスコープを広げない」ことだ。エンジニアが善意で対応した追加作業がスコープクリープの原因になることが多い。「変更要求書を出す → 承認を得る → 対応する」のフローを全員が守れるよう、プロジェクト開始時にルールを共有することが大切だ。
スコープ管理計画書でよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
スコープ確認フレーズ
| 日本語 | 英語 |
|---|---|
| それはスコープ内ですか？ | Is that within the scope of this project? |
| それはスコープ外です | That is out of scope for this project. |
| スコープ変更として処理します | We will handle that as a scope change. |
| 変更要求書を提出してください | Please submit a Change Request. |
| スコープへの影響を確認します | We need to assess the impact on scope. |
スコープ変更交渉フレーズ
| 日本語 | 英語 |
|---|---|
| この変更は工数〇時間の追加が必要です | This change requires an additional [X] hours of effort. |
| スケジュールに〇週間の影響が出ます | This will impact the schedule by [X] weeks. |
| 優先度を調整することを提案します | We propose adjusting the priority of existing items. |
| この変更はCCBの承認が必要です | This change requires CCB approval. |
| 変更の影響分析が完了しました | The impact analysis for this change is complete. |
スコープと品質を合わせて管理するには英語品質管理計画書の書き方のテンプレートが役立つ。品質基準・レビュープロセス・テスト計画の4セクション構成で、何をもって品質を満たしたと判断するかを全員で合意できる。
スコープ変更の管理と合わせてプロジェクト全体の変更プロセスを整備するには英語変更管理計画書の書き方のテンプレートが役立つ。変更要求書・承認権限マトリクス・変更ログの3点セットで、あらゆる変更を一元管理できる。
まとめ：英語スコープ管理計画書は4つのセクションで完成する
英語スコープ管理計画書に必要な構成要素を整理した。
- スコープ定義はIn ScopeとOut of Scopeの両方を書き、「何をやるか」だけでなく「何をやらないか」を明確にすることでスコープクリープを防ぐ
- WBSと成果物一覧はフェーズごとの完了基準を定義し、「いつ・何が完成したら次に進めるか」を全員が判断できる状態にする
- スコープ変更管理は変更の大きさに応じた承認レベルを設定し、軽微な変更はPM一人で・大規模な変更はCCBでと決めることで意思決定を速くする
- スコープ検証・受け入れ基準はフェーズごとに「誰が・何をもって承認するか」を明記し、完了の定義を曖昧にしない
テンプレートをコピーして、まず「Out of Scope」から埋め始めてほしい。「やらないこと」を最初に合意することで、「やること」の議論がシンプルになる。
コメント