図3●現場側と経営側のそれぞれの問題意識が，企業をITILに向かわせる
[画像のクリックで拡大表示]

　「ITILに取り組み始めた」（東京ガス），「運用の委託先とITILに関する情報を交換している」（富士写真フイルムのシステムを開発/運用する富士フイルムコンピューターシステム システム事業部 主査 柴田樹氏），「RFPに，“ITIL準拠の運用”が盛り込まれるケースが増えた」（NEC マーケティング推進本部 シニアエキスパート 大畑毅氏）――。

　未導入企業がITILに寄せる関心は，ここに来て急速に高まっている。その背景には，現場側と経営側のそれぞれが抱える問題意識がある（図3）。

現場と経営の双方に「理由」

　現場側の問題意識は，本誌の読者には自明だろう。急速なオープン化でシステム構成が複雑化。運用スキルが未成熟なこともあり，障害は多発する。さらに，感染力の高いウイルスやワームが出現し，パッチ適用の緊急度/手間は増大。担当者間で知識やノウハウを共有している時間は取れない。忙しいだけで，成長している実感はない。

　経営側の問題意識はこうだ。障害の発生で業務遂行に支障が出る。その割には，システム投資額が過大/不透明。世間では開発/運用の現場が関与したと見られる情報漏洩（ろうえい）事件が起きている。不信と不安が払拭されない。

　お互いの問題意識が，理想の運用プロセス集「ITIL」に向かわせる。ITILでプロセスを明確化すれば，サービス品質は均一化し，品質とコストの関係が可視化されるのではないかと期待できるからだ。

ITILに基づいたが失敗

　だが，ITILを採用すれば，成功が約束されるわけではない。第一生命情報システムは，ITILに基づいたにもかかわらず“失敗”した。

　同社は2002年11月，SAP R/3システムの運用保守サービスにITILの「インシデント管理」を採り入れた。Excelファイルに蓄積していた障害情報/解決策/技術ノウハウを共有するために，「HP OpenView Service Desk」をベースとする「インシデント管理システム」を構築した。ITILでは，障害情報や変更情報などを一元化して共有し，ナレッジ（知識）を底上げする方法が推奨されている。この考え方に従い，キーワードを入力するだけで関連情報を一覧表示する機能をインシデント管理システム上に作り込んだ。

　インシデント管理そのものには成功したが，「ナレッジ共有機能は期待したほど使われず，（ナレッジ共有の計画は）事実上とん挫してしまった」（ソリューション企画本部 ERPビジネスソリューション アナリスト 中野光孝氏）。ソフトが搭載する検索機能が不十分なうえ，登録するデータの作り込みが甘かった。検索しやすくなるようにメタ情報を加えたりする工夫も足りなかった。結果的に，「必要な情報が見つからないために使われず，使われないので情報も登録されない悪循環に陥った」（中野氏）と反省する＊5。

4つの注意点がある


図4●ITILを活用する前段階の注意点
[画像のクリックで拡大表示]

　ITILを先行導入した企業や，導入を支援したベンダーの多くは，「安易に導入しても，効果は期待できない」（日立製作所 ITソリューション部 部長代理 八木隆氏）と警鐘を鳴らす。その警鐘から導き出される注意点は大きく4つある（図4）。

　(1)ITILに準拠することが「目的」ではない，(2)無理に準拠させると現場が混乱する，(3)ITILだけでは不十分，(4)経営層を巻き込むことが不可欠――である。以下，順に説明しよう。

　(1)ITILに準拠することは，最終的な目的ではない。ITILは運用改善の道具にすぎないが，経営側や親会社などの意向を受けて，「ITIL準拠が目的にすり替わっているシステム担当者が散見される」（日立の八木氏）という。別の例では，ITILは品質評価/保証の規格である「ISO9000」や「BS15000」と異なり組織を認定するものではない＊6のに，“お墨付き”を得る感覚で取り組む企業が後を絶たない。

　(2)既存の運用を無理にITILに準拠させると，現場は大きく混乱する。最悪の場合，改善効果が出るどころか，状況が悪化する恐れもある。隠れた問題を洗い出したうえで，リスクを考慮して準拠か否か決める。

