ITプロジェクトでバージョン管理や環境設定がバラバラになり、「どの設定が正しいか分からない」「本番と開発の環境が一致していない」という状況に陥ったことはないだろうか。こうした混乱の多くは、コンフィギュレーション管理計画書（Configuration Management Plan）がないことで起きる。
コンフィギュレーション管理計画書は「プロジェクトの成果物・環境・ドキュメントをどのように識別・管理・変更するかのルールを定める文書」だ。構成アイテム定義・ベースライン管理・変更制御・監査の4つを押さえれば、英語でも問題なく整備できる。
この記事では、英語コンフィギュレーション管理計画書に必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐにプロジェクトの設定管理体制を確立できる。
コンフィギュレーション管理計画書に必要な4つの構成要素
コンフィギュレーション管理計画書はプロジェクトの「設定・環境・成果物の一貫性を保つルールブック」だ。誰が何をいつ変更したかを追跡できるようにすることで、プロジェクト全体の品質と整合性を維持できる。以下の4つが実務で使いやすい構成要素になる。
- 構成アイテム定義（Configuration Item Definition）
- ベースライン管理（Baseline Management）
- 変更制御プロセス（Change Control Process）
- 監査と報告（Audit and Reporting）
コンフィギュレーション管理計画書と変更管理計画書の違い
変更管理計画書は「プロジェクトのスコープ・スケジュール・コストへの変更をどう審査・承認するか」を定める文書だ。コンフィギュレーション管理計画書は「ソフトウェア・ドキュメント・環境設定といった成果物（構成アイテム）の識別・追跡・変更制御のルール」を定める文書に当たる。変更管理計画書が「プロジェクト計画の変更」なら、CMPは「成果物そのものの変更管理」だ。
なぜコンフィギュレーション管理計画書が必要か
設定管理のルールがないプロジェクトでは、本番環境と開発環境の設定差異によるインシデントや、「どのドキュメントが最新版か分からない」という混乱が頻発する。CMPを整備することで、誰がいつどのバージョンの設定を変更したかが追跡でき、問題発生時の原因特定と復旧が迅速になる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
基本情報
| 項目 | 内容 |
|---|
| プロジェクト名 | （例：〇〇システム開発プロジェクト） |
| 作成者 | （例：田中（PM）） |
| 作成日 | （例：2026年7月10日） |
| バージョン | v1.0 |
| 対象期間 | （例：2026年8月〜2026年12月） |
構成アイテム定義（Configuration Item Definition）
構成アイテム（CI）一覧
| CI ID | CI名 | 種類 | 担当者 | 管理ツール |
|---|
| CI-001 | アプリケーションソースコード | ソフトウェア | 開発リード | GitHub |
| CI-002 | インフラ構成ファイル（IaC） | 環境設定 | インフラエンジニア | Terraform/GitHub |
| CI-003 | 要件定義書・設計書 | ドキュメント | PM | SharePoint |
| CI-004 | テストスクリプト | ソフトウェア | QAエンジニア | GitHub |
| CI-005 | データベーススキーマ | ソフトウェア | DBエンジニア | GitHub |
| CI-006 | 環境設定ファイル（開発・ステージング・本番） | 環境設定 | インフラエンジニア | 秘密管理ツール |
CI命名規則
| 種類 | 命名規則 | 例 |
|---|
| ソースコード | <サービス名>-<コンポーネント名> | order-service-api |
| ドキュメント | <文書種別>_<バージョン>_<日付> | requirements_v1.2_20260710 |
| 環境設定 | <環境名>_<サービス名>_config | prod_order-service_config |
ベースライン管理（Baseline Management）
ベースライン一覧
| ベースラインID | 名称 | 設定時期 | 対象CI | 承認者 |
|---|
| BL-001 | 機能ベースライン | 要件定義完了時 | CI-003（要件定義書） | スポンサー |
| BL-002 | 設計ベースライン | 設計完了時 | CI-003（設計書）・CI-005 | アーキテクト |
| BL-003 | 製品ベースライン | リリース承認時 | CI-001〜CI-006全件 | PM・スポンサー |
ベースラインの変更ルール
| ルール | 内容 |
|---|
| ベースラインの変更権限 | 変更制御委員会（CCB）の承認が必要 |
| 変更記録 | 変更ログに理由・内容・承認者を記録する |
| 旧バージョンの保管 | 変更前のベースラインはタグ・スナップショットで保持する |
変更制御プロセス（Change Control Process）
変更申請から承認までのフロー
変更要求起票（変更申請書）
→ 影響分析（担当エンジニア・3営業日以内）
→ CCBレビュー（週次CCB会議）
→ 承認 / 却下
→ 実施・テスト・記録
→ ベースライン更新
変更の優先度分類
| 優先度 | 定義 | 対応期限 | 承認フロー |
|---|
| 緊急（Emergency） | 本番障害・セキュリティ脆弱性 | 即時 | PM承認→事後CCB報告 |
| 高（High） | リリース影響あり | 次回CCB | CCB承認 |
| 中（Medium） | 通常変更 | 2週間以内 | CCB承認 |
| 低（Low） | 軽微な改善 | 次スプリント | チームリード承認 |
変更制御委員会（CCB）
| 役割 | 担当者 | 責務 |
|---|
| CCB議長 | PM | 会議の進行・最終承認 |
| 技術代表 | アーキテクト | 技術影響の評価 |
| QA代表 | QAリード | 品質・テスト影響の評価 |
| 運用代表 | インフラリード | 運用影響の評価 |
監査と報告（Audit and Reporting）
設定監査スケジュール
| 監査種別 | 頻度 | 目的 | 実施者 |
|---|
| 機能設定監査（FCA） | マイルストーン時 | ベースラインと成果物の整合性確認 | QAリード |
| 物理設定監査（PCA） | リリース前 | 本番リリース対象物の最終確認 | PM・QAリード |
| 定期CI棚卸し | 月次 | CIの最新状態確認 | 各CI担当者 |
報告サイクル
| 報告種別 | 頻度 | 報告先 | 内容 |
|---|
| CM状況レポート | 月次 | スポンサー・PM | CI変更件数・未承認変更・監査結果 |
| CCB議事録 | 会議毎 | 全ステークホルダー | 審議事項・承認/却下結果 |
| ベースライン変更通知 | 変更毎 | 開発チーム全員 | 変更内容・新バージョン・影響範囲 |
英語版テンプレート（コピペOK）
Basic Information
| Item | Details |
|---|
| Project Name | (e.g., [System] Development Project) |
| Prepared By | (e.g., Tanaka, PM) |
| Date | (e.g., July 10, 2026) |
| Version | v1.0 |
| Coverage Period | (e.g., August – December 2026) |
Configuration Item Definition
Configuration Item (CI) Register
| CI ID | CI Name | Type | Owner | Management Tool |
|---|
| CI-001 | Application source code | Software | Dev Lead | GitHub |
| CI-002 | Infrastructure configuration (IaC) | Environment | Infra Engineer | Terraform/GitHub |
| CI-003 | Requirements and design documents | Documentation | PM | SharePoint |
| CI-004 | Test scripts | Software | QA Engineer | GitHub |
| CI-005 | Database schema | Software | DB Engineer | GitHub |
| CI-006 | Environment config files (dev/staging/prod) | Environment | Infra Engineer | Secrets manager |
CI Naming Conventions
| Type | Convention | Example |
|---|
| Source code | - | order-service-api |
| Documents | __ | requirements_v1.2_20260710 |
| Environment config | __config | prod_order-service_config |
Baseline Management
Baseline Register
| Baseline ID | Name | When Set | Target CIs | Approver |
|---|
| BL-001 | Functional baseline | Requirements sign-off | CI-003 (requirements) | Sponsor |
| BL-002 | Design baseline | Design sign-off | CI-003 (design) + CI-005 | Architect |
| BL-003 | Product baseline | Release approval | CI-001 through CI-006 | PM + Sponsor |
Baseline Change Rules
| Rule | Detail |
|---|
| Authority | Change Control Board (CCB) approval required for any baseline change |
| Change log | Record reason, description, and approver for every change |
| Version retention | Preserve previous baselines via tags or snapshots |
Change Control Process
Change Request Workflow
Raise Change Request (CR form)
→ Impact analysis (responsible engineer, within 3 business days)
→ CCB review (weekly CCB meeting)
→ Approved / Rejected
→ Implement → Test → Document
→ Update baseline
Change Priority Classification
| Priority | Definition | Response Time | Approval Path |
|---|
| Emergency | Production outage / security vulnerability | Immediate | PM approval → post-hoc CCB report |
| High | Affects upcoming release | Next CCB | CCB approval |
| Medium | Standard change | Within 2 weeks | CCB approval |
| Low | Minor improvement | Next sprint | Team lead approval |
Change Control Board (CCB)
| Role | Owner | Responsibility |
|---|
| CCB Chair | PM | Facilitate meeting, final sign-off |
| Technical representative | Architect | Evaluate technical impact |
| QA representative | QA Lead | Evaluate quality and test impact |
| Operations representative | Infra Lead | Evaluate operational impact |
Audit and Reporting
Configuration Audit Schedule
| Audit Type | Frequency | Purpose | Conducted By |
|---|
| Functional Configuration Audit (FCA) | At milestones | Verify baseline–deliverable alignment | QA Lead |
| Physical Configuration Audit (PCA) | Before release | Final verification of release candidates | PM + QA Lead |
| CI inventory check | Monthly | Confirm current CI status | Each CI owner |
Reporting Cadence
| Report | Frequency | Recipients | Content |
|---|
| CM status report | Monthly | Sponsor + PM | CI change count, unauthorized changes, audit results |
| CCB minutes | Per meeting | All stakeholders | Items reviewed, approval/rejection decisions |
| Baseline change notification | Per change | Full development team | Change details, new version, impact scope |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
構成アイテム（CI）は「変更追跡が必要なもの」から選ぶ
CI登録の落とし穴は「すべてのファイルをCIにしようとすること」だ。CMPの目的は追跡と変更制御であり、管理コストが便益を上回っては意味がない。「このファイルが意図せず変更されたら、プロジェクトに影響が出るか」という基準でCIを絞り込むことが重要だ。
本番環境の設定ファイルやデータベーススキーマは変更が直接インシデントにつながるため、必ずCIとして登録する。一方、個人のメモやドラフト文書は対象外とするのが一般的だ。
ベースラインは「合意の証拠」として機能する
ベースラインはプロジェクトの節目に設定する「合意済みの状態のスナップショット」だ。機能ベースライン（要件合意後）・設計ベースライン（設計承認後）・製品ベースライン（リリース前）の3段階が基本となる。ベースラインが設定されていれば、「あの時点に戻してほしい」という要求に迅速に対応できる。
ADRでアーキテクチャ決定の根拠を記録し、CMPでその決定の実装状態をベースラインとして管理することで、設計の意図と実装の一致が継続的に検証できる。英語ADR（アーキテクチャ決定記録）の書き方と合わせて活用してほしい。
コンフィギュレーション管理計画書でよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
構成管理コミュニケーションフレーズ
| 日本語 | 英語 |
|---|
| この変更はCCBの承認が必要です | This change requires CCB approval. |
| ベースラインを更新しました | The baseline has been updated. |
| このCIの最新バージョンを確認してください | Please check the latest version of this CI. |
| 未承認の変更が検出されました | An unauthorized change has been detected. |
| 変更申請書を提出してください | Please submit a change request form. |
変更制御・監査フレーズ
| 日本語 | 英語 |
|---|
| 変更の影響範囲を分析してください | Please analyze the impact of this change. |
| この変更はベースラインに影響します | This change affects the baseline. |
| 変更ログに記録してください | Please record this in the change log. |
| CCBは変更を承認しました | The CCB has approved the change. |
| 設定監査を実施する必要があります | A configuration audit needs to be conducted. |
まとめ：英語コンフィギュレーション管理計画書は4つのセクションで完成する
英語コンフィギュレーション管理計画書に必要な構成要素を整理した。
- 構成アイテム定義は「変更追跡が必要なもの」を絞り込んでCIとして登録し、命名規則と管理ツールをセットで定めることで、誰が見ても管理対象が明確になる
- ベースライン管理はプロジェクトの節目に「合意済みの状態のスナップショット」を設定し、承認権限と旧バージョン保管ルールを明文化することで、過去の状態への復元と変更の根拠を証明できる
- 変更制御プロセスはCCBによる審査フローと優先度分類を組み合わせることで、緊急変更と通常変更の対応速度を使い分けながら、すべての変更を追跡可能な状態に保つ
- 監査と報告は機能設定監査・物理設定監査・月次棚卸しの3段階で実施し、ベースラインと実態の乖離を定期的に検出する体制を整える
テンプレートをコピーして、まず「CI一覧」を埋めることから始めてほしい。管理すべき対象が明確になれば、ベースラインと変更制御のルールが自然と固まる。
変更管理計画書でプロジェクト全体の変更承認プロセスを定め、CMPで成果物の設定変更を管理することで、変更管理の全工程がカバーできる。英語変更管理計画書の書き方と合わせて整備してほしい。
コメント