変更管理、課題管理の用語をゆるく説明｜PMP試験用語13

変更管理、課題管理は、PMP試験で出題数が多く、大変重要な分野です。

そんな変更管理、課題管理に関し、次の用語をざっくばらんに説明します。

• コンフィギュレーションマネジメント
• 予測型の変更管理
• 適応型の変更管理
• 課題管理とエスカレーション

実際の試験用語として厳密に参照されたい場合は、PMPOKや参考書をご確認ください。

コンフィギュレーションマネジメント

PMP試験で出てくるコンフィギュレーション・マネジメント（Configuration Management）について、分かりやすく、ちょっと試して解説しますね。

コンフィギュレーション・マネジメントとは？

一言で言うと……

「プロジェクトの構成物（成果物）の『正しい姿』を記録・管理して、勝手に無駄にしないお仕事」です。

例：ロボットを作っているプロジェクト

あなたのチームがAI付きの最強ロボット「タケボットX」を作りました。そのうち、エンジニアが言いました：

「ここのバッテリー、勝手に2倍のやつにしときました〜！そのほうが強そうでしょ？」

いや、ちょっと待って！？
それ、勝手に構成変えちゃってるじゃん！
他のパーツとバランス崩れるし、予算もスケジュールも狂うかも！

ここで登場するのが構成・管理です。

コンフィギュレーション・マネジメントのポイント

要素	内容
コンフィギュレーション識別	管理対象の構成物（成果物、ドキュメント、 仕様書など）を決定する
コンフィギュレーション管理	それぞれのバージョンをきちんと保管・整理する
変更管理	「この構成物を変更したい！」というときに、 正式な手続きをやめて（勝手に変えちゃダメ）
状態確認	「今、このパーツってどのバージョンですか？」を理解し、 混乱しないようにする
検証・監査	「ちゃんと変更ルール守ってる？」と定期的に見直す

要素	内容
コンフィギュレーション識別	管理対象の構成物（成果物、ドキュメント、 仕様書など）を決定する
コンフィギュレーション管理	それぞれのバージョンをきちんと保管・整理する
変更管理	「この構成物を変更したい！」というときに、 正式な手続きをやめて（勝手に変えちゃダメ）
状態確認	「今、このパーツってどのバージョンですか？」を理解し、 混乱しないようにする
検証・監査	「ちゃんと変更ルール守ってる？」と定期的に見直す

コンフィギュレーション・マネジメントが必須、
プロジェクトが「伝言ゲーム」状態になります。

最初は「赤いボタン」だったのに、最終的には「紫のLED付きスイッチ」に！

• コンフィギュレーション管理は変更管理とセットです。
• 特に「どの成果物を管理対象にするか」「バージョン管理」が問われやすい。
• アジャイルだと「プロダクトバックログの管理」も同様の構成管理と捉えられる。

予測型の変更管理とは？

一言で言えば…

「決めた計画を、勝手に一度いじるな！変えるなら、適切な手続きを踏んでね！」というお約束ごと。

予測型の世界観：

「計画が神。変更は悪。…尚、必要なら仕方ない。」

予測型プロジェクトは、最初に計画をガチッと固めてから実行や考えます。
にもかかわらず、「仕様っぱ変更して」「予定３日早くね？」なんてことを言われたら…

😱「うそでしょ！？ 積み上げたガントチャートが灰に……」

そうならないよう、変更はルールに則って、慎重に、厳重に扱います。

変更管理のプロセス（予測型の定番フロー）

1. 変更要求の提出
   • 誰かが「ここを変えたい」と言い出します。
   • 例：「この画面、やっぱりピンクにしたいです！」
2. 変化の記録
   • ちゃんと書面で残します（チャットじゃダメ！）。
   • 例：変更要求票（CR：変更要求）
3. 影響分析
   • 「この変更で、コスト・スケジュール・品質にどう影響が出るか」をガチ検討。
   • ピンクに変える → ボタン全とっかえ → 工数＋5日 → 費用＋10万円
4. 変更管理審議会（CCB）での審査
   • お偉いさんやPMが集まり、「その変更、アリカナシカ？」をジャッジ。
   • ※CCB：Change Control Board（変更統制委員会）
5. 承認／却下の決定
   • 承認されたら、晴れてプロジェクト計画書が更新される。
6. 変更の実行と追跡
   • 承認された変更を反映し、正しく変更通りに進んでるかチェック。

PMP試験でのポイント

• 「変更要求はプロセス評価中に・承認される」と明示的に覚えておいてください。
• 計画書やスコープベースラインの勝手な変更はNG。「随時承認」が必要です。
• アジャイルとは対照的で、柔軟性は少なく、限界力は強い。

用語	説明
CCB（変更管理審議会）	変更の承認却・下を決定チーム
CR（変更要求）	変更を正式に提出する書類
影響分析	変更が3大観点（スコープ・時間・コスト）に与える影響を分析
計画の更新	承認後、プロジェクト計画書などを改訂

用語	説明
CCB（変更管理審議会）	変更の承認却・下を決定チーム
CR（変更要求）	変更を正式に提出する書類
影響分析	変更が3大観点（スコープ・時間・コスト）に与える影響を分析
計画の更新	承認後、プロジェクト計画書などを改訂

適応型の変更管理

適応型（アジャイル型）プロジェクトの変更管理について、ご紹介します。

適応型の変更管理とは？

ひとことで言えば…

「変化？ウェルカムですけど何か？」
― アジャイルの精神

適応型の世界：「変化は見えるではなく、チャンス！」