不足部分は独自に補足


図5●ITILで記述されていない内容は独自に補足する必要がある
あるサービス業者は，所管部門ごとに縦割りだった運用を改善するため，ITILの変更管理を採り入れた。ITILに基づいて，変更の影響範囲を事前に分析・検討する部門横断型の変更諮問委員会を設置した。ただし，委員会の体制や変更依頼書の書式などはITILに記述されていないので，独自に定める必要があった
[画像のクリックで拡大表示]

　(3)ITILは理想の運用プロセス集だが，記述範囲は汎用的な部分だけだ。企業固有の領域は各社が独自に考えなければならない。ここの作り込み次第で，ITILの実効性が決まると言っても過言ではない。

　具体的な例で説明しよう。あるサービス業者は，情報システムの変更管理にITILを採り入れた。ITILには，変更内容の影響範囲や優先度を事前に分析するための組織（変更諮問委員会＊7）を設置すべきことが記述されている。この委員会に，事前に「変更依頼＊8」という書類を提出し，レビューを経て変更を許可するというプロセスも明記されている。だが，具体的に委員会をどんなスケジュールで開催し，どのメンバーを招集し，どんな書式の変更依頼を用意すべきかについては，明記されていない（図5）。

　この企業の場合，部門ごとにシステムの構築/運用が縦割りで，改修の通達が事前に他部門に伝わっていないことが問題視されていた。そこで変更諮問委員会には，主に各部門の担当者と保守ベンダーの担当者を招集した。改修の1～2週間前には変更依頼を委員会に提出するというルールも決め，変更依頼の書式も定型化した。

現場と経営の協力が欠かせない

　(4)改善プロジェクトの開始前，または一定の効果を上げた初期段階で，経営側とうまくパイプを築いておく必要がある。先行企業の大半は現場の問題意識からボトムアップでITILに取り組んできたが，それらの企業が「現場だけの取り組みでは，早晩に立ちゆかなくなる恐れがある」（第一生命情報システム ソリューション企画本部 ERPビジネスソリューション 上席アナリスト 坂井直樹氏）と注意を促す。

　主な理由は3つある。まず1つ目は，「継続的な改善活動のための予算を確保するためにも，経営陣を巻き込むことが欠かせない」（日本情報通信 システム運用サービス事業部 ビジネス推進グループ 應和周一氏）からだ。

　2つ目は，現場の士気を上げることができるからだ。丸紅情報システムズの場合は，現場のプロジェクト・リーダーがデータセンター長を説得し，データセンター長が社長を説き伏せた。そうして社長が，全社員にITILに取り組む重要性を説明した。「現場の取り組みがトップを動かしたと，現場の士気が上がった」（当時のプロジェクト・リーダーで現在はソリューションサービス開発本部 副本部長 斎藤浩二郎氏）と指摘する。

　3つ目は，ITILの「サービスデリバリ」で記述されているIT投資の最適化などの効果を得るには，「企業の経営戦略とIT戦略の関係から見つめ直す必要がある」（コンピュータ・アソシエイツ テクノロジーディビジョン テクノロジーサービスマネージャー 伊藤正博氏）から。経営戦略に応じてIT投資の規模が決まり，それに見合う運用体制を整えるのが道理である。

　逆に，経営側がトップダウンで一方的に現場にITILを強要すると，「反発を招き，うまくいかない可能性もある」（富士通 ソフトウエア事業本部 運用管理ソフトウェア事業部 第一開発部 部長 今井辰己氏）という指摘もある。ボトムアップで取り組んだ丸紅情報システムズの阿部氏でさえ，末端に近い立場にいた当時は「トップに“やらされている”という意識があった」と打ち明ける。それでも，当時のプロジェクト・リーダーから何度も導入の意義について説明を受け，さらに自分が改善プロジェクトのリーダー役を務めるようになり，「ようやく必要性を実感できた」（阿部氏）という。教育/啓蒙と改善意識の共有が不可欠だ。