ITIL サービスデザイン − サービスデザイン概要２

Vol.005 - 2008年12月02日（月2回発行）

今回は前回に引き続き、「サービスデザイン」の概要をもう少し詳しくお話します。
4回目ではおおまかに、以下のようなことを述べました。

• サービスの具体的な内容を決めるのは「サービスデザイン」の仕事である
• ビジネスニーズをITサービスに変換する役割を果たすのが「サービスデザイン」である

これらをうまく実現するためにには、どのような方針、あるいは方策を念頭に置いておけばよいでしょうか。今回は、サービスデザインの目標や原則にフォーカスをあてて詳しく説明します。

まずは、「サービスデザイン」の目標からです。「サービスデザイン」の最終目標は「設計すること」です。前述の「ビジネスニーズをITサービスに変換する」作業とは、すなわちITサービスやそれに付随するさまざまなものを設計することに他なりません。では、何を何のために設計するのでしょうか。

まず何を、という部分についてです。

• ITサービスそのもの
• 管理するためのプロセス、およびプロセスを支援するためのツール、仕組み、情報、サービス・ポートフォリオなど
• IT資産（リソース／能力）
• 成果の測定方法と測定基準
• 計画や方針、およびそれらをまとめた文書

「サービスデザイン」は、これらのことを設計する責任があります。

IT資産の「リソース／能力」とは、コラムの第2回目で「材料と道具」という言葉で説明をしたものにあてはまります。ITIL では IT資産を、ITインフラストラクチャやソフトウェアなどの「リソース」と、組織体制やスタッフのスキル、管理体制といった「能力」とから構成される、と解いています。

一方、それを何のために設計するかというと、次のような理由が挙げられるでしょう。

• 品質、コンプライアンス、リスク、およびセキュリティの観点で事業達成目標を成し遂げるため。
  ビジネス・ニーズに整合した効果的・効率的なITサービスを提供するため。
• コストの最適化、および削減のため。
• サービスをそのライフサイクル全体を通して管理できるようにするため。
• サービスを開始する前にリスクを排除または軽減できるようにするため。
• セキュリティで対障害弾力性を高い水準に保つため。
• 設計プロセスとその成果物の有用性と効率性を評価するため。

設計がどれだけ重要であるか、これを見ただけでも十分すぎるほどわかりますよね。

具体的な例で考えてみましょう。前回は、「レストランを経営する」ということを例に挙げました。それではちょっと広すぎるので、その中でも「お客様からの食事代金を回収する」という部分にフォーカスしてみることにします。

食事が終わったお客様から食事代金を回収するには様々な方法が考えられます。一番原始的なやり方は、食事代金を暗算や計算機などで計算し、それを現金で徴収することです。お客様からもらったお金は手提げ金庫のようなところに保管します。お釣りもそこから出すようにします。しかしこの方法では、お客様がどの料理を注文したかという履歴が残りません。クレジットカードでの支払いにも対応できないでしょう。

ビジネスサービス側のニーズとして、例えば次のようなことが考えられるでしょう。

• いつ、どの料理がどれだけ売れたかという履歴をとりたい
• 会計時に、客層（カップルとか家族連れとか友人同士とか）をカテゴリ分けしたい
• クレジットカードでの決済にも対応したい
• 月末には自動的に売上管理簿ができあがるようにしたい

これらをITの力を借りて実現しようと「設計」するのが、「サービスデザイン」の役割なのです。しかしそれはただ「十分な性能のPOSレジを導入する」ということを決定するだけではありません。POSレジにどのような機能を持たせるのか、ビジネスニーズにどのように応えるのか、どのようなインフラストラクチャやソフトウェアを用いるのか、といったことを決定するのはもちろんのこと、ビジネス上許されるレベルの可用性の範囲、故障時の対応方法や連絡体制、 POSレジ業者やクレジットカード業者との契約内容、といったことまできちんと設計しておく必要があるのです。

