SLA(Service Level Agreement)って?①
1. このタイトルにしたきっかけ
アーリーフェーズのスタートアップに転職したところ、その日からSLA!SLA!
と社内会議で用語が飛び交っていました。
前職まででそこまで「SLA」を気にしたことがなく、社内ルールや、契約上のサポート体制の
統制を行ってきた経験はあったのですが、SLAを決める!という経験もなかったです。
(あとあと弊社で飛び交っていた「SLA」は「SLO」に近いもので、かつ用語を適切に理解して使っているわけではなさそうでした)
漠然と、守れなかったら保障が発生する重大なルールくらいにしか思ってなかった一般的な「SLA」
を理解しつつ、調べた結果を文字化して残しておかねばと思い、作成しました。
2. Service Levelの用語整理
まず大きく用語として、3つ挙げさせていただきます。
もしかしたらこの3つのSLが混在して議論されることもあるのではないでしょうか?
個人的には、役割は整理したうえで、場合分けがあるという理解のもと設計することで、
お客様にも、社内にもメリットのあるルール設計ができると思うので非常に参考になりました。
2-1. SLA(Service Level Agreement)とは
提供されるサービスの範囲・内容・前提事項を踏まえた上で
「サービス品質に対する利用者側の要求水準と提供者側の運営ルールについて明文化したもの」。
サービス利用契約を締結する際に、SaaS 提供者とサービスの利用者(以下、利用者)双方による合意の結果として、契約文書の一部もしくは独立した文書として締結されるケースが多い。
その内容は大きく、2つに分かれます。
(1)保証型
SLAで定める基準未達時には損害の発生の有無にかかわらずSLAで定めた範囲で違約金を支払う責任を負います。
(2)努力目標型
SLAで定める基準未達時には、目標値達成のためのサービス内容の見直し等の対策を実施することを責任とし、違約金などを発生させません。
参考:https://www.cloudsign.jp/media/sla/
2-2. SLO(Service Level Objective)とは
SLAによく似た言葉として「SLO」があります。
SLOとは、Service Level Objective(サービスレベルオブジェクティブ)の略で、サービス提供者が目標値として設定する品質水準を意味します。
SLAとの決定的な違いは、項目を守れなかった際の罰則が無い ということです。 SLOはあくまで目標値であるため利用者と内容の合意を行う必要がなく、具体的な項目が開示されていない場合もあります。
そのため、SLOはSLAよりもより厳しい基準で設けられていることが多く、サービス提供者側が内部の目標項目としてより厳しいSLOを設定してそれをもとに 運用を行うことで、利用者と合意したSLAを守る用途で使われることもあります。
参考:https://bcblog.sios.jp/what-is-sla/
2-3. SLR(Service Level Requirement)とは
ビジネス部門が求めるサービスに対する業務要件でビジネス側が策定。SLRはSLOまたはSLAの基礎となります。
3. SLAの重要性
こちらもずばりなのでそのまま引用させていただきます。
詳細 SLAガイドラインより
これまでSLA は、サーバやネットワークといった IT 基盤運用管理サービスの外部委託 において利用が進んできた反面、業務用システムについては、ソフトウェア・パッケージ を「製品」として利用者が購入し、自ら運用管理を行うことが多かったこともあり、活用範囲が限られていた。しかし、第三者の SaaS 事業者が業務用システムの運用管理を実施し、 ネットワーク経由で「サービス」として利用する SaaS では、通常のサービス委託契約と同様に、SaaS 提供者と利用者の間で合意事項を明文化しておくことが肝要である。
SaaS は利用者の期待が高く、中小企業を含めた企業において、多くの メリットが想定されるため、近年注目・関心が高まっている。
その一方で、同時に、以下 のような懸念の声も聞かれるようになっている。
- システムの応答速度(パフォーマンス)が遅いのではないか
- システムの調整/変更(カスタマイズ)が自由にできないのではないか
- 既存のシステムとの連携/統合が難しいのではないか
- サービス提供者からのサポートが十分受けられるか
- データのセキュリティが保たれるか不安がある 等
関連技術の進歩および SaaS 提供者の努力により、全体的な傾向としてはこれら懸念の多くが 解消される方向にある。
このような過渡的な状況においては、利用者の要求水準(期待)と、SaaS 提供者のサー ビス内容(現実)について、双方の認識が異なることが往々にして起こりがちである。
その結果、利用者の過度な期待や幻滅を招くのみならず、トラブルへと発展する恐れがある。 SaaS 提供者および利用者双方にとって様々な可能性を秘めたSaaS の活用促進に向けて、 適切な SLA の締結が重要となっている。
なお、SLA は締結したら終わりではなく、定めた サービスレベルを定期的に測定、分析、評価することにより継続的にサービス改善を実現することも必要となる。こうした管理手法又は運営の仕組み(ルール、プロセス、体制) のことを SLM(Service Level Management:サービスレベル管理)と呼ぶ
4. Service Levelのプロセス整理
それぞれに違いがあるよとなんとなく理解した上で、SLAをいったん、「SL」まで抽象化し、再度、具体に落としたものをプロセスとして整理してみました。
完結にいうと、僕の中の解釈では、「ビジネス部門が求めるサービスに対する業務要件」をはっきり決めた上で、「SLO」 をいくつか設計し、その中でも実際にランスルーを行い、定性、定量的に測定できるものかつ、こちらがある程度お約束できるものから 「SLA」 に昇華し、結果的に顧客の信頼を得られるものだと理解しました。
言い換えると守れない約束はするべきではない、と考えます。あくまでビジネスリクワイアメントを利かせた上で、かつ守れるルールに設計しましょう。守れるかわからないものを「サービス」として提供するのは一種の詐欺みたいなものです。
余談①
余談ですが、この記事を書く数日前にモバイルオーダー等飲食店業界を支えている「ダイニー」さんで大規模なシステム停止がありました。
サポートの経験があるからこそ、このタイムラインが流れてきたときは心臓がバクバクしました。
特に飲食業界といえば、毎日の売上が勝負で、使えなかったら次の日にまとめて計上なんてできない業界だと思うので、その日のうちにサービスが使えるようにしなければいけないプレッシャーを受けつつ、当日に復旧できる技術力の高さに感銘を受けました。
日々、システムが停止しないような仕組みや、何かあったときの避難訓練的なものも定期的に実施しているともお伺いしていて、それでもなお定期的に発生してしまうなんてシステムは何があるかわからないですね。
僕が調べた限りでは、SLAの金銭的補償の記述は見当たらなく、利用規約の第12条(保証の否認及び免責)で保証について言及しているようです。(もしかしたら顧客別に契約書で結んでる場合もありますし、見解が間違っていたら本当に失礼しました)
5. SLOのプロセス整理
6. SLAのプロセス整理
1.SLAの策定の目的と期待を明確にするために、ヒアリングシート等で課題を把握しておく。
Ex)①事業視点、②サービス品質面、③コスト管理面、④契約書・仕様書から、⑤運用プロセス面、⑥組織の役割面、⑦業界・市場動向から
2. マネジメント・コミットメントの発行、SLA策定の目的・期待効果を明確にする。
3. ビジネス要件・サービスレベル要件からSLOを選定する。
4. 選定したSLOから、事業戦略、IT戦略、品質とコストから定量的な情報を含んだサービス指標を策定する。
5. 目標値を絞り込む。
- 内部指標と外部指標の選別
- 類似制の排除
- 管理可能であるかどうか
- 改善可能か
- 目標値との妥当性
- SLRとの妥当性
SLOとSLAのプロセスの具体的な項目は似ていますが、目標値の絞り込みの前後にビジネスサイドともコミュニケーションをとって双方合意のもとのプロセスを踏むというところがあると思います。
図では表現しきれてませんが、=SLAの方がSLOより厳しい条件になる。項目は厳選すると考えていただければと思います。
7. SLAのメリット/デメリット
利用者におけるメリット(例)
- サービスレベルに対する保証の確保
- サービスレベルが達成されない場合の補償対応の明確化
- 継続的管理によるサービスレベルの維持・向上
- SaaS 提供者選定における判断基準の明確化
◆SaaS 提供者におけるメリット(例)
- サービスに対する信頼性の確保
- サービス提供における責任範囲の明確化
- 利用者との関係維持・強化
- 優れたサービスレベルの提示による競争優位性の確保
◆SaaS 提供者におけるデメリット(例)
- サービスレベルを維持するためのコスト
- サービスレベルが達成できなかった場合のコスト
- SLAの変更に伴う周知、最新化コスト
メリットとしては、競合優位性や安心感につながるサービス付加価値として提供できると考えます。
逆にメリットとしてはすべてコストで、サービスレベルを維持するためのコストだと例えば、
- メンテナンスのために計画的に停止することが可能なシステムと24時間365日絶対に停止しないシステムでは運用コストが大きく異なる。
第1回目のコールセンターのお話でも少し触れましたが、安易に24/365サポートをしてほしいといってもそれ相応の維持コストがかかります。その維持コストはコールセンターもそうですし、今回のダイニーのように、おそらくエンジニアの方の待機なども立派なコストかと思います。
それがビジネス要求に見合うのか?というところを設計する必要があるのかなと思います。
発展した話だと、アーリーフェーズのタイミングで顧客の売り先も、日中帯稼働の顧客と、深夜帯稼働の顧客と、日祝稼働の顧客とといると思うので、本当にこのタイミングでこの金額で受注すべきか、受注した際のサービスレベルとしてお伝えするにはどうする?という部分がまさにSLAでまずとり扱う議題なのかなと思います。
余談②
前職の上司とSLAに関してお話を聞く機会があり、その上司はもともと保険屋さんだったので、経験談を含めてお話してくださりました。
その中で印象に残ったのは、「発生強度」と「発生頻度」という概念です。
発生強度とはいわゆる、発生した時の費用で、発生頻度はその名も通り頻度です。
例えば、保険でいうと地震保険や、感染症特約(コロナでは流行ったやつ)は、発生頻度が極小
と見込んで、その分発生強度を高い金額設定にすることで、月額費用もそれなり。
心配な方だけ入ってくださいねー、という切り口でサービス展開していて高利益率をだしていた。
しかし、実際にほとんど発生してなかったものが最近、発生してしまい、
顧客としてはお金が下りて良かったー、保険屋さんとしては、赤字?と
なってしまった例です。
これを 「SLA」 に置き換えると、例えばHWのサービスを提供している会社で
- 「xx安心サポートパック」に加入していると、そのパック内のサポート、修理費用、メンテ費用が
かかりません。
というサービスでそのパック中身が 「SLA」 なのかなと思います。(上図でいう左上です。)
その「xx安心サポートパック」で利益をより上げる方法としては
- 定期メンテナンス時に経年劣化の部品をあらかじめ交換することで、エマージェンシーコールを受けないようにする
- マニュアルを充実させることで、問い合わせ件数を減らす
- 修理件数を予測して、その部品を一括で購入することによりボリュームディスカウントする
- 傾向障害かも?を危機察知して開発にエスカレーションすることで、大火事になる前に対策を打つことで被害を最小化する
などとなります。この保険の例も、安心サポートパックの例も発生強度がそれなりに高くて、発生頻度が低いからこそサービスと成り立つと考えます。
そして、発生頻度を努力して下げることができるのが、カスタマーサポートの仕事なんだと思います。
(ここは、実はビジネスポイントで、だからサポートが大事なんだよーと上司は言ってくれました。そして、この考えが理解できて施策をしてくれたのはおもちくんだけだよーとも言ってくれました。)
裏を返すと、この座組(ビジネスリクワイアメント含めて)が成り立つ条件でないと、カスタマーサポートの施策はただの慈善活動となってしまうなとも改めて思いました。
8. まとめ
- SLAを抽象化してサービスレベルとしてみたときにSLAはサービスレベルのプロセスの中のひとつである。
- 一般的には「SLR」⇒「SLO」⇒「SLA」⇒「SLM」⇒「SIM」というプロセスで決定する。
- なので、SLAを決める際はSLOを定義したうえで、SLAに落とし込むのが適切である。
- SLAが守られなかったことによる保証に関しては諸説あるが、社内では整理して用語を統一することが誤解を防ぐことにつながる。
- ビジネスリクワイアメントを理解した上でサービスレベルの策定をしないと、コストのデメリットが大きくでてしまう。
実際にSLAを策定しての実践が経験できたら具体例を交えて記事を書いてみようかなと思います。
Discussion