変更管理（change management）

• マネジメント系
• サービスマネジメント
• ITパスポート
• 基本情報
• 応用情報
• 重要度 ★★★★☆

下書き：本文は書き終えていますが、運営者の確認待ちのため未公開です。 検索エンジンには noindex を返しています。

もう少し詳しい説明

変更管理は、システムやサービスへの変更について、影響を見積もったうえで「やってよいか」を判断する活動です。

なぜ、わざわざ承認が要るのか

本番環境への変更は、障害のいちばん大きな原因だからです。

動いているものに手を入れれば、思わぬところが止まります。良かれと思った修正が、別の機能を壊すこともあります。だから、**「直せるから直す」ではなく、「直してよいかを決めてから直す」**という手順を挟みます。

何を評価するのか

**変更要求（RFC：Request For Change）**が出るところから始まります。「こう変えたい」という申請です。

そのあと、次を評価します。

3つ目の「元に戻せるか」が、実務ではいちばん重要です。戻せない変更は、失敗したときに打つ手がありません。承認の条件として、切り戻しの手順を用意させることが多くあります。

大きな変更は、**変更諮問委員会（CAB：Change Advisory Board）**にかけて審議します。関係する立場の人を集めて、見落としがないか確かめる場です。

変更管理とリリース管理の分担

ここが、この用語でいちばん狙われます。

判断と実行を分けているのが要点です。同じ人が「やってよい」と決めて自分で実行すると、歯止めが効きません。内部統制で出てくる職務の分離と、同じ考え方です。

緊急の変更はどうするか

障害対応で、承認を待っていられない場合もあります。そのために緊急変更の手順が別に用意されています。

ただし、「承認なし」ではありません。 通常より少人数で素早く判断し、実施後に必ず記録して、事後に審議します。

試験では「緊急時は変更管理を経ずに実施してよい」という選択肢が誤りとして出ます。 手順が簡略になるだけで、管理の外に出るわけではありません。

呼び名の注意

ITIL 4 では、この活動は**「変更実現（change enablement）」**に呼び名が変わりました。「管理」という言葉が「止める役目」と受け取られやすかったためです。

ただし試験や参考書では、従来どおり「変更管理」と書かれていることがほとんどです。同じものを指していると知っておけば十分です。

覚え方：道路工事の許可

• 変更管理 … 工事の許可を出す役所。いつ、どの範囲を、どう通行止めにするかを審査する
• リリース管理 … 実際に掘る工事業者
• 切り戻し手順 … 途中で中止になったときに、元どおり舗装し直す段取り

役所が工事まで自分でやってしまうと、誰も止められなくなる。 判断と実行を分ける理由は、ここにあります。

試験ではこう出る

科目A（旧・午前）のサービスマネジメント分野で出ます。多いのは、変更管理とリリース管理の役割を入れ替えた選択肢を見分ける問題と、CABの役割を問う問題です。応用情報では、緊急変更の扱いや、構成管理との関係まで踏み込みます。

判断の軸は1つです。変更管理は「やってよいか」まで、リリース管理が「実際に展開する」。 選択肢に「本番環境へ展開する」とあればリリース管理です。もう1つ、緊急変更でも管理の外には出ないという点を押さえておくと、引っかけを避けられます。

関連する用語

リリース管理

承認された変更を、計画に沿って本番環境へ展開する活動。変更管理が判断、リリース管理が実行

問題管理

インシデントの原因を突き止め、再発を防ぐ活動。その恒久対策は変更管理を通してから実施する

インシデント管理

止まったサービスを早く元に戻す活動

構成管理

どの機器にどのソフトが入っているかを正確に記録し、最新の状態に保つ活動

ITIL

ITサービスの運用でうまくいったやり方をまとめた手引書の集まり

内部統制

組織が自らを律する仕組み。判断と実行を分ける「職務の分離」は、変更管理と同じ考え方

ミニクイズ

最終更新：2026-09-25