ITIL サービスデザイン − サービス・カタログ管理

ITIL V3で登場のサービスカタログ管理。わかりやすそうで、実は奥が深い！今回のコラムを読めば、その奥深さを理解いただけます。
by BMCソフトウェア編注

Vol.007 - 2009年01月14日（月2回発行）

今回からサービスデザインの7つのプロセスに話題を移します。1回あたり、1つのプロセスを取り上げる予定です。ところで、今までこのコラムでは「プロセス」という言葉を出来る限り使わないようにしてきました。ITIL v2 との区別を明確にするためです。ITIL v2 関連の書籍では、どれもがITIL本の赤本、青本に関してのみ解説していて、さらに「１つの機能と10のプロセス」がすべてであるかのように書かれています。それはそれで間違いではないのですが、そのように解釈をしたために、ITIL＝運用管理、ITIL＝プロセスという誤解をも生むことになりました。itSMF も ITIL v3 ではそれを恐れているらしく、7冊の本すべてに書かれている内容を5冊にまとめなおした上に、プロセスはあくまでも ITIL を推進していくための手段に過ぎない、という位置づけをとっています。そのためプロセスそのものの解説は、ITIL v2 の頃に比べて簡単になっている、という印象を受けます。プロセスよりも、そのプロセスにいたるまでの考え方のほうが重要だ、ということでしょう。IITL 本にも、「どのようにやるか」よりも「何をやるか」のほうが重要だ、と書かれています。

また、ITIL v2 のときと同じプロセス名のものがあっても、ITIL v3 のプロセスは内容が微妙に異なります。もちろん基本的なことは同じです。しかし、詳しさや論点が変わっている部分もあるのです。ITIL v2 のプロセスの事はちょっと忘れて（ちょっとむりかもしれませんが）読み進めていってください。

さて、「サービスデザイン」には以下の７つのプロセスがあります。

サービス・カタログ管理
サービスレベル管理
キャパシティ管理
可用性管理
ITサービス継続性管理
情報セキュリティ管理
サプライヤ管理

ITIL本「サービスデザイン」の中には、これらのサービスデザインのプロセスは「主に、新規または変更されるサービス・ソリューションの設計に対して、重要な情報を

提供することに責任を持つ」とあります。以前にも書きましたが、これは「サービスの具体的な内容を決めるのは『サービスデザイン』の仕事である」ということを示しています。ITサービスのデザインの内容を決めるときに、上記の7つのプロセスがどのような役割をしているのかひとつひとつ確認していきましょう。

今回は、サービス・カタログ管理を取り上げます。「サービス・カタログ」とは、「顧客に提供されるサービスの一覧表」のことです。電化製品や化粧品、車や洋服などを購入する際に参照する商品カタログと同じである、と思っていいでしょう。サービス・プロバイダが提供しうるサービスはおおきく２つに分けられます。それは顧客から見えるサービスと、顧客からは見えないサービスです。具体的には、現在進行形で顧客に提供しているサービスや、提供が決まっていて準備中であるサービスは、顧客から見えるサービスであると言えます。一方で構想が練られている段階でまだ提供できると決まっていないサービスや、完全に提供が終わってしまったサービスは、顧客から見えないサービスです。このうち、顧客から見えるサービスをわかりやすく一覧にしたものがサービス・カタログです。また、そのサービス・カタログを含め将来提供するであろう内容や提供が完了したサービスも含めた全体が、サービス・ポートフォリオなのです（図１）。

図１：サービス・ポートフォリオとサービス・カタログの関係

顧客から見えるのはサービス・カタログの部分だけですが、それは残念ながらすべてのサービスの全体像を明確に示しているとは言えません。サービスの全体像を明確に示すためには、過去に必要とされてきた／提供してきたサービスや、将来必要となるであろう／提供するであろうサービスも明確にしておく必要があります。そういった意味でサービス・プロバイダは、サービス・カタログだけでなくサービス・ポートフォリオ全体を一貫性を持った一元的な情報源として管理していく必要があるのです。さらにサービス・カタログは、そのサービス・ポートフォリオ全体と矛盾のない、正確でわかりやすいものでなければなりません。

サービス・カタログによって、顧客は自分たちが受けるITサービスの内容や情報などの全てが分かるようになりますし、逆にいうとサービス・カタログはそのように作らなければなりません。サービス・カタログ管理の目的は、合意されたすべてのサービスに関する一貫した情報源−つまりサービス・カタログ−を提供することです。正確なサービス・カタログは、顧客側にとって自分たちがどのようなサービスをどのような形で受けることができるのかわかるというメリットがあり、またサービス・プロバイダ側にとっては、自分たちが提供するサービス内容を一元管理できるようになるというメリットがあります。

たとえば、顧客の情報や市場動向などを調べるためにインターネットに接続したい、という事業ニーズがあったとします。顧客はサービス・カタログを参照し、インターネット接続サービスがあるか確認します。サービス・カタログにインターネット接続サービスが明記されていれば、顧客はインターネット接続ができる、というわけです。さらに、サービス・カタログにはインターネット接続サービスがあるかどうかが記述されているだけでなく、その責任者や対応窓口、サービスレベルやサービス提供時間、課金の有無、（もし有償なら）利用料金、といったことまでわかるように記述します。もちろんこれらの内容は、顧客とサービス・プロバイダとの間で合意できている内容でなければなりません。サービス・プロバイダもこのサービス・カタログを参照することになります。プロバイダにとっては自分たちが提供するサービスの内容がそこにはっきりと示されているわけです。ですから担当者や担当時間、サービスの提供先などによってサービスの内容がぶれてしまうというようなことが防げます。

