
ITサービスを運用する際は、機能改修や保守メンテナンスなど、さまざまな「変更」が発生します。変更管理とは、これらの変更によるリスクを最小限に抑えつつ、変更内容を計画的かつ安全に実施するための仕組みです。
本記事では、変更管理の目的やプロセス、よくある課題などを解説します。
変更管理とは、ITサービスやインフラストラクチャに発生するあらゆる変更を、標準化された手順に基づいて計画・評価・承認し、適切に管理するプロセスを指します。これにより、ITサービスの中断や品質低下といった影響を最小限に抑えながら、必要な変更を効率的かつ安全に進めることができます。
例えば、カスタマーサポート部門の場合、ITサービスの変更は顧客に直接的な影響をおよぼします。変更管理が適切に実施されない場合、システム障害によるサービス停止や、顧客からの問い合わせ増加、対応の遅延などにつながりかねません。その結果、顧客満足度の低下やサポート担当者の負担増大などにつながる恐れがあります。
変更管理の対象は、大きく下記の三つに分類できます。
一方で、下記の作業は変更プロセスが確立しており、ITサービスへの影響が低いことから変更管理の対象外となっています。
変更管理と混同されがちなのが「リリース管理」です。リリース管理(Release Management)とは、承認された変更を本番環境へ展開するプロセスのことです。ITサービスのテスト工程では、さまざまなテストを実施し、その結果を踏まえて変更内容を承認します。リリース管理の目的は、テスト済みの変更がサービス品質に悪影響を与えないこと、本番環境へ問題なく導入できることを保証することです。
一方で、変更管理は「変更そのものを承認し、適切に制御すること」を目的としています。つまり、下記のような役割分担になります。
変更管理の主な目的は下記の3点です。
変更管理では、変更に関わる担当者を招集し、「どのような変更が必要なのか」「なぜ変更が必要なのか」「変更による影響範囲はどこか」といった内容を事前に明確にした上で評価します。変更の計画・実施・承認の担当者や、想定外の事態が起きた際のリカバリ計画、指揮系統などをあらかじめ整理することも重要です。
ITIL(Information Technology Infrastructure Library)とは、ITサービスを効率的に運用するためのベストプラクティスをまとめた国際的なフレームワークのことです。ITILに準拠した変更管理は、下記のプロセスで進めていきます。
それぞれの内容を見ていきましょう。
ITサービスに対する変更の必要性が生じた際には「変更要求(RFC)」を提出します。RFCに記載すべき内容は下記のとおりです。
| RFCに記載すべき内容 | |
|---|---|
| 変更の目的・理由 | 変更する目的や必要性、メリット |
| 変更内容の詳細 | 何を、どのように変更するのか |
| 変更によって期待される効果 | 変更することで得られる効果 |
| 影響範囲 | 変更に関連しているサービスや部門、顧客など |
| 費用・リソース | 変更に必要な費用や人員、時間など |
| スケジュール | 変更作業を実施する際のスケジュール |
変更管理ツールを利用すれば、登録画面からこれらの項目を入力し、必要な書類を添付して送信するだけでRFCの登録作業をスムーズに進められます。
登録されたRFCは、変更諮問委員会(CAB: Change Advisory Board)によって評価されるのが一般的です。CABとは、IT部門やセキュリティ部門など、変更に関わるステークホルダーの代表者で構成された委員会のことです。主な評価ポイントは下記のとおりです。
| 評価のポイント | |
|---|---|
| 変更に伴うリスク | システムやサービスの停止、障害の大きさなどを評価する |
| コスト | 人件費や機器の購入費などの総コストを予算に照らし合わせて評価する |
| 影響範囲 | 関連システムやユーザー、業務プロセスなどを評価する |
| リソース | 必要な人的リソースやスキル、設備などを確保できるかを確認する |
CABの承認を得られなければ、次のステップに進めることができません。
続いて、下記の要素を盛り込んだ上で詳細な計画を策定していきます。
| 変更の計画に含まれる主な内容 | |
|---|---|
| 手順 | 変更を実施する際の具体的な手順 |
| テスト計画の内容 | 変更に伴う影響を確認するためのテスト項目、テストの手順 |
| 関係者への連携 | 変更スケジュールや具体的な内容、影響などを関係者にどのように連携して伝えていくか |
| ロールバックの計画 | 変更作業が失敗した際に、どのような手順で元の状態に戻すのか |
計画を策定したら、まずテスト環境で検証し、その後本番環境で実施します。
変更後のシステムやサービスを確認し、問題点や改善点を洗い出します。検証結果を踏まえて手順を見直し、より安全で効率的な変更管理プロセスへ改善する流れです。
変更管理では、下記のような課題がよく見られます。
変更管理プロセスでは、変更の可否だけでなく、実施時期や優先順位などの重要な判断も承認項目に含まれています。これらの承認を属人的な方法(メール・口頭・担当者の判断など)で行っている場合、情報共有の遅れや判断基準のばらつきが発生しやすくなるため注意が必要です。
部署や担当者によって変更管理の手法が異なると、変更のたびに異なる手順や判断基準が用いられることになります。このような状態では、作業効率が低下し、結果として時間もコストも増大するでしょう。
これらの課題を解決するためには、変更管理ツールの導入が効果的です。変更管理ツールを活用することで、承認フローの標準化や変更履歴の一元管理、関係者間の情報共有の効率化などを実現できます。これにより、属人化や手続きのばらつきを防止しながら、効率的で再現性の高い変更管理を実施できるでしょう。
今回は、変更管理の目的やプロセス、よくある課題などを解説しました。適切な変更管理を実施することで、システムトラブルの抑止や業務品質の向上につながります。ぜひ本記事を参考に、自社の変更管理体制の整備・改善に取り組んでみてください。