[Doc] SLA（Service Level Agreement）の設計と書き方　(+Operation Level Agreement,Underpinning Contract)

多くの方にご覧いただき、誠にありがとうございます。  実務においてSLAの策定や運用に関わる方に向けて、わかりやすく丁寧にSLAの書き方をまとめました。  **2025年4月更新：SLAテンプレート構成、KPI指標、作成手順、違反対応フローを追加し、実務に即した形でアップデートしました。**

# 運用フェーズに欠かせないSLAとは  
**– SLA/OLA/UCの基本と実践的な考え方 –**

## はじめに

システムやサービスの開発が完了し、いよいよ運用フェーズへと移行する段階で必要になるのが **SLA（Service Level Agreement）** です。  
実際には、開発前の段階からクライアントと合意し、SLAの内容を明確にしておくことが理想です。

---

## SLA / OLA / UCとは何か

### SLA（Service Level Agreement）

SLAとは、「サービス品質保証契約」とも呼ばれ、**サービス提供者と利用者の間で取り交わされる、サービス内容や品質レベルに関する合意文書**です。

#### 主な内容例

- 稼働率（例：99.9%の可用性）
- サポート時間帯
- 障害発生時の対応時間

#### SLAが必要な理由

- 品質の明文化により、トラブルを未然に防止できる
- 提供者側の「防御線」として機能する
- 利用者に安心感と信頼を提供できる

---

### OLA（Operational Level Agreement）

SLAを守るために、**社内チーム間で取り交わす合意書**です。  
担当者や対応範囲、責任分界点、エスカレーション手順などを明確にします。

---

### UC（Underpinning Contract）

外部ベンダーやクラウドサービスと結ぶ契約書で、SLAを支える基盤となります。  
たとえば、AzureやAWSのSLAを自社SLAに反映させる必要があります。

---

## SLA作成のステップ（詳説）

SLAは、単に契約文書を作る作業ではなく、サービスの全体設計と運用方針を明文化する重要なプロセスです。以下に、実務的な視点での手順を詳しく解説します。

---

### 1. サービス内容の棚卸しと構成の整理

- 提供するサービス、機能、対象範囲を洗い出す
- SaaSの場合：Webアプリ、API、バッチ処理、管理画面など
- どの範囲がSLAの対象になるか（例：本番環境のみ、検証環境は対象外）

📝 **目的**：曖昧な範囲はトラブルの元。まずはスコープを明確に。

---

### 2. クライアント視点で重要な品質項目を特定

- ユーザーがもっとも重視する項目は何か？（例：レスポンス時間、安定稼働、障害時の対応スピード）
- 利用シーンや業務上の制約から逆算する
- ユーザーとのヒアリングが効果的

📝 **目的**：SLAの中心は“ユーザー価値”。ズレると形骸化します。

---

### 3. 社内でOLAを締結し役割を明確化

- 開発・SRE・カスタマーサポートなど、関係チームの責任を分担
- 例：障害検知はSRE、初動連絡はCS、技術調査は開発チームなど
- 夜間・休日対応の有無なども明確に

📝 **目的**：社内で実行できないSLAは意味がありません。内部合意が不可欠です。

---

### 4. 外部ベンダーとのUC（Underpinning Contract）を確認

- クラウドインフラ（Azure, AWSなど）、外部API（SMS送信、決済など）
- それぞれのSLAと制限事項（例：S3の耐久性、Cloudflareの保証範囲など）
- 自社のSLAより高い保証はできないため、ベンダーSLAを必ず確認・添付

📝 **目的**：依存先の限界を知らずに自社SLAを組むと破綻します。

---

### 5. KPIを設定し評価方法を明記

- 例：月間稼働率99.9%、障害初動10分以内、CS対応満足度85%以上など
- KPIは「可視化可能」かつ「継続測定」できるものにする
- メトリクス取得元（監視ツール、ログ、アンケートなど）を明示

📝 **目的**：KPIなきSLAは、評価できない約束になってしまいます。

---

### 6. SLAドラフト作成 → レビュー → クライアント合意

- ドラフト作成後、社内レビュー（運用・法務・営業）
- クライアントへ提示し、質疑応答を経て合意
- バージョン管理と合意履歴の保存も重要

📝 **目的**：契約として成立するには、相互理解と明文化が必要です。

---

## SLAにおけるKPI（評価指標）

| KPI項目 | 説明 |
|--------|------|
| SLA合意目標の未達率 | 目標稼働率や対応時間に届かなかった割合 |
| OLA・UCの未対応件数 | 内部・外部要因で未達となった件数 |
| SLAレビュー率 | 定期レビューの実施率 |
| SLA変更件数 | 契約改定や修正の頻度 |
| SLA未カバー業務の発生数 | 対象外の業務が発生した件数 |
| 顧客満足度 | ユーザーアンケートなどのスコア |

---

## SLA違反が発生した場合の対応フロー

1. ユーザーからの報告受付（問い合わせ、監視検知）  
2. 運用チームによる影響確認とSLA適用判断  
3. 復旧対応とログ・証跡の記録  
4. SLA未達が確定した場合：  
   - クライアントへの報告  
   - 補填や返金などの合意対応  
   - 再発防止策の提示

---

## SLAの種類

### 努力目標型SLA

- 初期導入フェーズに適している  
- SLA未達でもペナルティなし（ただし計測は行う）

### 目標保障型SLA

- 本格運用、公共案件に多い  
- SLA未達時の補償条件や契約解除条項が必要

---

## SLAテンプレート構成例

### 1. 適用範囲

- サービス名・機能概要  
- 対象となるサービスの提供範囲  
- 提供者情報（会社名・部署など）

### 2. サービス提供時間帯

- 稼働時間（例：24時間365日）  
- サポート時間（例：平日9:00〜18:00）

#### 計画停止について

- 停止の通知期限（例：3営業日前）  
- 停止の目的、頻度、通知方法の明記

### 3. SLA未達成時の対応

- 利用者からの申請手順  
- 返金の有無と上限額  
- 契約見直しの条件など

### 4. サービスごとの基準値

- 可用性（例：月間99.9%以上）  
- 障害対応時間（例：初動5分以内）  
- 障害復旧目標時間  
- 通知手段と通知時間

### 5. 障害の定義

例：  
> 「30分以上、全ユーザーがサービスへアクセスできない状態を“障害”と定義する」

### 6. SLAの適用外条件

- 天災（地震、洪水など）  
- 通信回線障害（ユーザー側）  
- 外部サービス停止（例：クラウド障害）

### 7. SLA変更フロー

- 提出手順、レビュー方法  
- 通知期間（例：変更30日前）  
- クライアント同意取得の手段

---

## SLA運用Tips・よくある落とし穴

- 「障害」などの定義が曖昧でトラブルになりやすい  
- ベンダーのSLAを考慮せずに高い目標を掲げてしまう  
- SLAのレビューや更新が行われず形骸化する

---

## SLAは誰が作る？いつから作る？

- **作成者：サービス運用責任者（PMやSRE）**  
- **レビュー：法務・営業部門**  
- **タイミング：要件定義と並行して早期に着手することが望ましい**

---

## 参考リンク

- [要件定義書テンプレート - Qiita](https://qiita.com/syantien/items/9a8a7cbaeca2be3ef0d7)
- [Microsoft Azure SLA（公式）](https://azure.microsoft.com/ja-jp/support/legal/sla/)

---