SLAとは？SLAの必要性とOLAとの違い

SLA（サービスレベル契約）とは？

SLA（Service Level Agreement）とは、サービスプロバイダーと顧客の間で文書化された契約・合意です。具体的にはITサービスの提供における品質、可用性、責任などに関する取り決めをSLAと呼んでいます。

このSLAによって「必要とされるサービスレベル」「期待されるサービスレベル」を数値化することができ、サービスを供給する側・提供される側の双方が、客観的な数値をもとにサービスがどこまで有効かを評価・識別することができます。これらの契約は公式・非公式のどちらでも問題ありません。

ITサービスマネジメントにおいては、SLAはエンドユーザーが要求を提起したり、インシデントを報告する際の期待値の設定や管理においても役立ちます。ヘルプデスクを例にとると、SLAは主にサービスの提供とインシデントの解決にかかる時間を定義するのに使用されます。例えば「サービス要求への応答時間は〇分以内に行う」「インシデントが発生した際は〇分以内に対応する」などがSLAの一例です。

OLAとは？SLAとOLAの違い

OLA（Operational Level Agreement）とは運用レベル契約とも呼ばれ、サービスプロバイダー事業者の内部での合意・約束を文書化したものです。一つの組織・企業の中でも、様々な部署やチームが協力してITサービスを提供しています。そのためSLAのようにサービスプロバイダーが顧客との間に様々な取り決めを行うように、組織内部でもOLAによって部署・チーム間の取り決めを行うことで、提供するサービス品質を維持した運用を行うことが目的です。

SLAとOLAの違いとして、SLAは顧客、OLAは組織内部と、約束を結ぶ相手の違いがあります。さらに踏み込んだ違いとして、SLAではサービス内容における取り決めが中心となり、OLAでは技術面における取り決めが多いという違いがあります。

■ SLAの項目例

• サービス要求への応答時間
• インシデントへの対応時間
• 一次回答率
• サービス稼働率
• 計画中止予定通知など

■ OLAの項目例

• 責任と役割の明確化
  仮にネットワーク障害が発生した際に、アラートに気付いた部署は何分以内に他部署に報告し、ネットワークチームのエンジニアが何分以内に対応するのかを文書化。
• 様々な対策を文書化
  輻輳（ふくそう）による社内のネットワークダウンを防ぐために、大容量のデータをチーム全体でダウンロードする場合は、あらかじめ別のチームに事前に伝える。

またペナルティに関する違いもあります。SLAの場合は顧客とサービスプロバイダーの合意であるため、仮に違反があればプロバイダー側にペナルティが課されます。しかしOLAは顧客との合意ではないため、仮に違反があったとしても顧客からのペナルティを課されることはありません。ただし、SLAを順守できないのには何らかの理由があり、その原因が内部組織の連携ミスというケースは山ほどあるため、OLAによって組織内の連携を強化することには大きな意味があります。

ヘルプデスクにおけるSLA（サービス・レベル・アグリーメント）

日頃、私たちがECサイトを利用するとき、到着予定日に商品が届かなかったときは不安になります。製品やサービスが遅れて届くことへの不満や不安はあまり経験したくなく、このフラストレーションは別のECサイトに乗り換えるのに十分な理由になります。

同様にヘルプデスクもエンドユーザーにサービスを提供します。チケットには、インシデントと引き上げられたサービス要求の報告があり、それらは妥当な時間内での解決が望まれます。しかしこの「妥当な時間内」については、一人ひとりの依頼者の期待がそれぞれ異なります。ではどのようにすれば、エンドユーザーの期待を効果的に標準化し、管理することができるのでしょうか？

ここで役立つのがSLAです。SLAは依頼者の期待を数値化し、サービス品質を高く維持するためにヘルプデスクが採用できる協力なツールです。ここからは「SLAを作成するために必要な要素」「SLAのベストプラクティス（事例）」などを見ていきます。

SLAの設計方法

SLAはサービスプロバイダーと顧客の間の契約・合意であるため、提供されるサービスの範囲とレベルを文書化しなければなりません。契約条件を効果的に記録に残しておくため、SLAは一般的に次の要素を組み合わせて構成されます。

