インシデントの原因は変更管理の不備にある：ITIL Managerの視点から（2/2 ページ）

[谷誠之，ITmedia]

正解は「必要」

画面1：RFCのサンプル（クリックで拡大）

　筆者は、壊れたプリンタを修理するためにもRFCの提出が必要だと考えている。なぜか？　それに答える前に、そもそもなぜRFCを作成するのか、その目的を明確にしておきたい。RFC作成の主な目的は、次の通りである。

• 誰がどのような理由でどんな変更を要求しているのかを明らかにする
• 変更を実行することによって発生する（正／負両方の）インパクトを明確にする
• 変更を実行しないことによって発生する（主に負の）インパクトを明確にする
• 変更によって発生するコストを明確にし、ビジネスに対して正当化する
• 似ている変更要求をひとつにまとめ、一度に変更することでリスクとコストを抑える

　壊れたプリンタを現場の判断で（RFCを提出せずに）修理したとしたら、ひょっとしたらコスト的にもビジネス的にも負の要因が発生するかもしれないのだ。

　プリンタを修理するよりも買い換えたほうが安い、という判断がなされるかもしれない。（余談だが、先日筆者のクライアントが所有するカラーレーザープリンタが壊れた。筆者はそのクライアントの依頼で、カラーレーザープリンタを７万円で入手した。もちろん新品である。ただし最新機種ではなかった。お客様のニーズを検討すると、最新機種でなくてもよい、と判断したのだ。一方、そのお客様の壊れたプリンタを修理するためにメーカーに問い合わせたところ、やはり７万円必要だ、という見積りが出ていたのである。）あるいは、壊れたプリンタはモノクロプリンタで、他部署からカラープリンタを購入するRFCが提出されており、モノクロプリンタと置き換える予定だったのかもしれない。もしそうなら、壊れたプリンタを修理したのは無駄だった、と判断されることになるかもしれない。

　上記のような理由から、すべての変更（サービス要求は除く）においてRFCを提出し、変更マネジャー（情報システム部門）がすべての変更要求を把握しておくようにすることが重要である。

　さて、RFCにはどのような内容が盛り込まれている必要があるのだろうか。RFCに含まれる代表的な項目は次の通りである。

• RFC番号
• 変更の提案者
• 変更が提案された日付
• 変更されるITインフラの内容
• 変更の理由
• 変更を導入しない場合の影響
• 変更の期限
• 変更の優先度、重要度
• 変更にかかる工数や費用
• 変更に伴う想定されるリスク
• 現在のRFCのステータス
• 承認者、承認日付

　以下にRFCのサンプルを示しておく（画面1）。筆者の経験上、RFCは紙で回すほうがよい。最初の起票は電子的に行う（Excelなど）としても、提出時にはそれを印刷することを推奨する。RFCには検討の段階で追加の情報が書き込まれたり、複数の似たRFCがまとめられたりする。そのような場合は、何かと紙のほうが扱いやすいのだ。どれだけオンライン化が進んでも、紙という媒体は絶対になくならないだろう。

　次回はCAB（変更諮問委員会）について説明する。RFCを検討するための会議体のことである。生身の人間が関係するだけあって、なかなか奥が深いのだ。

谷 誠之（たに ともゆき）

IT技術教育、対人能力育成教育のスペシャリストとして約20年に渡り活動中。テクニカルエンジニア（システム管理）、MCSE、ITIL Manager、COBIT Foundation、話しことば協会認定講師、交流分析士1級などの資格や認定を持つ。なおITIL Manager有資格者は国内に約200名のみ。「ITと人材はビジネスの両輪である」が持論。ブログ→谷誠之の「カラスは白いかもしれない」