もちろん、設計した内容がちゃんとビジネスニーズを満たす必要があります。その基準ともいえるものが、SLA（Service Level Agreement）です。顧客サービスプロバイダとの間でサービス内容やサービスレベルについてきちんと討議し、合意しておく必要があります。さらにその合意内容は、顧客のわかる言葉で文書化しておかなければなりません。ITIL v2 にも登場したSLAの考えた方は、ITIL v3 でもそのまま引き継がれています。そしてその SLA を作るのも「サービスデザイン」の重要な役割のひとつなのです。

SLAを支援するものが、サービスプロバイダ内部の合意文書であるOLA（Operational Level Agreement）と UC（Underpinning Contract）です。この考え方も ITIL v2 と同じです。ただ、UC は請負契約ではなく、外部委託契約という訳に変更になりました。

ここで少し脱線して、用語の定義を明確にしておきましょう。ITIL v3 では、顧客にITサービスを直接提供する組織のことを「サービス・プロバイダ」と言う、と定義しています。サービスプロバイダは自社内に存在するかもしれない（内部サービス・プロバイダ）し、社外にアウトソーシングしているかもしれません（外部サービス・プロバイダ）。同じく、サービス・プロバイダから見た顧客も社内にいる場合と社外にいる場合とがあります。内部サービス・プロバイダにとっての顧客は内部顧客であり、外部サービス・プロバイダにとっての顧客は外部顧客です。顧客とサービス・プロバイダとの間で取り交わす合意文書が SLA です。一方、そのサービス・プロバイダを様々な形で支援する外部のサードパーティのことを、サプライヤといいます。ITIL v3 では、サプライヤのことを「商品やサービスの供給を責務とするサードパーティ」であると定義しています。サプライヤは顧客に、間接的に（サービス･プロバイダを通じて）商品やサービスを提供します。サービス・プロバイダとサプライヤとの間で取り交わす契約が UC です。「サービス・デザイン」は、このサプライヤを効果的に活用するための「サプライヤ管理」という側面も持っています。これは、サプライヤから投資に見合う価値をちゃんと得ているかどうかとか、UC の内容がちゃんとビジネスニーズにマッチしているかどうかなどを管理するものです。

サービスデザインが備品やスタッフの導入計画を立てたり、事業ニーズの変化による備品などの変更計画を立てたりする際に気をつけなければならないことは、導入する備品の機能要件だけを重要視しすぎないことです。高機能な備品は価格が高くなってしまったり、入手が困難になってしまったりする傾向があります。さらに高機能な備品を使いこなすまでのスタッフの教育にも時間がかかってしまうこともあります。もちろん、それだけの高機能が必要なのかといったことも重要です。そもそも機能性というのは様々な側面から考えるべきものでしょう。それらを端的に表したものが図１です。開発環境はよく「コストと品質と納期のバランスが大事だ」と言われます。設計においても同じことが言えるでしょう。提供すべきサービスを企業（ここの例題ではレストラン）の戦略やガバナンスの視点から考え、事業要件に応じたサービスを設計する必要があります。その際、設計するサービスの「機能性」、設計したサービスを顧客やユーザへ提供する納期的時間（スケジュール）、設計に用いる様々な資産（リソース）の3つの要素を、絶妙なバランスを保ちながら確保してゆく必要があります。設計マネージャ、開発マネージャの腕の見せ所といったところでしょうか。「サービスデザイン」は、これらのバランスを保つために有効に働きます。

図1：微妙なバランス

さて、前述のとおり「設計」とは、提供するサービスそのものやそのためのITインフラストラクチャだけを設計するわけではありません。設計には大きく５つの側面があります。

• サービス・ソリューションの設計
  ・・・事業要件とサービス要件との整合性をとるための、サービスそのものやITインフラストラクチャなどの設計
• 技術アーキテクチャの設計
  ・・・適切なITサービスを展開、運用、改善するための、ITの方針、戦略、アーキテクチャ、文書などの設計
• プロセス設計
  ・・・サービス・ライフルサイクルで使用される ITIL プロセスの設計
