筆者は、壊れたプリンタを修理するためにもRFCの提出が必要だと考えている。なぜか? それに答える前に、そもそもなぜRFCを作成するのか、その目的を明確にしておきたい。RFC作成の主な目的は、次の通りである。
壊れたプリンタを現場の判断で(RFCを提出せずに)修理したとしたら、ひょっとしたらコスト的にもビジネス的にも負の要因が発生するかもしれないのだ。
プリンタを修理するよりも買い換えたほうが安い、という判断がなされるかもしれない。(余談だが、先日筆者のクライアントが所有するカラーレーザープリンタが壊れた。筆者はそのクライアントの依頼で、カラーレーザープリンタを7万円で入手した。もちろん新品である。ただし最新機種ではなかった。お客様のニーズを検討すると、最新機種でなくてもよい、と判断したのだ。一方、そのお客様の壊れたプリンタを修理するためにメーカーに問い合わせたところ、やはり7万円必要だ、という見積りが出ていたのである。)あるいは、壊れたプリンタはモノクロプリンタで、他部署からカラープリンタを購入するRFCが提出されており、モノクロプリンタと置き換える予定だったのかもしれない。もしそうなら、壊れたプリンタを修理したのは無駄だった、と判断されることになるかもしれない。
上記のような理由から、すべての変更(サービス要求は除く)においてRFCを提出し、変更マネジャー(情報システム部門)がすべての変更要求を把握しておくようにすることが重要である。
さて、RFCにはどのような内容が盛り込まれている必要があるのだろうか。RFCに含まれる代表的な項目は次の通りである。
以下にRFCのサンプルを示しておく(画面1)。筆者の経験上、RFCは紙で回すほうがよい。最初の起票は電子的に行う(Excelなど)としても、提出時にはそれを印刷することを推奨する。RFCには検討の段階で追加の情報が書き込まれたり、複数の似たRFCがまとめられたりする。そのような場合は、何かと紙のほうが扱いやすいのだ。どれだけオンライン化が進んでも、紙という媒体は絶対になくならないだろう。
次回はCAB(変更諮問委員会)について説明する。RFCを検討するための会議体のことである。生身の人間が関係するだけあって、なかなか奥が深いのだ。
谷 誠之(たに ともゆき)
IT技術教育、対人能力育成教育のスペシャリストとして約20年に渡り活動中。テクニカルエンジニア(システム管理)、MCSE、ITIL Manager、COBIT Foundation、話しことば協会認定講師、交流分析士1級などの資格や認定を持つ。なおITIL Manager有資格者は国内に約200名のみ。「ITと人材はビジネスの両輪である」が持論。ブログ→谷誠之の「カラスは白いかもしれない」
Copyright © ITmedia, Inc. All Rights Reserved.