インシデントの原因は変更管理の不備にある:ITIL Managerの視点から(2/2 ページ)
ビジネスに影響を与えるインシデントのうち、実に90%が、情報システム部などが把握していない「勝手な変更管理」が原因だという。つまり変更管理プロセスをうまく回せば、インシデント発生を防げるということだ。
正解は「必要」
筆者は、壊れたプリンタを修理するためにもRFCの提出が必要だと考えている。なぜか? それに答える前に、そもそもなぜRFCを作成するのか、その目的を明確にしておきたい。RFC作成の主な目的は、次の通りである。
- 誰がどのような理由でどんな変更を要求しているのかを明らかにする
- 変更を実行することによって発生する(正/負両方の)インパクトを明確にする
- 変更を実行しないことによって発生する(主に負の)インパクトを明確にする
- 変更によって発生するコストを明確にし、ビジネスに対して正当化する
- 似ている変更要求をひとつにまとめ、一度に変更することでリスクとコストを抑える
壊れたプリンタを現場の判断で(RFCを提出せずに)修理したとしたら、ひょっとしたらコスト的にもビジネス的にも負の要因が発生するかもしれないのだ。
プリンタを修理するよりも買い換えたほうが安い、という判断がなされるかもしれない。(余談だが、先日筆者のクライアントが所有するカラーレーザープリンタが壊れた。筆者はそのクライアントの依頼で、カラーレーザープリンタを7万円で入手した。もちろん新品である。ただし最新機種ではなかった。お客様のニーズを検討すると、最新機種でなくてもよい、と判断したのだ。一方、そのお客様の壊れたプリンタを修理するためにメーカーに問い合わせたところ、やはり7万円必要だ、という見積りが出ていたのである。)あるいは、壊れたプリンタはモノクロプリンタで、他部署からカラープリンタを購入する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と人材はビジネスの両輪である」が持論。ブログ→谷誠之の「カラスは白いかもしれない」
関連記事
- サービス可用性――その評価手法を知っているか?
「可用性の向上」とはよく聞く標語だが、その基準は意外と知られていない。ただの掛け声に終わらないよう、その評価手法を紹介する。 - 確率論を究める――交通事故とシステムダウンの関係
今回は、可用性を高めるために先人が残した分析手法を紹介する。温故知新という言葉もある。昔から色々と研究され、編み出された手法を使わせてもらうのは非常に有効な手段である。 - 究極の選択――落ちないシステムとすぐ直るシステム
MTTR(平均修理時間)が短いシステムとMTBF(平均故障間隔)が長いシステム、あなたならどちらを選択するだろうか。システム管理者にとっての究極の選択である――。 - 初めてのサービスレベルアグリーメント【その3】
SLAを支援する文書として、OLA(Operational Level Agreement)およびUC(Underpinning Contract)を紹介する。 - 初めてのサービスレベルアグリーメント【その2】
連載初回では、SLAの意義や作成手順について述べた。今回は、SLAの具体的な中身を解説する。 - 初めてのサービスレベルアグリーメント
企業のIT担当者ならば、「サービスマネジメント」というコトバに聞き覚えがあるだろう。要は効率の良い、費用対効果の高いシステム管理のことであるが、ITがビジネスの根幹になって以来、未解決の課題となっており、多くのIT担当者がその実現に悩んでいるのだ。 - ITガバナンスを定義してみる
- ITILの成り立ちと現状を知る
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.