MENU
IT運用・ITSMを軸に、AIと個人開発を実務で試して整理する。
  1. ホーム
  2. IT運用・ITSM
  3. SLA達成率98%でも「問題なし」とは限らない — 月次Service Reviewで聞く5つの質問

SLA達成率98%でも「問題なし」とは限らない — 月次Service Reviewで聞く5つの質問

IT運用・ITSM

※タイトルおよび本文中の「98%」は、考え方を説明するための例示値です。

目次

TL;DR

月次Service Reviewで見るべきなのは、SLA達成率そのものではありません。

重要なのは、その数字から

「何を変える必要があるのか」

を判断できることです。

私ならKPIを見るとき、最低でも次の5つを確認します。

  1. Targetを満たしたか

  2. 前月・直近数か月から悪化していないか

  3. ユーザーやBusinessへの影響と数字が一致しているか

  4. 同じ問題が繰り返されていないか

  5. 次回Reviewまでに誰が何を変えるのか

最終的には、各論点を

WATCH / ACTION / ESCALATE

のどれかへ落とします。

数字を読み上げて終わるなら、それはReportingです。

Service Reviewの価値は、数字を使って次の行動を決めることにあります。

EVIDENCE

FACT 1 — Service Levelは「Businessに基づくTarget」である

PeopleCertのITIL Service Level Managementでは、Service Level Managementの目的を、service utility・warranty・experienceについてbusiness-based targetを設定し、Business objectiveとのAlignmentを確保することとして説明しています。

つまりSLAは、

「測れる数字だから管理する」

ものではなく、

BusinessやCustomerにとって必要なService Levelを測定可能にしたもの

であるべきです。

出典：PeopleCert — ITIL 4 Practitioner: Service Level Management

FACT 2 — SLA達成率が高くても、Business Satisfactionが高いとは限らない

PeopleCertが2026年に公開したSLA Compliance Rateの解説では、高いSLA達成率が高いBusiness Satisfactionを自動的に意味するわけではないとしています。

Targetが低すぎる、実際のBusiness Needを反映していない、ユーザーが重視しているものを測れていない、といったケースがあるためです。

そのため、SLAだけでなくExperienceやBusiness Outcomeと合わせて見る必要があるとしています。

出典：PeopleCert Community — The 12 Days of Benchmarking – Day 4

FACT 3 — Service QualityはSLAだけでは測られていない

ServiceNowのService Quality指標でも、

  • Customer Satisfaction

  • Mean Time to Resolve

  • SLA Breach率

  • First Assignment Resolution

  • Reopened Ticket率

など複数のKPIが並列で扱われています。

これは少なくとも、

「SLA達成率だけ見ればService Qualityが分かる」

という設計にはなっていないことを示しています。

出典：ServiceNow — サービス品質

FACT 4 — 指標はDecision Ruleにつながって初めて意味を持つ

GoogleのSRE Workbookでは、SLOを単なるReporting Metricとして置くのではなく、ReliabilityにどこまでResourceを投入するかというDecision Makingに利用しています。

例えばError Budgetを使い切った場合には、Reliability回復まで一部のChangeやReleaseを止める、特定条件ならPostmortemを必須にする、といった具体的なAction Ruleを設定しています。

Google自身も、Decision Makingに使う仕組みがなければ、SLO Complianceは単なるKPIやReporting Metricになってしまうと説明しています。

出典：Google SRE Workbook — Implementing SLOs

WHAT IT MEANS

ここからは一次情報そのものではなく、上記EvidenceからのInferenceです。

SLA Reviewで本当に確認したいのは、

「何パーセントだったか」

だけではありません。

数字を

Target → Trend → Impact → Recurrence → Action

の順に読む必要があります。

例えば、

SLA達成率 98%

だけなら、Greenに見えます。

しかし、

  • 前月99.5%から悪化

  • 同じServiceで3か月連続低下

  • Major Incidentが2件

  • CSATも低下

  • 同一原因の再発

なら、98%だから「問題なし」と判断するのは危険です。

逆もあります。

SLAが1件だけ未達でも、

  • 一時的な例外

  • Business Impactが限定的

  • 原因が特定済み

  • Corrective Action実施済み

  • 再発傾向なし

なら、即Escalationが必要とは限りません。

数字の色と、Management上のPriorityは同じではない。

ここを分けて考えるのがService Reviewだと思っています。

NOBU INTERPRETATION

