EXERCISE 60分

ストーリー

田中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件
平均MTTR4.2時間
夜間対応発生率月平均8回
運用チームの離職率年30%(全社平均12%)
デプロイ頻度月2回(全チーム一括リリース)
デプロイ失敗率25%
変更管理委員会の承認待ち平均5営業日

Mission 1: SRE組織のミッションステートメント策定

要件

以下の要素を含むミッションステートメントを作成してください。

  1. ビジョン: SRE組織が目指す理想状態(1-2文)
  2. ミッション: SRE組織の存在意義と責務(2-3文)
  3. コアバリュー: SRE組織が重視する3-5つの価値観
  4. 定量目標(1年後): 具体的な数値目標を5つ以上

制約条件

  • 経営層(非エンジニア含む)が理解できる表現
  • 運用チームが「仕事を奪われる」と感じない表現
  • 開発チームが「負担が増える」と感じない表現
解答例

ビジョン

開発速度と信頼性を両立し、チーム全員がサービスの品質に当事者意識を持つ組織を実現する

ミッション

SREチームは、信頼性をエンジニアリングの問題として捉え、データに基づく意思決定と自動化を通じて、組織全体のサービス信頼性と開発生産性を向上させる。既存の運用チームのスキルと経験を活かしながら、手動の繰り返し作業をエンジニアリングで解決し、運用の仕事を「対処」から「改善」に進化させる。

コアバリュー

価値観説明
データドリブン感覚ではなく、SLI/SLOに基づいて判断する
自動化ファースト2回以上繰り返す作業は自動化の候補とする
ブレームレス障害の原因を個人ではなくシステムに求める
共有オーナーシップ信頼性は特定チームではなく全員の責務
継続的改善完璧を目指すのではなく、毎週少しずつ良くする

定量目標(1年後)

指標現状1年後目標改善率
重大インシデント数12件/半年6件/半年50%削減
MTTR4.2時間1時間以内75%改善
夜間対応発生率月8回月2回以下75%削減
運用チーム離職率30%15%以下50%改善
デプロイ頻度月2回週1回以上2倍以上
デプロイ失敗率25%5%以下80%改善
変更承認リードタイム5営業日1営業日以内80%改善
トイル比率未計測40%以下計測開始

Mission 2: SRE組織モデルの選定と根拠

要件

前提条件の組織に対して、最適なSRE組織モデルを選定してください。

  1. モデル選定: 4つのモデルから選択(複合も可)
  2. 選定根拠: なぜそのモデルが最適かの分析
  3. 組織図: 新しい組織構造の図
  4. 段階的展開計画: Phase 1〜3のロードマップ
  5. リスクと対策: 予想されるリスクを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 10-6ヶ月基盤構築・クイックウィンSRE2名採用、SLI/SLO導入(主要3サービス)、ポストモーテムプロセス確立
Phase 26-12ヶ月拡大・文化浸透全サービスSLO化、オンコール体制確立、トイル50%以下達成
Phase 312-18ヶ月ハイブリッド型へ移行クリティカルサービスに組み込みSRE配置、開発チームのSRE自走化支援

リスクと対策

リスク影響度対策
外部SRE採用が困難採用条件の柔軟化、育成重視への転換
運用チームの反発スキルアップ研修の先行実施、1on1での丁寧な説明
経営層の期待値過大6ヶ月ごとのROIレポート、段階的な目標設定
開発チームの非協力クイックウィン(デプロイ高速化等)で信頼獲得

Mission 3: ステークホルダー向け説明資料の作成

要件

以下の3つのステークホルダーに対する説明の要点をまとめてください。

  1. 経営層向け: ROIと事業インパクト中心
  2. 運用チーム向け: キャリアパスとスキルアップ中心
  3. 開発チーム向け: 彼らにとってのメリット中心
解答例

経営層向け

項目現状コスト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分