• サービス内容：契約内容、関係者、提供サービスの詳細
• サービスの品質：サービス基準の詳細
• サービスの応答性：サービスの提供速度の詳細
• 合意条件を満たさなかった場合のペナルティ：合意を満たさなかった場合の段階的なペナルティの詳細
• パフォーマンスの測定：測定方法を含め、測定する必要のある指標のリスト
• キャンセル条件：契約条件が適用されないケースの詳細

SLAはこれらすべての要素を含む必要はありません。 要素の組み合わせ方は、提供されるサービスの種類によって決まります。

SLAの種類とは？

SLAは提供されるサービスの種類ごとに異なる場合がありますが、大きく次の3つの種類に分類できます。

・顧客に基づいたSLA：

顧客ベースのSLAは、サービスプロバイダーと顧客または顧客グループに基づくものです。提供されるサービス、サービスのレベル、および関係条件について詳しく説明します。例えば、オンデマンドビデオサービスと加入者の関係を例に挙げると、1つの契約の中に、利用可能なサービスや提供されるサービス期間、約束された稼働時間が網羅されています。契約は顧客が選択したプランに基づいて、それぞれの顧客ごとに変更されます。ここでいうSLAとは個々の顧客に基づいたものです。

・サービスに基づいたSLA：

サービスベースのSLAは、顧客が選択したサービスや製品に基づいている場合に提供される契約です。通常および追加の提供サービスとサービスレベルを詳述しています。例えば、ヘルプデスクはすべての依頼者に異なるサービスを提供しており、各サービス項目には提供されるサービスと時期を詳細に示す、サービス固有のSLAがあります。ここでいうSLAは、すべてのエンドユーザーに共通のSLAを持つサービス項目に基づいています。

・マルチレベルのSLA：

マルチレベルのSLAとは、SLAが複数の層またはレベルに分割され、単一のサービスを利用する一連の顧客を指定する契約です。これは企業、顧客、およびサービス・レベルでの契約に対応します。ワークステーションのサービス要求を例にすると、上席の職員から要求される場合は優先度の高いSLAとなり、臨時の職員から要求される場合は優先度の低いSLAです。

なぜITSMにSLAが必要なのか？

それでは次に、SLAがITSMにどのような価値をもたらすのかを見てみましょう。ITSMツールServiceDesk Plusには、SLAを自動化できる機能が備わっています。ここからはServiceDesk Plusのサンプル画面を参考に、従業員のオンボーディングにおけるサービス要求チケットの例を取り上げます。

担当者Aは従業員のオンボーディングのためのチケットを発行します。従業員向けのオンボーディング・テンプレートを選択し、リクエストします。チケットの作成時に、担当者Aはこのサービス要求が14日以内に完了することを確認し、同時に彼の期待値として設定されます。担当者Aは午後12時53分にリクエストを出し、SLAタイマーが開始されます。

SLAは次のようなサービス提供条件を定義します。

レスポンス（応答時間）：アサインされた技術担当者がチケットに応答する時間。この場合、アサインされた技術担当者はチケット作成時点から24時間以内にこのチケットに応答しなければなりません。

解決時間：ワークステーションが納品される時間。この例では、チケットの作成から14日以内に解決・納品する必要があります。

エスカレーション：レスポンスまたは解決時間に違反した場合に行われるアクションと通知を解説します。以下のサンプル画面では、従業員のオンボーディング・テンプレートに関連付けられているSLAに基づいて、SLA違反が発生した場合に起きるいくつかのエスカレーションと措置が設定されていることがわかります。最初のエスカレーションは、チケットが応答していないことを、チケットの所有者に通知するために設定されます。レスポンスのSLAが不履行となる30分前に、チケット所有者に自動的に通知されるよう設定されています。その他のエスカレーションは、解決に向けたSLAにおける違反となります。第1段階のエスカレーションは、解決期限の1日前にチケット所有者に通知するよう再設定されます。第2段階のエスカレーションは、チケット所有者の報告先にあたる上司にフラグを立て、優先順位の高いユーザー管理チケットを処理できる特別な技術担当者グループに配置し、チケットを最短時間で解決するよう設定します。

リクエストの終了後には、SLAが満足のいく設計どおりの動きができたのかを確認するため、担当者Aのフィードバックを収集する満足度調査が行われます。

