SLA とは? サービス レベル アグリーメントの解説

重要ポイント: SLA (サービス レベル アグリーメント) は、チームが達成を確約する応答時間と解決時間を定義し、明確な期待値の設定とパフォーマンスの測定に役立ちます。

• 概要: チケットを確認、更新、解決した速さに関する時間ベースの目標とルール。

• 重要である理由: 適切に設計された SLA は、一貫性、説明責任、ユーザーの信頼を向上させ、ボトルネックやキャパシティ ギャップを明らかにします。

• Jira Service Management の機能: チームが SLA を定義、追跡、自動化できるよう、視覚的なタイマー、アラート、レポートをサービス プロジェクトに組み込みます。

SLA の意味やこれらの契約が実際にどのように機能するのか疑問に思ったことがある方は、決して少なくありません。サービス レベル アグリーメントは、IT チームやサービス プロバイダーがどのようにサポートを提供するかに影響を与えますが、しばしば誤解されたり、適切に実装されていなかったりします。 

SLA は、カスタマーがサービス プロバイダーに期待できる内容と、それらの期待が満たされない場合に何が起こるかを定義します。これらの契約は、IT チームが作業に優先順位を付け、カスタマー関係を管理し、自らのパフォーマンスを測定するのに役立ちます。適切に設計された SLA は、サービスに対する期待の曖昧さを排除することで、すべての関係者の業務を容易にします。

このガイドでは、SLA とは何か、なぜ重要なのか、そしてサービス プロバイダーとカスタマーの双方にとって有効な契約の作成方法について説明します。

Service Collection を無料で試す

Service Collection には Jira Service Management が含まれており、チームが SLA の作成および適用のプロセスを効率化できるようにします。このプラットフォームは、開発、IT、およびビジネス チームを単一のシステム上で連携させ、高速なサービス提供を実現します。

SLA とは?

サービス プロバイダとしてのサービス レベル アグリーメントとは、(社内外を問わない) ユーザーとその顧客との間で交わされた分かりやすい言葉で認められている契約です。この契約では、提供するサービス、期待される応答性、どのようにパフォーマンスを測定するかについて定義します。

SLA は、アップタイムやサポート応答性など、サービスに関して契約上合意された条件を定義します。たとえば、カスタマーに 99.9% のサービス アップタイムや、24 時間以内のサポートからの回答を約束するなどです。SLA ではサービスの期待事項の明文化に加えて、要件に違反した際の救済条件も定められています。

SLA は、信頼を構築する上で重要な IT チームとカスタマーとの間の基本契約です。カスタマーの期待値を適切に管理するとともに、チームが解決責任を負う課題を把握できるようにします。SLA の準備を整えることで、サービスの期待事項に関する共通の理解が得られます。SLA を導入すると、次のようなさまざまな方法で IT チームにメリットがもたらされます。

• IT チームとカスタマーの関係強化: SLA はリスクに対する懸念を緩和して、当事者間の信頼を向上させます。違反が発生した場合に何が起こるかを定義することで、不確実性を減らします。

• コミュニケーションの形式化: IT 課題に関する関係者との会話は難航する場合があります。誰も 1 人のカスタマーから 1 日に 10 回も連絡が欲しいとは思いませんし、カスタマーにサービス パフォーマンスに対する暗黙の期待を密かにくすぶらせてほしくありません。SLA により関係者は、すでに合意された条件に基づいて順序立てられた会話を進められます。 

• 生産性と士気の向上: SLA は、受け取ったリクエストの緊急性を定義します。そのため IT チームは、優先的に対応すべき課題に集中できるようになります。

SLA の主要な構成要素

効果的な SLA には、明確な期待事項の形成に連携して寄与する複数の中核要素が含まれます。主な構成要素は次のとおりです。

• 提供されるサービス: このセクションでは、契約の対象となるサービス内容を明確に定義します。ITSM サポート、クラウド ホスティング、またはその他のサービスであるかにかかわらず、内容を具体的にすることで、何が含まれ何が含まれないかに関する混乱を防ぎます。

