ストーリー
田
田中VPoE
SREの原則と従来運用との違いを理解した。次は「どのようなSRE組織モデルを採用するか」だ。実はこの選択が最も重要で、間違うとSRE導入自体が失敗する
田
田中VPoE
ある。Googleモデルをそのまま真似ても、うちの規模や文化に合わない。組織の成熟度、チーム数、予算、採用力 — これらの制約の中で最適なモデルを選ぶ必要がある
田
田中VPoE
そうだ。しかも一度決めたら終わりじゃない。組織の成長に合わせてモデルを進化させる戦略も必要だ
SRE組織の4つのモデル
モデル1: 中央集権型SRE
CTO/VPoE
└── SREチーム(中央)
├── SRE-A → サービスX, Y, Z を横断的に担当
├── SRE-B → サービスA, B, C を横断的に担当
└── SRE-C → 共通基盤・プラットフォーム
| 観点 | 内容 |
|---|
| 特徴 | 独立したSREチームがすべてのサービスの信頼性を担当 |
| メリット | 専門性の集中、ベストプラクティスの統一、採用が容易 |
| デメリット | ボトルネック化しやすい、サービスの深い理解が難しい |
| 適したフェーズ | SRE導入初期、10チーム以下の組織 |
モデル2: 組み込み型SRE
CTO/VPoE
├── チームA
│ ├── 開発者 × 5
│ └── SRE × 1(チーム専属)
├── チームB
│ ├── 開発者 × 5
│ └── SRE × 1(チーム専属)
└── チームC
├── 開発者 × 5
└── SRE × 1(チーム専属)
| 観点 | 内容 |
|---|
| 特徴 | 各開発チームにSREが配属される |
| メリット | サービスの深い理解、チームとの密なコミュニケーション |
| デメリット | SREの孤立化、スキル成長の停滞、横断的な知見共有が困難 |
| 適したフェーズ | サービスが成熟し、専門的なSRE支援が必要なフェーズ |
モデル3: ハイブリッド型SRE
CTO/VPoE
├── SREプラットフォームチーム(中央)
│ ├── 可観測性基盤
│ ├── インシデント管理プロセス
│ └── 共通ツール・フレームワーク
├── チームA
│ ├── 開発者 × 5
│ └── 組み込みSRE × 1
├── チームB
│ ├── 開発者 × 5
│ └── 組み込みSRE × 1
└── チームC(SRE未配属)
└── 開発者 × 6(中央SREが支援)
| 観点 | 内容 |
|---|
| 特徴 | 中央チームが共通基盤を提供し、重要サービスには組み込みSREを配置 |
| メリット | 柔軟性が高い、リソースの最適配分が可能 |
| デメリット | 組織設計が複雑、役割の重複・曖昧さが生じやすい |
| 適したフェーズ | 10チーム以上の中〜大規模組織 |
モデル4: コンサルティング型SRE
CTO/VPoE
├── SREコンサルティングチーム(中央)
│ ├── SRE-A → チームXにSREプラクティスを指導(3ヶ月)
│ ├── SRE-B → チームYにSREプラクティスを指導(3ヶ月)
│ └── SRE-C → ドキュメント・教育プログラム整備
├── チームX(SREプラクティス自走中)
├── チームY(SRE指導中)
└── チームZ(指導待ち)
| 観点 | 内容 |
|---|
| 特徴 | SREチームが期間限定で各チームを支援し、自走化を促す |
| メリット | SRE文化の組織全体への浸透、少ないSREで多くのチームを支援可能 |
| デメリット | 深い専門支援が難しい、指導後の品質維持が課題 |
| 適したフェーズ | SRE人材が少ない初期、または全チームのSRE成熟度を底上げしたい時 |
モデル選定のフレームワーク
判断マトリクス
| 制約・条件 | 中央集権型 | 組み込み型 | ハイブリッド型 | コンサルティング型 |
|---|
| SRE人材が少ない(3名以下) | ◎ | × | △ | ○ |
| チーム数が多い(10+) | △ | × | ◎ | ○ |
| サービスの複雑性が高い | △ | ◎ | ○ | × |
| SRE文化がまだない | ○ | △ | △ | ◎ |
| 予算制約が厳しい | ◎ | × | △ | ○ |
| 高い信頼性要件 | ○ | ◎ | ◎ | △ |
選定フロー
SRE人材は何名確保できる?
├── 1-3名 → 中央集権型 or コンサルティング型
│ ├── 短期的に信頼性改善が必要 → 中央集権型
│ └── 長期的なSRE文化浸透が優先 → コンサルティング型
├── 4-8名 → ハイブリッド型
│ ├── クリティカルなサービスが明確 → クリティカルに組み込み + 残りは中央
│ └── すべて同等の重要度 → 中央 + ローテーション
└── 9名以上 → 組み込み型 or ハイブリッド型
├── チーム間の共通課題が多い → ハイブリッド型
└── 各チームが独立性高い → 組み込み型
組織進化のロードマップ
フェーズ別アプローチ
| フェーズ | 期間 | モデル | 目標 |
|---|
| Phase 1: 立ち上げ | 0-6ヶ月 | 中央集権型 | 基盤構築、クイックウィン |
| Phase 2: 拡大 | 6-18ヶ月 | ハイブリッド型 | クリティカルサービスへの組み込み |
| Phase 3: 成熟 | 18-36ヶ月 | 組み込み + コンサルティング | 全チームのSRE自走化 |
進化のトリガー
| トリガー | 現在のモデル | 次のモデル |
|---|
| SREチームがボトルネックに | 中央集権型 | ハイブリッド型 |
| チーム固有の課題が増加 | ハイブリッド型 | 組み込み型を増やす |
| SRE文化が定着しないチームがある | ハイブリッド型 | コンサルティング要素を追加 |
| SRE人材の採用が進んだ | コンサルティング型 | ハイブリッド型に移行 |
現実的なトレードオフ
よくある失敗パターン
| 失敗 | 原因 | 教訓 |
|---|
| 「全チームにSREを配置」宣言 | SRE人材が足りず、名前だけSRE | 段階的に展開、最初は1-2チームで成功事例を |
| Googleモデルの完全コピー | 組織規模・文化の違いを無視 | 原則を理解した上で自組織に最適化 |
| SREチームを「上位運用チーム」扱い | 既存運用の延長線で理解 | エンジニアリング文化の構築が前提 |
| 組織モデルの固定化 | 「決めたら変えない」思考 | 定期的にモデルの適合性を評価 |
まとめ
| ポイント | 内容 |
|---|
| 4つのモデル | 中央集権型、組み込み型、ハイブリッド型、コンサルティング型 |
| 選定の鍵 | SRE人材数、チーム数、サービス複雑性、文化の成熟度 |
| 進化の考え方 | 一度決めて終わりではなく、組織の成長に合わせてモデルを進化させる |
チェックリスト
次のステップへ
次は「演習:SRE組織のミッション定義」です。ここまで学んだ知識を活かして、実際にSRE組織のミッションステートメントと組織モデルを設計しましょう。
推定読了時間: 30分