SLA：概要とベストプラクティスを解説

顧客、サービスプロバイダー、社内の各部門の間では、さまざまな理由で曖昧さ、誤解、未達成のコミットメントが発生します。SLA（サービスレベル契約）は、ビジネス関係の早い段階でこのようなリスクを低減し、明確な期待値を設定するための効果的な方法です。

SLAは複雑で分かりにくいと思われるかもしれませんが、そのようなことはありません。本記事では、SLAの概要、種類、ベストプラクティスを包括的に解説します。

SLAとは？

SLAとは、顧客がサプライヤーやベンダーに期待するサービス水準を規定したものです。 ベンダーに期待されるサービス、成果を計測するための指標、いずれかの当事者によって契約が履行されない場合の罰則が詳述されています。SLAは通常、ベンダーと顧客（企業）との間で締結されます。また、企業の部門間で締結される場合もあります。

アドビ、Google、Amazon Web Services、Microsoftなどの主要なベンダーの多くは、SLAを採用しています。こうしたSLAでは、顧客に対するインターフェイスの可用性の保証、サーバーのダウンタイムの予測、条件違反による障害発生時に顧客が期待できる債権など、サービスに関する詳細が規定されます。

SLAが必要な企業とその理由

SLAで定義される期待値や指標の多くは、一見明白なものに見えますが、参照用に文書化することで、各当事者が契約について同じ認識を共有できます。また、ベンダーが提供するサービスに問題が発生した場合、当事者は契約履行の失敗、指標の未達成、可用性の欠如について把握していないと、主張することはできません。

さらに、社内でSLAを締結することで、部門間の誤解や行き違いを防ぐことができます。

SLAの主な利点は、次のとおりです。

SLAの仕組み

SLAの規定事項は、ベンダーごとに異なります。ここでは、SLAを策定する前に理解しておくべき基本的な事項を解説します。

SLAにおける当事者

ほとんどのベンダーは、サービスの価格帯ごとに標準的なSLAを策定しています。これは顧客にとって良い出発点となりますが、ベンダーのSLAは、一般的に顧客よりもベンダーを保護することに主眼を置いています。そのため、ベンダーの標準的なSLAは、弁護士と連携して交渉を進めるための基盤として扱うのが賢明です。

SLAの主な構成要素

SLAの具体的な内容は、ベンダーごとに異なります。SLAに含めるべき最も重要かつ一般的な構成要素は、次のとおりです。

補償条項の目的

補償条項とは、SLAにおいて、ベンダーが合意したサービスのいずれかを提供できなかった場合に、ベンダーが顧客に補償することを明記した条項です。補償とは、ベンダーがSLAに違反した結果、顧客が被る訴訟費用、損害、損失、負債をベンダーが負担することを意味します。

ベンダーの標準的なSLAには、補償条項が含まれていないことがあります。その場合、顧客は補償条項の草稿を作成し、免責の範囲についてベンダーと交渉する必要があります。

一般的に、次の項目について交渉します。

3種類のSLA

SLAには、3つの基本タイプがあります。これらの目的は類似している一方で、それぞれ異なるビジネス関係に対応し、独自の意味合いを有します。

顧客SLA

顧客SLAは、ベンダーと顧客の間で締結されます。これは、ベンダーが顧客（個人、団体、企業）に対して、特定の水準のサービスを提供することを約束するものです。顧客とインターネットプロバイダーとの間で締結されるSLAは、顧客SLAの一例です。

内部SLA

内部SLAでは、両当事者が他方当事者（部門）の責任と義務を認識するよう保証します。これにより、部門間の理解が深まり、各部門の期待、役割、成果などに関する曖昧さを回避することができます。

例えば、営業部門とマーケティング部門の間で、内部SLAを締結できます。この場合、マーケティング部門がノルマを達成するために、毎月一定数のリードを営業部門に引き渡す必要があることを明記できます。

マルチレベルSLA

マルチレベルSLAとは、SLAをさまざまな階層に分割し、それぞれの階層で顧客や部門のサブセットに対応するようにしたものです。このSLAでは、複数のベンダーや利用者の期待値など、各当事者との契約に関連するあらゆる要素を包括的に規定できます。

例えば、外部向けのマルチレベルSLAでは、あらゆる顧客に適用される一般条項と、特定のパッケージやサブスクリプションを購入した顧客にのみ適用される条項を含めることができます。一方、SLAでは、あらゆる部門に適用される条件と、営業部門とIT部門のみに適用される条件を規定できます。こうした共通条件と排他的条件の内容は、企業や部門のニーズによって異なります。

SLAのベストプラクティス

SLAに対するアプローチは、企業によって異なります。SALを実際に策定する中で、自社のニーズに適した独自のベストプラクティスを見出しましょう。ここでは、その基礎となる標準的なベストプラクティスを解説します。

目標を現実的かつ明確にする

達成したい目標の範囲を設定します。その際、ベンダーや部門の能力、期待できる合理的な成果を考慮します。目標について各関係者の同意を得たら、SLAに明記します。他の従業員に、目標の記述がわかりやすいものであることを確認してもらいましょう。

詳細を具体的に説明する

SLAの目的は、あらゆる関係者がアクセスでき、さまざまな疑問に答え、紛争を解決し、誤解を解くための文書を作成することです。関係者が理解している、または想定していると思われる内容も含め、あらゆる要素を詳述する必要があります。

SLAの 指標を定義 しましょう。契約条件はSLAの重要な要素ですが、提供するサービスの質を測定するための指標もまた、SLAに不可欠です。適切な指標は、SLAの当事者、業種、設定された目標などによって異なります。SLAに含めるべき指標の例を、次に示します。

SLAの実例