• パフォーマンス メトリック: チームが達成を確約する測定可能な基準です。所要時間、解決時間、稼働率、その他の定量的な目標により、成功の明確なベンチマークを全員が把握できます。

• 役割と責任: 誰が何を担当するかを明確にします。サービス プロバイダーが担当するタスク、カスタマーが担当するタスク、および引き継ぎが発生する箇所を定義します。役割を明確に定義することで、課題発生時の責任転嫁を防ぎます。

• 救済措置とペナルティ: これは、SLA の条件が満たされない場合に何が起こるかを示します。サービス クレジット、返金、その他の補償のいずれであっても、あらかじめ結果を定義しておくことで責任の所在が明確になり、カスタマーに対して救済手段が提供されます。

SLA のタイプ

SLA は、ビジネス モデルやカスタマーのニーズに応じてさまざまな形で構成できます。適切な構造は、サービスの提供方法や対象とするカスタマーによって異なります。

カスタマー ベースの SLA

カスタマー ベースの SLA は、サービス プロバイダーと組織またはカスタマーとの間で締結される契約です。このタイプでは、カスタマーが受けるすべてのサービスを対象とし、それぞれの特定の要件や優先事項に合わせて調整されます。

このアプローチは、独自のニーズを持つ大規模なエンタープライズ クライアントがいる場合や、カスタマーごとにサービス提供が大きく異なる場合に効果的です。カスタマー ベースの SLA では、パフォーマンス目標、サポート時間、その他の条件を、その特定のカスタマーが実際に必要とする内容に合わせてカスタマイズできます。

サービスベースの SLA

サービスベースの SLA は、特定のサービスを使用するすべての顧客に適用されます。そのサービスの提供方法について顧客ごとにカスタマイズするのではなく、標準的な契約を作成します。

クラウド ホスティング プロバイダーは、よくこのモデルを使用して、すべての顧客に同じアップタイム率とサービス リクエストの応答時間を約束します。IT サポート チームは、すべての部門に等しく適用されるメール サポートのサービスベース SLA を作成することがあります。このように標準化することで、SLA を大規模に管理しやすくなります。

マルチレベル SLA

マルチレベル SLA は、企業レベル、顧客レベル、およびサービス レベルのアグリーメントを組み合わせて階層構造にします。このアプローチにより、大規模な組織でも一貫性を保ちながら柔軟性を得ることができます。

たとえば、企業レベルの SLA で、すべてのサービスのベースライン標準を設定します。顧客レベルの契約で個々のクライアントに対する具体的な条件を追加し、サービス レベル アグリーメントで各サービス提供の詳細を掘り下げます。この構造により、複雑なサービス ポートフォリオを持つ企業でも、書類の処理に追われることなく、数百の SLA 条件を管理できます。

さまざまな業界の SLA の例

実際の SLA の例を見ることで、さまざまな分野で実際にこれらの契約がどのように機能するかを理解しやすくなります。

• IT サポート サービス: ある社内 IT チームは、営業時間内にはサービス デスク チケットに 2 時間以内に応答し、重大な課題を 4 時間以内に解決することを約束しています。SLA では、応答時間がこれらの目標を超えた場合、IT ディレクターが影響を受ける部門長に遅延について説明する必要があると規定されています。パフォーマンスは、チケット管理システムで追跡される IT メトリックを通じて測定されます。

• クラウド ホスティング: あるウェブ ホスティング会社は、すべての顧客 Web サイトに対して 99.95% のアップタイムを保証しています。月間アップタイムがこのしきい値を下回った場合、顧客にはその月に対するサービス クレジットが提供されます。自動監視によってアップタイムを追跡し、月次レポートを発行します。

• カスタマー サービス: あるソフトウェア会社は、サポート依頼の 70% に対し最初の連絡での解決を確約し、24 時間以内のメール返信を約束しています。すぐに解決できない依頼は、1 営業日以内に階層 2 サポートにエスカレーションされます。SLA 違反が繰り返し発生した顧客には、追加費用なしで Premium サポートを提供します。

