月次報告ではSLAを達成しているのに、利用部門からは「遅い」「状況が分からない」「業務が止まる」と言われる。 これは珍しい矛盾ではありません。平均稼働率や平均応答時間が契約上の目標を満たしていても、 重要な時間帯、利用者層、業務の節目で起きる摩擦は、集計の中に埋もれることがあるからです。

ITIL 4のService Level Managementは、単に違反件数を集計する実務ではありません。 PeopleCertの公式説明では、サービスのutility（目的への適合）、warranty（利用に適した状態）、 experience（利用時の体験）について、明確で事業に基づく目標を設定し、提供と利用を評価・監視・管理する実践として示されています。 さらに、サービスレベルを価値ストリームと事業目標へ統合し、関係者やサプライヤーと継続的に改善することが重視されています。

本記事では、ITIL 4を運用の土台として保ちながら、2026年のITIL公式情報で強調されている 利用体験と事業成果の視点も取り入れます。SLAを廃止するのではなく、技術的な約束を、 人がサービスを使って仕事を進められる状態と、その先の成果へ結び直す5つの手順を整理します。

具体的な課題：SLAが「守ったことを証明する表」になる

SLAは期待を明確にし、提供者と利用者の認識をそろえるために役立ちます。 一方、作成時の前提や利用状況が変わっても同じ指標を追い続けると、報告は整っていても改善判断に使えなくなります。

  • 平均値が痛点を隠す：月間平均は良好でも、月末処理や営業時間の障害が大きな影響を生む。
  • 提供者が測りやすい指標へ偏る：サーバー稼働率は追うが、利用者が業務を完了できたかを確認しない。
  • 契約と実態がずれる：サービス、利用者、依存先が変化しても、対象範囲や優先度を更新しない。
  • 数値と利用者の声が分離する：SLA報告、問い合わせ、満足度調査、業務KPIが別々に管理される。
  • 達成判定で会議が終わる：目標達成の緑色表示を確認するだけで、次に何を改善するか決めない。
SLAは品質そのものではなく、期待と実態を対話するための共通言語です。達成率の確認から、価値を改善する判断へ進める必要があります。

考え方：「性能・体験・成果」を一つのサービス像で捉える

技術指標を捨てて主観だけを重視するのではありません。三つの層を関連づけ、異なる証拠を組み合わせます。

  1. 性能：可用性、応答、復旧、処理成功率、サポートの応答など、提供状態を客観的に捉える。
  2. 体験：利用者が状況を理解できるか、必要な操作を完了できるか、余計な負担や不安がないかを捉える。
  3. 成果：業務の継続、処理時間、顧客対応、売上機会、リスク低減など、サービスが支える目的の変化を捉える。

ITIL公式の2026年版Performance Benchmarking Modelも、デジタル技術の評価をIT内部の活動だけで完結させず、 事業との整合、レジリエンス、アジリティ、運用の有効性へ結びつける考え方を示しています。 また、ITIL Experienceは、数値だけでなく利用者の語りや行動も証拠として扱い、気づく、解釈する、 仮説を立てる、実験するという反復を重視しています。

重要なのは、一つの万能指標を探すことではありません。「この性能が、この利用場面の体験を支え、 この事業成果へ影響する」という仮説を明示し、証拠を見ながら更新することです。

実践手順1：重要なサービスと利用場面を一つ選ぶ

すべてのSLAを同時に作り直さず、事業影響が大きく、利用者との認識差が目立つサービスを一つ選びます。 サービス名だけでなく、誰が、いつ、何を達成するために使うかを記述します。

たとえば「受注システム」ではなく、「営業担当者が月末の営業時間内に受注を登録し、 出荷と請求へ正確につなげる場面」とします。利用者、業務時間帯、重要な処理、依存する外部サービス、 失敗時の代替手段までを一枚にまとめると、平均値では見えない重点が明らかになります。

実践手順2：utility・warranty・experience・成果を合意する

次に、サービスが何を可能にするか、どの条件で安心して使えるか、どのように感じられるべきか、 どの事業目的を支えるかを、利用部門、サービス責任者、運用、開発、サプライヤーで確認します。

  • Utility：利用者が完了できる仕事と、必要な機能。
  • Warranty：必要な時間帯、容量、継続性、セキュリティ、サポート条件。
  • Experience：分かりやすさ、待ち時間への納得、状況の透明性、復旧時の安心感。
  • Outcome：処理の完了、顧客への約束、業務継続、損失やリスクの抑制。

