変更管理のプロセス｜ITIL準拠の6ステップと業務フロー図
「ちょっとした設定変更のつもりが、本番を止めてしまった」——情報システム部門なら、一度はヒヤリとした経験があるのではないでしょうか。誰がいつ何を変えたのか追えず、切り戻しにも時間がかかる。変更にまつわるトラブルの多くは、プロセスが曖昧なまま「その場の判断」で進めてしまうことから起こります。
この混乱を防ぐ仕組みが、変更管理（チェンジマネジメント）です。ITILでは、ITサービスへのあらゆる変更を、起票・評価・承認・実装・レビューという決まった流れに乗せて管理します。属人的な勘ではなく、合意されたプロセスでリスクをコントロールするのが狙いです。
この記事では、ITIL準拠の変更管理プロセスを6つのステップに分けて解説します。RFC起票からCAB承認、クローズまでの全体像を業務フロー図で可視化し、標準変更・通常変更・緊急変更の使い分け、つまずきやすいポイントまで順番に整理します。読み終わる頃には、自社の変更管理フローを描く道筋がはっきり見えているはずです。
この記事でわかること
- 変更管理（チェンジマネジメント）の目的とITILでの位置づけ
- RFC起票→影響評価→CAB承認→実装→レビュー→クローズの6ステップ
- 標準変更・通常変更・緊急変更の違いと使い分けの判断基準
- CAB（変更諮問委員会）の役割と、承認を滞らせないコツ
- 変更管理フローを業務フロー図で可視化するメリットと作り方
変更管理（チェンジマネジメント）とは
変更管理とは、ITサービスやシステムに対するあらゆる変更を、決められた手順に沿って評価・承認・実施・記録する仕組みのことです。サーバー設定の修正、アプリのリリース、ネットワーク機器の入れ替え——本番環境に影響しうる変更はすべて対象になります。
目的はシンプルです。変更に伴うリスクとサービス停止を最小化しながら、必要な変更を迅速に届けること。「変えない」ことが目的ではなく、「安全に、素早く変える」ための土台づくりだと考えてください。
ITIL（ITサービスマネジメントのベストプラクティス集）では、変更管理は中核プロセスの一つに位置づけられています。最新のITIL 4では「変更実現（Change Enablement）」と呼ばれ、変更を妨げるのではなく、ビジネスのスピードを保ちながらリスクを管理する考え方が強調されています。
変更管理が機能していないと起こること
- 誰がいつ何を変えたのか記録が残らず、障害時の原因切り分けに時間がかかる
- 影響範囲を評価しないまま実施し、想定外のシステムを巻き込んで停止させる
- 切り戻し手順が用意されておらず、トラブル発生時に復旧の見通しが立たない
- 承認なしの「勝手な変更」が横行し、構成情報（CMDB）と実態がずれていく
ミナミさん
現場の業務改善担当
正直、小さな変更まで毎回プロセスに乗せていたら、現場が回らなくなりませんか？スピードが落ちる気がして…。
スパーク先輩
DrillSparkコンサルタント
いい質問だね。だからこそITILは変更を3種類に分けているんだ。リスクの低い定型作業は『標準変更』として事前承認しておけば、毎回CABを通さなくていい。重い変更だけ丁寧に審査する——メリハリをつけるのが、速さと安全を両立するコツだよ。
標準変更・通常変更・緊急変更の違い
ITILの変更管理では、すべての変更を同じ重さで扱いません。リスクと緊急度に応じて、大きく3つのタイプに分類し、それぞれ承認のルートを変えるのが基本です。この使い分けこそが、変更管理を「現場で回る仕組み」にする最大のポイントです。
| 変更タイプ | 概要 | 承認ルート | 具体例 |
|---|---|---|---|
| 標準変更 | リスクが低く手順が確立した定型変更。事前に承認済み | 都度の承認は不要（事前承認） | 定例パッチ適用、アカウント発行、定型のリリース |
| 通常変更 | 影響評価と個別承認が必要な変更 | 影響度に応じてCABまたは責任者が承認 | 本番DBの構成変更、新機能リリース、ミドルウェア更新 |
| 緊急変更 | 障害対応など、即時の対応が必要な変更 | ECAB（緊急CAB）が迅速に承認 | 重大障害の暫定対応、緊急セキュリティパッチ |
標準変更：あらかじめ承認しておく
標準変更は、リスクが低く、手順とリスク評価が確立している繰り返し作業です。一度プロセスを承認しておけば、以降は個別の承認なしで実施できます。変更管理を回し始めると、実は変更の大半がここに収まります。標準変更をうまく整備することが、現場の負荷を下げる近道です。
通常変更：影響を評価して個別に承認する
通常変更は、影響範囲やリスクを個別に評価し、承認を経てから実施する変更です。影響度が大きいものはCAB（変更諮問委員会）の審査にかけ、小さいものは変更管理責任者の承認で進める、というように段階を分けるのが一般的です。
緊急変更：止血を優先しつつ記録を残す
緊急変更は、重大インシデントへの対応など、通常の承認フローを待てない変更です。ECAB（Emergency CAB）と呼ばれる少人数の体制で迅速に承認しますが、「記録を後回しにしない」ことが鉄則です。対応が落ち着いたあと、必ず事後レビューを行い、何を変えたのかを正式に残します。
変更管理プロセスの6ステップ
ここからは、通常変更を例に、変更管理プロセスの全体像を6つのステップで見ていきます。緊急変更はこの流れを短縮・並行化したもの、標準変更はステップ3の承認を事前に済ませたもの、と捉えると理解しやすくなります。
- RFC起票：変更要求（Request for Change）を登録し、目的・内容・希望時期を明確にする
- 影響評価：影響範囲・リスク・切り戻し手順を評価し、優先度と分類を決める
- CAB承認：変更諮問委員会で実施可否とスケジュールを審査・承認する
- 実装：承認された計画に沿って変更を実施し、テストで結果を確認する
- レビュー（PIR）：変更後レビューで、目的達成と副作用の有無を検証する
- クローズ：記録を確定し、構成情報（CMDB）を更新して変更を完了する
ステップ1：RFC（変更要求）の起票
すべての変更は、RFC（Request for Change）の起票から始まります。「何を」「なぜ」「いつ」変えたいのかを記録し、要求者・対象システム・想定スケジュールを明確にします。この入口を徹底することで、承認のない『勝手な変更』を防げます。
ステップ2：影響評価とリスクアセスメント
次に、その変更がどのシステム・サービス・ユーザーに影響するかを評価します。あわせて、失敗したときの切り戻し（ロールバック）手順を必ず用意します。ここで7R（誰が起票したか、理由、得られる利益、リスク、必要なリソース、責任者、関連性）を確認する手法もよく使われます。
ステップ3：CABによる承認
影響度の大きい通常変更は、CAB（変更諮問委員会）で審査します。実施の可否だけでなく、他の変更との競合がないか、実施タイミングは適切かまで含めて判断します。CABについては次の章で詳しく扱います。
ステップ4：実装とテスト
承認された変更計画に沿って、実際に変更を実施します。可能な限り事前に検証環境でテストし、本番適用後も動作確認を行います。問題が起きた場合は、ステップ2で用意した切り戻し手順に従って速やかに元の状態へ戻します。
ステップ5：変更後レビュー（PIR）
実装後は、PIR（Post Implementation Review／変更後レビュー）を行います。変更が当初の目的を達成したか、想定外の副作用が出ていないかを検証します。失敗した変更も、何が原因だったかを記録に残すことで、次の変更管理の質が上がります。
ステップ6：クローズと構成情報の更新
最後に、変更記録を確定してクローズします。このとき忘れてはいけないのが、CMDB（構成管理データベース）の更新です。実際の構成と記録がずれると、次の変更の影響評価が不正確になります。クローズまでやりきって、はじめて変更管理は1サイクル完了です。
ミナミさん
現場の業務改善担当
文字で6ステップを追うと、なんとなくわかった気にはなるんですが…実際の分岐まで含めると、頭の中だけだと混乱しそうです。
スパーク先輩
DrillSparkコンサルタント
そうなんだよね。承認OK/NGの分岐や、失敗時の切り戻しが入ると、文章だけでは追いきれなくなる。だから次の章で、この流れを業務フロー図にして可視化してみよう。図にすると、分岐の抜け漏れも一目でわかるようになるよ。
変更管理フローを業務フロー図で可視化する
6ステップを文章で説明しましたが、変更管理は承認の可否や失敗時の切り戻しといった分岐が多く、文章だけでは全体像が頭に入りにくいものです。こういうときこそ、業務フロー図の出番。流れと分岐をひと目で共有できます。
通常変更のプロセスをフロー図にすると、次のようになります。承認NGや実装失敗のルートまで描いておくのがポイントです。
このように図にすると、「却下されたらどこに戻るのか」「失敗したらどう復旧するのか」という、文章では流しがちな分岐が明確になります。緊急変更ではここからCAB承認を簡略化し、標準変更では承認をスキップする——という違いも、同じ図をベースに説明できます。
フロー図で可視化する3つのメリット
- 認識合わせが速い：申請者・承認者・実装担当が、同じ1枚を見て役割と順番を共有できる
- 抜け漏れが見つかる：切り戻しや差し戻しの分岐が描けているかを、目で確認できる
- 監査・引き継ぎに強い：『うちの変更管理はこう動く』を、文章より確実に伝えられる
DrillSparkなら、こうした変更管理フローを日本語で話しかけるだけで作れます。「RFC起票から影響評価、CAB承認、実装、レビュー、クローズまでの変更管理フローを作って」と伝えれば、AIが約3秒で下書きを生成。あとは対話しながら、自社のルートに合わせて整えるだけです。図はMermaid形式で出力できるので、社内ドキュメントやリポジトリにもそのまま貼り込めます。
CAB（変更諮問委員会）の役割と進め方
変更管理の要となるのが、CAB（Change Advisory Board／変更諮問委員会）です。CABは、影響度の大きい変更について、実施の可否・スケジュール・リスク対策を多角的に審査する場です。承認の責任者は変更管理マネージャーが担い、CABはあくまで助言・審議を行う役割と整理されます。
CABが確認する主な観点
- ビジネスへの影響：変更が利用者やサービスに与える影響と、その許容可否
- 技術的リスク：失敗の可能性と、切り戻し手順の妥当性
- スケジュール：他の変更や繁忙期との競合がないか
- リソース：実施・検証に必要な人員と時間が確保されているか
CABを滞らせないための工夫
CABは丁寧さと引き換えに、承認の遅さがボトルネックになりがちです。会議を待つあいだに変更が積み上がる——よくある悩みです。これを避けるには、次の工夫が効きます。
| 課題 | 対策 |
|---|---|
| 毎回CABを開くと承認が遅い | リスクの低い定型変更は標準変更として事前承認し、CABの対象から外す |
| 緊急時にCABを待てない | ECAB（緊急CAB）を少人数で常設し、即時の承認ルートを用意する |
| 審査の判断基準がばらつく | 影響度・緊急度のマトリクスを定め、誰が見ても同じ分類になるようにする |
変更管理でつまずきやすい3つのポイント
せっかく変更管理を導入しても、形だけになって機能しないケースは少なくありません。よくある失敗は、だいたい次の3つに集約されます。先に知っておけば、確実に避けられます。
失敗1：プロセスが重すぎて現場が迂回する
すべての変更に同じ重い手続きを課すと、現場は「正規ルートだと間に合わない」と感じ、こっそり変更してしまいます。これでは本末転倒です。標準変更を整備してリスクに応じた重みづけをし、軽い変更は軽く通すことが、形骸化を防ぐ第一歩です。
失敗2：切り戻し手順が用意されていない
承認は通っても、いざ失敗したときの復旧手順がない——これは最も危険なパターンです。影響評価の段階で、必ず切り戻し（ロールバック）手順をセットで用意しましょう。「戻せること」が確認できて、はじめて承認に値する変更だと考えてください。
失敗3：記録とCMDBが更新されない
実装が終わると安心してしまい、レビューやCMDB更新を後回しにしがちです。しかし記録が残らなければ、次の変更の影響評価が当てになりません。クローズまでをプロセスに含め、記録の更新を必須ステップにすることが大切です。
スパーク先輩
DrillSparkコンサルタント
3つの失敗に共通するのは、『プロセスが見えていない』ことなんだ。手順が頭の中や分厚い手順書の奥に埋もれていると、人はラクなほうへ流れる。フロー図で1枚にして全員が見える場所に置くだけで、迂回も抜け漏れもぐっと減るよ。
まとめ｜変更管理フローを図にするところから始めよう
この記事のまとめ
- 変更管理は、ITサービスへの変更を安全かつ迅速に届けるためのプロセス
- 変更は標準・通常・緊急の3タイプに分け、承認ルートを使い分ける
- 通常変更はRFC起票→影響評価→CAB承認→実装→レビュー→クローズの6ステップ
- 切り戻し手順とCMDB更新を欠かさないことが、形骸化を防ぐカギ
変更管理を機能させるコツは、最初から完璧な規程を作り込むことではありません。まず自社の変更が「どんな流れで、どこで分岐するのか」を1枚の業務フロー図にして、関係者で共有すること。これが、迂回も抜け漏れもない運用への最短ルートです。
とはいえ、分岐の多い変更管理フローを白紙から描くのは骨が折れます。そんなときこそDrillSparkの出番です。やりたい変更管理の流れを日本語で話しかけるだけで、AIが約3秒でフローチャートの下書きを生成。承認の分岐や切り戻しのルートも、対話で掘り下げながら整えられます。
複雑になりがちな変更管理も、ドリルダウン機能で『全体の流れ』と『各ステップの詳細』を階層に分けて整理できます。完成した図はMermaid形式で出力でき、社内Wikiやリポジトリにそのまま組み込めます。クレジットカードは不要、無料で始められます。
まずは自社の変更管理フローをひとつ、DrillSparkに話しかけて図にするところから始めてみましょう。プロセスが目に見えるようになれば、改善すべき点も自然と浮かび上がってきます。
ミナミさん
現場の業務改善担当
6ステップとフロー図がつながって、ようやく全体像がつかめました。まずはうちの通常変更のフローを、DrillSparkで図にしてみます！
スパーク先輩
DrillSparkコンサルタント
その一歩が大事だよ。完璧じゃなくていい、まず1枚描いてみよう。図にすれば、次に直すべきところが自然と見えてくる。応援してるよ！