ITサービスの変更管理の目的と活動内容を解説

変更管理は、システム改修などITサービスの変更を、計画・実行・評価してリスクを最小化するプロセスです。
本書は変更管理の目的と進め方を、実際の作成資料の例も使いながら説明します。

変更管理とは

変更管理は、ITの変更を安全に実施するためのルールや手順のことです。

変更管理は次のようなソフトウエアやハードウエアの変更、SLAの見直し、バッチのスケジューリング変更などに適用されます。

変更管理の目的

ITILでは、変更管理の目的を「変更によるリスクを最小限に抑えつつ、サービス品質を維持しながら、有益な変更を円滑に実施すること」と述べています。

変更管理の例

サーバーのOSアップグレード
データベースのバージョン更新
ソフトウエアの新機能の追加や、バグ修正のリリース、パッチ適用
ネットワーク構成の変更、ストレージ容量の拡張
ファイアウォールのルール変更
サービス提供時間の変更、SLAの見直し、運用手順変更
バッチサービススケーリングの設定変更

変更管理プロセスがスタートするきっかけ

変更管理は問題管理からの問題に対する恒久対応（ソフトウエアの修正など）や、サービス要求管理からの要求対応（機能の追加など）、継続的改善（運用効率向上など）がきっかけでスタートします。

これらのプロセスがRFC（Request for Change：変更要求）提出し、それを受け付けするところから変更管理がスタートします。
RFCとは、変更の内容を記述した依頼書や申請書です。（詳細はこの後で説明）

システムやサービスに手を加えるときには、ちゃんと計画して、安全に、問題が起きないように進める”ためのものということになります。

変更管理の活動内容

変更管理はRFCを受付して①記録と分類、②アセスメント・承認、③実装、④レビューの順で実施します。

各活動内容の詳細について説明します。

①記録と分類

■記録

RFCの内容を記録します。

■分類

変更の内容に応じてを分類します。
分類は次の3つがあります。

標準変更・・・事前承認されている変更（定期的なパッチ適用など）
緊急変更・・・予期していない変更で、即時対応が必要な高リスク変更（悪意のある攻撃を受けた時の対応など）
通常変更・・・緊急性はないが審査・承認が必要な変更。

この分類により、（承認や対応の方法）が変わります。

②アセスメント(評価)・承認

アセスメントでは変更をすることによる影響、利益、リスクなどを評価します。

■CABについて
変更管理のアセスメント・承認では、CAB(変更諮問委員会)という専門部隊から助言を受けたり、承認を得ながら進めます。
CABは、顧客、サービスデスク、アプリケーション設計者、インフラ担当者などからの代表者で構成されます。

評価をするにあたり、具体的な例を提示します。

順番	評価・確認項目	主な招集者	実施内容
1	業務影響	業務担当者	変更をすることで業務に支障がでないかを確認します。変更後の業務フローや画面のイメージを使って確認するとスムーズに進みます。変更ボリュームが大きい場合、要件定義から進めていきます。
2	技術的な影響	設計者（ソフトウエアの場合）インフラ担当者（ハードウエアの場合）	変更による影響はないか（他のプログラムへの影響やパフォーマンス低下）を確認します。構成アイテム(CI)がある場合、これを使って他への影響を確認します。可能であればテスト環境を使っての検証をすると安全です。
3	他システムへの影響	他システム担当者	他システム担当者へ変更内容を説明して、影響有無を確認します。影響が出る場合は対応内容や費用の提示を依頼して、再度内容を確認します。
4	リソース評価	設計者（ソフトウエアの場合）インフラ担当者（ハードウエアの場合）顧客(オーナー)	＜ソフトウエアの修正の場合＞変更を実行するために必要な工数を見積もります。 ※過去の類似したプロジェクト実績があればそれを参考にすると良いです。算出した工数から、現在の技術要員で対応可能かと、要員を考慮したスケジュールを作成します。＜ハードウエアの場合＞ハードウエアの変更に対するする工数、既存のハードウエア構成でキャパシティ面で問題はないか確認します。
5	投資対効果	顧客(オーナー)	変更にかかるコストと、期待される成果を比較・評価します。変更実施による投資効果（ROI）を評価します。
6	リスク対応策	設計者（ソフトウエアの場合）インフラ担当者（ハードウエアの場合）	これまで出たリスクに対して、回避、軽減、移転、受け入れの対応策を決定し、実行する。

１と２の影響確認は構成管理から推測できるようにしておくと良いです。

4の「リソース」ではスケジュールを作成し、他作業のスケジュール調整案を作成して検討します。

③実装

実装では設計やプログラミング、ハードウエアの調達や入れ替えが行われます。

変更管理の役割としては、その変更を適切に実行するための管理と監視が中心となります。
具体的には、変更がどのように実施されるかを確認し、計画通りに進行しているかを追跡します。

実際の設計やプログラミングそしてリリースなどの作業は、「サービス設計と移行」、「リリース管理」プロセスの範疇です。

■構成管理データベースへの反映
変更内容をソフトウエア(プログラム)やインフラに適用する際、構成管理データベース（CMDB）の構成アイテム（CI）の変更が必要になります。

④レビュー

変更リクエストで使用したすべての文書データ、変更ログ、話し合いの内容のまとめなどを今後もアクセス可能な共有スペースに保存します。
具体的には次のような活動が行われます。

名称	実施内容
変更の結果確認	変更が意図した通りに機能しているか、目的を達成しているかを確認します。
品質の確認	エラーや不具合がないかを確認します。計画通りに進められたかを確認します。