変更管理とは？ITILの標準プロセスを参考に目的やフローを解説

ITサービスを運用する上で機能改修や最新技術の導入、保守メンテナンスなど大小様々な「変更」が発生します。変更管理とはITサービスへの変更に伴うリスクを最小限にとどめて、変更をスムーズに実施するためのプロセスです。

この記事ではIT運用管理のデファクトスタンダードやベストプラクティス（成功事例）を集めたITILをベースに変更管理の目的やフローについて詳しく解説します。

変更管理とは

変更管理は簡単にいうと「何を」「どのように」変更するのかを管理するためのプロセスです。IT開発・運用に携っていれば、どんな形であれ変更管理を実施している方も多いでしょう。ただし、変更管理が正しく実施できていないとITサービスの利用現場で大きな混乱を招く可能性があります。ここからは変更管理の前提知識となる考え方や目的について解説します。

変更管理の目的

変更管理の大きな目的は以下の3点です。

1.変更履歴を残す

2.変更後のダウンタイム（ITサービスの停止時間）を最小化する

3.変更対象外のシステムをコントロールする

具体的な作業としては、変更に関わる担当者を招集し「なんの変更が必要なのか」「なぜ変更が必要なのか」「変更による影響範囲はどこか」など事前に明確にした上で、評価をします。

また、変更を実施する中で万が一のトラブルが発生した場合に現場の混乱を避けることも重要です。変更計画・実施・実行の担当者、想定外の事態が発生した時のリカバリ計画、指揮系統などを明らかにしておきましょう。

管理対象となる変更

変更と一口にいっても、ITサービスの何を変更するのかによって大きく3つに分類できます。

なお、ITサービスに影響を及ぼす可能性が低く、変更プロセスが確立しているルーティン作業は変更管理対象として管理しません。具体的には以下のような作業が挙げられます。

・プリンタのトナーやドラムを交換する

・セキュリティソフトのパターンファイル更新

ITILでの変更管理

このように、一口に変更管理といっても、意外にやることが多くあります。闇雲にやっても効果を出すどころかかえって手間になってしまうことも。そのため、ITILのようなベストプラクティスとなるものを参考に運用を構築する必要性が出てきます。

ITI.(Informatio.Technolog.Infrastructur.Library)とは情報システムの運営管理における成功事例を集めた教科書です。ITサービスのマネジメント規格であるISO/IE.20000のベースとなる知識体系となります。

ITILでは管理するのはサービスの企画・構築・運用のシステムライフサイクルに関わる5つのカテゴリです。変更管理はITサービスの立ち上げ・移行に関わる「サービス・トランジション」に該当し、中でも重要なプラクティスとして定義されています。

ここからは、ITILにおける変更管理の考え方を、4つの段階で解説します。

変更管理の流れ 1.変更要求

何を変更するのかを明確にするためのプロセスです。RFC（Reques.Fo.Change:変更要求書）として以下のような変更内容を起票します。

・変更提案者

・変更内容

・変更理由

・変更計画（スケジュールや変更手順、担当メンバー、予算など）

・変更による定性・定量効果

・変更しなかった場合の影響

なお、変更が発生する都度RFCの検討内容が変更となっては非効率であり、重大な不備を見逃し変更による混乱を引き起こす恐れがあります。共通のフォーマットを設定して、すべての変更要求を統一的に記録・管理することが重要です。

変更管理の流れ 2.評価と計画

RFCで記載した内容を元に、以下の内容を収集・評価した上で具体的な計画に落とし込みます。

・優先度、重要度、緊急度

・スケジュール

・変更実施プラン

・変更のリソース（ヒト・モノ・カネ）

・インパクト（影響範囲・影響期間など）

・トラブル発生時の対処方法

変更評価・計画にあたっては、技術的な観点だけでなく、業務・ビジネスへの影響など様々な観点から多角的に検証が重要です。適切な判断ができるように複数の部門から担当者を集めて助言するCAB（chang.advisor.boar..変更諮問委員会）を設置することもあります。

変更管理の流れ 3.承認

RFCや前述した評価内容を元に変更を承認するプロセスです。承認にあたっては以下の観点から評価します。

・財務:予算内での変更が可能かどうか

・技術:実現可能な変更、かつ利用者に不適切な影響を与えることなく変更できるかどうか

・事業:前述した2つが承認済みで、ビジネス的にも影響なく実行可能かどうか

また、承認のプロセスや承認者は、変更の種類やレベルによって異なります。あらかじめ「誰に承認を取るのか」、「どのような判断基準で承認するのか」などを明確にしておくことが重要です。

変更管理の流れ 4.実施・レビュー

承認された変更を実施し、実施結果をレビューするプロセスです。計画通りに変更作業を進めていき、万が一のトラブルが発生した場合も事前に明確にした計画に沿って対応します。

レビューについては、予定していた変更がすべて完了しているかどうか、期待していた結果が得られたかどうかを検証します。

変更管理の種類

変更管理の手順を理解したところで、変更管理の種類についても見ていきましょう。ITILでは変更のインパクト、大きさによって変更を3つのタイプに分類しています。

1.標準変更

繰り返し変更作業が行われている定型的な変更で、変更の手順がドキュメント化され承認済みの変更です。例えばハードウェアのメモリやストレージ追加、ルーター交換などが標準変更に該当します。変更に伴うリスクが低いため、リスク評価・承認プロセスを省略するなど最低限の変更プロセスで実施可能です。

2.緊急変更

重大トラブルを解決させるための対策やセキュリティに関わるパッチ適用など、迅速に導入すべき変更です。業務・ビジネスなどへの影響も大きく、変更に関わる担当者・承認者での混乱を引き起こすため、そもそも緊急変更が発生させないようにすることも重要です。

3.通常変更

通常変更は標準化された変更手順がなく未承認、かつ緊急ではない変更です。事前に定義された変更プロセスに則って変更計画・承認・実行の作業を進めていきます。

どの変更タイプに該当するかは固定ではありません。例えば、通常変更で実施している変更が頻繁に発生するため、「どうやって変更するのか」といった変更手順まで明文化した場合、変更に伴うリスクが低下するので、標準変更に変更できます。

【補足】変更モデル

変更モデルとは変更を実施するためのプロセスやフローを定義したものです。例えば、通常変更では変更要求⇒計画評価⇒承認⇒実施・レビューの4プロセスを実施するモデルを定義し、標準変更では計画評価を省略した変更要求⇒承認⇒実施・レビューのモデルを使います。

変更タイプごとに1変更モデルというルールではないので、変更内容などを元にモデルを作ることもできます。

変更管理とリリース管理の違い

ITILには変更管理と同じような概念で「リリース管理」も定義されています。リリース管理とはITサービス品質を一定に保つことを目的として、本番環境への変更に注目しコントロールするプロセスです。変更起票から本番環境への適用までの全体フローを管理するのが変更管理なので、リリース管理とは目的や管理対象となる作業が異なります。

変更を行う際は変更管理のプロセスに沿って承認を得た上で、本番環境への変更する段でリリース管理のプロセスを適用します。変更管理とリリース管理は扱う範囲が重なる部分もあるので一緒にされることもありますが、それぞれの目的を意識しプロジェクトマネジメントを進めることが重要です。

ITIL標準プロセスを参考に変更管理を実施しよう

ITサービス運用に欠かせない概念である変更管理は、業務上に取り入れているもの何となく実施されていることも多いです。稼働中のITサービスへの影響を考えると重要、かつ奥の深いプロセスなので、ベストプラクティスを集めたITILの考え方を参考に自社の変更管理プロセスを見直してみましょう。