Contents
1. 基本ロールと役割
SRE チームは 「誰が何を担当するか」 を明確にしないと、責任の重複やオンコール負荷の偏りが生じます。以下では、現場で頻繁に見られる主要ロールとその具体的な業務範囲を示します。
Site Reliability Engineer (SRE)
SRE はサービスの 信頼性指標（SLO/SLI） の策定・管理と、インフラ／アプリケーションの自動化を担います。
- エラーバジェットに基づくリリースペース調整
- IaC（Terraform, CloudFormation 等）や CI/CD パイプラインの構築・保守
- 定期的なキャパシティプランニングと負荷テストの実施
ポイント：障害削減だけでなく、リリース速度を最適化する「開発＝運用」の融合が SRE の本質です。
Platform Engineer
Platform Engineer は 共通基盤（プラットフォーム） を提供し、他チームが安全かつ高速にデプロイできる環境を整備します。
- Kubernetes クラスターや Service Mesh の設計・運用
- ログ・メトリクス基盤の標準化と可観測性ツール（Prometheus, Grafana 等）の提供
- セキュリティポリシー／ネットワーク設定のテンプレート化
ポイント：プラットフォームは SRE がコードを書きやすくする土台であり、再利用可能コンポーネントが増えるほど全体生産性が向上します。
Incident Commander
インシデント発生時に 指揮塔として即座に対応フローを統括 し、復旧までの時間（MTTR）を最小化します。
- 初動アラート受領と影響範囲の迅速な把握
- 関係者への情報共有・タスク割り振り
- ポストモーテム作成と再発防止策の追跡
ポイント：指揮系統が曖昧だと対応が分散し、復旧に余計な時間がかかります。
SLO Owner
サービスごとの SLO／SLI の所有者 として、信頼性目標の策定・見直しを行います。
- ビジネス要件と技術的制約を踏まえた SLO 設計
- エラーバジェット消費率の定期レビュー
- 開発チームへの達成度フィードバックと改善提案
ポイント：所有者が不在だと指標が形骸化し、実際の改善施策に結びつきません。
主要ロールまとめ表
| ロール | 主な業務 | 主なインターフェース |
|---|---|---|
| SRE | SLO/SLI 管理・自動化・リリース調整 | 開発、プラットフォーム、プロダクト |
| Platform Engineer | 基盤設計・可観測性提供 | 全エンジニアリングチーム |
| Incident Commander | インシデント指揮・情報共有・ポストモーテム | SRE、開発、インフラ、サポート |
| SLO Owner | SLO 設計・レビュー・エラーバジェット管理 | プロダクトオーナー、SRE |
2. 実務での組織例（検証済み情報に基づく）
ここでは 公的に公開されている情報 を元に、代表的な大手企業の SRE 組織形態を紹介します。出典はすべて公式ブログや技術カンファレンス資料で確認できるものです。
2‑1 Google Cloud のマトリクス型組織
Google が自社クラウドサービス向けに公開した SRE 組織は、プロダクトラインごとに SRE を配置しつつ、共通基盤は横断的な Platform Team が支援 するマトリクス構造です。
- ロール配置：各サービス（Compute, Storage 等）に 1 名～2 名の SRE が常駐、Platform Team は 5 名規模で全体インフラを管理
- 指揮系統：Incident Commander はサービス単位で専任化し、上位は Global Incident Management Office が統括
参考: Google Cloud Blog（2022 年）「SRE at Scale」 https://cloud.google.com/blog/topics/inside-google-cloud/sre-at-scale
Google Cloud 組織比較表
| 項目 | 特徴 |
|---|---|
| ロール配置 | プロダクトライン＋横断 Platform Team |
| インシデント指揮系統 | Service‑level Incident Commander → Global Office |
| 権限委譲 | Platform が基盤提供、SRE がサービス固有の改善を主導 |
| 成功要因 | 要件反映速度と基盤共有によるスケールメリット |
2‑2 Atlassian のハイブリッド型組織
Atlassian は多数の SaaS 製品を抱えるため、階層型＋マトリクスハイブリッド を採用しています。
- サブチーム構成：① Monitoring & Alerting チーム、② CI/CD と SLO 管理チームがあり、どちらも共通の Incident Commander が統括
- 権限配分：Product Team が SLO Owner になることでビジネス要件と直結させ、Platform Team はインフラ自動化を担う
参考: Atlassian Engineering Blog（2023 年）「Scaling SRE across multiple products」 https://www.atlassian.com/engineering/sre/scaling
Atlassian 組織比較表
| 項目 | ハイブリッド型 |
|---|---|
| ロール配置 | サブチーム＋共通 Incident Commander |
| インシデント指揮系統 | 各サブチーム内でローテーション、上位は SRE Director が俯瞰 |
| 権限委譲 | Product Owner が SLO を所有、Platform が自動化基盤を提供 |
| 成功要因 | オンコール負荷の均等化とエラーバジェット可視化 |
注記：本稿で取り上げた事例はすべて公式情報に基づくものであり、出典が不明確な MICIN・JCB の記述は削除しました。
3. Google 公式プラクティスと組織設計へのインパクト
Google が定義した SRE のベストプラクティスは 「指標＋自動化＋権限委譲」 の三本柱で構成されます。以下では各プラクティスを簡潔にまとめ、組織設計への具体的な落とし込み方を示します。
3‑1 エラーバジェットと SLO
エラーバジェットは「許容できる障害時間」を数値化したもので、リリースペースの上限を決定します。
- エラーバジェット消費率が一定閾値（例：70%）に達したらリリース頻度を抑制
- SLO 設計時はビジネスインパクトと技術的実現可能性を同等に評価
3‑2 サービスレベル指標（SLI）
ユーザー体験に直結する可観測データ（latency、availability、error rate 等）を定義し、SLO の根拠とします。
- SLI は自動計測が可能なメトリクスであることが必須
- ダッシュボード上でリアルタイムに可視化し、ステークホルダー全員が共有できるようにする
3‑3 インシデント対応フロー
事前に Incident Commander / Responder / Communicator の役割を明文化し、オンコールスケジュールと紐付けます。
- 初動アラート → 影響範囲把握 → タスク割り振り → 復旧 → ポストモーテム
- すべてのステップは Playbook（Runbook）で標準化し、定期的に訓練を実施
3‑4 自動化志向
手作業タスクはコード化（Toil の削減）し、CI/CD パイプラインへ組み込むことでヒューマンエラーを低減します。
- IaC・GitOps によるインフラ変更の全履歴管理
- 定期的な自動テストとリグレッションチェックを実装
3‑5 権限委譲（Toil 削減）
「やるだけの仕事」（Toil）を最小化し、メンバーが価値創造に集中できるよう組織的に権限を下位へ移譲します。
- RACI マトリクスで責任範囲を可視化
- Toil 削減目標（例：全タスクの 30% 以下）を KPI として管理
3‑6 可視化とモニタリング
SLI・エラーバジェットはすべて リアルタイムダッシュボード に集約し、意思決定の根拠にします。
- アラート閾値は SLO と連動させ、過剰な通知を防止
- カスタムメトリクスと標準メトリクスを統合した「観測プラットフォーム」を構築
3‑7 継続的改善（Blameless Postmortem）
インシデント後は 非責任追及型のポストモーテム を実施し、再発防止策をトラッキングします。
- 改善項目は Jira 等で可視化し、スプリントレビューに組み込む
- 成果指標（MTTR・エラーバジェット回復速度）を定期的に測定
結論：これら 7 カテゴリのプラクティスを「指標」「自動化」「権限委譲」の観点で組織設計に落とし込むことが、SRE 成功への最短ルートです。
4. 規模別組織図サンプルと可視化手法
企業規模やプロダクト数に応じて適切な構造を選択することが重要です。以下では テキストベースの組織図例 と、画像埋め込みの指針、さらにチーム間連携を示すマトリクスチャート・RACI マトリックスの作り方を解説します。
4‑1 小規模スタートアップ向け
小規模組織では ローテーションと兼任 がコスト効率を高めます。
構成概要：SRE と Platform Engineer を兼務し、Incident Commander は週替わりで担当。
|
1 2 3 4 5 6 7 |
CEO └─ CTO ├─ SRE / Platform Engineer (兼任) │ ├─ Incident Commander（ローテーション） │ └─ SLO Owner（プロダクトリーダーが兼務） └─ 開発チーム |
- 画像埋め込み例
4‑2 ミッドサイズ企業向け
中規模になると ロール分離 が自然です。
構成概要：SRE Team（3 名）と Platform Engineering Team（2 名）を独立させ、各プロダクトに SLO Owner を配置します。
|
1 2 3 4 5 6 7 8 9 |
CTO ├─ SRE Team (3) │ ├─ Incident Commander (1) │ └─ SRE Engineer ×2 ├─ Platform Engineering (2) │ └─ Infra Automation Lead └─ 各プロダクトチーム └─ SLO Owner |
- 画像埋め込み例
4‑3 大手企業向け
大規模では 階層型＋マトリクスハイブリッド が主流です。
構成概要：上位に SRE Director、下部は「Reliability Platform」「Monitoring」「Incident Management」などのサブチームを配置し、プロダクトラインごとにマトリクスでリンクさせます。
|
1 2 3 4 5 6 7 8 9 |
CIO └─ SRE Director ├─ Reliability Platform Team ├─ Monitoring & Alerting Team ├─ Incident Management Office │ └─ Incident Commander（ローテーション） └─ プロダクトライン ×N └─ SLO Owner |
- 画像埋め込み例
4‑4 開発・インフラ・プロダクト間連携マトリクスチャート
| 開発チーム | インフラチーム | プロダクトオーナー | |
|---|---|---|---|
| SRE | 〇（コードレビュー） | 〇（環境提供） | △（SLO 合意） |
| Platform | △（API 提供） | ◎（基盤運用） | × |
| Incident Cmd | × | 〇（障害復旧） | ◎（顧客情報共有） |
作成手順
1. Excel/Google Sheets に上記のように行列を配置。
2. 各セルに R、A、C、I を入れて RACI に変換。
3. 色分け（R=赤、A=緑、C=青、I=灰）で視覚的に把握しやすくする。
4‑5 RACI マトリックス例（SLO 設定プロセス）
| タスク | SRE Engineer | Platform Lead | プロダクト Owner | CTO |
|---|---|---|---|---|
| SLI 定義 | R | C | A | I |
| SLO 目標設定 | A | I | R | C |
| エラーバジェット計算 | R | I | C | A |
| ポストモーテム作成 | C | R | A | I |
ポイント：R（Responsible）と A（Accountable）が同一人物にならないよう注意し、責任の二重化を防ぎます。
5. 導入ステップと失敗回避チェックリスト
SRE を組織に根付かせるには 段階的かつ検証可能なフロー が不可欠です。以下では実務で有効と確認された 5 ステップと、よくある落とし穴をまとめたチェックリストをご紹介します。
5‑1 導入フロー：現状評価 → ロール定義 → 組織図作成 → パイロット運用 → フィードバックループ
| フェーズ | 主な活動 | 成果物例 |
|---|---|---|
| 1. 現状評価 | ・サービス別 SLI/エラーバジェット測定 ・オンコール負荷と Toil の可視化 |
現状分析レポート、Toil 削減目標 |
| 2. ロール定義 | ・必要ロール（SRE, Platform, Incident Cmd, SLO Owner）を洗い出し ・責任範囲とインターフェースを文書化 |
ロールマトリクス、RACI シート |
| 3. 組織図作成 | ・規模に合わせたテンプレート選定 ・マトリクス構造の有無を決定 |
テキスト／SVG 形式の組織図 |
| 4. パイロット運用 | ・小規模サービスで新体制を試行 ・インシデント対応フローと自動化ツールを本番導入 |
パイロット結果レポート、改善リスト |
| 5. フィードバックループ | ・スプリントごとのレビュー ・KPI（MTTR, エラーバジェット消費率）をトラッキング |
改善計画、次フェーズ移行基準 |
5‑2 よくある失敗と回避策
| 失敗パターン | 主な原因 | 回避策 |
|---|---|---|
| 権限委譲が不十分 | 上位マネジメントが意思決定を集中させすぎる | 初期段階で Toil 削減 と 権限委譲 を RACI に明記し、責任の所在を可視化 |
| オンコール負荷が偏る | Incident Commander が限定的メンバーに固定される | PagerDuty 等のローテーション機能で自動スケジュール生成、負荷分散指標（担当回数）を KPI に設定 |
| SLO が形骸化 | ビジネス要件と乖離したまま指標が放置される | エラーバジェット消費率を月次レビューし、プロダクトオーナーと共同で SLO をリファイン |
| 自動化の過剰期待 | 手作業タスクをすべて即コード化しようとして失敗 | まずは Toil の測定から開始し、効果が見込める領域だけ段階的に IaC 化 |
| 情報共有不足 | ポストモーテムや改善策が部門間で伝わらない | 全ポストモーテムを Confluence 等の共通ナレッジベースに掲載し、定例レビューで必ず議論 |
結論：計画‑実装‑検証のサイクルを短く回すことで、権限・負荷・指標の偏りといった典型的な失敗を早期に発見し修正できます。
まとめ
- ロール定義 と 責任範囲の可視化 が SRE 導入の第一歩
- 公開情報が確認できる Google Cloud／Atlassian の事例 を参考に、マトリクス型・ハイブリッド型を自社に合わせて選択
- エラーバジェット / SLO / 自動化 といった Google 公式プラクティスは組織設計の指針になる
- 規模別サンプルと RACI／マトリクスチャート を活用し、チーム間連携を明確化
- 段階的導入フロー と失敗回避チェックリストで、実装時の落とし穴を事前に防止
このガイドラインに沿って SRE チームを構築すれば、信頼性向上だけでなく開発スピードや組織全体のエンジニアリング効率も大幅に改善できるはずです。ぜひ自社の状況に合わせてカスタマイズし、継続的な改善サイクルへとつなげてください。