SGのSLA・サービスレベル管理｜応答と解決、測定条件、改善を図解

SGシラバスVer.4.1のサービスマネジメント分野には、SLA、サービス時間、応答時間、サービスレベル管理、サービスレベル目標、パフォーマンス評価と改善などが挙がっています。これらを個別の略語として暗記するだけでなく、何を約束し、どの記録で達成を判断し、何を改善するかという流れでつなぎます。

サービスレベル管理（SLM）で扱うのは、稼働率だけではありません。利用する業務に応じて、サービスを使える時間、処理の速さ、問い合わせへの対応など、必要な品質を合意します。CPU使用率が低いことだけをもって、利用者が満足していると判断しないようにします。

ISMS-ACのITSMS解説も、顧客との水準の合意、品質管理、状況報告と、供給者との整合・監視を示しています。業務上の必要を聞き、測定できる条件へ具体化し、その後も確認するという関係が土台です。サービスの契約書を作る実務や、個別契約の法的な判定を代行する記事ではありません。

運用の合意の前に、導入する仕事の境界を整理する学習はSGのWBS・スコープと追加要望のケースへ。プロジェクトの完了条件と、継続するサービスの水準を分けて考えます。満足度調査などの数字はSGの回答の偏り・確証バイアスで、誰の結果から何を結論にできるかを確認できます。 関係する要素と設定の基準はSGの構成管理・CI・CMDBで、サービスの約束とは別の記録として確認できます。 合意した水準を支える能力の確認はSGのキャパシティ管理で、開始直後の集中と負荷試験の条件を独自例で整理できます。 障害の回復・原因の調査・利用申請の区別はSGのインシデント管理と問題管理・サービス要求で、関連する記録と終了条件を独自ケースから読み分けられます。

架空の会社Uの社内ヘルプデスクでは、対象の通常問い合わせについて「平日の9時から18時を受付・対応時間とし、受付後30分以内に担当者が最初の対応を始める割合を月90%以上とする」と合意したとします。ここでは休日は対象外、計測はその対応時間内で行う設定です。現実の標準値ではありません。

ある平日の10時に申請画面の不具合を受け付け、担当者が10時25分に状況を聞き始め、14時に動作の回復を確認しました。この一件の初動は25分で、架空の30分という条件内です。しかし解決まで25分だった、とはいえません。開始と終了に何を置くかが違います。

受付の自動返信が10時直後に届いていても、この会社の合意は「担当者が最初の対応を始める」です。受信確認メールだけで達成扱いにすると定義が変わります。一方、別の合意で自動受付を指標にしているなら、その定義を読みます。「自動だから全て無効」と単語だけで決めるのも誤りです。

会社Uで17時50分に受け付けた場合、30分後をそのまま18時20分としてよいでしょうか。対応時間だけを数える設定なら、当日18時までの10分と、次の対応日の残り20分をつなぐことになります。夜間や休日も数える合意なら結果は変わります。問題文にない休日や営業時間を勝手に補わないでください。

また、問い合わせの全件を対象にするのか、重複や対象外依頼を除くのかを固定します。未達だった案件だけを後から対象外にすれば、前月と比較できなくなります。定義を変える必要があるときは、変更理由と適用日を合意し、旧定義の実績と区別して報告します。

同じ定義で集計した会社Uの月次結果が、対象100件、30分以内の初動94件だったとします。この指標の実績は94%で、90%以上という設定を満たします。ただし、6件は条件内に初動できていません。「全件が約束どおりだった」と報告するのは誤りです。

さらに、この指標では、担当者が対応を始めた後の長い待ち時間や、案内の分かりやすさを評価し切れません。目標を達成していても、利用者から「返事は来るが、その後に状況が分からない」という声があれば、別の問題として確認します。苦情が一件あるだけで月次の94%が虚偽になるわけでもありません。

数字と声を対立させず、どのサービス品質を捉えた指標かを明示してください。会社Uなら、未達案件の時間帯、担当の引継ぎ、初動後の連絡間隔などを記録から調べる余地があります。調べる前から、人員不足や担当者の怠慢が原因だと決めつけることは避けます。

サービスレベル管理では、実績と合意を比べ、差や傾向、利用者への影響を確認します。会社Uの未達が特定時間に集中するなら、受付件数と担当体制、引継ぎの記録を調べ、対応の配分や連絡方法を検討します。対策の後も同じ定義で測り、改善したかを確かめます。

目標を現実に合わせて変更する検討もあり得ますが、未達を消すために、利用部門へ知らせず30分を60分へ書き換えることとは違います。業務の必要、費用、提供能力、残る影響を話し合い、合意した条件の変更として扱います。過去の実績も、新目標で達成していたことに置き換えません。

実際の例として、Microsoft Azureの公式案内は、初動応答をサポート要求から担当エンジニアが連絡し対応を始めるまでの期間と説明し、プランや事業影響、対応時間帯などで条件を分けています。この説明からも、初動応答と問題の解決を同じ意味にはできません。具体的な数値や条件は購入時の公式案内・契約で確認してください。

会社Uが外部の事業者を使うなら、外部の受付条件と社内の連絡・切り分けに要する時間を整理します。外部が対応を始める時点は、利用者が社内窓口へ連絡した時点と一致するとは限りません。顧客への合意と供給者への合意が整合するかを確かめ、間の作業が抜けないようにします。

GoogleのSRE資料で整理されるSLIは測る指標、SLOはその目標、SLAは達成・未達に伴う扱いを含む合意です。ただし、未達なら無条件に現金が返る、という意味ではありません。補償の種類、対象、申請などの条件は合意を確認します。本記事の架空ケースにも、自動返金の条件を追加していません。

会社Uを復習ノートにまとめるなら、「30分以内の初動を月90%以上と合意」「受付と初動の記録を月次に集計し見直す」「今月は100件中94件が条件内」と分けて書きます。合意書、管理の活動、測定された結果の区別がつけば、略語を入れ替えた文章の違いも説明しやすくなります。

計算自体で迷う場合はSGの割合・稼働率・単位の整理へ。文章の条件を見失う場合は科目Bの主体・権限・制約の読み方へ進んでください。指標の種類を増やす前に、いま示された指標が何を説明でき、何は説明していないかを確認しましょう。

学習範囲はSGの目次、操作と解説の体験は無料6問で確認できます。少数の体験問題でサービス管理分野全体の理解度を判定するものではありません。対象教材と購入条件はSGの教材・料金へ。

合意した品質を運用判断へつなげる周辺学習として、SLOとエラーバジェットの計算も確認できます。成功率の分母と集計窓、件数と停止時間の違いを区別します。