LESSON 30分

ストーリー

田中VPoE
SREの原則と従来運用との違いを理解した。次は「どのような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人材数、チーム数、サービス複雑性、文化の成熟度
進化の考え方一度決めて終わりではなく、組織の成長に合わせてモデルを進化させる

チェックリスト

  • 4つのSRE組織モデルの特徴を理解した
  • 自組織に適したモデルを選定できる判断軸を理解した
  • 組織進化のロードマップの考え方を理解した

次のステップへ

次は「演習:SRE組織のミッション定義」です。ここまで学んだ知識を活かして、実際にSRE組織のミッションステートメントと組織モデルを設計しましょう。


推定読了時間: 30分