変更管理委員会（CCB）とは？
変更管理委員会（Change Control Board：CCB）は、変更要求を審査して、承認・却下・保留を決める正式な会議体です。ベースライン（スコープ・スケジュール・コストの基準）を変えるような変更は、ここで判断するのが一般的です。PMBOK ガイド第8版の日本語版でも「変更管理委員会」と訳されています。
CCB の目的は、変更を止めることではありません。関係する立場の人が、影響を見たうえで一度に判断します。そうすることで、勝手な変更と、必要な変更の放置の両方を防ぐのが目的です。
CCBは誰で構成される？
構成は、プロジェクトの規模や組織で変わります。よくある顔ぶれは次のとおりです。
| メンバー | CCBでの役目 |
|---|---|
| スポンサー（または代理） | 予算や事業上の優先順位からの判断 |
| 顧客・業務部門の代表 | 変更が業務や便益に与える影響の判断 |
| プロジェクト・マネジャー | 影響の分析を示す。多くの場合は進行役で、投票権の有無は組織しだい |
| 技術・品質の責任者 | 技術的な実現性、品質やセキュリティへの影響の判断 |
| PMO・構成管理の担当 | 手続きの確認、記録の管理 |
ポイントは、PM は CCB の判断材料を用意する役だということです。影響の分析を示し、議論を進めますが、自分の権限を超える変更を自分で承認することはできません。
似た会議体に、運営委員会（ステアリング・コミッティ）があります。運営委員会は、プロジェクト全体の方向づけと、PM の権限を超える判断を担う上位の会議体です。CCB は、変更要求の審査に絞った会議体です。小さな組織では、運営委員会やスポンサーが CCB の役割を兼ねることもあります（ステアリングコミッティとは）。
CCBにかける変更・かけない変更は？
すべての変更を CCB にかけると、判断が遅れてプロジェクトが止まります。逆に何もかけなければ、統制がききません。そこで、かける基準をしきい値で決めておきます。
PM が判断（CCB にかけない）
- 作業ベースラインを変えない作業の入れ替え
- コスト予備費の範囲内に収まるコストの変動
- 日程最終期限に影響しない小さな日程の調整
- 基準・要件誤字の修正など文書の軽微な訂正
CCB にかける
- 作業スコープの追加・削除
- コスト決められた額を超える予算の変更
- 日程マイルストーンや最終期限の変更
- 基準・要件品質基準・セキュリティ要件の変更
当サイトの例。実際の線引きは変更管理計画とガバナンスで決める
緊急の変更（安全や重大な障害への対応など）について、事後に CCB へ報告する手順を決めておく組織もあります。この場合も、手順として決められていることが前提です。PM がその場の判断で手順を省いてよいわけではありません。
PMの権限としきい値はどう決める？
PM がどこまで自分で決めてよいかは、プロジェクト憲章、変更管理計画、ガバナンスの取り決めで決まります。2026年版のECOは、Business1（ガバナンス）で「エスカレーションの経路としきい値を決める」ことを挙げています。Business3（変更管理）では「変更管理のプロセスを実行する」ことを挙げています。CCB は、この2つをつなぐ仕組みです。
しきい値は数字で決めます。「大きな変更は CCB」では、人によって判断が割れます。だれが見ても同じ判断になる形にするのがコツです。
| 変更の大きさ（例） | 判断する人 | 変更の例 |
|---|---|---|
| 小：費用50万円以下で、マイルストーンに影響なし | PM | テスト手順の見直し |
| 中：費用50万円超〜300万円以下、またはマイルストーンが2週間以内で動く | CCB | 機能の追加・削除 |
| 大：費用300万円超、または最終期限や事業の目標が変わる | 運営委員会・スポンサー | リリース時期の変更 |
上げる基準の考え方は、エスカレーションの判断基準でも扱っています。
旧版（2021年版）のECOでは、変更管理は Process10、ガバナンスは Process14 と別々のタスクでした。2026年版では両方が Business Environment に入りました。ガバナンスで決めた基準どおりに変更を処理できるかを、同じ領域の中で一続きに考えておくと整理しやすくなります。なお、出題の傾向は公表されていないため、これは当サイトの見方です。
CCBの判断はどう伝える？
CCB が判断したら、PM が結果を伝え、記録を更新します。
- 変更ログに判断（承認・却下・保留）と理由、日付を記録する
- 依頼者に結果と理由を伝える。却下や保留の場合も必ず伝える
- 影響を受けるチームや関係者に、何が変わるか（変わらないか）を伝える
- 承認された変更を実施し、計画書・ベースラインなどの文書を更新する
CCB の判断に、関係者が不満を持つこともあります。その場合も、PM が判断を覆すことはできません。新しい情報があるなら、改めて変更要求として出し直してもらいます。判断の後の手順全体は、変更管理の手順で詳しく整理しています。
却下された要望が、関係者の間の問題として残ることもあります。その場合は課題として記録して追いかけます（課題管理表の書き方）。
PMP試験ではCCBがどう問われる？
状況問題で押さえたい判断の型は次のとおりです。
- CCB の前にやること：変更要求を記録し、影響を分析する。分析なしに CCB にかける選択肢は不十分です。
- CCB を飛ばさない：顧客や上位者に頼まれても、CCB にかけるべき変更を PM が承認しない。
- CCB の決定に従う：却下された変更を「顧客のため」と実施するのは誤りです。
- アジャイルとの区別：スクラムのチームでは、通常は CCB ではなくプロダクトオーナーがバックログで判断します。
変更が新しいリスクを生む場合は、リスク登録簿も更新します。CCB の問題は、選択肢の「順番」を問うことが多い型です。タスク別ドリルで Business3 の問題を続けて解くと、型が身に付きます。
確認問題1
役員が直接承認を求める
（当サイトの独自問題）スポンサーの上司にあたる役員が PM のもとに来て、来月の発表に向けた機能の追加を求めました。「CCB にかける時間はないので、今ここで承認してほしい」とのことです。変更管理計画では、機能の追加は CCB で判断すると決まっています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：2。役員の要求でも、決められた手順は飛ばせません。ただし、急ぎの事情には応える必要があります。変更要求として記録して影響を素早く分析し、CCB を臨時に開いてもらうなど、手順の中で早く判断できる道をとります。
1：役員は CCB の代わりではなく、手順を飛ばした承認になります。3：断るかどうかを PM が決めることになり、権限を超えます。4：要求そのものを消そうとするのは、正しい判断の機会を奪います。
確認問題2
却下された変更を実施したい
（当サイトの独自問題）CCB は、データ出力の形式を変える変更要求を、費用対効果が低いとして却下しました。依頼した業務部門の課長は納得せず、PM に「小さな作業なので、こっそり対応してほしい」と頼んできました。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。CCB の決定に反して実施することはできません。却下の理由を丁寧に説明し、費用対効果を変える新しい情報があるなら、改めて変更要求として出してもらいます。
1：承認されていない変更の実施です。2：まず本人と対話するのが先です。3：PM が決定を覆す側に回るのは筋が違います。
確認問題3
しきい値の内側の変更
（当サイトの独自問題）変更管理計画では、費用が50万円以下でマイルストーンに影響しない変更は、PM が判断できると決まっています。テストの手順を見直す変更要求が出され、分析すると費用は20万円、マイルストーンへの影響はありません。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。しきい値の内側の変更は、PM が判断できます。判断したら、変更ログに記録し、関係者に伝え、必要な文書を更新します。
1・2：権限の内側の判断を上に上げると、判断が遅れ、上位者の負担も増えます。4：権限の内側でも、記録と伝達の手順は省けません。