ウォーターフォール型が「変更＝敵」と思ったら、
アジャイル型は「変更＝ユーザーの気づき✨」​​と捉えます。

そのため、変更管理はこんな感じ：

• 新しいアイデアが出ました？→「よし、ログバックに入れとこう！」
• 今すぐやる？→「優先順位によるけど、次のプリントで検討しよう！」
• やめたくなった？→「じゃ、ログバックから削除で！」

まるで、食べ放題バイキングで「やっぱ食べたい」って戻って自由さです（笑）

適応型の変更管理の流れ（概要）

ステップ	内容
①バックログに追加	新しい変更要求はプロダクトバックログに登録されます。
②優先順位決定	製品オーナーが「今重要かどうか」を判断して並び替えます。
③スプリント計画で検討	次のプリントでどうですかをチームで相談してください。
④実装 → レビュー	実際に作って、ステークホルダーと成功と確認。「うん、これこれ！」となれば。

ステップ	内容
①バックログに追加	新しい変更要求はプロダクトバックログに登録されます。
②優先順位決定	製品オーナーが「今重要かどうか」を判断して並び替えます。
③スプリント計画で検討	次のプリントでどうですかをチームで相談してください。
④実装 → レビュー	実際に作って、ステークホルダーと成功と確認。「うん、これこれ！」となれば。

PMP試験でのポイント

• アジャイルでは変更は織り込み済み。
• ただし、「何でもその場で変えちゃう」わけではなく、ログバックという公式な管理手段で整理される。
• スプリント中は変更しないが原則。短いサイクルの中で安定して作業するためです。

用語	説明
製品バックログ	要件や変更要件が全部つめこにある「やることリスト」
プロダクトオーナー（PO）	変更の優先順位を決める人。ユーザー視点の番人
スプリント計画	変更はいつやるのか、チームと話し合う場
インクリメント	小さく作って、小さくレビュー。 変化に強くなる魔法

用語	説明
製品バックログ	要件や変更要件が全部つめこにある「やることリスト」
プロダクトオーナー（PO）	変更の優先順位を決める人。ユーザー視点の番人
スプリント計画	変更はいつやるのか、チームと話し合う場
インクリメント	小さく作って、小さくレビュー。 変化に強くなる魔法

予測型と適応型のちがい（変更管理）

項目	予測型	適応型
変更の扱い	原則NG、審査必須	ウェルカム、一応優先順位管理あり
計画の変更	計画書を改訂	バックログを更新
承認方法	CCBなどの会議	POが判断
タイミング	実施前の審査	スプリントごとに反映可能

項目	予測型	適応型
変更の扱い	原則NG、審査必須	ウェルカム、一応優先順位管理あり
計画の変更	計画書を改訂	バックログを更新
承認方法	CCBなどの会議	POが判断
タイミング	実施前の審査	スプリントごとに反映可能

課題管理とエスカレーション

課題管理（Issue Management）とエスカレーション（Escalation）について、説明します！

課題管理とは？

一言でいうと……

「もう発生しちゃった『おかしいごと』に対処すること」

リスクが「かもね（未来の不安）」なら、
課題は「出たよ！（現実問題）」です。

課題管理を例えるなら…

あなたはプロジェクトマネージャーです。
予定3日前、テスト中の開発リーダーが言いました。

👨‍💻「あっ…バグでデータ全部飛んでいきました」
😇「今なんて？」

はい、それが課題（問題）です。
もう起きちゃった問題は「なかったこと」にはできません。きちんと
記録して、追跡して、潰していくのが課題管理です。

課題管理の基本ステップ

ステップ	内容
登録	起きた問題を「課題登録簿」 に記録（事実ベース）
分析	原因や影響を調査 （どれくらいヤバい？）
対応策検討	解決に向けたアクションを考える （応急措置と根本対策）
担当割り当て	誰が解決するか決める （丸投げNG）
状況監視	解決まで追跡。放置しない （ここ重要！）

ステップ	内容
登録	起きた問題を「課題登録簿」に記録（事実ベース）
分析	原因や影響を調査（どれくらいヤバい？）
対応策検討	解決に向けたアクションを考える（応急措置と根本対策）
担当割り当て	誰が解決するか決める（丸投げNG）
状況監視	解決まで追跡。放置しない（ここ重要！）

エスカレーションとは？

今度、どうにもならない課題が出てきたときは…？

「PMレベルでは無理！もっと上の人、助けてー！」

それがエスカレーション（上位報告・上申）です。

エスカレーションを例えるなら…

バグ修正が無い → ベンダー増員が必要 → 契約変更が必要
→ 💬「もう部長レベルの判断じゃん！PMには権限ないよ！」

そんな時はすぐにエスカレーション。
権限ある人に判断をゆだねて、プロジェクトを中止しませんように。

PMP試験でのポイント

• 課題とリスクは別物！
  　リスク：まだ起きてないかもしれないこと
  　課題：もう起きちゃった事実
• 課題は記録・追跡・対処が必須
  　課題ログ（Issue Log）を正しく活用しよう。
• エスカレーションは「許可の壁」を乗り越える手段
  　「PMが全て解決できるわけではない」ことを前提にしている。

用語	内容	ポイント
課題管理	発生した問題への対応	厳重に放置禁止。記録＆追跡が命。
エスカレーション	権限を超える問題を上位者に報告	判断を上にパスして、前に進む！

用語	内容	ポイント
課題管理	発生した問題への対応	厳重に放置禁止。記録＆追跡が命。
エスカレーション	権限を超える問題を上位者に報告	判断を上にパスして、前に進む！