HP OpenView News 【40-03】
続・アポロ13とITIL -3-

物語では、アポロ13の酸素タンクが爆発し、燃料電池稼動に必要な酸素が失われ、宇宙船内のコンピュータや宇宙船制御用機器、暖房用ヒータ、無線機器等が使えない状況に陥り、それだけではなく、宇宙船に乗り込んだ3人の呼吸の為の酸素さえも足りないような危機的な事態に追い込まれます。地上の管制官やエンジニア達は必死に緊急解決策を考え、次々と発生する困難に立ち向かっていきます。この地上での全ての作業を指揮しているのが、白いベストをまとった地上管制の責任者です。ITILで言うところのインシデントマネージャにあたります。映画では、彼の「絶対に諦めない」という強い意思が全ての管制官とエンジニアに伝わり、一致団結して困難に立ち向かっていきます。
例えば、ITの基幹システムに重大障害が発生した時に、出来ることなら彼のようにかっこよく組織を管理してみたいと思うのは私だけでしょうか?

さて、物語を観ているとこんな場面があります。地球に3人を無事に帰還させることが非常に難しい状況であり、無事に帰還する確率が非常に低いと予想されている時点で、アメリカ大統領に対してどのように報告したら良いかと議論が行われる場面です。議論しているのは、白いベストをまとった彼の上司にあたるポジションにいる、アポロ13の計画遂行に責任をもつと思われる2〜3人です。アポロ13の計画遂行に責任を持つ者が、白いベストの彼に対して質問をします。

「3人の宇宙飛行士が無事地球に帰還する確率は何％程度か？」

この質問に対して、彼は丁寧に答えることはせずに「絶対に3人を無事に地球に帰してみせる、彼らは絶対に帰ってくる」と少々感情的に答えます。結局、アポロ13計画遂行責任者達は、大統領に対して宇宙飛行士達が無事に帰還する確率を、自分たちだけで勝手に想定した適当な数値で報告することにするのです。

白いベストの彼には、時間をかけて丁寧に大統領にわかるように説明している余裕がありません。つまり、次々と発生する難題を緊急避難的に解決することで頭がパンクする状態だったと推測できます。

さて、ここで重要なのは、このアポロ13の危機的状況の中で、アメリカ大統領は、このある意味いい加減な情報を伴ったステータスのアップデートに満足したでしょうか？ たぶん答えはNOですね。

アメリカ大統領はアポロ計画の最高の責任者であり、冷戦の時代においてアポロ計画を成功させアメリカ国家の威信を保ち、人々の目をベトナム戦争から平和の希望であるアポロ13へ向けさせると言う非常に重要な目的をもっていたはずです。アポロ13の失敗はそれらの目的達成に多大なインパクトを与えると共に、失敗した場合はアメリカ大統領として、国民やマスコミといった世論からの非難への対策などを行う必要があるため、万が一の場合に備えて大統領としてはできるだけ正確に状況を掴んでおく必要があったと考えられます。従って、単なる気合で「全員無事に帰す」ということでは何の役にも立たない情報だったと言えるでしょう。

ITのビジネスアプリケーション、特に会社のロジスティックに関わる基幹システムを想定してみましょう。重大なインシデント（障害）が発生し、インシデントの根本原因がつかめず、システムの復旧にはかなりの時間を要すことが予想されます。また、緊急避難的にビジネスを復旧させるワークアラウンドもなかなか見つからない状況だとしましょう。読者が仮にインシデント管理マネージャの役割を演じていたならば、システムに詳しい人材をかき集めながら、必死になってシステムの復旧とワークアラウンドを探し出すことになるはずです。基幹システムのビジネスオーナ、例えばロジスティックのマネジメントに対して、タイムリーに的確にインシデントの状況をアップデートしている余裕は無いかもしれませんね。
しかし、アポロ13の報告を待つアメリカ大統領同様、ロジスティックのマネジメントは、システムが何時間程度復旧しないのであれば、どの時点でBCP（事業継続プラン）を発動しなければならないかなどの準備に、迅速に取り掛かる為の指示を出さなくてはなりません。場合によっては、顧客に対して、出来るだけ的確な連絡もしなければならないでしょう。それらの判断をする為にはビジネスの言葉（IT専門用語の羅列ではなく）で的確に情報をアップデートされる必要があるわけです。

さて、ここからITILに戻ります。
ITILでは、サービスデスクの機能として、70%から80%の一次解決率を目指すべきだと考えられています。
普段、社内ユーザや顧客からのインシデント等は、まずはサービスデスクに入ります。サービスデスクでは要員のトレーニングやナレッジデータベースを整備する等の準備がされているため、それらのインシデント等にはすぐに対応が可能であり、その時点で大体の解決がされる場合が多いと思われます。
つまり、実はサービスデスクで行う作業には、本来インシデント管理が行うべきプロセスが多く含まれていると言うことができます。

ということであれば、責任者であるサービスデスクマネージャとインシデントマネージャとを兼任させてしまえば一石二鳥では無いかと誰もが思いつくのですが・・・。

サービスデスクの重要な役割は、社内ユーザと顧客に対してSPOC（Single Point of Contact）、即ち、問い合わせやインシデントがあった場合に社内ユーザと顧客に対して最後まで責任を持つと言うものです。仮に、サービスデスクで解決できなかった場合においても、どのような状況であるのか社内ユーザや顧客に対する責任ある窓口として、タイムリーに情報を提供しなければなりません。そうすることによってビジネス上発生するかもしれない負のインパクトを最小限に止め、社内ユーザや顧客の満足度を向上させることができます。
これに対して、インシデント管理では一刻も早くビジネスを復旧することに重点が置かれなければなりません。そこで、ITILでは、サービスデスクの責任者とインシデント管理の責任者は兼任しないほうが良いと記述しています。インシデントを解決する為に大忙しの時には、社内ユーザや顧客に対してタイムリーにしかもビジネス側の人にわかりやすく説明している余裕がインシデント管理の責任者にはないからと言う理由からです。前述したアポロ13の物語でもその通りだったわけですね。読者も是非参考になさってみて下さい。
サービスデスクとインシデント管理の関係以外にも、変更管理の責任者はあまりIT技術に詳しくない方が良いとされています。なぜなら、IT技術に詳しい人は技術的な話に入り込みやすく、CAB（変更諮問委員会）を通じてビジネス側の責任者とビジネスの観点でコミュニケーションをするには適切ではないかもしれないからです。

ただ、ITILは、必ずそのようにしなければならないと言うものではありません。現実的に1人しか適当な人材がいないのであればサービスデスクとインシデント管理の責任者を兼任させるしか無いわけです。しかし、社内ユーザや顧客に対するコミュニケーションがおろそかになるかも知れないことを予めITILから学んで理解しておけば、この問題は解決することが出来るのではないでしょうか。

現状に何かしら問題意識を持ってITILを考えると大変参考になりますし、ほんの少しの、しかし大変重要な改善のヒントを得ることが出来ます。皆さんも是非ITILを利用してみてください。

さて、今まで色々な切り口からITILの有効性、有用性について語ってきましたが、そもそもITILは何のために実践するのか、何のために取り組んでいるのかということをお考えになったことはありませんか？
ITIL実践は単純にIT運用の効率化のみが目的ではありません！

次回は、ビジネス戦略をサポートするためのITILについてご紹介します。
お楽しみに。