「ITIL でインシデント管理は回っている。でも MTTR は改善しないし、開発と運用の対立は深まる一方」――2026 年、中堅企業（従業員 500-3,000 名）の情シス部長から繰り返し聞く課題である。 Google が 2003 年に SRE（Site Reliability Engineering）を始めて 20 年以上が経ち、SLO（Service Level Objective）/ Error Budget / トイル削減 という運用思想は世界の業界標準になった。本記事は ITIL 中心の中堅企業が SRE / SLO 文化へ段階的に移行する 3 年ロードマップを、Google SRE Book と Team Topologies の枠組みに沿って整理する。記事内の引用・概念定義は執筆時点（2026 年 4 月）の各書籍 / Google 公式ドキュメントに基づく目安であり、適用時は最新版を必ず参照されたい。
目次
- なぜ ITIL 単独では 2026 年の中堅企業に足りないか
- SRE / SLO / Error Budget の基礎概念
- SLI / SLO / SLA の正しい関係
- Team Topologies に基づく SRE 組織設計
- 3 年ロードマップ（Year 1 / Year 2 / Year 3）
- Error Budget Policy の作り方
- トイル削減 と 50% ルール
- ITIL からの移行で起きる組織抵抗と対処
- よくある質問（FAQ）
- 関連記事
なぜ ITIL 単独では 2026 年の中堅企業に足りないか
ITIL（Information Technology Infrastructure Library、現行は ITIL 4）は 「インシデント管理 / 問題管理 / 変更管理」 などのプロセス標準として現在も中堅企業で広く運用されている。しかし以下の構造的な限界が顕在化している。
限界 1：信頼性に「定量目標」がない
ITIL の SLA（Service Level Agreement）は「月次稼働率 99%」など契約目標として存在するが、日次・サービス単位の SLI（実測値）と SLO（運用目標）の階層が緩い。結果として「SLA は達成したが、ユーザー体験は劣化」という現象が発生する。
限界 2：開発と運用の「対立」を構造化してしまう
ITIL の変更管理は「リリースを止める」ことが容易な設計で、開発の速度と運用の安定性が 構造的に対立 する。開発チームは「リリースさせろ」、運用チームは「リスクがあるから止めろ」の二項対立が文化として根付く。
限界 3：トイル（toil）の概念がない
定型的な手作業（アカウント発行 / バックアップ確認 / 月次レポート作成）が運用工数を 60-80% 占めるが、ITIL では 「トイルを工数比率で定量管理する」 概念がない。改善モチベーションが構造化されない。
限界 4：ポストモーテムが「責任追及」になる
ITIL の問題管理は根本原因分析（RCA）を含むが、「Blameless（無責)」が文化として明文化されていない。結果として障害報告が政治化し、本当の原因が共有されない事故が多発する。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
SRE / SLO / Error Budget の基礎概念
Google SRE Book（2016 年初版、Niall Murphy / Betsy Beyer 編）で体系化された SRE は、信頼性を 「機能要件と同等のエンジニアリング対象」 として扱う運用思想である。
SRE の 7 大原則（書籍より要約）
- 信頼性は機能要件と同等のエンジニアリング対象 である
- 100% 信頼性は目標にしない（コストが無限大、ユーザー体験への寄与は逓減）
- SLI / SLO / Error Budget で信頼性を定量管理 する
- トイル（toil）を 50% 以下に抑え、エンジニアリング工数を確保 する
- Blameless ポストモーテム で障害から学ぶ
- 自動化が最高のスケール戦略 である
- 共有責任（開発と運用の対立構造を解消）
Error Budget の核心アイデア
SLO 99.9%（月次ダウン許容 43.2 分）を設定すると、「43.2 分 / 月のダウン予算」= Error Budget が生まれる。Error Budget が残っている限り 開発チームは積極的にリリースしてよい、Error Budget を使い切ったら リリース凍結 + 信頼性改善優先 にスイッチする。
このルールにより 「リリース速度 vs 信頼性」の経営判断が定量化 され、開発と運用の対立が構造的に解消する。
SLI / SLO / SLA の正しい関係
3 つの S はしばしば混同されるが、階層が異なる。
| 概念 | 定義 | 例 | 主担当 |
|---|---|---|---|
| SLI（Indicator） | 実測指標 | リクエスト成功率、p95 レイテンシ | SRE / 観測基盤 |
| SLO（Objective） | 運用目標 | リクエスト成功率 99.9% | SRE + プロダクト |
| SLA（Agreement） | 契約目標（顧客約束） | 月次稼働率 99%、超過時返金 | 法務 + 営業 + プロダクト |
SLO は SLA より「厳しく」設定する
SLA を 99% とした場合、SLO は 99.5-99.9% など SLA より厳しく 設定する。SLO 違反で内部アラート → 改善開始、SLA 違反で顧客対応 / 返金、という二段構えで顧客影響を防ぐ。
SLI 設計の Four Golden Signals
Google SRE Book で提唱された 4 つの基本観測指標。
- Latency：応答時間（p50 / p95 / p99）
- Traffic：リクエスト数 / 秒
- Errors：エラー率
- Saturation：リソース使用率（CPU / Memory / Disk）
中堅企業の SLI 設計はこの 4 軸を起点にし、業務固有指標（決済成功率 / 検索結果適切率など）を追加する。
SLO 設計の典型ライン
| サービス特性 | SLO 例 | Error Budget（月次） |
|---|---|---|
| 業務基幹システム | 99.95%（高信頼） | 21.6 分 |
| 顧客向け Web | 99.9% | 43.2 分 |
| 社内ツール | 99.5% | 3.6 時間 |
| バッチ処理 | 99% | 7.2 時間 |
100% を目指さない理由は 「100% を目指すコストが線形以上に跳ね、ユーザー体験への寄与は逓減する」 ため。SLO は「ユーザーが不満を感じない最低ライン」を狙う。
Team Topologies に基づく SRE 組織設計
Matthew Skelton / Manuel Pais 著「Team Topologies」（2019）は、組織を 4 種類のチーム + 3 種類の相互作用で設計する枠組みで、SRE 導入の組織設計と相性が良い。
4 つのチームタイプ
- Stream-aligned team（ストリーム整合チーム）：プロダクト / サービスを End-to-end で担う開発チーム
- Platform team（プラットフォームチーム）：他チームに内部プロダクトを提供（観測基盤・CI/CD 基盤など）
- Enabling team（イネーブリングチーム）：Stream-aligned team に専門知識を一時的に移転（SRE / セキュリティ / DBA など）
- Complicated subsystem team（複雑サブシステムチーム）：高度専門領域の集中チーム（決済エンジン・ML 基盤など）
SRE はどう配置するか（中堅企業の現実解）
中堅企業（SRE 5-15 名規模）では以下の 2 段階移行が推奨される。
Year 1：
- SRE を Enabling team として 3-5 名配置
- 1 つのストリームチームに 6-12 ヶ月 hands-on 支援
- SLI / SLO 設計・観測基盤導入を伴走
Year 2-3：
- SRE Enabling team は維持しつつ、観測 / CI 基盤を Platform team として独立化（3-5 名）
- 各ストリームチームに SRE-aligned engineer（SRE 思考を持つ開発者）が育つ
- 重要サービスには Embedded SRE（プロダクトチーム常駐 SRE）を 1-2 名配置
Anti-pattern：「SRE = 運用部門の改名」
ITIL 運用部門をそのまま「SRE 部」に改名するだけでは失敗する。Google SRE の核心は 「ソフトウェアエンジニアが運用課題を解く」 であり、コードを書かない SRE は SRE ではない。中堅企業では 採用 + 既存運用エンジニアの再教育 の両輪が必須。
3 年ロードマップ（Year 1 / Year 2 / Year 3）
中堅企業が ITIL から SRE 文化に段階移行する標準ロードマップ。
Year 1：パイロットと文化の種植え
第 1 四半期：基盤整備
- 経営合意：SRE / SLO 導入の意思決定（CIO + CTO）
- 観測基盤調達 / 整備（SaaS or 内製）
- パイロット対象 1 サービス選定（業務クリティカルでない中規模サービス推奨）
第 2-3 四半期：パイロット
- パイロットサービスで SLI 計測開始（最低 2 ヶ月のベースライン）
- SLI 分布から SLO 設定（経営 / プロダクトオーナー合意）
- Error Budget Policy 起草
第 4 四半期：拡大準備
- パイロット成果のレビュー
- ポストモーテム文化の Blameless 訓練
- Year 2 拡大対象サービス 5-10 個選定
Year 2：拡大と Error Budget 運用
- 5-10 サービスに SLO 適用拡大
- Error Budget Policy を組織標準化
- リリース凍結 / 改善期間の運用ルール確立
- トイル測定開始（工数の何 % がトイルか可視化）
- ポストモーテム公開化（社内 wiki で共有）
Year 3：標準化とプラットフォーム化
- 全主要サービスに SLO 適用（カバレッジ 80% 以上）
- 観測 / CI / リリース基盤の Platform team 独立
- SRE Embedded をクリティカルサービスに常駐
- 経営報告に SLO / Error Budget 達成状況を組み込む
- 全社 KPI に「トイル比率 50% 以下」を組み込む
各年の人員 / 投資目安（中堅企業）
| 年 | 専任 SRE | 投資額（人件費含む） |
|---|---|---|
| Year 1 | 3-5 名 | 5,000 万-1 億円 |
| Year 2 | 6-10 名 | 1-2 億円 |
| Year 3 | 10-15 名 | 1.5-3 億円 |
初年度の経営合意なくして 3 年継続はない。導入意思決定時に 3 年予算の経営承認を取り付けることが必須。
Error Budget Policy の作り方
Error Budget Policy は SRE 組織の核心ドキュメントで、「Error Budget をどう使い、どう枯渇したら何が起きるか」 を経営合意レベルで明文化する。
標準テンプレート
- 対象サービス：このポリシーが適用されるサービス一覧
- SLO 一覧：可用性 / レイテンシ / エラー率の SLO 値
- 計測期間：月次 / 28 日ローリングウィンドウ など
- Error Budget 残量別アクション：
- 残量 50% 以上：通常リリース可
- 残量 10-50%：高リスクリリースは事前レビュー
- 残量 10% 未満：リスクのあるリリース凍結、信頼性改善優先
- 残量ゼロ：全リリース凍結（緊急セキュリティ修正除く）、Postmortem 強制
- 承認権限：例外承認の意思決定者（CTO / プロダクトオーナー）
- 見直し頻度：四半期ごと
Policy 運用の落とし穴
- Error Budget を毎月リセットしない：28 日ローリングで「直近の傾向」を反映
- 凍結を「罰」と認識させない：信頼性改善は開発工数の正当な使い道
- Policy を経営承認しない：Error Budget 枯渇時のリリース凍結が業務都合で覆されると Policy が形骸化
トイル削減 と 50% ルール
Google SRE Book は 「SRE のトイル工数を 50% 以下に抑える」 を組織ルールとして提唱する。
トイルの定義
- 手作業（自動化可能だが手でやっている）
- 反復的（繰り返し発生する）
- 戦術的（緊急対応・根本解決でない）
- スケールしない（サービス成長と共に線形以上に増える）
- 永続的価値を生まない
トイル削減の標準アプローチ
- トイル時間の月次計測（タイムトラッキング or ticket 分類）
- トイル Top 10 の特定
- 自動化バックログ化（プラットフォーム team / SRE team で開発）
- 削減後の効果測定
50% ルールが守れない時のアクション
- SRE 増員（採用 / 再教育）
- 該当サービスを開発チームに差し戻し（信頼性責務移管）
- プラットフォーム化投資の前倒し
- 経営エスカレーション（信頼性投資 vs 機能開発のリソース配分判断）
ITIL からの移行で起きる組織抵抗と対処
抵抗 1：「変更管理を緩めるとリスクが増える」
対処：Error Budget が定量的なリスク管理装置 であることを経営に説明。Budget が枯渇したら自動でリリース凍結が発動するため、ITIL より厳格に運用できる。
抵抗 2：「SRE は開発の言いなりになる」
対処：SRE は Error Budget Policy の執行者 であり、Budget 枯渇時にはリリース凍結を主張する独立した意思決定権限を持つ。
抵抗 3：「ポストモーテム公開は責任追及につながる」
対処：Blameless 文化の経営宣言 を CIO / CTO 名義で発出。匿名化 / 個人名削除 / 「組織課題」フレーミングで運用。
抵抗 4：「ITIL 認定を取得した運用部門の存在意義がなくなる」
対処：ITIL 4 と SRE は 共存可能。ITIL は「ガバナンス・契約・コンプライアンス」、SRE は「信頼性エンジニアリング・自動化」と役割分担する。ITIL 認定は引き続き価値を持つ。
抵抗 5：「3 年は長すぎる、すぐ効果が欲しい」
対処：Year 1 末のパイロット成果（MTTR 改善 / リリース頻度向上 / インシデント件数減）を定量提示 することで継続承認を取る。Year 2 / Year 3 の拡大判断は実績ベース。
よくある質問（FAQ）
Q1. 中堅企業で SRE 採用は可能か
A. 専任 SRE のスキルセット（Kubernetes + プログラミング + 信頼性工学）を持つ人材は希少。既存運用エンジニア + 開発エンジニアの再教育（6-12 ヶ月） が現実解。Google SRE Book の輪読 + ハンズオン研修が標準入門路。
Q2. SLO の値はどう決めるか
A. 2 ヶ月以上のベースライン計測 → ユーザー不満発生ラインを過去データから推定 → プロダクトオーナー合意 が王道。最初から「99.99%」など極端な値を置くと運用破綻する。99% から始めて段階的に厳しくする。
Q3. Error Budget Policy で本当にリリース凍結できるか
A. 経営承認 + 文書化が必須。「ビジネス都合で覆せる」とチームが認識した瞬間に Policy は死ぬ。覆す場合は CTO レベルの正式承認 + 議事録残し + 次月の Budget 増配というフロー化が必要。
Q4. ITIL を完全廃止すべきか
A. 不要。ITIL のガバナンス / 契約 / コンプライアンス機能は引き続き有効。SRE は「日次運用と信頼性エンジニアリング」、ITIL は「組織ガバナンスと契約」 で役割分担する企業が多数派。
Q5. SLO 達成しているのに体感障害が出るのはなぜか
A. SLI が業務指標と乖離している可能性が高い。「リクエスト成功率」だけでなく「ユーザージャーニー成功率」 を SLI に追加する。例えば EC なら「カート → 決済完了の Conversion Rate」を SLI に。
Q6. ポストモーテムのテンプレートは
A. Google SRE Book / Postmortem.io / Atlassian テンプレートが定番。最低項目は (1) サマリ、(2) 影響範囲、(3) 時系列、(4) 根本原因、(5) アクションアイテム + 期限 + 担当者、(6) 学んだこと（Good / Bad / Try）。
Q7. SRE と DevOps の違いは
A. SRE は「信頼性に特化した DevOps の具体実装」。DevOps が文化 / 思想なら、SRE は SLO / Error Budget / トイル削減という具体ツールセット。Google が「class SRE implements interface DevOps」と表現する関係。
Q8. プラットフォームエンジニアリング（IDP / Backstage 等）との関係は
A. Year 2-3 で SRE が Platform team に発展 するパターンが多い。Backstage / Spotify Backstage 系の Internal Developer Platform は、SRE 文化が成熟した組織で「開発者体験向上」に投資する次の一手。
関連記事
- Datadog / New Relic / Splunk 中堅コスト最適化 2026
- OpenTelemetry 内製基盤 2026｜Grafana Tempo / Loki / Mimir で中堅 SRE が SaaS 高騰を回避する
- Datadog vs New Relic vs Prometheus 中堅企業 監視 比較 2026｜価格・APM・ログ・運用負荷 6 軸スコア
- DevOps / CI/CD 導入ガイド 中小企業向け 2026
- DX 組織構築 ミニマムガイド 中小企業向け
参考資料
- Google "Site Reliability Engineering"（2016）/ "The Site Reliability Workbook"（2018）/ "Building Secure and Reliable Systems"（2020）（https://sre.google/books/）
- Google SRE Book Online（https://sre.google/sre-book/table-of-contents/）
- Matthew Skelton / Manuel Pais "Team Topologies"（2019）
- Niall Murphy 他 SRE Book 執筆陣の各種カンファレンス公演
- ITIL 4 公式（Axelos）
- CNCF / OpenTelemetry / Prometheus 公式ドキュメント
SRE / SLO / Error Budget 導入のご相談
GXO は中堅企業（従業員 500-3,000 名）向けに、ITIL 中心の運用組織から SRE / SLO / Error Budget 文化への 3 年移行を支援します。SLI / SLO 設計、Error Budget Policy 起草、Team Topologies に基づく組織設計、ポストモーテム文化醸成、トイル削減プログラム、SRE 採用 / 再教育プランまで一貫対応可能です。経営合意形成から Year 1 パイロット選定まで、初期コンサルテーションから承ります。
