英語で変更管理計画書を作るよう言われたとき、スコープ管理計画書との違いが分からず、何を書けばよいか迷った経験はないだろうか。
変更管理計画書（Change Management Plan）は「プロジェクト中に発生する変更要求をどのように評価・承認・実施・記録するか」のプロセスを定めた文書だ。変更要求管理・影響分析・承認プロセス・変更ログ管理の4つを押さえれば、英語でも問題なく整備できる。
この記事では、英語変更管理計画書に必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のプロジェクト立ち上げで活用できる。
変更管理計画書に必要な4つの構成要素
変更管理計画書は「変更要求が来たときにどう動くか」のルールブックだ。ルールがないと、小さな要求が次々に積み重なってスコープ・スケジュール・コストが崩れる（スコープクリープ）。以下の4つが実務で使いやすい構成要素になる。
- 変更要求管理（Change Request Management）
- 影響分析プロセス（Impact Assessment Process）
- 変更承認プロセス（Change Approval Process）
- 変更ログ管理（Change Log Management）
変更管理計画書とスコープ管理計画書の違い
スコープ管理計画書はプロジェクトの「何をやるか・やらないか」を定義し、スコープ変更のルールも含む文書だ。変更管理計画書はスコープだけでなく、スケジュール・コスト・品質・リソースなどプロジェクト全体に関わるあらゆる変更のプロセスを管理する。
スコープの定義と変更のルールの基礎は英語スコープ管理計画書の書き方でも確認してほしい。変更管理計画書と合わせて整備することで、スコープ・スケジュール・コストの変更を一元管理できる。
なぜ英語で書くのか
グローバルプロジェクトでは、変更要求の申請・承認が英語で行われることが多い。変更管理計画書を英語で整備することで、海外のプロジェクトマネジャーやステークホルダーも同じプロセスで変更要求を処理できる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | （例：〇〇システム開発プロジェクト） |
| 作成者 | （例：田中（PM）） |
| 作成日 | （例：2026年1月10日） |
| バージョン | （例：v1.0） |
| 承認者 | （例：鈴木（PMO）） |
変更要求管理
変更要求の提出方法
| 項目 | 内容 |
|---|---|
| 提出方法 | Jiraで変更要求チケットを起票する |
| 提出者 | プロジェクト関係者（誰でも提出可能） |
| 提出タイミング | 随時（変更が必要と判断した時点） |
| 必須記載項目 | 変更内容・変更理由・希望実施日・優先度 |
| 窓口 | PMO（田中） |
変更要求書（Change Request）の記載項目
| 項目 | 内容 |
|---|---|
| 変更要求ID | （例：CR-001） |
| タイトル | （例：ログイン画面のUI変更） |
| 申請者 | （例：営業部・佐藤） |
| 申請日 | （例：2026年1月10日） |
| 変更の種別 | スコープ変更 / スケジュール変更 / コスト変更 / 品質変更 |
| 変更内容 | （例：ログイン画面にSSOボタンを追加する） |
| 変更理由 | （例：顧客企業のセキュリティポリシー対応のため） |
| 希望実施日 | （例：2026年2月末までに対応してほしい） |
| 優先度 | 高 / 中 / 低 |
影響分析プロセス
変更要求が提出されたら、PMOが以下の観点で影響分析を行う。
| 分析観点 | 内容 | 担当 |
|---|---|---|
| スコープへの影響 | 変更により何が増減するか | PM + 開発リード |
| スケジュールへの影響 | 何日・何週間の遅延が生じるか | PM |
| コストへの影響 | 追加工数・コストはいくらか | PM + PMO |
| 品質への影響 | 他機能・システムへの影響はあるか | 開発リード + QAリード |
| リスク | 変更を実施しないリスクはあるか | PM |
影響分析の所要期間
| 変更規模 | 分析期間目安 |
|---|---|
| 軽微（工数±20時間以内） | 1〜2営業日 |
| 中規模（工数±20〜100時間） | 3〜5営業日 |
| 大規模（工数100時間超） | 1〜2週間 |
変更承認プロセス
| ステップ | 内容 | 担当 | 期限 |
|---|---|---|---|
| 1. 提出 | 変更要求書をJiraで起票する | 申請者 | 随時 |
| 2. 受付確認 | PMOが受領を確認し、変更ログに記録する | PMO | 提出後1営業日以内 |
| 3. 影響分析 | 工数・コスト・スケジュールへの影響を分析する | PMO + 関係者 | 変更規模に応じた期間 |
| 4. 審査・承認 | 変更管理委員会（CCB）が承認・条件付き承認・否認を決定する | CCB | 分析完了後3営業日以内 |
| 5. 実施 | 承認された変更をプロジェクト計画に反映する | PM + 担当者 | 承認後1営業日以内 |
| 6. 記録 | 変更ログを更新し、ステークホルダーに通知する | PMO | 実施完了後1営業日以内 |
承認権限マトリクス
| 変更規模 | 基準 | 承認者 |
|---|---|---|
| 軽微 | 工数±20時間以内・コスト±50万円以内 | PM単独承認 |
| 中規模 | 工数±20〜100時間・コスト±50〜200万円 | CCB（PM・テックリード・ステークホルダー代表） |
| 大規模 | 工数100時間超・コスト200万円超 | CCB + スポンサー（経営層）承認 |
| 緊急変更 | 本番障害への対応など緊急を要する変更 | PM単独承認（事後にCCBへ報告） |
変更ログ管理
変更ログはすべての変更要求の状態を追跡するための台帳だ。Jiraまたは以下の表形式で管理する。
| 変更要求ID | タイトル | 申請者 | 申請日 | 種別 | 優先度 | ステータス | 承認者 | 承認日 | 実施完了日 |
|---|---|---|---|---|---|---|---|---|---|
| CR-001 | ログイン画面にSSOボタン追加 | 佐藤 | 2026/01/10 | スコープ | 高 | 承認済 | CCB | 2026/01/15 | 2026/01/31 |
| CR-002 | レポート出力フォーマット変更 | 鈴木 | 2026/01/20 | スコープ | 中 | 審査中 | — | — | — |
| CR-003 | リリース日を1週間延期 | 田中 | 2026/02/01 | スケジュール | 高 | 否認 | PM | 2026/02/03 | — |
ステータス定義
| ステータス | 意味 |
|---|---|
| 提出済（Submitted） | 変更要求が提出され、PMOが受領した |
| 分析中（Under Analysis） | PMOが影響分析を実施している |
| 審査中（Under Review） | CCBが審査を進めている |
| 承認済（Approved） | CCBまたはPMが承認した |
| 条件付き承認（Conditionally Approved） | 特定の条件を満たすことを前提に承認した |
| 否認（Rejected） | CCBまたはPMが否認した |
| 実施済（Implemented） | 変更が完了した |
英語版テンプレート（コピペOK）
Basic Information
| Item | Details |
|---|---|
| Project Name | (e.g., [System] Development Project) |
| Prepared By | (e.g., Tanaka, PM) |
| Date | (e.g., January 10, 2026) |
| Version | (e.g., v1.0) |
| Approved By | (e.g., Suzuki, PMO) |
Change Request Management
How to Submit a Change Request
| Item | Details |
|---|---|
| Submission method | Log a Change Request ticket in Jira |
| Who can submit | Any project stakeholder |
| When to submit | At any time when a change is identified as needed |
| Required fields | Change description, reason, requested date, priority |
| Point of contact | PMO (Tanaka) |
Change Request Form Fields
| Field | Details |
|---|---|
| Change Request ID | (e.g., CR-001) |
| Title | (e.g., Add SSO button to login screen) |
| Requested By | (e.g., Sales Dept., Sato) |
| Date Submitted | (e.g., January 10, 2026) |
| Change Type | Scope / Schedule / Cost / Quality |
| Description | (e.g., Add an SSO login button to the login screen) |
| Reason | (e.g., Required to comply with client’s security policy) |
| Requested Date | (e.g., Please implement by end of February 2026) |
| Priority | High / Medium / Low |
Impact Assessment Process
When a Change Request is submitted, the PMO assesses the impact from the following angles:
| Assessment Area | Content | Owner |
|---|---|---|
| Scope impact | What will be added or removed | PM + Dev Lead |
| Schedule impact | How many days or weeks of delay | PM |
| Cost impact | Additional effort and cost | PM + PMO |
| Quality impact | Effect on other features or systems | Dev Lead + QA Lead |
| Risk | What is the risk of NOT implementing this change | PM |
Impact Assessment Lead Times
| Change Size | Assessment Time |
|---|---|
| Minor (effort ±20 hours or less) | 1–2 business days |
| Moderate (effort ±20–100 hours) | 3–5 business days |
| Major (effort over 100 hours) | 1–2 weeks |
Change Approval Process
| Step | Action | Owner | Deadline |
|---|---|---|---|
| 1. Submit | Log a Change Request in Jira | Requestor | As needed |
| 2. Acknowledge | PMO confirms receipt and logs in change log | PMO | Within 1 business day of submission |
| 3. Impact Analysis | Assess impact on effort, cost, and schedule | PMO + stakeholders | Based on change size |
| 4. Review & Decision | CCB approves, conditionally approves, or rejects | CCB | Within 3 business days of analysis |
| 5. Implement | Reflect approved changes in project plan | PM + Owner | Within 1 business day of approval |
| 6. Record | Update change log and notify stakeholders | PMO | Within 1 business day of implementation |
Approval Authority Matrix
| Change Size | Criteria | Approver |
|---|---|---|
| Minor | Effort ±20 hours or less; cost ±500K JPY or less | PM only |
| Moderate | Effort ±20–100 hours; cost ±500K–2M JPY | CCB (PM, Tech Lead, Stakeholder Rep) |
| Major | Effort over 100 hours; cost over 2M JPY | CCB + Sponsor (executive) approval |
| Emergency | Urgent changes such as production incident response | PM only (report to CCB after the fact) |
Change Log
The Change Log tracks the status of all change requests. Managed in Jira or in the format below:
| CR ID | Title | Requestor | Submitted | Type | Priority | Status | Approved By | Approved | Completed |
|---|---|---|---|---|---|---|---|---|---|
| CR-001 | Add SSO button to login screen | Sato | 2026/01/10 | Scope | High | Approved | CCB | 2026/01/15 | 2026/01/31 |
| CR-002 | Change report output format | Suzuki | 2026/01/20 | Scope | Medium | Under Review | — | — | — |
| CR-003 | Delay release date by 1 week | Tanaka | 2026/02/01 | Schedule | High | Rejected | PM | 2026/02/03 | — |
Status Definitions
| Status | Meaning |
|---|---|
| Submitted | Change Request submitted and acknowledged by PMO |
| Under Analysis | PMO is conducting impact analysis |
| Under Review | CCB is reviewing the request |
| Approved | Approved by CCB or PM |
| Conditionally Approved | Approved subject to specific conditions being met |
| Rejected | Rejected by CCB or PM |
| Implemented | Change has been completed |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
緊急変更（Emergency Change）の扱い方
本番障害への緊急対応など、CCBの審査を待てない変更が発生することがある。このような緊急変更は「PM単独承認で即対応・事後にCCBへ報告」とルールを定めておくことで、緊急時でも変更プロセスを維持できる。
| 日本語 | 英語 |
|---|---|
| 緊急変更として処理します | We will process this as an emergency change. |
| 事後にCCBへ報告します | We will report to the CCB after the fact. |
| 影響分析を省略して進めます | We will proceed without a full impact analysis given the urgency. |
| 本番環境に緊急で適用しました | The change has been applied to production on an emergency basis. |
プロジェクト憲章との連携
プロジェクト憲章では変更管理の方針を高レベルで定め、変更管理計画書でその詳細プロセスを規定する。英語プロジェクト憲章の書き方と合わせて整備することで、変更管理のルールをプロジェクト開始時から明確にできる。
変更管理計画書でよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
変更要求の受付・確認フレーズ
| 日本語 | 英語 |
|---|---|
| 変更要求書を受け取りました | We have received your Change Request. |
| 影響分析を開始します | We will begin the impact assessment. |
| 3営業日以内にご連絡します | We will get back to you within 3 business days. |
| 追加情報が必要です | We need additional information to proceed. |
| 変更要求IDはCR-001です | Your Change Request ID is CR-001. |
承認・否認の通知フレーズ
| 日本語 | 英語 |
|---|---|
| 変更要求が承認されました | Your Change Request has been approved. |
| 変更要求が否認されました | Your Change Request has been rejected. |
| 以下の条件を満たすことを前提に承認します | This is conditionally approved, subject to the following conditions. |
| 今回は対応が難しい状況です | We are unable to accommodate this change at this time. |
| 次フェーズでの対応を検討します | We will consider this for the next phase. |
増員・担当変更・ツール追加などのリソース変更を正式なプロセスで管理するには英語リソース管理計画書の書き方のテンプレートが役立つ。リソースカレンダーで過負荷を早期に発見し、変更管理プロセスと連携することで計画外の追加コストを防げる。
スケジュール変更を正式なプロセスで管理するには英語スケジュール管理計画書の書き方のテンプレートが役立つ。遅延検知から承認・計画更新・周知まで6ステップのプロセスで、スケジュール変更を変更管理と連携して処理できる。
リスクへの対応としてスコープや計画を変更する場合は英語リスク管理計画書の書き方と連携させてほしい。リスクが顕在化したときの対応策を変更管理プロセスで正式に記録・承認することで、対応の根拠が明確になる。
まとめ：英語変更管理計画書は4つのセクションで完成する
英語変更管理計画書に必要な構成要素を整理した。
- 変更要求管理は「変更要求書をJiraで起票する」のように提出方法と必須記載項目を定め、口頭やメールでの非公式な変更依頼を受け付けない仕組みを作る
- 影響分析プロセスはスコープ・スケジュール・コスト・品質・リスクの5つの観点で変更の影響を定量化し、「この変更には工数〇時間・コスト〇万円が必要」と明確に示せる状態にする
- 変更承認プロセスは変更規模に応じた承認権限を設定し、軽微な変更はPM一人で迅速に・大規模な変更はCCBで慎重に判断できる体制を整える
- 変更ログ管理はすべての変更要求のステータスをJiraや台帳で追跡し、「あの変更はどこまで進んでいるか」がいつでも確認できる状態を維持する
テンプレートをコピーして、まず「承認権限マトリクス」から埋め始めてほしい。「誰が何を承認できるか」を最初に合意することで、変更要求が来たときの判断が速くなる。
コメント