この例からは、SLAによってインシデントとサービス要求が時間どおりに解決され、ダウンタイムを最小限に抑え、通常業務が可能になることがわかります。また、優先度の高いチケットには直ちに対応し解決できる適切なSLAを割り当て、優先度の低いチケットはそれに適したSLAを割り当てることでチケット対応の優先順位が明らかになります。これにより、ヘルプデスクは効率的に業務を行えます。

サービスレベル管理の役割と責任

次からはサービスレベル管理（SLM）の責任者と、さまざまな関係者の責任について見ていきましょう。

• サービスレベルマネージャー（プロセスの所有者）：サービスレベルマネージャーは、SLMプロセス全体に対して責任があります。プロセスが効果的であり、適切な利害関係者がプロセスに関わっていることを保証します。各サービス項目におけるサービスレベルについても最終的な発言権を持っています。
• サービスオーナー：サービスオーナーは、合意されたサービスレベル内でサービスを提供する責任があります。 彼らは通常、内部のサポートグループを率いています。
• サポートグループ：合意されたサービスレベル内でサービスを提供する専門技術担当者のグループです。
• 技術担当者：技術担当者は、合意されたサービスレベル内でサービスを提供するサポートエージェントです。
• エンドユーザー（依頼者）：エンドユーザーはサービスの利用者です。

サービスレベル管理改善のためのベストプラクティス

SLAを改善するために使えるいくつかのベストプラクティスを紹介します。

1つのSLAがすべてに合うわけではありません。チケットの種類と優先度に応じて、様々なSLAを作成することが重要です。これによってヘルプデスクは各チケットに適切なリソースを割り当て、依頼者の期待にそった動きを取りやすくなります。

レスポンスSLAは、技術担当者がチケットにどれだけすばやく応答するかを示します。チケットに応答すると、それが着々と処理されていることが示されるため、依頼者の満足度を大幅に高めることができます。レスポンスSLAは、依頼者が繁忙期でもすべてのチケットに時間どおりに応答できるようにし、すべてのチケットが時間どおりに応答されるようにエスカレーションを構成します。

解決のためのSLAは、チケットの解決に必要な時間を参照します。

SLA違反は避けられない場合があります。発生した場合は、チケットがすぐに解決されるようなメカニズムを導入する必要があります。SLAエスカレーションは、SLAに違反したチケットや期限が近づいているチケットなど、管理上の問題に自動的にフラグを立てます。SLAエスカレーションはニーズに応じて事前対応型または事後対応型にでき、複数のレベルのエスカレーションを設定し、チケットを確実に解決します。エスカレーションへの対応は、チケットの優先順位を上げ、エスカレーションの各レベルで自動的に特定のサポートグループまたは技術担当者に再割り当てするように設定できます。

ヘルプデスクのパフォーマンスを測定し、SLAが有効かどうかを確認するためにSLAを定期的に監視する必要があります。ヘルプデスクの環境は絶えず変化しており、SLAを評価することでSLAの関連性と効果を維持するために必要な調整を理解しやすくなります。ダッシュボードを使用してSLAを監視し、レポートによって詳細な指標を取得できます。追跡する重要な指標には、解決に向けた最初の呼び出し、欠陥率、平均応答時間、所要時間、平均回復時間などがあります。

最後に、最も重要なことは現実的なSLAを設定することです。行き過ぎた約束と不十分な届け方のSLAは、あらゆるITサービスデスクの悩みの種です。チケットは時間どおりに解決されず、依頼者は満足せず、最終的には通常の業務が中断され、組織はお金を失うことになります。そのためSLAを定義するときは、まずはチケットの要件と利用可能なリソースを評価します。

• チケットの重要性に応じた個別のSLAの作成
• レスポンスと解決のためのSLA設定
• SLAエスカレーションの設定
• SLAパフォーマンスの定期的な監視
• 現実的なSLAの作成

適切なSLA管理がもたらすメリット

SLAを適切に使用すると、チケットの優先順位付けが楽になります。そしてチケットを時間どおりに解決できるよう必要なリソースが慎重に割り当てられることで、ITサービスデスクの効率も高められます。またSLAはサービスの提供基準を定義し、依頼者の期待をより適切に管理しやすくなります。SLAを設定することで、サービス提供を次の段階へと引き上げ、依頼者がサービスの遅延に不満を感じないようにします。

ServiceDesk Plusでは、これらのベストプラクティスをスクリプトなしで実装可能です。