ITIL「変更管理」とは？リリース管理との違いやプロセスを解説

変更管理とは

変更管理とは、ITサービスを構成する要素への変更に対する業務を管理し、変更によるリスクを最小限にとどめ、ITサービスを円滑に供給するためのプロセスを言います。

変更管理における「ITサービスを構成する要素」には、ITサービスに直接または間接的な影響を与える可能性のあるハードウェア / ソフトウェア / 人が該当します。

ここでの「変更」には、ITサービスを構成する要素に対する追加や削除も含まれます。

変更管理の例

• ハードウェアの変更： OSの変更、アップデート、サーバーの増設 など
• ソフトウェアの変更：セキュリティパッチの適用 / ソフトウェアアップデートのスケジュール変更 など
• 人の変更：ITサービス担当者の変更 / 新しいマニュアルの導入 など

変更管理の目的

変更管理の目的は、変更によるITサービスへの影響やリスクを最低限に抑えることです。

「変更によるリスク」には、たとえば以下のようなものがあります。

• OSアップデートによるダウンタイムの発生
• セキュリティパッチの適用による障害発生
• マニュアルの廃止・統合による影響発生

このようなリスクを最小限にとどめるために、「変更の業務フロー」を制御するのが変更管理です。

ITILにおける変更管理

変更管理は、ITサービスのベストプラクティス「ITIL」にも重要な概念として登場します。

ここでは、1つ前のバージョンであるITILv3/2011、最新バージョンのITILv4 それぞれの変更管理についてお伝えします。

ITILv3 / ITIL2011における変更管理

ITILv3 / ITIL2011 における変更管理は、サービストランジションの主要プロセスの１つとして定義されています。変更管理は、サービス移行に区分されるプロセスです。

ITILv4における変更管理

ITILv4では、変更管理は「変更コントロール」というプラクティスとして定義されています。

「プラクティス」は、ITIL v3/2011の「プロセス」に代わり、ITILv4から導入された新しい概念です。インシデント管理 / 問題管理  / ナレッジ管理などの「プロセス」と、サービスデスクなどの「機能」が、ITILv4では「プラクティス」と表現されるようになりました。

ITILv4において、プラクティスは「業務の遂行や目的の達成のために設計された、一連の組織リソース」と定義されています。

ITILv4には34個のプラクティスがあります。ITILv4のプラクティス群は、「一般管理プラクティス」「サービス管理プラクティス」「技術管理プラクティス」の3種類に分類されています。変更コントロールは、「サービス管理プラクティス」に分類されます。

ITILにおける変更管理とリリース管理の違い

ITILでは、変更管理と混同されがちな、リリース管理という概念が登場します。

変更管理では、変更によるリスクを最小限におさえることを目的として、システムに対する変更の一連の流れをコントロールします。一方、リリース管理ではITサービスの品質を保つことを目的として、ITシステムの本番環境に加える変更をコントロールします。

どちらも「変更」に対するアプローチですが、その目的と管理対象が異なります。

変更管理において、承認された変更依頼に対してのみ、リリース管理チームは、本番環境への実装を行います。

ITIL以外における変更管理

ITIL以外の各種規定でも、ITに関する国際規格において、変更管理は重要なプロセスとして位置づけられています。

• ISO/IEC ISO27001:2014 … 情報セキュリティマネジメントシステム

A12 運用のセキュリティ- A12.1.2 変更管理

A14 システムの取得、開発及び保守 – A14.2.2システムの変更管理手順

• COBIT5…情報技術管理のベストプラクティス集

構築、調達、導入-プロセスBAI06 変更管理

ITILにおける変更管理プロセス

それでは、実際に変更管理はどのようなプロセスで実施すれば良いのでしょうか。

ここでは、ITILv4における変更管理について紹介します。

変更リクエスト

RFC（Request For Change：変更要求書）を起票し、変更管理チームに送信します。変更管理担当者は、RFCに対し、検証と承認を行います。

RFCは統一されたフォーマットを設定、以下のような項目を記載します。

• 変更提案者
• 変更の理由
• 変更の計画（メンバー、日程、方法 など）
• 変更をしなかった場合の影響

変更の評価と計画

変更管理チームは、変更の計画と評価を行います。

