ITIL v2 のサービデリバリはどうなったの？

Vol.003 - 2008年11月11日（月2回発行）

前回は、ITIL Version 2（以下 ITIL v2）の「サービスサポート」の概念が、ITIL Version 3（以下 ITIL v3）ではどうなったか、というお話でした。今回は前回の予告どおり、ITIL v2の「サービスデリバリ」に含まれている5つのプロセスが ITIL v3ではどうなったのか、というお話しです。

解説を行う前に、ITIL v2 の「サービスデリバリ」の5つのプロセスが何だったか、確認しておきましょう（表１）。
 

表１：サービスデリバリ構成

「サービスデリバリ」にあったこれらの機能は、ITIL v3の「サービスストラテジ」、および「サービスデザイン」に散らばりました。「サービスサポート」のときと同様、「サービスデリバリ」の各プロセスも単純に散らばっただけではなく、新しい概念が追加されたり、考え方が変わったりしている部分があります。しかしそれぞれの詳細については、やはり第4回目以降で解説をしていきます。

まず、「サービスデリバリ」に含まれていた5つのプロセスのうち

• ITサービス財務管理

が「サービスストラテジ」に含まれました。前回にも触れましたが、「サービスストラテジ」とは「事業ニーズに合ったITサービスを計画する」というフェーズです。事業ニーズに見合ったITサービスを提供するためには、どの程度のお金がかかるのか、ということを計画時点で見積もりましょう、ということです。

そして残りの4つのプロセス、

• サービスレベル管理
• 可用性管理
• キャパシティ管理
• ITサービス継続性管理

は「サービスデザイン」に含まれたのです。「サービスデザイン」は、費用対効果の高いITサービスを設計するフェーズです。言い換えれば、これらのことはITサービスを導入する前にあらかじめ考えておきましょうね、ということです。

では、ITIL v2の「サービスサポート」の機能やプロセスがITIL v3の「サービストランジション」や「サービスオペレーション」に散らばったのに対して、「サービスデリバリ」はなぜ「サービスストラテジ」と「サービスデザイン」なのでしょうか。そもそも、「サービスストラテジ」と「サービスデザイン」は、何を目的とした書籍なのでしょうか。一部、前回の繰り返しになるところもありますが、ITIL v3 の考え方を認識するために重要ですのでお付き合いください。

まずは「サービスストラテジ」の主な目的から説明します。

「サービスストラテジ」の目的は、ITサービス、またはITサービスマネジメントを、事業体（企業や公共施設、非営利団体など）がお客様に事業サービスを提供する際の戦略的資産として捕らえ、ITサービスを設計、導入、運用する上での青写真を書くことです。その青写真を書くのはITサービスマネジメントを行うサービス・プロバイダの仕事です。もちろん、サービス・プロバイダが勝手に（あるいはサービス・プロバイダ側の都合で）ITサービスを設計したり、開発したりするわけにはいきません。ITサービスを利用する事業体の事業戦略を正しく理解し、顧客やユーザのニーズを正しく把握した上で、その目的を果たすための戦略（設計、開発、実装のための戦略）を提供する必要があります。そのための手引きとなるのが、「サービスストラテジ」です。

ちなみに ITIL v3 においては、サービスとは「価値を提供するもの」であり、その価値は様々な資産を「材料」にして作る、と解いています。これは、第2回目にも書きました。 ITIL v3 書籍では、この「材料」のことを「リソース」と呼んでいます。「サービスストラテジ」では、ITサービスにおける「リソース」は、次の５つです。

• 人材
• インフラストラクチャ
• アプリケーション
• 情報
• 金融資本

いわゆる、「ヒト」「モノ」「カネ」ですね。このうち「モノ」に相当するのが、ハードウェア（インフラストラクチャ）だったり、ソフトウェア（アプリケーション）だったり、データ（情報）だったりするわけです。つまり、IT資産です。

おそらく、1990年代の半ばぐらいまでは、高性能なIT資産を持てば競合他社に対して競争優位性が持てる、と思われてきました。しかし、IT資産を導入してからのほうが手間やお金がかかるということが明らかになり、1990年代後半から2000年代前半ぐらいまでは、TCOの削減とか ROI の向上だとかの運用面にフォーカスが当たりました。

実際には、それでもまだ不十分だったのです。そのIT資産は、誰のために、何のために存在するのか、どのような価値を生産するのか、なぜ、そうするのか、そのためにIT資産はどうなっていなければならないのか、ということをふまえた計画が必要なのです。従来のIT資産管理や運用管理は、そこまで述べられていませんでした。ですからITはコスト食いだとか、手間がかかるとか、最悪の場合は使えないとか言われてきたのだと思います。これまでの反省と改善の結果が、「サービスストラテジ」という分野であると言ってもいいでしょう。

そのため「サービスストラテジ」は、ライフサイクルの最初に存在しているもの、として位置づけられています。また、最初だけに存在するのではなく、ライフサイクルが「サービスデザイン」、「サービストランジション」、「サービスオペレーション」へと移行するための軸にもなっていると考えます。つまり、ライフサイクル全体にかかわっていることになります。

IT資産のひとつである「カネ」を戦略的に管理するため、「ITサービス財務管理」が「サービスストラテジ」に含まれたことになります。「サービスストラテジ」には、そのほかに「需要管理」「サービス・ポートフォリオ管理」といったものが含まれますが、それらの詳細は回をあらためて解説することにします。

次に、サービスデリバリのもうひとつの継承者である「サービスデザイン」の目的についてです。

「サービスデザイン」の目的は、「サービスストラテジ」で計画した戦略に基づき、企業が事業目的を達成するために必要としているITサービスを設計し提供することです。顧客の活動である事業を見据え、ビジネスニーズをしっかりと理解し費用対効果的に見ても妥当で効率的なITサービスを提供するための手引きとなることです。

「サービスデザイン」では、ITサービスを提供するサービス・プロバイダ、およびサービス・プロバイダを外部から支援するサプライヤの役割と位置づけを明確に定義しています。顧客が展開する事業を支援するITサービスをどの程度、どのように提供するのかということを提案するのが、サービス・プロバイダの役割です。顧客は提供されたITサービス、言い換えればITサービスがもたらす「価値」を検証し、サービス・プロバイダと合意します。サービス・プロバイダはその合意内容にしたがって、適切なITサービスを設計してゆくわけです。

「顧客とサービス・プロバイダが、サービスレベルに関して合意する」というのはまさにサービスレベル管理です。また、サービスレベル・アグリーメント（SLA）に基づき、ITサービスの可用性や継続性、キャパシティについて考えていく基本姿勢は、ITIL v2 をそのまま受け継いでいます。ITIL v3　ではそれに加えて、サプライヤ管理やサービスカタログ管理といったプロセスが増えています。

「サービスデザイン」は、この設計部分にフォーカスしています。設計をきちんとしておくことで、そのIT資産を実際の稼働環境に導入するときにもスムーズに行えますし、何らかのトラブル（つまりインシデント）が発生した場合でもその対応の優先度付けや実際の対策も容易になります。「サービスデザイン」でしっかりとした設計を行い、事業を支援するITサービスを包括的にとらえるアプローチを採用することで、続く「サービストランジション」「サービスオペレーション」において、合意したサービスを提供し続けることができるようになるのです。また、事業の目的をいつでも認識することによって、一貫性と統一性をもったIT技術をエンドツーエンドで提供することもできるのです。

さて、次回（4回目）では、いよいよITILv3のライフサイクルを中心とした考え方の一つ一つについてご紹介をしていきましょう。お楽しみに。