私なら、月次Service ReviewではKPIを最終的に3種類へ分けます。

WATCH

Target内。

大きな悪化傾向もなく、Business ImpactやRecurring Issueも見えていない。

今月Actionを追加する必要はないが、Trendは継続監視する。

ACTION

Target内であっても、

  • 悪化傾向

  • Repeat Incident

  • Reopen増加

  • User Experienceとの乖離

  • 特定Vendor / Serviceへの集中

などが見えている。

次回ReviewまでにOwnerとActionを設定する。

ESCALATE

Target未達だけでなく、

  • Business Impactが大きい

  • 同一問題が繰り返されている

  • Actionが進んでいない

  • Accountabilityが不明

  • Service LevelそのものがBusiness Requirementと合っていない

といった状態。

通常運用の範囲から一段上げて判断を求める。

これはITILの公式分類ではなく、私がService Reviewを「報告会」にしないために使う実務上の考え方です。

SERVICE REVIEWで聞く5つの質問

1. Targetを満たしたか？

まずBaselineです。

ただし、

「Greenだから終了」

にはしません。

未達なら、

どのService / Category / Vendor / Priorityで外れたのか

までBreakdownします。

平均値だけでは局所的な問題が隠れるためです。

2. Trendは改善しているか？

今月98%でも、

99.5% → 99.0% → 98.0%

なら話は変わります。

逆に、

92% → 95% → 98%

なら、Target未達でも改善Actionが機能している可能性があります。

私はCurrent Monthだけでなく、前月との比較に加えて、直近数か月のTrendを見ます。

3. User / Business Impactと数字は一致しているか？

ここが最も重要です。

SLAはGreenなのに、

「最近このService、ずっと遅い」

と言われているなら、

SLA側が何かを取り逃している可能性があります。

CSAT、Reopen、Major Incident、Business Impactなどを合わせて見ます。

PeopleCertが指摘するように、SLA達成とBusiness Satisfactionは必ずしも一致しません。

DashboardがGreenでも、ユーザーがRedなら確認が必要です。

4. 同じ問題が繰り返されていないか？

平均MTTRが改善していても、

同じ障害を毎月直しているなら、

Service自体は改善していません。

ここでは件数より、

  • Repeat Incident

  • Reopen

  • 同一Root Cause

  • 同一Vendor

  • 同一Service

  • 同一時間帯

などの集中を見る方が重要な場合があります。

「早く復旧した」

と

「問題をなくした」

は別です。

5. この数字を見て、次に何を変えるのか？

最後に必ずこれを聞きます。

So what?

です。

Actionが必要なら最低限、

WHAT
OWNER
DUE DATE

を決めます。

そして次回Reviewでは、新しい数字を読む前に、

前回Actionが終わったか

を確認します。

そうしないと、毎月同じPowerPointを見ながら同じ問題を話す会議になります。

NEXT ACTION

次回のService Reviewで、Dashboardを作り直す必要はありません。

まず既存のKPIから一つだけ選んで、

次の順番で見てみてください。

TARGET
↓
TREND
↓
IMPACT
↓
RECURRENCE
↓
ACTION

そして最後に、

WATCH / ACTION / ESCALATE

のどれかを書きます。

これだけでも、

「98%でした」

で終わるReviewから、

「では何をするか」

を決めるReviewへ変わります。

REUSABLE CHECKLIST

Monthly Service Review — Decision Checklist

確認項目 回答
KPI / SLA
Target
Current
Previous Month
Recent Trend ↑ / → / ↓
Business / User Impact Low / Medium / High
Repeat / Reopen Yes / No
Specific Service / Vendor Concentration
Root Cause Known Yes / No / Partial
Required Action
Owner
Due Date
Decision WATCH / ACTION / ESCALATE

最後の「Decision」が空欄なら、

まだService Reviewが終わっていない

くらいに考えていいと思います。

NEXT ISSUE BRIDGE

KPIから「ACTION / ESCALATE」が見つかった後、次に問題になるのがRCAです。

RCA資料は出てきた。

原因も書いてある。

でも翌月、また同じIncidentが起きる。

次号では、

「RCAを原因説明で終わらせないために、Service Delivery側が確認したい7つの質問」

を扱います。

IT運用・ITSM
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

Nobuのアバター Nobu

IT運用・ITSMを軸に、AIと個人開発を実務で試して整理しています。

関連記事

コメント

コメントする

目次