ITIL サービスデザイン − サービスレベル管理

Vol.008 - 2009年02月09日（月2回発行）

前回に引き続き、サービスデザインの「7つのプロセス」について解説を進めていきましょう。今回はサービスデザインのふたつめのプロセスである「サービスレベル管理」についてです。サービスレベル管理は、ITIL v2 のときには「サービスデリバリ」の中のプロセスでした。ITIL v3 では「サービスデザイン」の中に含まれます。基本的な考え方は ITIL v2 と大きくは変わっていません。とはいうものの、サービスレベル管理が扱う SLA が、サービスデザインの残りのプロセスのみならず、「サービストランジション」や「サービスオペレーション」、そして「継続的サービス改善」などの活動の根拠になるものですので、おろそかにはできません。

サービスレベル管理（SLM）の最大の目的は、SLAを作成し、維持することです。

これは大きく３つの側面がある、と考えることができます。

• 適切なITサービス目標値について顧客と交渉し、合意し、文書化する
• 実際に提供しているITサービスが合意された目標値を達成しているかどうかモニタリングし、測定し、顧客に報告し、必要であれば改善する。
• 時折サービスレベルを見直し、顧客との良好な関係を維持する。

ひとつひとつ具体的に見ていきましょう。

まずは、ITサービスの目標値を顧客と合意する、という側面です。これが最も重要な部分であると考えられます。ITサービスの目標値を合意し、文書化したものが SLA（Service Level Agreement）です。SLA は、ITサービスを受ける側である顧客やユーザと、そのITサービスを提供するサービス・プロバイダとの間で、実際に提供されるサービスの内容や程度、サービス時間、費用といったようなことを互いにすり合わせ、お互いに納得し合意した内容を文書化したものです。SLAに含めるべき内容の例を表１に載せます。

表１：SLAに含めるべき内容の代表例

• サービスの名称
  例：電子メール送受信サービス
• サービスを提供する対象
  例：○○株式会社の全従業員
• サービスの適用期間
  例：2009年1月1日より
• サービスの適用条件
  （SLAが有効となるために必要な条件を書いておく。例えば災害時や突発的な事象が発生した場合はどうするかなどもあらかじめ決めておく）
• サービス提供の目標値
  例1：サーバの稼動率
  例2：障害時の復旧目標時間
  例3：メールボックスの最大数
  例4：メールボックスの最大サイズ
  （稼働率だけでなく、キャパシティやセキュリティなどに関する項目も決めておくとよい）
• M料金体系
  （基本料金、追加料金、追加料金が発生する条件、課金の有無、課金方法など）
• 顧客側の責任者
• サービスプロバイダ側の責任者
• 問い合わせ窓口
• 問い合わせ時間
• サービスレベルの報告の方法と頻度
  （サービスレベルを達成しているかどうかを顧客に報告するためのもの）
• サービスレベルの見直しのタイミングと頻度
  （目標値の変更やサービスの追加、削除など）
• 賞罰
  （ただし、ITILでは言及していない）

SLAを作成するための基になる文書は、サービス・カタログとサービスレベル要件（SLR）です。サービス・カタログはサービス・プロバイダが提供しうるサービスのカタログであり、SLR とは顧客がITサービスに求める具体的な要件です。サービス・カタログの作成はサービスカタログ管理の範疇ですが、達成可能な SLA を作成するための重要なインプットであることは間違いありません。一方、顧客が求めるサービス要件をまとめた文書である SLR を作成するのは、サービスレベル管理の範疇です。もっとも、荒唐無稽な（実現不可能な）サービス要件を顧客から突きつけられても困りますし、サービスプロバイダ側から顧客に対して「必要なサービス要件を挙げてくれ」と申し出ても、おそらく顧客は困ってしまうでしょう。そのため SLR の草案は、サービス・プロバイダ側から提出することになります。

SLAをとりまく他の文書

SLAは（顧客にとってもサービス・プロバイダにとっても）現実的であり、達成できたかどうかの指標がはっきりしており、かつ客観的でなければなりません。これは ITIL書籍に書かれていることではなく筆者が勝手に提唱するものですが、SLA は SMART に作ると良いでしょう。すなわち

• Specific ・・・具体的であること
• サプライヤMeasurable ・・・測定可能であること
• サプライヤAchievable ・・・達成可能であること
• サプライヤRealistic ・・・現実的であること
• サプライヤTime bounded・・・時間的制限があること

ということです。少し話は脱線しますが、ある企業の SLA で「ネットワークの可用性は 99%」というものがありました。しかし顧客側はこのネットワークはインターネットへの接続も含まれていると解釈し、サービス・プロバイダ側は社内ネットワークに関するものだと解釈していたため、きちんと SLA が締結されているにもかかわらず混乱が起きました。SLA はこのようなことのないよう、できるだけ具体的で、誰が見ても同じ解釈ができるように記述する必要があります。

ところで SLA にはたいてい賞罰がつきものです。達成できた場合のインセンティブや達成できない場合のペナルティなどを定めておかないと、顧客・プロバイダ双方が SLA 達成のための努力を払わない可能性がある、というのは残念ながら事実です。しかし、ITIL では SLA に対する賞罰に関してはまったく触れられていません。これは SLA が Agreement、すなわち「合意」であり、契約（Contract）ではないという側面が強く出ています。厳しいペナルティを決めてしまうと、サービス・プロバイダは努力しなくても達成できるような低いレベルの（しかも事業目標の達成にあまり有効ではない）サービスレベルしか提供しなくなってしまうだろう、というのです。確かに ITIL 的な考え方はそうなのですが、この賞罰という部分は非常にデリケートな問題ですので、実際には企業のカルチャや実績などに照らし合わせて盛り込んでいったほうがいいでしょう。