これらの例は、SLA が抽象的な約束を、実際の結果を伴う具体的で測定可能なコミットメントに変換する方法を示しています。

SLA に含めるべきメトリック

追跡するメトリックによって、SLA が実際に法的拘束力を持つものか、それとも単なる目標にすぎないかが決まります。効果的な SLA によく含まれる一般的なメトリックは次のとおりです。

• アップタイムと可用性: このメトリックは、サービスが稼働し、アクセス可能である時間の割合を測定します。ほとんどの SLA では、99.9% のアップタイムのようにパーセンテージで表現されます。

• 応答時間: サービス リクエストや課題が報告されてから、チームが受信を確認するまでの時間です。応答時間 SLA は通常、優先度によって異なります。

• 解決時間: 初回レポートから最終修正まで、課題を完全に解決するのにかかる時間を追跡します。応答時間と同様に、解決目標は通常、課題の重大度によって異なります。

• 品質メトリック: 一部の SLA には、最初の連絡での解決率や顧客満足度スコアなどの指標が含まれており、スピードの追及により品質が損なわれないようにします。

これらのメトリックを追跡することは重要です。測定しないものは改善できないからです。IT サポート ソリューションにレポート機能が組み込まれていれば、パフォーマンスの監視や、問題になる前の傾向の把握が容易になります

SLA の設定とパフォーマンスの測定方法

以上のように、SLA が少し恣意的に感じられるか、企業のより大きなビジネス目標を直接サポートするものを測定しているとは限りません。適切なものを測定してビジネスの他の部分が抱えるユーザーの期待に応えるために、定期的に SLA を確認することをお勧めします。次のプロセスに従ってください。

• ベースラインを設定します。現在の SLAとその SLA に対してどのようなパフォーマンスを発揮しているかを見ていきます。提供するものと、会社と顧客のビジネス目標にどのようにそれが対応しているかを評価します。

• 順調かどうかを聞いてみましょう。顧客と直接話し合って、建設的なフィードバックを集めます。何を上手くやっているのですか? もっと改善できることはありますか? 適切なサービスを提供していますか?

• 上記のステップの結果に基づいて、新しい SLA の下書きを作成します。不要になったサービスを取り除いて顧客の満足度を高め、ビジネスと IT の両方に価値をもたらすサービスを追加します。

• 経営陣からのサポートを受けましょう。SLA を成功させるには、IT リーダー、顧客組織のリーダーの協力も欠かせません。まず、自分の経営陣の同意を得て、顧客の経営陣との交渉をサポートしてもらいます。

上記のプロセスに従っていれば、SLA は相当に洗練されてくるはずです。

効果的な SLA を作成するためのベスト プラクティス

現在のビジネス ニーズとカスタマー ニーズに対して最善の SLA をまとめたら、それを実行します。ここでは、SLA をまったく新しいレベルの使いやすさと効果に引き上げるためのヒントを紹介します。

顧客が返信するのを待っている間、解決までの時間の追跡を停止する SLA を作成する

IT 部門は、可能な限り最高のサービスを提供するために、部門自体の応答時間を効果的に測定できる必要があります。それでも、応答の遅い顧客やサードパーティへのエスカレーションによって応答時間が実際よりもはるかに悪く見えるため、SLA の測定はすぐに複雑になります。測定システムおよびレポート システムがこのような例外に対応できるようにして、サービス デスク チームが実際のパフォーマンスに基づいて追跡されるようにしてください。

Jira Service Management で自動化ルールを設定して、一定期間非アクティブなチケットを自動的にクローズすることもできます。これにより、古い課題が SLA メトリックに悪影響を与えることを防げます。Jira Service Management でのサービス リクエスト管理では、このようなシナリオを処理するための組み込みワークフローが提供されています。

エージェント エクスペリエンスを記録する

