LESSON 30分

ストーリー

田
田中VPoE
SREの原則はわかった。だが、うちの組織には「運用チーム」が既にある。彼らの仕事をSREに置き換えるわけだが、何がどう変わるのかを明確にしないと、混乱と抵抗を招く
あなた
既存の運用チームの方々は不安に感じるかもしれませんね
あ
田
田中VPoE
そう。だから「あなたたちの仕事を奪う」ではなく「あなたたちの仕事をエンジニアリングに進化させる」というメッセージが重要だ。具体的な違いを理解して、適切にコミュニケーションする必要がある

プラクティスの比較

障害対応

観点従来運用SRE
目標「障害を起こさない」「障害からの復旧を速くする」
対応者運用チームが全件対応オンコールローテーション
判断基準経験と勘ランブックとSLOベースの判断
振り返り「犯人探し」会議ブレームレスポストモーテム
改善再発防止策（個人の注意力依存）システムの改善（自動化、冗長化）

キャパシティ管理

観点従来運用SRE
計画年次のキャパシティ見積もり継続的なキャパシティプランニング
スケーリング手動プロビジョニング自動スケーリング
予測「去年比1.5倍」の経験則トラフィックモデリングと予測
コスト「足りなくならないように多めに確保」「必要な分だけ効率的に使う」

変更管理

観点従来運用SRE
リリース頻度月1回、大きなリリース日複数回、小さなリリース
リリースプロセス変更管理委員会（CAB）の承認自動化されたパイプライン + SLOベースの判断
ロールバック手動、時間がかかる自動、数分以内
リスク評価主観的（「大丈夫だろう」）定量的（エラーバジェット残量）

組織構造の違い

従来型

CTO
├── 開発部門
│   ├── フロントエンドチーム
│   ├── バックエンドチーム
│   └── モバイルチーム
└── 運用部門
    ├── インフラチーム
    ├── 監視チーム
    └── ヘルプデスク

問題: 「壁の向こうに投げる」文化

SRE型

CTO/VPoE
├── プロダクト開発
│   ├── チームA（フルスタック + SRE責務）
│   ├── チームB（フルスタック + SRE責務）
│   └── チームC（フルスタック + SRE責務）
├── SREチーム（横断）
│   ├── プラットフォームSRE
│   ├── インシデント管理
│   └── 可観測性基盤
└── インフラチーム
    └── クラウド基盤管理

ポイント: 開発チームが信頼性に責任を持ち、SREが横断的に支援

移行における課題と対策

よくある抵抗パターン

抵抗発言例対策
運用チームの不安「自分たちの仕事がなくなる」SREへのスキルアップパスを提示
開発チームの拒否「運用まで面倒を見る余裕がない」エラーバジェットの範囲内なら開発に集中できることを説明
経営層の懐疑「今の体制で問題ないのでは」インシデントコストとSRE投資のROIを提示
中間管理職の不安「組織変更で自分のポジションがなくなる」SREリーダーとしての新しい役割を提案

まとめ

ポイント内容
最大の違い「障害を防ぐ」から「障害からの回復を速くする」への発想転換
組織構造開発チームが信頼性に責任を持ち、SREが横断的に支援
移行の鍵「仕事を奪う」ではなく「仕事をエンジニアリングに進化させる」

チェックリスト

  • 従来運用とSREの具体的な違いを理解した
  • 組織構造の変化を理解した
  • 移行時の抵抗パターンと対策を理解した

次のステップへ

次は「SRE組織モデル」です。SRE組織をどのような形態で構築するか、複数のモデルから選定する方法を学びましょう。

推定読了時間: 30分