今も述べたように、サービス・カタログは顧客側もプロバイダ側も参照する、一元的な情報源です。さらに、この後に続くサービスレベル管理やキャパシティ管理、可用性管理などのプロセスが活動する上での重要な根拠にもなります。利用する人や立場が変われば必要な情報も変わります。顧客にとって必要な情報と、プロバイダ側にとって必要は情報は違うでしょう。顧客にとってのサービス・カタログは、顧客に分かる言葉でビジネスに直結した形で書かれている必要があるでしょうし、プロバイダにとってのサービス・カタログは、そのサービスがどのIT資源と密接に関係しているか、という情報が記述されているべきでしょう。

このことを踏まえて、サービス・カタログには二つの側面があります。顧客側から分かりやすくなっている「ビジネス・サービス・カタログ」と、プロバイダが一元管理しやすい「技術サービス・カタログ」です（図２）。

図２：サービス・カタログの２つの側面

「ビジネス・サービス・カタログ」は、顧客視点で書かれたサービス・カタログです。ITサービスとビジネス・プロセス（ビジネス・ニーズ）との関係が、顧客視点で書かれたものです。顧客は自分たちにとって必要で有用なITサービスをビジネス・サービス・カタログから探します。もし存在しなければ要求することになるでしょうし、存在してもビジネスを支援するようになっていないITサービスであれば、改善を要求するでしょう。自分たちのビジネス・プロセスを満足するITサービスを選択し、その提供されるITサービス内容がビジネスを支援するものであれば、その内容に合意します。

「技術サービス・カタログ」は、提供が決まったITサービスの内容と、そのITサービスを影で支援するサービス、ハードウェアやソフトウェア、必要なデータといったIT資源、その他様々なCIとの関係を、プロバイダ視点で書いたものです。また、ビジネス・サービス・カタログを支える上でも、ほかのプロセスに対して情報を提供する上でも、重要なサービス・カタログとなります。技術サービス・カタログは顧客の視点で書かれるものではないため、その内容はよりITシステム寄りになります。

重要なことは、この「ビジネス・サービス・カタログ」と「技術・サービス・カタログ」を混同しないことです。ITシステムそのものはサービスではありません。サービスは必ず複数のITシステムと密接に関係していますし、ITシステムも複数のサービスと密接に関係しています。また、ひとつのビジネス・プロセスは複数のサービスを必要とするでしょうし、ひとつのサービスは複数のビジネス・プロセスを支援します。このふたつの側面を矛盾なく正確に含むサービス・カタログを作成することが重要なのです。このふたつの側面の関係は、図３に表します。

図３：ふたつの側面の関係

サービス・カタログは顧客、プロバイダ双方にとってコミュニケーションがとりやすくなる文書だけでなく、他にも次のようなメリットがあります。

よりプロアクティブな管理を促すことが出来る
サービスレベル管理プロセスの開発が進みやすくなる
SLAやOLAに合意しやすくなる
インシデントに対する対応が迅速になる
ITサービス継続性管理との調整がしやすくなる

サービス・カタログ管理にとってもっとも重要なことは、正確で一貫性のあるサービス・カタログを作成する、ということです。提供されているサービスがサービス・カタログに記載されていないという状態や、サービスとビジネス・プロセスとの関係、あるいはサービスとITインフラとの関係があいまいであるという状態は望ましいことではありません。また、サービス・カタログの内容がどの程度顧客やプロバイダ内のスタッフに認知されているか、ということも重要です。特にプロバイダ内の全ITスタッフに容易に参照できるような仕組みを整えた上で、ITスタッフがサービス・カタログを参照するようなカルチャを作っていかなければなりません。自分たちがどのようなITサービスを提供しているか、ということを正確に認識しておくことが、正しいITサービスを提供するための成功要因となるのです。

サービス・カタログの内容（情報）が変更されたり追加されたりするタイミングは、事業要件が新しく追加されたり変更されたりするときや、サービス内容に変更が起きたときなどです。具体的には新規サービスの開始、既存サービスの変更、廃棄などです。新規サービスに関しては、そのサービスの提供が始まる段階ではなく、準備している段階からサービス・カタログに載せるようにします。

さて、次号ではサービスレベル管理のお話をします。お楽しみに。

前回のコラムで、「外部サービス・プロバイダとサプライヤの違いがわかりますか？」という問いかけがありました。実は Vol.005 でも触れていたのですが、もういちど、ここでおさらいしておきましょう。

ITIL v3 では、顧客とプロバイダは必ずしも同じ組織内にいるとは限らない、となっています。顧客とプロバイダが同じ組織（会社）に所属する場合、それは互いに「内部顧客」「内部サービス・プロバイダ」です。一方、顧客とプロバイダが異なる組織（会社）にいる場合は、互いに「外部顧客」「外部サービス・プロバイダ」となります。つまり、顧客に直接ITサービスを提供しているIT組織のことを「サービス・プロバイダ」というのです。顧客とサービス・プロバイダとの間は、互いの関係が内部であっても外部であっても、SLAを規定してサービスレベルを合意することになります。

一方、このサービス・プロバイダを様々な形で支援している第三者の組織（つまりサード・パーティ）のことを「サプライヤ」といいます。サプライヤは間接的に顧客にサービスを提供しますが、あくまでもサプライヤが支援するのはサービス・プロバイダです。サービス・プロバイダとサプライヤの間は、外部委託契約（UC）を締結することになります。日本語訳が「請負契約」から変わったことに注意してください。