ITIL NaviITガバナンス/運用管理のワンストップ情報コーナー

用語集

変更管理

2010年03月05日

変更管理とは、ITサービスへの変更を、変更作業に伴うリスクを最小限に抑えながら、効果的・効率的に実現するためのIT運用管理プロセスです。IT運用管理プロセスの中でも最も重要なプロセスの1つです。その目的は主に以下に示す3つです。

【変更管理の目的】

  • 変更履歴を残すため(障害の原因追跡手段の確保や改善のためのインプットの入手)
  • ITサービス利用者への影響を必要最小限に抑えるため(変更の対象となるITサービスのみならず、変更対象外のITサービスのダウンタイムを最小限に抑えるため)
  • 既に適切に導入されているコントロールを維持するため
なお、ここで言う「変更」とはITサービスに影響を与える可能性のある変更の全てを指します。したがって、たとえば、バッチジョブのスケジュール変更や、アクセス権限の変更、OSの変更、ソフトウエアへのパッチ適用、ハードウエア設定などの変更が含まれます。

変更管理の導入でおさえるべき5つのポイント

「変更管理」の導入では、以下の点について自社の特性を考慮しながらルール化を進めていくことが必要になります。
  • アセスメントはどうするのか?
  • 承認はどうするのか?
  • 実装はどうするのか?
  • レビューはどうするのか?
  • 緊急事態における変更はどうするのか?
「アセスメントはどうするのか?」とは、変更がITサービスにもたらす効果やリスク、リスクが健在化しないための予防策、不幸にもリスクが健在化してしまった際の対処策など、どのような要素に基づいて誰がどうやって変更の妥当性について評価を行うのか、ということです。

「承認はどうするのか?」とは、誰からのどのような申請に基づいて、誰がどのような判断基準で、変更実施を許可するのか、ということです。

「実装はどうするのか?」とは、変更の承認がおりた変更内容について、誰がどのような手続きで、実際に変更を行うのか?ということです。

「レビューはどうするのか?」とは、変更した結果について、その変更した内容が当初の予定通りに行われているかどうか(検証)や、変更した結果もたらされた効果が期待していたものと同じであったかどうか(有効性の確認)といったことを、誰がどのように行うのか?ということです。

「緊急事態における変更はどうするのか?」とは、システムダウンによりお客様に明らかに迷惑がかかっている際のインシデント対応など、対応のスピードが要求される場面においての手続き(例:申請手続きの簡素化を許可する)ということです。

リリース管理との違いは、変更の対象

変更管理と混同されがちなリリース管理は、ともに”何らかの変更を加える”という点では同じですが、その対象が異なります。前者が「ITサービスに影響をあたえる可能性のある全ての変更」を対象としているのに対し、リリース管理では「本番環境への変更」を対象としています。言い換えると、リリース管理は「ソフトウエア(およびそれに伴うハードウェアや新しいマニュアルなどについて)の本番環境への移行」を前提とした際の手続きについて定めるプロセスであるということができます。

つまり、どのような場合でもITサービスへ何らかの変更を加える場合には、まずは「変更管理」にもとづく変更の承認を受ける必要がありますが、さらにこの変更が本番環境への変更を伴う場合に関しては、その具体的な進め方について「リリース管理」に基づく準備作業や移行作業、文書化作業などを行う必要があります。

様々な規格に登場する「変更管理」

変更管理は、「ITガバナンス」、「ITの運用管理」、「情報セキュリティ」のいずれの考え方においても極めて重要なコントロールとして位置づけられています。

以下に、代表的な規格における変更管理の位置づけについて挙げておきます。
ISO/IEC ISO27001-1:2005 付属書Aの10.1.2(運用上の変更管理;インフラや運用手順、システム設定などの変更)、Aの10.5.1(業務用ソフトウェアの変更管理)
ISO/IEC ISO20000-1:2005 9.2「変更管理」
ITIL Ver3 サービストランジションの主要プロセスの1つとして言及
COBIT4.1 調達と導入におけるAI6にて言及

(文責:工藤 秀義