目標値は業界平均を機械的に採用せず、事業上の必要性、実現コスト、測定可能性、例外時の判断を含めて合意します。 目標を厳しくするほど常に価値が高まるとは限りません。過剰な冗長化や待機体制が、他の改善投資を圧迫する場合もあります。

実践手順3：三層をつなぐ少数の指標と証拠を選ぶ

性能、体験、成果からそれぞれ少数の信号を選び、同じ利用場面へひもづけます。 例として、重要時間帯の処理成功率、問い合わせへの初回応答、業務完了までの時間、 利用者が状況を理解できた割合、手作業の迂回件数などが考えられます。

全体平均だけでなく、重要時間帯、拠点、利用経路、優先度など、事業上意味のある区分で確認します。 ただし、利用者個人を不必要に追跡しないよう、収集目的、閲覧権限、保持期間を定めます。 数値だけでは理由が分からないため、問い合わせ記録、現場観察、短いインタビュー、障害時の振り返りも組み合わせます。

実践手順4：月次報告を「サービス対話」に変える

会議資料を達成率の一覧から、重要な利用場面ごとの対話へ変えます。 目標、実績、分布、例外、利用者の声、事業影響を同じ画面で確認し、 「何が起きたか」「なぜそう解釈するか」「次に何を確かめるか」を分けて話します。

SLA違反だけでなく、達成していても体験が悪かった事例、障害にはならなかった予兆、 問い合わせを諦めた可能性も扱います。外部サービスが関係する場合は、サプライヤーの数値を転載するだけでなく、 エンドツーエンドの利用場面への影響を共同で確認します。

ITIL公式のNunsys Group事例では、複雑な指標を避け、応答、解決、支援チャネルの可用性、 顧客満足など体験へ影響する要素へ焦点を当て、客観的な報告データと事業影響を結びつけています。 これは一社の事例であり同じ指標をそのまま採用する根拠ではありませんが、対話を簡潔に保つ参考になります。

実践手順5：改善を仮説と小さな実験で回す

会議の終点を評価ではなく、次の改善判断にします。たとえば、 「障害通知を業務用語へ変えれば、重複問い合わせと不安が減り、代替手順への移行が早まる」 というように、性能・体験・成果のつながりを仮説として記述します。

影響範囲の小さい利用者群や時間帯で試し、成功条件、停止条件、責任者、確認日を決めます。 期待した変化が起きなければ、利用者の理解不足と断定せず、仮説、計測、サービス設計を見直します。 目標値やSLA本文の変更が必要な場合は、関係者との正式な合意や契約手続を経て反映します。

注意点：体験を理由に測定を曖昧にしない

  • SLA達成だけで品質を断定しない：平均値、分布、重要時間帯、影響範囲、体験、成果を併せて見る。
  • 指標を増やしすぎない：収集・説明・改善判断に使われない指標は、定期的に整理する。
  • 数値と対話を対立させない：客観データは規模を示し、利用者の語りは背景や仮説を示す証拠として組み合わせる。
  • 目標値を評価ゲームにしない：測定対象外への押し出しや優先度操作を招かないよう、望ましくない行動も監視する。
  • 契約変更を即断しない：サービスレベル、責任分担、費用、損害、法的条件は関係部門と専門家を交えて確認する。
  • 因果を断定しない：事業成果は複数要因で変わるため、サービス改善の寄与は仮説として検証する。
  • 個人データを必要以上に集めない：体験把握の目的と範囲を明確にし、プライバシーと労務上の配慮を行う。

まとめ

SLAは、提供者が約束を守ったことを示すだけの報告表ではありません。 重要なサービスと利用場面を選び、utility、warranty、experience、事業成果を合意し、 性能・体験・成果の証拠を少数に絞ってつなぎます。月次報告を共同判断の場へ変え、 改善仮説を小さく試すことで、サービスレベル管理を継続的な価値改善へ近づけられます。

最初の一歩は、SLA達成率が高いのに不満が残るサービスを一つ選び、 重要な利用場面について「何を測っているか」「利用者は何を経験しているか」 「どの事業目的を支えているか」を一枚に並べることです。

参考にした公式資料

本記事は公式資料をもとに一般的なITサービスマネジメントの考え方を整理したものであり、 個別組織の契約、法令、投資その他の専門上・法律上の助言を行うものではありません。 公式資料は2026年8月6日時点で確認しています。実際のSLAや契約条件の設計・変更では、 自社の事業要件、利用実態、既存契約、関係部門、必要に応じた専門家の確認を踏まえてください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る