変更管理の目標は何かシステム管理入門(4)(1/2 ページ)

利用者の現場レベルでの変更も含めて、システム担当者はITインフラの変更すべてを把握する必要があるが、実際には極めて難しい。どうすればいいのだろうか。

» 2010年07月06日 12時00分 公開

この記事は会員限定です。会員登録すると全てご覧いただけます。

 今回は、「変更管理」という概念についてお話します。

 これまで「インシデント管理」、「問題管理」について紹介し、双方とも、主人公は業務、あるいはその業務を遂行している人だと説明しました。決してITは主人公ではありません。極端に言えば、業務に必要とされていないITは存在価値がないのです(例えば、ウルトラマンがどんなに格好良く強くても、怪獣のいない世界であればあれほどまでの大役はなかったはずです)。

 インシデント管理や問題管理の活動の中では、しばしばITシステムの変更が伴います。その変更依頼は、インシデント管理からも、問題管理からも提出されます。具体的には、大きく「ハードウェアの変更」「ソフトウェアの変更」「人の変更」があります。

ハードウェアの変更

 1. 新しいハードウェアの追加導入

 2. 既存のハードウェアの拡張(オプション製品の導入など)

 3. ハードウェアの買い増し

 4. 壊れたハードウェアの修理

 5. 既存のハードウェアを新しいハードウェアに置き換え

 6. ハードウェアの廃棄


ソフトウェアの変更

 1. 新しいソフトウェアの導入

 2. ソフトウェアのバージョンアップ

 3. ソフトウェアの更新(パッチ当て)

 4. 既存のソフトウェアへのオプションプログラムの導入

 5. ソフトウェアの置き換え

 6. ソフトウェアの廃棄


人の変更

 1. 新しいプロセス(手順や仕組み)の導入

 2. 担当者の変更(人そのものの変更)

 3. 役割の変更(人は変わらず、役割分担だけが変わる)

 4. プロセスや手順の変更

 5. ある特定の役割の廃止

 6. プロセスや手順全体の廃止


 上記は変更の代表例です。読者の方々が経験したことのある変更の多くは上記に当てはまるでしょう。ただし、ここでは定常的なプロセスが確立された変更は扱いません。例えば、「プリンタのトナーやドラムを新しいものに交換する」とか「ウイルス対策ソフトのパターンファイルを更新する」といったものです。

 インシデント管理や問題管理以外の原因で変更が起きる可能性もあります。例えば、ITインフラを変更することでコスト削減につながる、ある製品のメーカーサポートが終了したため使い続けることがリスクにつながる、といった場合です。これら、人も含めたITインフラストラクチャの変更はすべて、「変更管理」によって管理する必要があります。では、なぜ変更管理が必要なのでしょうか。

負の影響を避けることが目標

 変更管理の最終目標は、ITILで次のように記されています。

「すべての変更を効率的かつ迅速に取り使うために、標準化された方法、手順が使われることを確実にすることと、それによって変更に起因するインシデントがサービス品質に与える影響を最小限にし、組織の日々の運用を改善すること」(ITIL v2)

「顧客の変化する事業要件に対応すると同時に、価値を最大化し、インシデント、中断、手直しを削減すること、およびサービスとビジネスニーズを整合させるような、事業と IT の変更要求に対応すること」(ITIL v3)

 ITIL v3では、より事業寄りの表記になっていますが、根本は同じです。一言で表すと、変更管理の目標は、変更が原因で業務に負の影響が起きるのを避けるということです。言い換えれば、変更管理は「変更を管理する」のではなく、「変更がもたらす影響を管理する」ことなのです。

 ITILを深く読み込むと、変更管理には厄介なことが書かれています。まず、(軽微な変更、標準化された手順が確立している変更を除いて)すべての変更は変更管理プロセスを通さなければなりません。現場での勝手な変更は許されません。変更プロセスは、変更管理プロセスに変更要求(RFC:Request For Change)を提出して始まります。

 また、その変更が妥当なものか、ほかに類似の変更要求はないか、変更をいつ、どのように行えばいいかといったことを決める変更諮問委員会(CAB:Change Advisory Board)を召集するなどの対策が重要です。このようなしっかりしたプロセスを確立するのが理想ですが、いきなりそんなことを言われても困りますよね。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