ＳＬＡ（Service Level Agreement）

ＳＬＡとは

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

ＳＬＡを行う時期

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

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

（注）ソフトウェアの検収にあたり，一定期間内に発見された欠陥に対して，開発側が無償で修正を行ったり損害賠償責任を負ったりすることを瑕疵担保責といいますが、ＳＬＡは瑕疵担保責任とは異なります。
　ＳＬＡは瑕疵担保責任の対象よりも広い範囲、複数のシステム全体を対象にすることもあります。また、契約先も該当システム提供者に限定せず、第三者のＩＴサービス業者と契約することもあります。

ＳＬＡの必要性と効果

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

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

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

ＳＬＡの目的は、（広義の）可用性を大きくすることであり、可用性管理といいます。可用性管理は次の４つで構成されます。

• （狭義の）可用性：利用者がＩＴサービスを必要とした時間内に、実際にサービスを利用できた時間の割合
  例えばシステムが１００時間のうち１回故障して復旧までに１時間かかったのであれば、可用性は１％となります。サービスレベルを０.５％にするには、復旧時間を３０分にする必要があります。
• 信頼性：システムの壊れにくさのこと
  上の例で、１０回故障したが６分で復旧した場合、可用性は同じ１％ですが、「しょっちゅう使えない」ことになり、信頼性が低いといえます。
• 保守性（能力）：障害が起こったときに通常の状態に回復させる能力
  １時間を３０分に短縮できる能力です。そのたまの知識経験だけでなく、ＩＴＩＬのような総合的な体制が重要になります。
• 対障害弾力性：障害が発生しても、継続して機能する能力
  機器の多重化や自家発電装置の設置などの対策です。

このうち対障害弾力性は多分に利用者側の決定事項ですので、ＳＬＡとしては他の３つに着目して対象項目やサービスレベルを設定するのが適切です。

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

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

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

ＳＬＡの対象項目やサービスレベルへの要求は、運用経過とともに変化します。当初は大きな問題だったのに対策を講じて安定して満足する状態になったときには、もはや対象にする必要がないでしょう。逆に、当初予測した以上にシステムの利用度が高まったときには、応答時間の遅れが深刻な問題になるなど、新しい項目やサービスレベルの見直しが必要になります。
　また、当初は予見が不十分だったために、「とりあえず」の設定をしたので、現実には到底実現できない／あまりにも緩やかで利用者の満足が得られないという状況が発生することがよくあります。
　そのため、ＳＬＡは逐次改訂する必要があります。それをマネジメントとして行うのがＳＬＭです。

ＳＬＭ

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

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

ＳＬＡの標準

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