ITILのメリットに気づき始めた米国企業
ITILの適用に際して注意すべきポイントを事例から探る 2006/09/27
ITサービス業務を行うための有力なプロセス・フレームワークとして、すでに欧州や日本では活用が進んでいるITIL（IT Infrastructure Library）。今やこの波は、“ITIL後進国”だった米国をも席巻しつつある。そこで、本稿では、ITILの適用に取り組む米国企業の姿を観察しながら、ITILのメリットおよびデメリット、そして実際に自らの組織にITILを適用する際のヒントについて探ってみたい。
ベン・ワーセン ● text by Ben Worthen
ITILのパワー
ミード・ウェストベーコのCIO、ジム・マッグレーン氏は、常々IT業務に標準的なプロセスが必要であると考えていたが、スタッフの1人が探してきたITILを読んで、それがその答えになることに気づいたという。 photo by Joe Harrison
米国の2大林産品／梱包材メーカーであったミードとウェストベーコが2002年の初頭に合併した際、ミードのプロセス開発担当副社長だったジム・マッグレーン氏は、新会社（年商72億ドルのミード・ウェストベーコ）のCIOに就任するとともに、新会社のシステムをSAPシステムで統一するという大がかりなプロジェクトを任されることになった。
実は、マッグレーン氏は1998年からミードの受注管理／財務プロセスの再設計に取り組んでおり、そのプロジェクトでの実績を買われて、この大役を任されたのである。
だが、プロジェクトを開始してしばらくたつと、同氏はどうしようもない違和感にさいなまれることになった。マッグレーン氏は、常々ビジネス部門の業務プロセスを標準化したうえで、より効率的になったプロセスを支援するためのシステムを構築しようと心がけてきたが、同氏が率いるIT部門は相も変わらず、旧態依然としたやり方で業務をこなしていたのだ。ITスタッフは多くの場合、その場しのぎの対応でトラブルを切り抜けていたし、IT部門でのプロセスに至っては、標準化されているものは皆無に等しかったのである。
「IT部門の業務プロセスは共通化されていないどころか、ビジネス部門のそれと比べると、まったく焦点が定まっていなかった」（マッグレーン氏）
同氏が違和感を覚えたのも当然のことだと言える。標準化されたビジネス・プロセスの開発と実施のサポートに責任を負っているIT部門自身が、実は標準化されたプロセスを持っていなかったのだから。
それに気づいたマッグレーン氏とIT部門の上級スタッフは、2002年の大半をIT部門のビジョンづくりと、そのビジョンを実行するためのプロセスづくりのために費やすことにした。
同氏によると、IT部門の標準的な業務プロセスを確立するために、当初はガートナーやIBMが提唱するフレームワークの採用を検討したが、それらはすぐに展開できるような代物ではなかったという。
「各社とも専門用語を羅列して説明するばかりで、それらが何を意味するのか、実際にどのように役立つのかについては、ほとんど教えてくれなかった」（マッグレーン氏）
そんなときに、同氏のスタッフの1人が見つけ出したのが、ほかならぬITIL（Information Technology Infrastructure Library）だったのである。
ITILは、20年ほど前にイギリス政府が作成した、IT業務のベスト・プラクティスを集めた書籍だ。マッグレーン氏たちがそれまでに検討した他のプロセス・フレームワークと違って高レベルだが、各用語の意味も解説されており、きちんと勉強すれば、自らのIT部門に適用できそうな感触があったという。こうしてITILに興味を持ったマッグレーン氏は、早速10部（ITILは、本またはCD-ROMのセットで入手できる）購入してチーム・メンバーに配布するとともに、クリスマスの休暇を利用して、すべての巻を読破した。
かくして、2003年の第1四半期末、マッグレーン氏はITILのフレームワークを使ってIT部門の業務プロセスを再構築するという計画を正式に発表した。ミード・ウェストベーコにおける改革は現在も進行中であるが、現時点で把握できる範囲ではすでに機器のメンテナンスにかかわる契約の経費を10万ドル以上節減できたほか、業務の安定性が向上したことで収益が10％も増えたという。
「これらの利益と経費削減効果は、ほかでもなくITILによってもたらされたものだと考えている」（マッグレーン氏）
COLUMN 1: ITILの長所を知る
適用には時間がかかる
パーシングのCIO、スーレシュ・クマー氏は、「（ITILのおかげで）IT部門の実績を随時評価したり、プロセスを絶えず改善したりできるようになった。当社のIT部門では、いくつかのボトルネック（問題個所）をすでに特定しており、現在、その問題解決に励んでいるところだ。ITILがなければ、こうしたことを行うのは難しかったと思う」と主張する。 photo by Peter Murphy
IT業務のアウトソーシングを検討する企業が多くなっていることもあり、会社に対するIT部門の貢献度を可視化する必要性が日増しに高まっている。また、米国企業改革法によって財務情報の監督強化が義務づけられるといった事情も重なり、最近、多くのCIOがITシステムをきちんと運用管理するためのプロセス・フレームワークに注目している。
フレームワークに基づいたプロセスの構築は、これまで自らの仕事を“アート”だととらえてきたIT部門に、一貫性や業績評価能力、そして科学的厳密さといったものをもたらすことになるはずだ。フレームワークには、さまざまな種類があり、CMM（Capability Maturity Model）に代表されるような能力成熟度モデルやシックスシグマ、COBIT（Control Objectives for Information and Related Technology）といったものが特に有名だ。
ITILもこうしたフレームワークの1つだが、IT業務だけに焦点を当てているという点で他のフレームワークとは性格を異にする。だが、IT業務に特化したフレームワークであるため、これに基づいたプロセスを構築することで、システムの稼働時間を延ばしたり、問題を迅速に解決したりといった具合に、ITサービスの品質を向上させることができるわけだ。
これまで、ITILは日本や欧州地域では積極的に受け入れられてきたが、米国ではもうひとつ評価が低かった。だが、ここにきて、やっと米国でも普及の兆しが見えつつある。ガートナーが2004年に行った調査によると、ITILの認知度と精通度は前年を上回ったという。同社によると、ITILをある程度利用していると答えた企業は、2003年には31％であったのが、それが2004年には41％にまで増加したという。
とはいえ、ITILの導入は口で言うほど簡単ではない。マッグレーン氏によると、IT部門の業務プロセスを大々的に変更する作業が必要になるため、CIOはITILプロジェクトをERP（Enterprise Resource Planning）システムのインプリメンテーションと同程度の規模のプロジェクトとして取り扱うべきだと忠告する。
「ITILをすぐに組織に適用できると思ったら大間違いだ。プロジェクトの評価も、数カ月ではなく数年のスパンで行う必要がある。ITILを自らのIT部門に簡単に適用できると考えているCIOがいたとすれば、痛い目に遭うに違いない」（同氏）
実際、詳細に書かれたソフトウェア開発の書籍や方法論に慣れているCIOは、ITILを読んで、ショックを受けるかもしれない。というのも、ITILにはベスト・プラクティスは列挙されているが、それを実装・展開する方法については何ら説明がなされていないからだ。
グローバルに事業を展開している大手企業65社のCIOを対象に、フォレスター・リサーチが2005年に行った調査では、ITILに対する関心は世界中に広がっているにもかかわらず、IT部門の業務プロセスの標準化手法として実際に利用している企業は、全体のわずか3％にすぎなかったという。フォレスターCIOグループの副社長ボビー・キャメロン氏は、「ITILをIT部門の戦略の一部として積極的に進めている企業となるとさらに少ないだろう」と見ている。
しかしながら、そう遠くない将来、ITILは多くの企業にとって、現在よりもはるかに当たり前の存在となるはずだ。ゼネラルモーターズをはじめ、米国政府やカナダ政府も、近々IT関係の請負業者にITILの採用を求める予定だ。また、フォレスター・リサーチも先の調査で、あらゆる企業のIT部門でITILが事実上の標準になるのは時間の問題だと結論づけている。
「ITILは、IT業務に利用するうえで最良のフレームワークだ。これに匹敵するものはほかにない」（キャメロン氏）
投資仲介業者であるパーシングのCIO、スーレシュ・クマー氏も「（ITILのおかげで）IT部門の実績を随時評価したり、プロセスを絶えず改善したりすることができるようになった。当社のIT部門では、いくつかのボトルネック（問題個所）をすでに特定しており、現在、その問題解決に励んでいるところだ。ITILがなければ、こうしたことを行うのは難しかったと思う」と、ITILのメリットを強調する。
ITILの活用法
「ビジネス部門がやっていることでIT部門が知らないことはたくさんある。変更前に警報を発しておけば、ビジネス部門の意向に沿うことができるうえ、必要なシステムが利用できなくなって、ユーザーの怒りを買うといったことを防ぐこともできる」と語る、フィニスターのグローバルIT担当ディレクター、クリスティン・ローズ氏。 photo by Andy Freeberg
では、実際にITILに基づいたプロセスを取り入れた企業は、それをどのように運用しているのだろうか。
パーシングでは、社員のだれかがITシステムやハードウェアの問題に遭遇した場合には、まずサービスデスクに電話をかけることになっている。同社のサービスデスクは、「デスクトップ」、「ネットワーク」、「メインフレーム」、「分散システム」という4つの専門分野ごとに担当者が分かれており、ユーザーから問題の内容を聞いた段階で、それぞれの担当に電話が振り分けられるようになっている。
同社では、2004年1月にITILを導入したが、それによりサービスデスクで電話に対応する専門スタッフは、以前に発生したインシデントやその対処法を参照しながら問題解決に当たるようになった。
さらに、サービスデスクの担当者が10分たっても問題を解決できない場合には、サービスデスク・メニューが自動的にそれを認識し、その問題に精通した専門スタッフを呼び出すような仕組みにもなっている。
専門スタッフの持ち時間は最大1時間と決まっており、その時間内に当該インシデントを解決できない場合には、クマー氏を含むIT部門の上級幹部がコンファレンス・コールで作業に加わるようになっている。さらに
2時間たってもインシデントが解決できない場合には、クマー氏がビジネス部門の責任者に電話をかけ、そのインシデントが持つ意味と実行すべき対策について話し合いがもたれることになる。
クマー氏によると、ITILを導入した結果、サービスデスクの対応時間は約半分に縮まったという。また、インシデントを発生するたびに個別に追跡管理しているため、根本原因を分析してインシデントの発生傾向を見つけ出したり、慢性的な問題を解決したりすることもできるようになった。
「システムの変更や、新しいリリースのインストールに際しても、ITILを導入したおかげで、いきなり問題が発生するような事態を防ぐことができるようになった」（クマー氏）
端的に言えば、こうした一連のプロセスこそがITILなのである。ミード・ウェストベーコのマッグレーン氏は、現在、多くの企業が直面している問題を次のように指摘してみせる。
「企業には、優秀なネットワーク・グループやメインフレーム・グループがある。しかし、それぞれのグループが自分の担当する分野の価値を最大化することばかりに気を取られていると、組織全体のために価値を創造するという点がおろそかになってしまう」
そうした全体最適を実現するために、IT部門におけるすべての取り組みを調整し、持てる能力を十分に発揮させるようにするための言語とプロセスを提供するのがITILだ、というわけである。
ITILの歴史
ITILは、今では存在しない英国政府の「CCTA（Central Computer and Telecommunications Agency：中央コンピュータ電気通信局）」によって、政府機関のIT部門で利用できるベスト・プラクティスを集めたカタログとして、1980年代末に初めて作成された。それがやがて、英国内の民間企業でも使われるようになり、その後欧州各国に広まって、最近は日本や米国でも広まりつつある。
第2版である現在のITILは、7つの書籍で構成されている。それぞれの書籍は、およそ200ページから成り、価格は115ドルほどだ。1冊で1つの業務分野をカバーしており、それぞれ「サービス・サポート」、「サービス・デリバリ」、「サービス管理の導入計画立案」、「セキュリティ管理」、「ICT（情報および通信技術）インフラストラクチャ管理」、「アプリケーション管理」、「ビジネス展望」というテーマについて書かれている。
現在、ITILを導入している米国企業の大半は、サービス・サポートおよびサービス・デリバリという2つの業務分野の中の一部該当する業務だけにITILを適用している（コンサルタントがITILという用語を使う場合、サービス・サポートだけを指すことが多いため、注意が必要だ）。サービス・サポートは、多くのIT組織にとって最も改善が容易な分野であり、ITIL導入の出発点にしやすいと考えられているからだ。
サービス・サポートの書籍には、5種類の具体的なプロセスが記載されている。それは、インシデント管理、問題管理、変更管理、構成管理、リリース管理だ。
コンピュータ・アソシエイツのITILワールドワイド・プラクティス・マネジャーで、ITIL開発チームのメンバーでもあったブライアン・ジョンソン氏によると、これらのプロセスは、企業におけるインシデントのライフサイクル（すなわち、あるインシデントが初めて発生してから、システムの変更または新たなリリースによって、それが恒久的に解消されるまでの時間）全体を支援できるよう考えられているという。
COLUMN 2: ITILの7つの書籍
適用方法は企業によってまちまち
SAT（Scholastic Assessment Test：米国の大学進学希望者を対象とした共通試験）を管理している大学入試センターのソフトウェア・エンジニアリング統括責任者、ジム・ストランデ氏は、かねてからITILがインシデントのライフサイクルを管理できるということに、大きなメリットを見いだしていたという。同氏は、それこそがITILを導入したきっかけであったと強調する。
大学入試センターのビジネス部門とIT部門との間では、IT業務に関する正式なサービス・レベル契約は結ばれていなかったが、ストランデ氏はWebサイトのメンテナンスに対するビジネス部門の期待に十分にこたえられていないことだけは認識していたという。IT部門では年間平均で99.9％の稼働時間を達成してはいたが、裏を返せば、それは年間におよそ9時間もサイトがダウンしているということを意味していたからだ。しかも、サイト・ダウンは必ずと言っていいほど、受験の登録受け付けや得点発表が行われる40日～50日の間（サイトの必要性が最も高まる時期）に発生していたという。
そこで、ストランデ氏はシステムの稼働率を向上させるとともに、IT部門の業務を正当に評価することを目指してITILを採用することにした。採用に先だって自らの部門の評価を行ったストランデ氏は、IT部門が各種インシデントの原因を十分に追跡できていないことを知って愕然としたという。
「ITILの用語で説明すると、当部門ではインシデント（あらゆる種類の基準外の出来事）と問題（ITシステムの基本的な不具合のこと。複数のインシデントの結果とされることが多い）の区別もできていなかった。そのため、Webサイトの問題も解決されずに放置されたままで、さまざまなインシデントが繰り返し発生することになってしまっていた」（同氏）
そこで、ストランデ氏はITILのサービス・サポートの巻に記されている手法を使って、ビジネス部門でインシデント／問題管理を担当する職務を再編するとともに、インシデントと問題とを明確に線引きすることで、重要なイベントに対して定められた方法でスタッフが対応できるようにした。
ストランデ氏は、このような取り組みによって、問題の再発件数を全般的に減らすことができ、サービス・レベルを向上させることができたと胸を張る。
一方、前述したように、パーシングでは問題が発生してから2時間たってもサービスデスクの担当者や専門スタッフがインシデントを解決できない場合には、CIOのクマー氏がビジネス部門の役員に電話をかけることになっている（タイムリミットが深夜にかかるような場合であっても例外ではない）。
「午前2時にCEOのところに電話をかけるのは、あまり気が進まないが、最近では、決済手形交換所（仲介業者に代わって、昼間行われた取引を夜間に一括処理している外部の会社）のシステムがクラッシュしたときにCEOに電話を入れた。このような緊急事態が発生した場合には、これまでも数回深夜に電話をしたことがある」（クマー氏）
決済手形交換所の問題が発生したとき、クマー氏はおよそ30人の役員と真夜中に電話会議を行い、法的な問題や手作業で処理を行う場合の要求条件といったあらゆる問題について話し合ったうえで行動指針を決定した。
「問題が起こったら早い段階でマネジャーたちを呼び出し、それぞれの作業負荷を評価して、各担当分野に適切なスタッフを配置する一方、IT部門は問題を回避するための解決策を探り、追加リポートを作成してビジネス部門をサポートするという合意が出来上がっていたため、（夜中に電話をかけても）だれも腹を立てたりしなかった。当社では、問題が発生したときには、全員で解決しなければならないということをだれもが理解しているのだ」（クマー氏）
ITILの“肝”はCMDB
ITILのサービス・サポートの巻には、インシデントを追跡して問題を特定し、変更を行ってそれらを解決するためのプロセス全般についての記述がなされているが、CIOが注力しなければならないのは、最終的にインシデントや問題が起こった場合に、ITスタッフがあらかじめ社内で決められている一定のプロセスに従って、問題を解決するように徹底させるという点だ。
それを実現するための最良の方法は、ITスタッフをトレーニングするとともに、ITスタッフに代わってプロセスを順守させるための“システム”を導入することだ。その“システム”とは、あらゆるITILプロジェクトで技術的な基盤となる「構成管理データベース（CMDB）」である。
2002年にITILを導入したフィニスターで、グローバルIT担当ディレクターを務めるクリスティン・ローズ氏は、CMDBについて次のように説明する。
「CMDBは、ITILの中核となる基盤だ。CMDBがあれば、資産を追跡できるようになるとともに、それまでに行ったあらゆる作業の実行履歴を参照することができるようになる」
基本的にCMDBは、企業が保有するすべての技術要素（システム、ルータ、サーバ、PCなど）のマップであり、それぞれの資産に対して行ったあらゆる変更、インシデント、周りの技術環境と、その資産との関係などを示すカタログだ。
例えば、ローズ氏は、CMDBと照らし合わせながらリポート機能を実行することで、フィニスターのFTPサーバが、最近発生した複数のインシデントの原因になっているという事実を突きとめた。このFTPサーバは、エンドユーザーにテクニカル・サポートを提供するために使われているもので、利用頻度が高いためにハードディスクが容量不足に陥っていたのだ。そこでローズ氏は、ストレージの容量を拡張することで、この問題を解決した。
「ビジネス部門の人たちは常に自分たちの業務で手一杯だ。そのため、ニーズを自分のほうからIT部門に伝えたりはしないものだ。そのため、サーバの履歴を見るなどして、IT部門が自分たちでこうした傾向に気づく必要がある。そうしなければ、問題が改善されることはないのだ」（同氏）
ミード・ウェストベーコのマッグレーン氏によると、現在市販されているCMDB製品の多くは、インシデント・問題・変更を追跡する機能を内蔵しているという。
多くの場合、CMDBは仮定に基づく計画をあらかじめ立案しておくことで、提案されている変更が同じ環境内にある他のシステムに意図しない影響をもたらすのを防いでくれる。ITILに記載されている変更管理手法のベスト・プラクティスでは、大きな変更を行う際には、その72時間前にビジネス・ユーザーに警告を発することになっている。そうすることで、例えば、財務部門が帳簿を締めるまでシステムを稼働させておく必要があるので、ERPシステムの変更作業をもう少し遅らせてほしいといった要望を出すことができるのだ。
「ビジネス部門がやっていることでIT部門が知らないことはたくさんある。変更前に警報を発しておけば、ビジネス部門の意向に沿うことができるうえ、必要なシステムが利用できなくなって、ユーザーの怒りを買うといったことを防ぐこともできる」（ローズ氏）
ITILは万能薬ではない
このように、ITILをうまく自らのIT業務に適用し、活用すれば、ITサービスを効率的に提供することができるようになるが、だからといって、ITILは決して万能薬というわけではない。
ITILの大きな弱点は、企業が実行できればよいと思われるIT管理のためのベスト・プラクティスのリストでしかない、ということだ。ITIL開発チームのメンバーだったジョンソン氏は、次のように説明する。
「ITILはベスト・プラクティス集にすぎないため、ITILそのものをインプリメントすることはできない。ITILは、組織の変更を支援するために使うだけのものなのだ」
つまり、ITILは掲載されているベスト・プラクティスを応用するための方法を示しているわけではないため、それを活用したければ、それぞれの組織が、ITILの原則に基づいて独自にプロセスを設計しなければならないのだ。
大学入試センターのストランデ氏は、「ITILはフレームワークにすぎないため、組織で活用しようと思えば、だれかの助けを借りて足りない部分を補う必要がある」と語る。大学入試センターでは、このため、ITILをインプリメントするに際してノーブルスターとブーズ・アレン・ハミルトンのコンサルタントに支援を依頼したという。
ITILのインプリメントにコンサルタントが必要になるという状況は、当初から予想されていなかったわけではない。
1980年代に出版されたITILのオリジナル・バージョンは、英国政府の職員が書いたものであったが、現在のバージョンはすべてコンサルタントやベンダーによって書かれている。言うまでもなく、これらの人々はITILに記載されているベスト・プラクティスを自らの組織に実装しようとする企業が支払うお金で生計を立てている。
ITILの日常的な監督業務を行っている（ITILの商標は今も英国政府が持っているが、各種の実務的な理由によって、現在はitSMFが管理している）組織であるITサービス・マネジメント・フォーラム（itSMF）のCEO、エイダン・ローウェス氏も、「ITILの資料作成には、ある種の思惑が働いていることは間違いない」と認める。
ミード・ウェストベーコのマッグレーン氏やフィニスターのローズ氏は特にコンサルタントを雇っているわけではないが、ITILについての専門知識を自分たちで作り上げるためには、一定の時間と人的リソースが不可欠であることは認めている。
ミード・ウェストベーコでは、社内のスタッフ・トレーニングに1年ほどを要したため、それによって、IT部門の組織再編が2004年第3四半期にずれ込むことになってしまったという。
ただ、コンサルタントを雇うにしろ、社内スタッフをトレーニングするにしろ、そうしたことは、ITILの実装の出発点にすぎない。新しいプロセスの設計は数カ月で終わるかもしれないが、必要な変更作業の量は膨大であり、IT部門はそれを数年かけてインプリメントすることになるのだ。
2005年9月の時点で、サービス・サポートとサービス・デリバリだけを実装しているミード・ウェストベーコでも、ITILプロセスに沿って一部の業務を開始できるようになったのは2005年末のことだったという。これは、同社がこのフレームワークに取り組み始めてから、およそ2年後に当たる。さらにマッグレーン氏は、プロセスを導入してから、業務遂行のための手段として実際に使うようになるまでには、18～24カ月はかかると見ている。
ITILの大きな効用
ITILを導入するためには、組織の文化的な問題にも向き合わなければならない。フィニスターのローズ氏は、「ユーザーがサービスデスクを通さずに、知り合いのITスタッフに直接電話するのを防ぐため、ITスタッフ全員に新しい携帯電話番号を割り当てなければならなかった」と、笑い話にもにた経験を語る。
また、新しいプロセスに対応できないITスタッフがいる場合には、解雇をも辞さない態度で臨む必要があるというのは、多くのCIOが口をそろえて指摘するところだ。一方、大学入試センターのストランデ氏のように、スタッフを新たに雇い入れるケースもかなり出てくるかもしれない（ストランデ氏は、問題管理を強化するために数人のスタッフを新たに雇い入れた）。
だが、多くのCIOにとって、ITILの導入に伴う苦労は、それに十分見合うだけの成果をもたらしてくれるものだ。フィニスターのサービスデスクがITILによって標準化されたことで、同社の社内ユーザーの満足度は、33％から95％にまで向上したという。また、同社のIT支出も、売上高の4％から2.4％にまで削減された。
最後は、ミード・ウエストベーコのマッグレーン氏の言葉で締めくくろう。
「IT部門をビジネス部門と同じように運用するには、部門の主な業務について理解し、それを整理する必要がある。ITILを使えば、業務を視覚化することができるうえ、一定のプロセスに従って業務を遂行することが可能になる。どの業務が重要なのかを評価できれば、価値を生み出す業務に力点を置き、そうでない業務からリソースを移し替えることもできるのだ。ITILの価値を最大化させること──それが、今後企業にとっての重点課題になることは間違いあるまい」
