対象試験と出題頻度
変更管理は、基本情報技術者・応用情報技術者で出題されるテーマです。
サービスマネジメントの主要プロセスとして定番化しており、「インシデント管理」「問題管理」「リリース管理」「構成管理」との役割の違いを正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
サービスマネジメントを勉強していると、「変更管理って、結局リリース管理や構成管理と何が違うの？」と混乱しがちです。
変更管理（Change Management）とは、一言で言うと
「ITサービスへの変更を、計画・評価・承認のステップを踏んで安全に実施するための管理活動」
のことです。
イメージとしては、「マンションのリフォーム審査」です。
分譲マンションで壁を壊すような工事をしたいとき、いきなり自分で工事を始めることはできません。管理組合に申請書を出し、「他の住人に影響はないか」を審査してもらい、承認が下りてはじめて着工できます。
変更管理も同じで、「システムをいじりたい」という要望をいきなり実行するのではなく、影響を審査して承認を得てから動かす仕組みです。
📊 変更管理の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Change Management |
| 分類 | サービスマネジメント（ITILの主要プロセス） |
| 主な目的 | 変更に伴うリスクとサービス停止を最小化する |
| キーとなる登場人物 | CAB（変更諮問委員会）、変更管理責任者 |
解説
ITサービスは一度作って終わりではなく、機能追加やバグ修正、サーバ増強などで日々手が入ります。ところが、思いつきで変更を加えると、関係ないところでシステムが止まったり、元に戻せなくなったりします。
そこで「変更には必ず手続きを通す」というルールを設け、影響範囲の評価と承認を経てから実施する流れが整備されました。これがITILで体系化された管理プロセスの背景です。
変更管理の基本フロー
変更管理は、おおむね次の流れで進みます。
RFC（変更要求）から始まり、評価・承認を経て実施、最後に振り返るのが一連の型です。
▲ 承認（③）の前に必ず影響評価（②）を行うのが変更管理の肝
CAB（変更諮問委員会）の役割
CAB（Change Advisory Board）は、変更の承認可否を判断する助言組織です。技術担当・運用担当・利用部門など複数の立場のメンバーが集まり、「この変更を実施して大丈夫か」を多角的に評価します。
マンションのリフォーム審査でいう管理組合の役割にあたります。
なお、サーバ障害への緊急対応など、悠長に会議を待てない変更については緊急変更（緊急CAB／ECAB）として迅速に承認する例外ルートも用意されます。
隣接プロセスとの比較
変更管理を正しく位置づけるには、混同しやすい他のプロセスと「何を担当するか」で整理するのが近道です。
| プロセス | 担当すること | 見分けキーワード |
|---|---|---|
| 変更管理 | 変更の評価・承認・統制 | RFC、承認、CAB |
| リリース管理 | 承認された変更を本番環境へ展開 | 展開、配布、本番反映 |
| 構成管理 | 構成品目（CI）の情報を正確に維持 | CI、CMDB、台帳 |
| インシデント管理 | 障害発生時にサービスを早く復旧 | 復旧、暫定対応、SLA |
| 問題管理 | インシデントの根本原因を究明・除去 | 根本原因、再発防止、恒久対策 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 変更管理の核心を3行で
・変更を「評価→承認→実施→レビュー」の手順で統制するサービスマネジメントのプロセス
・承認を担うのがCAB（変更諮問委員会）、緊急時はECABが対応
・「実際に本番へ展開する」のはリリース管理の仕事で、変更管理は統制を担当する
試験ではこう出る！
変更管理は、FE・APの午前問題でサービスマネジメント（ITIL）プロセスの役割を問う形で繰り返し登場します。
出題パターンは大きく2つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE R元秋 午前 問57 |
変更管理プロセスの目的・活動として適切なものを選ぶ問題。 | ・「変更の影響を評価し承認する」が正解 ・障害復旧（インシデント管理）の説明がひっかけ |
| AP H30秋 午前 問56 |
CAB（変更諮問委員会）の役割を問う問題。 | ・「変更の承認可否を助言・判断する」が正解 ・根本原因の調査（問題管理）と混同させる |
| AP H29春 午前 問55 |
RFC起票後の正しい処理順序を選ぶ問題。 | ・「評価→承認→実施」の順序が問われる ・承認前に実施する選択肢がひっかけ |
📝 IPA試験での出題パターン
パターン1：「プロセスの説明を選べ」
複数のサービスマネジメントプロセスの説明文が並び、変更管理に該当するものを選ぶ形式。ひっかけとして「サービスを迅速に復旧する」（インシデント管理）、「根本原因を取り除く」（問題管理）、「本番環境へ展開する」（リリース管理）の説明が紛れ込む。キーワードは「承認」「影響評価」。
パターン2：「登場人物・順序を問う」
CABの役割や、RFC起票後の処理順序を問う形式。「承認の前に必ず影響評価を行う」という流れを押さえれば、順序を入れ替えたひっかけ選択肢を弾けます。
試験ではここまででOKです。CABの開催頻度やITILのバージョン差まで問われることはほぼないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. サービスマネジメントにおける変更管理の説明として、最も適切なものはどれでしょうか？
- A. 発生した障害に対し、サービスを可能な限り早く復旧させ、業務への影響を最小化する。
- B. 構成品目（CI）の情報を正確に記録・維持し、システムの構成を最新の状態で把握する。
- C. ITサービスへの変更を、影響評価と承認の手続きを経て統制し、リスクを抑えて実施する。
正解と解説を見る
正解：C
解説：
変更管理は、ITサービスへの変更を計画・評価・承認のステップを踏んで安全に実施する管理活動です。CABによる承認を経てリスクを抑えることが核心であり、選択肢Cがこれに該当します。
選択肢Aはインシデント管理の説明です。障害発生時の早期復旧を担うプロセスであり、変更の承認・統制を行う変更管理とは目的が異なります。選択肢Bは構成管理の説明です。CIの情報を正確に維持するプロセスであり、変更そのものの可否を判断する役割は持ちません。
よくある質問（FAQ）
Q. 変更管理とリリース管理は、なぜ別のプロセスに分かれているのですか？
「やってよいかを決める」役割と「実際にやる」役割を分けることで、統制が効きやすくなるためです。変更管理が承認の意思決定を担い、リリース管理が承認済みの内容を本番環境へ展開します。両者を分離すると、承認なしの勝手な反映を防げると同時に、展開作業の品質管理にも集中できます。
Q. 標準変更（標準的な変更）とは何ですか？
あらかじめ手順とリスクが定型化されていて、その都度CABの承認を取らなくても実施できる事前承認済みの変更です。例えば「パスワードリセット」や「定型的なソフト更新」など、繰り返し発生し影響が小さいものが該当します。逆に影響が読みにくい変更は「通常変更」としてCABの審査を通します。試験では細かい分類までは問われませんが、用語として覚えておくと選択肢を絞りやすくなります。
Q. 実務では変更管理はどんな場面で動きますか？
サーバOSのアップデート、ネットワーク機器の入れ替え、業務アプリの機能改修など「本番環境に手を入れるあらゆる場面」で動きます。多くの企業ではチケット管理ツール（ServiceNowやJira Service Managementなど）でRFCを起票し、承認フローを電子的に回します。深夜・休日のメンテナンス時間帯に変更をまとめて実施し、利用者への影響を抑えるのが現場の定番です。
Q. 変更管理と「プロジェクトの変更管理（スコープ変更）」は同じものですか？
名前は似ていますが別物です。本記事のものはITサービス運用の枠組みで、稼働中のサービスへの変更を統制します。一方、プロジェクトマネジメントで扱う変更管理は、スコープ・スケジュール・コストといった計画の変更を統制するものです。試験では文脈（サービスマネジメントかプロジェクトマネジメントか）で判断します。出題分野を確認すれば取り違えは防げます。