変更の評価と計画では、「優先度」「スケジュール」「変更実施プラン」「インパクト（影響範囲・影響期間 など）及びリソース評価（担当部門・ベンダー など）」「不具合が発生した際の巻き戻し方法」などを検討します。

変更の承認

変更管理チームは、管理者やCAB（変更諮問委員会）に対し、変更の承認を依頼します。

承認プロセスは、変更の種類によって異なります。 たとえば、ERPソリューションの交換などの大きな変更には、管理者だけでなくCABからの承認も必要です。一方、パッチ展開などの標準的な変更では、CABの承認は必要ありません。

RFCは、すべてのCABメンバーが承認した場合にのみ承認されます。 否決された場合、再評価とレビューをした後、再度CABへの承認依頼を行います。

変更の実施とレビュー

CABにより承認された変更リクエストに対し、リリース管理チームが変更を実装します。

変更が実装された後、変更管理チームは、レビューを行います。レビューでは、CABに承認された通りに変更が行われているかを確認します。

変更管理導入の3つの課題

（1）関係者や担当部門が多く、連携が大変

変更管理では、CAB（変更諮問委員会）、リリース管理チーム、開発部門や外部の関連会社など、多くの関係者と連携する必要があります。承認状況の確認や、変更に関する情報共有などの細かいプロセスをコントロールするのは大変な手間となるでしょう。

（2）影響範囲の特定が困難

変更管理では、事前に「インパクト（影響範囲や影響期間）及びリソースの評価」が必要です。変更が大規模になればなるほど、依存関係のあるシステムやIT資産を正確に特定するのは困難です。

（3）関連するドキュメントの管理が煩雑

変更管理のプロセスには、RFCの起票はもとより、計画のためのガントチャートなどさまざまなドキュメントが必要です。また、作成したドキュメントは関係者へ周知しなければなりませんし、そのバージョン管理も重要です。

サービスデスクツールが解決する変更管理プロセスの課題

変更管理プロセスの課題は、変更管理機能を備えたサービスデスクツールを活用することで解決します。

サービスデスクツールは、変更管理プロセスにおける、部門間をまたぐやり取りや承認依頼を一元化します。協力会社など、他の組織に属するメンバーへの情報共有もツール上で完結することができます。

また、多くのサービスデスクツールではCMDB（構成管理データベース）の構築が可能です。CMDBはシステム変更の影響範囲を的確に可視化します。CMDBを活用すれば、インシデント管理や、リリース管理など、他のプロセスと変更管理を連携することも可能です。

さらに、サービスデスクツールなら変更に関連するドキュメント（RFCやガントチャートなど）の作成が自動化できます。変更項目に対してドキュメントを関連付けて管理することもできますので、過去のドキュメントを参照するのも簡単です。

Freshserviceで ITIL準拠の変更管理を簡単に

Freshserviceは、ITIL準拠の変更管理を実現するサービスデスクツールです。変更管理に関するプロセスやドキュメントを一元管理し、変更管理業務をシンプルにします。

コミュニケーション機能

Freshserciveは、変更に関連するイベントの通知を自動化します。最もよく利用されるのはCABや部門担当者に対する承認依頼の自動通知設定です。CABは、外出先から変更を承認することもできます。

また、エンドユーザーに影響する変更があった場合に、お知らせメールを一斉送信するよう設定することもできます。

CMDB機能

FreshserviceはCMDBを管理・維持する機能を備えたサービスデスクツールです。組織内のITサービスを構成する要素を、自動的にスキャンし、定期的に情報を更新します。CMDB機能と変更管理プロセスを連携することももちろん可能です。シンプルな画面から、変更に伴う影響範囲を正確かつ迅速に行うことができます。変更に関連するオブジェクト同士の依存関係を、一目で把握しましょう。

ドキュメント管理機能

Freshserviceは、変更管理のドキュメント作成を簡単にします。RFCなどのフォーマットは、シンプルで自由度の高い管理画面から、自社向けにカスタマイズすることができます。プロジェクト管理機能から、変更に関するガントチャートを作成することも可能です。

最短１日で導入！ITIL準拠サービスデスクをかんたんに行えます！

無料でお試し

資料請求はこちら