SLAの詳細は、顧客のビジネスやニーズによって異なります。ここでは、SLAの実例をいくつか紹介します。

Google Workspace

Google WorkspaceのSLA

Google WorkspaceのSLAでは、重要な条件が規定されています。例えば、Google Workspaceのwebインターフェイスは「毎月の保証稼働率が99.9％以上」、「Google Voiceは、顧客が管理コンソールで音声サービスの特定条件に同意してから2営業日以内に利用可能となる」ことなどが規定されています。また、GoogleがSLAに定める義務を果たさない場合、顧客は、SLAに規定されたサービスクレジットを受ける権利を有します。

実践方法

SLAの条件を簡潔なものにしましょう。Googleでは、毎月の保証稼働率およびGoogle Voiceサービスの稼働日数という、ふたつの具体的な条件を顧客に提示しています。曖昧さを避けるために、SLAで使用する用語を明確に定義することが重要です。

Microsoft Azure

Microsoft AzureのSLA

Microsoft Azureでは、モバイルアプリサービス、分析、Azure Site Recoveryなど、クラウドサービスごとに個別のSLAを提供しています。例えば、一部のSLAでは、サブスクリプションで利用できるモバイルアプリについて、99.95％の稼働率を保証しています。

実践方法

複数のサービスを提供するベンダーにとって、Microsoft Azureの細分化されたアプローチは、顧客が各SLAを容易に検索できるようにするための優れた方法です。各SLAを、概要、一般条項、特定条項の3つの項目に分けることで、各サービスについて合理的かつわかりやすい条件を規定できます。

PandaDoc

PandaDocのSLA

SaaS型サービスを提供しているPandaDocは、シンプルで分かりやすいSLA条件を定めています。時間、日付、期待値などの詳細情報が分かりやすく提示されており、誤解を招く余地はほとんどありません。法律用語が使用されているものの、法律の知識がなくても容易に理解できる内容になっているため、優れたSLAとなっています。顧客とベンダーの責任、目的、期待値、制限事項が明確に規定されています。

実践方法

SLAが正確かつ理解しやすい構成になっていることを確認しましょう。契約に拘束力を持たせるために必要な法律用語のみを使用し、自社の要望などは分かりやすく記載する必要があります。サービス内容が顧客によって大きく異なる場合は、テンプレートを作成し、顧客名を容易に変更できるようにしましょう。これにより、SLAの策定プロセスが簡素化され、顧客ごとに新しいSLAをいちから作成する必要がなくなります。

Adobe Experience Cloud

アドビのSLA

アドビのSLAでは、「可用性」、「ダウンタイム」、「対象サービス」などの用語が概説され、顧客が理解しやすいように明確に定義されています。また、特定の稼働率に達しない場合、サービスクレジットを保証しています。例えば、対象となるアドビサービスの稼働率が99.9％未満99.5％以上の場合、顧客は月額料金の5％相当のサービスクレジットを取得できます。

実践方法
アドビのSLAは、サービス内容が明確に規定されているため、顧客企業とアドビの両方にとって有益なものとなっています。顧客は、サービスに対して何を期待できるのかを正確に把握できます。成果の指標や、成果を達成できなかった場合の罰則が明示されているため、混乱が生じる余地はありません。

よくある質問

SLAについて疑問点がある場合、自社のケースについて専門家に相談するのが最善の方法です。ここでは、専門家に相談する前に把握しておくべき、よくある質問と回答を紹介します。

SLAは引き継ぎ可能ですか？

ベンダーが他社に買収された場合、SLAの引き継ぎを検討することがあります。既存のSLAが引き継ぎ可能な場合もありますが、それを想定しないことをお勧めします。新しいベンダーが既存のSLAを尊重する場合もあれば、SLAを策定し直す必要がある場合もあるからです。

ベンダーがSLAに記載されたサービス水準を満たさない場合、どうなりますか？

あらゆるSLAには、最低限のパフォーマンス基準を満たさない場合の罰則を規定する条項が含まれている必要があります。こうしたSLAの不履行として、目標や指標の未達成、納期の遅延、高い欠陥率などが挙げられます。ベンダーは罰則として、顧客が合意した割合のサービスクレジットを提供する必要があります。

「アーンバック」とは何ですか？

一部のベンダーはSLAにおいて、顧客に支払ったサービスクレジットを取り戻すことができる条項を規定しています。これは、最低限のパフォーマンス基準を満たさなかったことに対する罰則として提供したサービスクレジットを、ベンダーが取り戻すことができるようにするものです。ベンダーは、一定期間、標準的なサービス水準以上のパフォーマンスを達成することで、サービスクレジットを取り戻すことができます。

SLAはどのくらいの頻度で見直すべきですか？

両当事者のニーズや要件によって異なります。一般的に、SLAは常に進化し続ける文書であると考えるのがよいでしょう。次のような場合には、SLAを見直す必要があります。

SLA向けツール

SLAは、顧客とベンダー、または部門間の曖昧さを排除し、摩擦を減らすのに役立ちます。

ベンダーと提携している場合、各部門と話し合い、ベンダーに期待することを明確にし、ベンダーが自社の期待に応えているかどうかを判断するための指標を策定しましょう。ベンダーは、サービスの範囲と合理的なアクセシビリティを明確に定義する必要があります。SLAを策定したら、CMS（コンテンツ管理システム）を利用してSLAを管理し、いつでも参照できるようにしましょう。

Adobe Experience Managerは、DAM（デジタルアセット管理）とCMSを兼ね備えた、優れたデジタルコンテンツ管理基盤です。Adobe Experience Managerのクラウドサービスは、パフォーマンスの最適化、優れたSLAの策定、エンタープライズレベルのセキュリティを実現します。詳細については、動画をご覧ください。