情報システムの運用では多くの障害が発生します。その障害の発生頻度や対策について、発注者と受注者が共通した認識を持ち、合意することをＳＬＡといいます。そして、ＳＬＡを円滑に運営し改善する管理をＳＬＭといいます。
ここでは、ＳＬＡ／ＳＬＭの必要性、その導入や改善における留意事項などについて説明します。
ＳＬＡ、ＳＬＭ、ＩＴサービス
ＩＴサービスとは、情報システムの受注者（提供者）が発注者（利用者）対して、システムの品質や性能、システム運用やヘルプデスクなど、システムに関連するサービス全体のことです。
ＳＬＡ（Service Level Agreement）とは、情報システムの運用にさいして、発注者（利用者）と受注者（提供者）の間で、提供するＩＴサービスの内容と範囲、品質に対する要求（達成）水準を明確にして、それが達成できなかった場合のルールを含めて、あらかじめ合意しておくこと、あるいは。合意内容を文書化した契約書のことです。
たとえば、次のような合意内容があります。
情報システム開発の受注者が、納品した情報システムの機能や性能について保証する場合と、納入後の運用を新たに契約する場合があります。そのため、受注者ごとにＳＬＡを行うこともあります。
ＳＬＡは、運用段階に入る時点で行うのが適切です。企画段階や設計・開発段階の業務は、繰り返して行われないので、サービスの品質を継続的に測定することができないからです。しかし、情報システムのエラー発見率や応答時間などに関しては、情報システムの設計に大きく関係しますので、ＲＦＰに示したり、開発契約に明記することが必要な項目もあります。
物事には完全を期待できません。十分にテストしたつもりでも、発見できない誤りがあります。ネットワークは、多様な原因により障害が発生します。これらの発生確率を低く抑えたいのは当然ですが、確率を下げる、すなわち、サービスレベルを上げるには、大きな費用がかかります。
どの程度のサービスレベルが適当かについて、発注者と受注者の間の合意がないと、トラブルの原因になります。そこで、委託者と提供者の間で誤解や不満が起こる原因であった曖昧さの排除を目的として、契約時に、双方の間でサービス品質の水準を明確にすることが必要なのです。
ＳＬＡを行うことにより、
・発注者は、期待通りのサービスが保証され、権利が確保される。
・受注者は、提供責任を明確にし、これを全うしたことを証明できる。
・双方にとって、責任のなすりあいのようなトラブルになるのを回避できる。
などのメリットがあります。
ＳＬＡの対象項目は、次の基準で選ぶのが必要です。
サービスレベルの設定には、次の２つがあります。
・目標保証型：受注者が責任を負うレベル
・努力目標型：努力はするが、責任までは問われない
また、目的保証型で達成できないときはペナルティを課し、努力目標型で達成したときにはインセンティブを与えるといった契約にすることもあります。
努力目標型では強制力がないのが欠点ですが、それでも双方でサービスレベルが明確になりますし、合意を得るのが容易です。
ＳＬＡを作成しただけでは効果がありません。
・サービスレベルが定期的にモニタリングされ、
・サービスレベルの状況と異常時対応などが定期的に報告され
・発注者と受注者がサービス改善に建設的な検討を行ない
・継続的に改善が行われる
ようにマネジメントすることが大切です。
こうした活動をＳＬＭ（Service Level Management）といいます。
ＳＬＡで設定したサービスレベルが達成していることを確認し、未達成のときには改善方法を協議するための会合をＳＬＭ運用会議といいます。これは定期的に、重要な問題が発生したときは臨時的に開催されます。
通常は、受注者からＳＬＡ達成状況や未達成の対策案を発注者に説明する形式になります。このとき、受注者が被告、発注者が検事のような立場になると、適切な運営ができません。ＳＬＡ達成のための協力体制であるとの認識が必要です。
ＳＬＡは固定的なものではありません。情報システムの運用を続けている間に、重要な項目が欠けていることに気づいたり、当初は重要だと思った項目が、実際にはさほど重要ではないとわかることもあります。
取扱データ量の増大や他の情報システムの導入などにより、従来の設定レベルを保証することが困難になる場合もあります。ハードウェアの変更により、設定レベルが自動的に達成されるので、管理する必要がなくなる場合もあります。
これらの変化に応じて、ＳＬＡの対象項目やサービスレベルを改訂する必要があります。
ＳＬＡに関する成熟度が低い状況のときに、ペナルティやインセンティブ規定をつけたＳＬＡを作成しようとすると、発注者も受注者も自己主張をすることになり、なかなか合意に達しませんし、責任のなすりあいになってしまいます。
当初は、ＳＬＡについて双方の認識を確認して、サービスの項目やレベルでの合意をとること、ＳＬＭ運用会議を設置して開催することがポイントになります。そして、相互の信頼関係が高まった段階で、ＳＬＡの見直しや改善を図るなど、発展させることが大切です。
ＳＬＡの対象項目やレベルは、対象情報システムにより、発注契約対象により大きく異なります。しかし、参考になる標準やガイドラインがあります。
ＩＴＩＬ（IT Infrastructure Library）は、ＩＴサービスマネジメントのベストプラクティスについて記述したものです。それをベースにして国際規格であるＩＳＯ２００００が策定されました。ＳＬＡ／ＳＬＭは、これの一部と位置付けられます。
経済産業省『情報システムに係る政府調達へのＳＬＡ導入ガイドライン』平成１６年３月
http://www.meti.go.jp/policy/it_policy/tyoutatu/sla-guideline.pdf
電子情報技術産業協会（ＪＥＩＴＡ）『民間向けＩＴシステムのＳＬＡガイドライン（第３版）』日経ＢＰ社、２００６年
http://home.jeita.or.jp/is/committee/solution/061002guideline/index.html
ＩＴコーディネータ協会『ＲＦＰ・ＳＬＡド見本』
http://www.itc.or.jp/foritc/useful/knowhow/rfpsla/rfpsla_main.html