ＳＬＡ（Service Level Agreement）

ＳＬＡとは

ＳＬＡ（Service Level Agreement）とは、情報システムの運用にさいして、発注者（利用者）と受注者（提供者）の間で、提供するＩＴサービスの内容と範囲、品質に対する要求（達成）水準を明確にして、それが達成できなかった場合のルールを含めて、あらかじめ合意しておくこと、あるいは。合意内容を文書化した契約書のことです。
　例えば、次のような合意内容があります。
　　・システムの稼働率を９９％以上にする。
　　・システムが故障したときは、最大５時間以内で復旧する。
　　・注文データは入力してから結果が得られるまでの時間を５秒以内とする。
　　・ヘルプデスクでは、質問に１回の電話で答える割合を８０％以上とする。

ＳＬＡを行う時期

情報システム開発の受注者が、納品した情報システムの機能や性能について保証する場合と、納入後の運用を新たに契約する場合があります。そのため、受注者ごとにＳＬＡを行うこともあります。

ＳＬＡは、運用段階に入る時点で行うのが適切です。企画段階や設計・開発段階の業務は、繰り返して行われないので、サービスの品質を継続的に測定することができないからです。しかし、情報システムのエラー発見率や応答時間などに関しては、情報システムの設計に大きく関係しますので、ＲＦＰに示したり、開発契約に明記することが必要な項目もあります。

ＳＬＡの必要性と効果

物事には完全を期待できません。十分にテストしたつもりでも、発見できない誤りがあります。ネットワークは、多様な原因により障害が発生します。これらの発生確率を低く抑えたいのは当然ですが、確率を下げる、すなわち、サービスレベルを上げるには、大きな費用がかかります（参照：「システム障害の日米比較」）。

どの程度のサービスレベルが適当かについて、発注者と受注者の間の合意がないと、トラブルの原因になります。そこで、委託者と提供者の間で誤解や不満が起こる原因であった曖昧さの排除を目的として、契約時に、双方の間でサービス品質の水準を明確にすることが必要なのです。
　ＳＬＡを行うことにより、
　　・発注者は、期待通りのサービスが保証され、権利が確保される。
　　・受注者は、提供責任を明確にし、これを全うしたことを証明できる。
　　・双方にとって、責任のなすりあいのようなトラブルになるのを回避できる。
などのメリットがあります。

ＳＬＡ対象項目とレベルの選定

ＳＬＡの対象項目は、次の基準で選ぶのが必要です。

• あまり多くの項目を対象にすると、管理が面倒になり、結果として効果が得られません。重要な項目に絞るのが適切です。
• 稼働率が重要な業務もあれば、応答時間が短いことが重要な業務もあります。対象業務により、項目やレベルを変えるべきです。
• 客観的な定量データが容易に得られる項目にするべきです。利用者へのアンケートなどは、主観的であり、定性的なので、せっかく入手しても解釈に違いが生じます。また、測定データを得るのに多大な作業を伴うものは、長続きしません。

サービスレベルの設定には、次の２つがあります。
　　・目標保証型：受注者が責任を負うレベル
　　・努力目標型：努力はするが、責任までは問われない
　また、目的保証型で達成できないときはペナルティを課し、努力目標型で達成したときにはインセンティブを与えるといった契約にすることもあります。 　努力目標型では強制力がないのが欠点ですが、それでも双方でサービスレベルが明確になりますし、合意を得るのが容易です。

ＳＬＭ

ＳＬＡを作成しただけでは効果がありません。
　・サービスレベルが定期的にモニタリングされ、
　・サービスレベルの状況と異常時対応などが定期的に報告され
　・発注者と受注者がサービス改善に建設的な検討を行ない
　・継続的に改善が行われる
ようにマネジメントすることが大切です。
　こうした活動をＳＬＭ（Service Level Management）といいます。

• ＳＬＭ運用会議
  ＳＬＡで設定したサービスレベルが達成していることを確認し、未達成のときには改善方法を協議するための会合をＳＬＭ運用会議といいます。これは定期的に、重要な問題が発生したときは臨時的に開催されます。
  通常は、受注者からＳＬＡ達成状況や未達成の対策案を発注者に説明する形式になります。このとき、受注者が被告、発注者が検事のような立場になると、適切な運営ができません。ＳＬＡ達成のための協力体制であるとの認識が必要です。
• 項目やレベルの改訂
  ＳＬＡは固定的なものではありません。情報システムの運用を続けている間に、重要な項目が欠けていることに気づいたり、当初は重要だと思った項目が、実際にはさほど重要ではないとわかることもあります。
  　取扱データ量の増大や他の情報システムの導入などにより、従来の設定レベルを保証することが困難になる場合もあります。ハードウェアの変更により、設定レベルが自動的に達成されるので、管理する必要がなくなる場合もあります。
  　これらの変化に応じて、ＳＬＡの対象項目やサービスレベルを改訂する必要があります。
• 成熟度による改訂
  ＳＬＡに関する成熟度が低い状況のときに、ペナルティやインセンティブ規定をつけたＳＬＡを作成しようとすると、発注者も受注者も自己主張をすることになり、なかなか合意に達しませんし、責任のなすりあいになってしまいます。
  当初は、ＳＬＡについて双方の認識を確認して、サービスの項目やレベルでの合意をとること、ＳＬＭ運用会議を設置して開催することがポイントになります。そして、相互の信頼関係が高まった段階で、ＳＬＡの見直しや改善を図るなど、発展させることが大切です。

ＳＬＡの標準

ＳＬＡの対象項目やレベルは、対象情報システムにより、発注契約対象により大きく異なりますが、参考になる標準やガイドラインがあります。
経済産業省『情報システムに係る政府調達へのＳＬＡ導入ガイドライン』２００４年
ＪＥＩＴＡ（電子情報技術産業協会）『民間向けＩＴシステムのＳＬＡガイドライン（第３版）』２００６年
ＩＴコーディネータ協会『ＲＦＰ・ＳＬＡ見本』
ＳａａＳ環境に特化したもの
経済産業省『ＳａａＳ向けＳＬＡガイドライン』２００８年
ＪＥＩＴＡ（電子情報技術産業協会）『民間向けＩＴシステムのＳＬＡガイドライン-追補版：SaaS対応編』２００８年