ストーリー
田
田中VPoE
SREの原則、従来運用との違い、組織モデル — 理論は揃った。ここからが本番だ。うちの組織でSREを立ち上げるためのミッション定義をしてもらう
あなた
理論を実際の組織に適用する、ということですね
あ
田
田中VPoE
そうだ。経営層への提案書の第一章になる部分だ。曖昧なことを書いたら即却下される。数字と根拠を持って、なぜSREが必要か、どのモデルで始めるか、何を達成するかを明確にしてくれ
あなた
承知しました。Step 1で学んだフレームワークを活用します
あ
田
田中VPoE
一つ注意がある。うちには「現場の声」がある。運用チームの山田さんは「SREなんて必要ない、今のチームで十分だ」と言っている。開発チームの鈴木さんは「運用なんて自分の仕事じゃない」と言っている。彼らを説得できるミッション定義にしてくれ
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | SRE組織のミッション定義 |
| 想定時間 | 60分 |
| 成果物 | SRE組織ミッション定義書 |
| 対象組織 | 開発チーム8チーム、運用チーム1チーム(計50名) |
前提条件
組織の現状
現在の組織構造:
CTO
├── 開発部門(部長: 鈴木)
│ ├── フロントエンドチーム(5名)
│ ├── バックエンドチーム A(6名)
│ ├── バックエンドチーム B(6名)
│ ├── モバイルチーム(5名)
│ ├── データチーム(4名)
│ ├── ML/AIチーム(3名)
│ ├── インテグレーションチーム(4名)
│ └── QAチーム(5名)
├── 運用部門(部長: 山田)
│ └── インフラ・運用チーム(8名)
└── 情報システム部(4名)
直近のインシデント実績
| 指標 | 値 |
|---|
| 過去6ヶ月の重大インシデント | 12件 |
| 平均MTTR | 4.2時間 |
| 夜間対応発生率 | 月平均8回 |
| 運用チームの離職率 | 年30%(全社平均12%) |
| デプロイ頻度 | 月2回(全チーム一括リリース) |
| デプロイ失敗率 | 25% |
| 変更管理委員会の承認待ち平均 | 5営業日 |
Mission 1: SRE組織のミッションステートメント策定
要件
以下の要素を含むミッションステートメントを作成してください。
- ビジョン: SRE組織が目指す理想状態(1-2文)
- ミッション: SRE組織の存在意義と責務(2-3文)
- コアバリュー: SRE組織が重視する3-5つの価値観
- 定量目標(1年後): 具体的な数値目標を5つ以上
制約条件
- 経営層(非エンジニア含む)が理解できる表現
- 運用チームが「仕事を奪われる」と感じない表現
- 開発チームが「負担が増える」と感じない表現
解答例
ビジョン
開発速度と信頼性を両立し、チーム全員がサービスの品質に当事者意識を持つ組織を実現する
ミッション
SREチームは、信頼性をエンジニアリングの問題として捉え、データに基づく意思決定と自動化を通じて、組織全体のサービス信頼性と開発生産性を向上させる。既存の運用チームのスキルと経験を活かしながら、手動の繰り返し作業をエンジニアリングで解決し、運用の仕事を「対処」から「改善」に進化させる。
コアバリュー
| 価値観 | 説明 |
|---|
| データドリブン | 感覚ではなく、SLI/SLOに基づいて判断する |
| 自動化ファースト | 2回以上繰り返す作業は自動化の候補とする |
| ブレームレス | 障害の原因を個人ではなくシステムに求める |
| 共有オーナーシップ | 信頼性は特定チームではなく全員の責務 |
| 継続的改善 | 完璧を目指すのではなく、毎週少しずつ良くする |
定量目標(1年後)
| 指標 | 現状 | 1年後目標 | 改善率 |
|---|
| 重大インシデント数 | 12件/半年 | 6件/半年 | 50%削減 |
| MTTR | 4.2時間 | 1時間以内 | 75%改善 |
| 夜間対応発生率 | 月8回 | 月2回以下 | 75%削減 |
| 運用チーム離職率 | 30% | 15%以下 | 50%改善 |
| デプロイ頻度 | 月2回 | 週1回以上 | 2倍以上 |
| デプロイ失敗率 | 25% | 5%以下 | 80%改善 |
| 変更承認リードタイム | 5営業日 | 1営業日以内 | 80%改善 |
| トイル比率 | 未計測 | 40%以下 | 計測開始 |
Mission 2: SRE組織モデルの選定と根拠
要件
前提条件の組織に対して、最適なSRE組織モデルを選定してください。
- モデル選定: 4つのモデルから選択(複合も可)
- 選定根拠: なぜそのモデルが最適かの分析
- 組織図: 新しい組織構造の図
- 段階的展開計画: Phase 1〜3のロードマップ
- リスクと対策: 予想されるリスクを3つ以上
考慮すべき制約
- SRE経験者は社内にゼロ(外部採用 or 内部育成が必要)
- 運用チーム8名の処遇を明確にする必要がある
- 予算は今期中に新規採用2名まで
解答例
モデル選定
Phase 1: 中央集権型 + コンサルティング要素
選定根拠:
| 判断軸 | 現状 | 判断 |
|---|
| SRE人材 | 0名(新規2名採用 + 既存運用チームから育成) | 少数 → 中央集権型 |
| チーム数 | 8チーム | 中規模 → 中央集権型で開始 |
| SRE文化 | 未形成 | コンサルティング要素で浸透 |
| 予算 | 2名採用枠 | 制約あり → 中央集権型 |
| 信頼性要件 | 重大インシデント多発 | 早期改善必要 → 中央集権型 |
新組織図
CTO
├── 開発部門(部長: 鈴木)
│ ├── フロントエンドチーム(5名)
│ ├── バックエンドチーム A(6名)
│ ├── バックエンドチーム B(6名)
│ ├── モバイルチーム(5名)
│ ├── データチーム(4名)
│ ├── ML/AIチーム(3名)
│ ├── インテグレーションチーム(4名)
│ └── QAチーム(5名)
├── SRE部門(新設・部長: 山田 ← 運用部門から転換)
│ ├── SREリード × 1(外部採用・経験者)
│ ├── SREエンジニア × 1(外部採用)
│ ├── プラットフォームエンジニア × 3(運用チームから転換)
│ ├── 可観測性エンジニア × 2(運用チームから転換)
│ └── インフラエンジニア × 3(運用チームから転換)
└── 情報システム部(4名)
ポイント:
- 運用部門を「SRE部門」にリブランド
- 山田部長を引き続き部門長に据える(ポジション維持)
- 外部から経験者2名を採用(SREリード + SREエンジニア)
- 既存8名は段階的にスキル転換
段階的展開計画
| フェーズ | 期間 | 目標 | 主な施策 |
|---|
| Phase 1 | 0-6ヶ月 | 基盤構築・クイックウィン | SRE2名採用、SLI/SLO導入(主要3サービス)、ポストモーテムプロセス確立 |
| Phase 2 | 6-12ヶ月 | 拡大・文化浸透 | 全サービスSLO化、オンコール体制確立、トイル50%以下達成 |
| Phase 3 | 12-18ヶ月 | ハイブリッド型へ移行 | クリティカルサービスに組み込みSRE配置、開発チームのSRE自走化支援 |
リスクと対策
| リスク | 影響度 | 対策 |
|---|
| 外部SRE採用が困難 | 高 | 採用条件の柔軟化、育成重視への転換 |
| 運用チームの反発 | 高 | スキルアップ研修の先行実施、1on1での丁寧な説明 |
| 経営層の期待値過大 | 中 | 6ヶ月ごとのROIレポート、段階的な目標設定 |
| 開発チームの非協力 | 中 | クイックウィン(デプロイ高速化等)で信頼獲得 |
Mission 3: ステークホルダー向け説明資料の作成
要件
以下の3つのステークホルダーに対する説明の要点をまとめてください。
- 経営層向け: ROIと事業インパクト中心
- 運用チーム向け: キャリアパスとスキルアップ中心
- 開発チーム向け: 彼らにとってのメリット中心
解答例
経営層向け
| 項目 | 現状コスト | SRE導入後(1年後見込み) |
|---|
| インシデント対応コスト | 年約2,400万円(12件×200万円) | 年約600万円(6件×100万円) |
| 機会損失(ダウンタイム) | 年約5,000万円 | 年約1,000万円 |
| 運用チーム離職・採用コスト | 年約720万円(2.4名×300万円) | 年約360万円 |
| SRE投資コスト | - | 年約2,000万円(採用2名+研修) |
| 年間純効果 | - | 約4,160万円の削減 |
運用チーム向け
| 現在の課題 | SRE転換後 |
|---|
| 夜間の緊急対応が多い | ローテーション制で負担を分散 |
| 手動作業の繰り返し | 自動化エンジニアリングにシフト |
| 「何かあったらお前のせい」 | ブレームレス文化 |
| キャリアパスが不明確 | SREエンジニア→シニアSRE→SREマネージャー |
| スキルが陳腐化する不安 | Kubernetes、可観測性、IaC等の最新スキル習得 |
開発チーム向け
| 現在の課題 | SRE導入後 |
|---|
| デプロイが月2回で遅い | 自動パイプラインで週1回以上に |
| 変更承認に5日かかる | SLOベースの自動承認で1日以内 |
| 本番環境の状態がわからない | ダッシュボードでリアルタイム可視化 |
| 障害対応で開発が止まる | エスカレーションフローで適切に分担 |
| 「運用のことは知らない」 | SREチームが支援、段階的にナレッジ共有 |
達成度チェック
| 観点 | 達成基準 |
|---|
| ミッションステートメント | ビジョン・ミッション・コアバリュー・定量目標が含まれている |
| 組織モデル選定 | 制約条件を踏まえた根拠ある選定ができている |
| 段階的展開 | 3フェーズ以上のロードマップがある |
| ステークホルダー対応 | 3者それぞれに刺さるメッセージが作れている |
| 実現可能性 | 予算・人材制約の範囲内で計画されている |
推定所要時間: 60分