2024.09.10
IT系のサービスやシステムを開発・提供する過程で、「SLA」という言葉が使われる場面は珍しくありません。
SLAは、サービスやシステムの開発企業のみならず、サービスを利用するユーザーも関与し得るもののため、SLAの理解を深めておくことは有用といえます。
今回はSLA（サービス品質保証）とは何か、概要をご紹介します。SLAに盛り込むべき項目例やメリット・デメリット、注意点も紹介するため、ぜひ参考にしてください。
- もくじ
1．SLA（サービス品質保証）とは？
この章では、 SLA（サービス品質保証）とは何か、SLAと混同されやすいSLO（サービスレベル目標）やSLM（サービスレベルマネジメント）との違いについて解説します。
1-1 SLA（サービス品質保証）とは
SLA（Service Level Agreement：サービス品質保証、サービスレベル契約）とは、サービスやシステムの「提供者」と「被提供者」の間で取り決める品質レベルのことです。
信頼性やパフォーマンスなど、さまざまな品質レベルをSLAで取り決めておき、双方の合意を固めます。
SLAは契約の一種であり、サービス・システムの利用や、受発注に関して提供者と被提供者が契約を交わす際、契約条件の一部として取り決めます。そのため、SLAは法的な拘束力を持つものです。
SLAの締結は、提供者・被提供者の間で品質レベルに対する認識が一致したことを意味します。提供者は品質レベル以上を担保しなければならず、被提供者はサービスに不満を感じたとしても、品質レベルを満たしていれば違反を主張できません。
これにより、契約後の品質に関するトラブルを抑制することができます。
1-2 SLO（サービスレベル目標）との違い
SLAと混同されやすい言葉に「SLO」があります。
SLO（Service Level Objective：サービスレベル目標）とは、サービスやシステムの開発・提供にあたって目標とする品質レベルのことです。
SLAは「最低保証」、SLOは「目標」という違いがあります。
SLOはSLAとは違い、基本的に法的な拘束力を持ちません。多くの場合は被提供者と合意を固めず、サービス提供者が信頼性やパフォーマンスなどに関する目標値をSLOとして設定します。
SLOは開発・提供時の品質管理や、対外的な信用を得る目的で利用可能です。なお、SLAを取り決める際に、努力目標の項目をSLOとして定めるケースもあります。
1-3 SLM（サービスレベル管理）との違い
SLAと関連する言葉に「SLM」があります。
SLM（Service Level Management：サービスレベル管理、サービスレベルマネジメント）とは、SLAで取り決めた品質レベルを管理する一連のプロセスのことです。
このプロセスには、SLAの策定や調整、達成状況のモニタリング、未達時の対処などが含まれています。
SLAを取り決めたところで、正しく管理されなければ意味がありません。 SLAで定めた品質レベルを達成して、維持していくためにはSLMが不可欠といえます。
2．SLAの主な種類
SLAには主に、「サービスのベンダーとユーザーのSLA」と「システムの発注側と受注側のSLA」の2種類があります。
それぞれの状況に応じたSLAの締結について、詳しく把握しておきましょう。
2-1 サービスのベンダーとユーザーのSLA
サービスのベンダー（提供する企業）と、そのユーザー（利用する個人や企業）の間で取り決めるSLAは、主にインターネットを介して機能を提供するクラウドサービスのベンダーが発行して、利用規約などに記載します。
ユーザーがサービスを利用開始する際は、この利用規約に同意してもらい、SLAを締結することが一般的です。
SLAを達成できなかった場合は、月額利用料を減額する、といったペナルティが課される場合もあります。
2-2 システムの発注側と受注側のSLA
システムを発注する側の企業と、受注する側の企業の間で取り決めるSLAは、基本的にBtoBにおいて利用されます。
発注側・受注側がシステム開発案件の契約を交わす際は、あわせてSLAも締結することが一般的です。受注側が最低限保証できる品質レベル、発注側が最低限保証してほしい品質レベルを互いに提示して、すり合わせます。
合意の取れたSLAに沿ってシステム開発を進めることで、品質に関する後々のトラブルを防ぐことができるのです。
3．SLAで取り決められる主な項目
システムやサービスによってSLAで策定する項目が変わるため、絶対的なフォーマットはありません。ここでは、SLAで取り決められる主な6つの項目を紹介します。
3-1 責任範囲
SLAでは、サービスやシステムの提供者がどこまで責任を負うのか、その範囲を明確に定めておく必要があります。
「SLA未達＝ペナルティ」と画一的に取り決めると、提供者が何もかも責任を負わなければならなくなるためです。
極論ですが、ユーザーがベンダーにSLA未達のペナルティを課す目的で、サイバー攻撃を行うケースも考えられます。こうしたケースで提供者が不利益を被らないよう、どこまで提供者が責任を負い、どこからは対象外なのかを明確にすることが大切です。
3-2 可用性
SLAでは多くの場合、「可用性」を定めます。可用性とは、サービスやシステムが正常稼働を維持して、必要な時に利用できる性質のことです。
被提供者は、SLAで可用性を取り決めることで、サービスやシステムが過度にダウンする事態を抑制できます。
具体的には、「稼働率（正常稼働している時間の割合）」をパーセンテージで定めることが一般的です。たとえば「月間稼働率99％」と定めた場合、1か月間のダウンタイムが1％を超えるとSLA未達となります。
3-3 信頼性
SLAでは「信頼性」を定めるケースも少なくありません。信頼性とは、サービスやシステムがダウンしにくい性質のことです。
SLAで信頼性を定めることで、提供者は文字どおりサービスやシステムの信頼性を担保でき、被提供者は過度のダウンを抑制できます。
具体的には、MTBF（平均故障間隔）を定めるケースが一般的です。
たとえば、24時間365日体制で稼働させるサービスの信頼性を「年間MTBF1,000時間」と定めたとしましょう。1年間で10回のダウンが発生した場合、MTBFは8,760(1年の総稼働時間)÷10(ダウン回数)＝876時間となり、SLA未達となります。
3-4 パフォーマンス
SLAでは、パフォーマンス（性能）について取り決める場合もあります。SLAでパフォーマンスの最低保証を定めることで、被提供者は低パフォーマンスに起因する業務への影響を防止することが可能です。
具体的には、応答時間（リクエストに対して応答するまでの時間）を定めるケースが一般的です。たとえば「応答時間3秒以内」と定めた場合、リクエストへの応答に3.1秒を要するとSLA未達となります。
ただし、応答時間はデータ量や回線の混雑状況などの影響を受けるため、約束できるものではありません。そのため、努力目標型のSLOとしたり、一定期間内の平均応答時間としたりするケースもあります。
3-5 セキュリティ
SLAでは、セキュリティについても取り決めることが多いです。
セキュリティ性が低いと、サイバー攻撃による通信内容の漏えいやデータの改ざんなどのリスクが高まります。セキュリティについて取り決めることは、提供者が信用を得る意味でも重要です。
具体的には、通信に対して適用する暗号化方式やデータのバックアップ方法、セキュリティ問題発生時の体制などを定めます。
3-6 違反時のペナルティ
提供者は、実際にSLAで違反があった場合のペナルティについても明確にしておく必要があります。ペナルティが不明確だと、SLA未達時に被提供者は適切な補償を受けられません。
クラウドサービスの場合は、SLA未達時に月額利用料を減額とするペナルティが一般的です。
システム開発の場合は、無償での再納品や、発注側の損害に応じた金銭的な補填など、契約内容によって様々です。
4．SLAを策定・締結するメリット
SLAを策定・締結することは、提供者・被提供者の双方にメリットがあります。ここでは、双方のメリットについて押さえておきましょう。
4-1 ベンダー・受注側のメリット
サービスやシステムの提供者であるベンダー・受注側のメリットは、主に次の3つです。
信頼感を高められる
SLAによって、品質レベルの最低保証を被提供者に提示できます。これにより、被提供者は「一定の品質が保証される」という安心感を得られて、信頼感が高まるでしょう。
品質管理の指標になる
SLAは、サービスやシステムの品質を管理するうえでの指標となります。SLAと稼働実績を比較すれば、品質レベルの達成状況を把握可能です。また、性能やセキュリティなどに関する非機能テストを実施する際にも、テストの期待値として活用できます。
納品後のトラブルを抑制できる
SLAで満たすべき品質レベルを明確にしておくことで、納品後のトラブルを抑制できます。サービスやシステムの稼働開始後に、思わぬクレームを受けるケースも考えられます。その際にSLAを満たしていると証明できれば、クレームを沈静化できるでしょう。
4-2 ユーザー・発注側のメリット
サービスやシステムの被提供者であるユーザー・発注側のメリットは、主に次の2つです。
品質問題のリスクを低減できる
SLAにより品質レベルの最低保証を求めれば、品質問題のリスクを低減できます。品質に関して契約で規定されていないと、提供者が品質を十分にケアしない場合もあります。しかしSLAを定めれば、未達時にペナルティを受ける提供者は品質を遵守するでしょう。
受領後のトラブルを抑制できる
SLAで品質レベルを明確にすることで、サービスやシステム受領後のトラブルを抑制できます。仮にSLAを満たさない項目があれば、提供者に不備を正当に主張することが可能です。
しかしSLAを定めていない場合は、品質に関する問題が発生しても、不当なクレームとして処理される可能性が高くなるでしょう。
5．SLAを取り決める際の3つの注意点
SLAは双方にメリットがありますが、適切に取り入れないとトラブルを招く場合もあります。SLAを取り決める際の注意点として、次の3つを押さえておきましょう。
5‐1 明確に評価できる指標を設定する
SLAの指標は、できる限り明確に評価できるものを設定しましょう。
SLAの指標が不明確だと提供者・被提供者の間で評価にずれが生じて、トラブルにつながる場合があります。
「月間稼働率99％」のように、できる限り数値を用いて、具体的な指標を設定するのが良いでしょう。SLAの達成状況を双方が同様に評価できる指標にすることで、トラブルを抑制できます。
5‐2 実現性のある指標を設定する
サービスやシステムの提供者は、実現性のある指標を設定しましょう。
被提供者から信用を得るために、シビアな指標を設定するケースも少なくありません。しかし、明らかに実現不可能な指標を設定してしまうと達成が困難になり、結果として信用を失うことになります。
SLAの指標を設定する際は、稼働開始後も継続的にSLAを達成できるかも含めて、実現性があるかを考えましょう。
被提供者が納得できる範囲で、かつ提供者が継続的に実現できる指標が理想です。
5‐3 継続的にモニタリングする
SLAは取り決めて終わりではありません。SLAの締結後や稼働開始後も継続的にモニタリングして、SLAを達成できているかチェックしましょう。
モニタリングによって、ベンダーや受注側はSLA未達を防止でき、発注側はSLA未達時に素早く対処できます。
ただし、応答時間や稼働率といったデータは正確に測定しなければなりません。その際は、SLAの達成状況を監視・測定できるツールを活用するとよいでしょう。
まとめ
SLA（サービス品質保証）とは、サービスやシステムの「提供者」と「被提供者」の間で取り決める品質レベルのことです。
可用性や信頼性、パフォーマンスといった品質レベルを取り決めることで後々のトラブルを抑制でき、品質管理の指標にもなります。
ただし、SLAは正しく設定しないと不利益を被ったり、かえってトラブルの原因となったりするケースもあります。
SLAを取り入れる際は今回の内容を参考にして、正しく締結しましょう。
なお当サイト「Qbook」では、SLA以外にもIT業界のお役立ち情報を数多くお届けしています。Qbookの無料会員登録を行えば、イベント情報や業界人のインタビューなど、最新のお役立ち情報をメールマガジンで受信できるため、ぜひご活用ください。