シンプルで明確な命名規則を使用してください。エージェントは、SLA の名前を読み取って、測定対象をすぐに理解する必要があります。目標を作り過ぎないように自重することも重要です。エージェントが目標を明確に理解できる必要があります。特殊な状況が多すぎるのもよくありません。目標を作れば作るほど、目標ごとの変動要素が増えるため、理解して遵守することが難しくなります。

大規模で複雑な SLA を分割する

複雑な SLA を作成するのではなく、一連の小さな SLA を使用して、全部ではなく個々のワークフローを測定してレポートできるようにします。こうすることで、SLA を更新して最新の状態に保つことも容易になります。

チケットの優先度レベルに基づいて異なるパフォーマンス目標を設定する

普段、サービス デスク チームはプリンターの障害を優先順位が最も高いチケットと見なしません。しかし CEO のプリンターだとしたら、別の問題になります。実際には、IT チームは影響を受けるのはビジネスのどの部分か、誰がチケットをオープンしたのか、さらに複雑な条件が絡み合ったもの (たとえば四半期末に販売予約システムに障害が発生した場合) など、実に多様な方法でチケットに優先順位を付けています。

サービス デスク ソフトウェアには柔軟性が必要なため、定義したパラメーターの組み合わせに基づいて、SLA パフォーマンスの目標を作成できます。チームの優先順位をビジネス ニーズの変化と完全に一致させるためには、それらを簡単に変更したり編集したりできることが重要です。

Jira Service Management の自動化機能を使用すると、手動操作なしで、これらの複雑な優先度の組み合わせを処理するルールを構築できます。チームの優先事項を変化するビジネス ニーズに完全に合わせるために、簡単にルールを変更・編集できます。

一部の SLA を年中無休で稼働させて、他の SLA を通常の営業時間に制限する

サービスデスクチームが月曜から金曜まで、通常の就業時間に働いているとしたら、どのサービスでも本当の 24 時間年中無休のサポートを提供することはできません。オンコールサービスデスクチームやカスタマーが料金を支払う優先サポートがあるとはいえ、サービスによっては、昼夜を問わない平日対応や即時対応を保証することが少なくありません。

土曜日と日曜日は中断するようにサービス デスクを設定しましょう。会社の休日など、カスタマイズされた規則を作成する場合はさらに複雑になります。また、異なる場所に拠点を置くチームをサポートするためにカレンダーの作成を検討します。

日常的な SLA タスクを自動化する

Jira Service Management は、手動操作なしで反復的な作業を処理できる自動化機能を備えています。一定期間非アクティブな状態が続いた場合や、課題が解決したことを顧客が確認した場合に、サポート チケットを自動的にクローズするルールを設定できます。これにより、古いチケットがキューに残って解決時間が歪められることを防ぎ、SLA メトリックを正確に保つことができます。

AI を使用して応答・解決を迅速化する

Rovo エージェントは、チケットのルーティングと初期応答の合理化に役立ち、顧客がより迅速に回答を得られるようにし、サポート チームの負担を軽減します。Jira の AI 作業分解機能を使って複雑な課題をより速く扱いやすい大きさに分解して理解できるようにすることで、解決時間を短縮し、SLA 目標をより一貫して達成できます。

SLA で確実に成果を上げる

SLA は、コンプライアンスを積極的に監視し、チームに責任を持たせる場合にのみ効果を発揮します。目標に対するパフォーマンスと不足している部分を確認するため、レビューの機会を定期的に設けます。Jira Service Management は、SLA の作成と実施を合理化し、サービス提供全体でのパフォーマンスの追跡と一貫性の維持を容易にします。

SLA はビジネスに合わせて進化させる必要があることを覚えておいてください。6 か月前にうまくいっていたことが、現在のニーズに合わない場合があります。四半期ごとにレビューの予定を組んで、SLA がビジネスの優先事項や顧客の期待と引き続き合致しているかを評価した後、必要に応じて目標を調整したり、古くなった契約を廃止したりしましょう。慎重に設計され、一貫して実施されている SLA は、信頼を築き、時間の経過とともにサービス品質を向上させるツールになります。