連載コラム

知らないでは許されない
ITILでシステムの効率化を目指そう

2005年8月11日　　協力●東芝ソリューション

第2回
「そのパッチ、当てる前に考えよう」～システムを安定させる変更管理～（2/3）

ステップ2　有識者により変更のインパクトを評価する

　次に、RFCの評価を行ないます。変更には必ずリスクがつきまといますので、変更をいつ、どのように行なうかは重要です。技術的にはささいな内容でも、業務への影響が大きいと判断されれば「変更を行なわない」という判断もあります。

　たとえば受発注システムが動いているサーバに、小さなパッチを当てたいとします。そのパッチはすでに他のサーバには何台も当てられていて、何の問題も起きないことがわかっていても、それが月末の月次処理の期間であれば、業務担当者からは「今はやめてくれ」といわれるはずです。このように単に技術的な要件を満たすだけでなく、業務への影響を勘案するのが変更管理者の重要な役割です。

　また、システムが複雑に関連している場合には、ネットワークやサーバそれぞれの専門家に意見を求めたくなるかもしれません。ITILでは各RFCについて、エンドユーザー、技術エキスパート、サポート部門などの代表がそれぞれの立場から内容を評価し、承認を与える方法を推奨しています。この承認を与えるチームのことを「CAB（Change Advisory Board：変更諮問委員会）」と呼んでいます。「委員会」というと非常に大袈裟な感じがしますが、必ずしも多くの人数でスケジュール調整しなければいけないという訳ではありません。転入者用に標準PCを新規に設置するといった定型的な作業の場合には、RFCの発行だけで特にCABの承認は必要ないでしょう。

　事例ではアウトソース先の運用会社で、この事前のインパクト評価がきちんとできていないようです。そのため、CABを設置するよう申し入れてみるのがよい方法でしょう。そうすればMさんもユーザーの立場からCABに参加し、変更後の確認事項や失敗した場合のプランがきちんと立てられているかをチェックできます。


変更要求書フォームには担当者や依頼先のほか、1.対象機器、2.変更内容、3.変更理由等を記入する欄を設ける。また、承認・レビューのため、4.変更の優先度、5.変更を行なわない場合の影響、6.承認者、7.レビュー等の記入欄もほしいところだ（画像クリックで拡大）