日本ヒューレット・パッカード（株）
コンサルティング・インテグレーション統括本部
HPサービス グローバル・プログラムマネージャ 池田 利明
ITシステムの運用管理において、最近注目されているキーワードに「ITIL」があ ります。ITIL（アイティル）とは「THE IT Infrastructure Library」の略で、イギ リスの政府が策定したITサービス管理のために統合したプロセスを中心とするベストプラクティスを示しています。今回は、このITILについて詳しくご紹介したいと思います。
1980年後半に英国の政府機関が作成・文書化をし、IT運用における実際の知識・ノウハウが集約されています。ITILを当初編纂したのは、イギリスのCCTA（Central Computer and Telecommunications Agency）という、現在はOGC（Office of Government Commerce）の一部門となっている機関です。1980年代後半、イギリスではITコストの増大が政府・企業活動の大きな負担になっていることが問題となり、これを是正するために、CCTAは適正なコスト算出方法を導く必要に迫られました。
そこでCCTAは、英国内のベンダ、コンサルタント、ユーザから数々のIT事例を収集･分析。 その数々のベスト・プラクティスの中から、最もコスト的に効率が良いとされるITインフラ構築の方法論がまとめられました。これが、ITIL（IT Infrastructure Library）としてまとめられています。
ITILの策定にあたって最初に、業界スペシャリストから構成された編集評議会で、各書籍の内容とその責任者を定め、また、内容を編集評議会で確認し品質保証が行われました。
そうして策定されたITILは、現在何冊かの書籍に編纂されています。日本では、ITサービスマネジメントフォーラムジャパン（itSMF）というNPO組織が発行しており、一般書店や通信販売で手に入れることができます。また、トレーニング、認定制度などの利用が進められています。
ITILは、図1のように7つのカテゴリからなります。「サービス・マネージメント」は、「サービス・デリバリ」と「サービス・サポート」に大きく分けられ、別々のプロセスとなっています。また、最近「ソフトウェア・アセット・マネージメント」という書籍も追加されました。
「アプリケーション・マネージメント」では、大きく「アプリケーション・ライフサイクル管理」と「ビジネス・バリュー管理」の2つのテーマに別れています。「アプリケーション・ライフサイクル管理」では、アプリケーションの開発要求当初から、その使用を終了するまでサービスを最適に保つかを、「ビジネス・バリュー管理」では、経営戦略とITサービスの融合を求め、いかに調整するかを記載しています。
ITILのこのような各項目について、それぞれの専門家を集めて、標準的にはどのようなプロセスがいいかを実績から決めたのがITILの根幹となります。
そしてITILの一番のポイントは、「こうしなさい」と読む人に考えを押し付けるものではないということです。あくまでも、「データセンターやシステムは、こういう風になっていますよ」とか「こういうやり方をしてますよ」という事例紹介の話をしているだけで、「すべき」とか「しなさい」とは一言も書いてません。これが、ITILが全世界に広まった理由の一つです。
ITILは、ITサービス管理の全体を網羅し、システム管理だけでなく、「アプリケーション開発管理」についても扱っています。例えばアプリケーションを開発する場合には、ソフトウェアのバージョン管理が大切です。「少しでも修正をしたら、バージョン番号を変えて、バージョン管理のリストを作ってそこに登録する」という事例がITILにあります。ささいなことですが、これをやってさえいれば、いつ誰がどのようにソフトウェアを変えたのかが分かるので、トラブルのときも、すぐその前まで戻せば良いということがすぐに分かります。さらに、「ただバージョンをリストアップするだけではなく、バージョンアップ前後のソフトウェアもきちんと残して管理しておく」という点にまで踏み込んで書いているわけです。
ITILというのは、このようにいろいろな分野を傘のように覆っていますので、幅広い人がこれを利用できます。例えば、運用担当者が良い運用の仕方を参考にすることもできるし、IT部門の管理者がネットワークの管理について事例を見たい場合にも利用できます。また、経営者がIT部門を今後どのような方向に持って行くかを考える際にも有効です。
なぜ、このようにさまざまな利用の仕方ができるかと言うと、ITILが“IT”というものを一つの塊として捉えているからです。日常の運営や運行、管理といった細かい見方ではなくて、一つのサービスという漠然とした大きな捉え方をしているわけです。だから、中には「マクドナルドはなぜ成功したか」といったITとはまったく関係のない話も非常に多く取り上げられています。
日本HPでも、10年前に情報システム部門で、ITILの導入を考えるためにグローバルなチームを作りました。そこで実際に導入プランや手順を作って、各国のIT部門に広めていった歴史があります。ここで重要なことは、サーバを動かしたり、情報を管理したりすることを“サービス”として捉えて、そのサービスがうまくユーザーに提供できているかどうかを計測するシステムまで作ったことです。
つまり、実際にはITILを読んで理解するだけではなく、それを実際に仕事に活用することまで、踏み込んで考える必要があるのです。それはアプリケーション開発の世界でも、運用管理の面でも、まったく同じことが言えます。
下の図には、ITILを実践するまでの道のりということで、スタンダードなやり方を挙げています。ここに挙げた6つの項目は、実は生産管理システムやOA業務のシステムを作るときと同じようなやり方をしています。何も目新しいことを言っているわけではなくて、“サービス”という漠然としたものを目に見えるようにしただけなのです。
要するに、ITサービスというと「アプリケーションを作って動かせばいい」「データを生成して蓄えておけばいい」という話になりがちですが、「一体、それでどのような付加価値を生むのか」という視点も大切だということです。「その付加価値にどれくらいの投資をして、その結果利益がいくら返ってくるのか」という問題です。当初ITILが目指したのはそのようなものではなく、あくまでもベストプラクティス、つまり成功事例を箇条書きにすることでした。しかし、それを利用する側である私たちは、事例を整理して、「利益や利便性をどれだけもたらすか」ということを定量的に測っていくことが大事だと思います。
この6つの項目を実践する際に、例えばソフトウェアを開発している担当者は、そのソフトがいつまで使われるのかはあまり考えていません。しかし、今ある技術で作成したソフトは、いつかは寿命が来るわけで、それは7年先かもしれないし、5年後かもしれない。そのときに、そのソフトに使った作業量やコストが本当に適正なものかを考える必要があります。このような問題はITILの中に記載があるので、一度目を通してもらいたいと思います。
このようにITILを実践していくことによって、システム管理者やアプリケーション開発者にとっては、次のようなメリットが生まれます。
- 現実的なサービスレベルアグリーメントによって、ビジネスライクな関係を確立できる
- ユーザーのサービスに対するニーズに対し、供給するサービスのコストを正確にバランシングできる（複雑な状態でも）
- ITリソースを正確に特定、割り当て、計画できる
- 予測できないデマンドが軽減される
- 調達コストの削減（今必要なものが何か、どの位なのか明確）
- 顧客満足度改善に向けたベースラインの確立
- 俊敏性を求めて、ビジネス上の意義ある議論の土台が得られる
例えば今、オブジェクト指向ということで、ユーザーのやりたいことをソフトに反映することが求められていますが、ITILには「使う側の声を聞いて、それを設計に取り入れる」ということが明確に書いてあります。その視点を忘れて、“技術オリエンテッド”になってはいけませんよ、ということが書いてあるわけです。このようなITILの事例をしっかり活用して、開発に役立てていただければと思います。