• 測定の仕組みと測定基準の設計
  ・・・最適なソリューションが選択されているか、プロセスはどの程度成熟しているかなどを管理するために必要な測定の設計
• サービス・ポートフォリオの設計
  ・・・ライフサイクル全体を支援する仕組み

「技術アーキテクチャ」とは、何もIT技術に限ったことではありません。ごく一般的な「技術」、「アーキテクチャ（具現化する仕組み）」のことです。もちろんITアーキテクチャもこの中に含まれますが、そのほかにもビジネス・モデル、人材、文書の種類や書き方などにも様々な技術があり、アーキテクチャがあります。それらを設計することを意味しているのです。

この中で最も聞きなれない言葉は「サービス・ポートフォリオ」という言葉でしょう。サービス・ポートフォリオとは、事業価値の面からプロバイダのサービスを説明・記述するために必要な管理の仕組みやツールのことをいいます。

もともとポートフォリオ(portfolio)とは、紙ばさみや折りかばん、ファイルなどのことです。持ち運びのできるポータブル(PORTable)な紙（FOLIO）のことです。それが転じて、将来にわたって価値のある情報を集めて一覧にしたもの、というような意味合いが生まれました。金融の世界では、各種の金融資産の一覧表のことを指したり、その情報を活用してローリスク・ローリターンの商品とハイリスク・ハイリターンの商品を用いてバランスよく資産運用する手法のことを指したりします。

サービス・ポートフォリオも同じようなことがいえます。サービス・プロバイダが提供するサービスと、そのサービスにまつわるすべての情報（前に述べた SLA とか サプライヤとの契約とか IT資産とかビジネス・プロセスとか）をまとめた中心的なリポジトリです。最終的にサービス・ポートフォリオは、以下のようなことを顧客に説明するための根拠となるのです。

• このサービスはどのような価値を顧客にもたらすか？
• ビジネス・ニーズに、我々のサービスはどのように対応づけられるか
• このサービスを我々（サービス・プロバイダ）から購入するメリットは何か？
• 課金の仕組みや根拠はどのようなものか？
• 我々の強みと弱みはどんなものか？
• 我々が現在持っているサービスのステータスはどのようなものか？

このように、企業内、組織内の全てのサービスに関わるすべての内容が記載されることになるサービス・ポートフォリオは、サービスナレッジ管理システム（SKMS）の一部として構成されることになります。さらにそれは、構成管理システム（CMS）に文書として登録されるべき内容でもあります。SKMS や CMS に関する詳細は、いずれ「サービス・トランジション」の説明をするときに解説します。

また、サービス・ポートフォリオには企業内にあるサービスの全てと、そのサービスに関する現在の最新のステータスを記載します。サービスの最新情報を記載するというのは、新たに導入を計画中であるようなサービスや、すでにサービスが終了し、廃棄してしまったサービスについても記載することになります。ただし、計画中であるサービスは、顧客にはまだ見せません。少なくともそのサービスを提供すると決定され、制定されたものしか公開しないのです。つまり、サービス・ポートフォリオは顧客側から見える部分と見えない部分があるということになります。見える部分はすなわちサービスカタログです。そして見えない部分はサービス・パイプラインと呼ばれます（図２）。

図2：サービス・ポートフォリオの内容

以上のようにサービスデザインの役割は、従来でいうところのITシステムの設計のみならず、サービスライフサイクル全般にわたる管理手法の設計や測定方法の設計など、大変幅広いものです。そしてここで設計された（ITシステムの設計も含む）様々な内容は、このあとに続く「サービストランジション」から「継続的サービス改善」まで揺らぐことのない、一貫したものとなるのです。

さて次回は、さまざまな「ソーシング」についてお話をします。ITIL v3 では、サービス・プロバイダは必ずしも社内にいるわけではない、という「現実に即した」考え方に改められています。古くからアウトソーシングを上手に使うことによって効率とコスト削減が可能になると考えられてきましたが、ITIL v3 での分類は「インソーシング」と「アウトソーシング」だけではありません。そのあたりのお話を中心にしてまいります。