# Who owns the Service Level? Navigation: [[@2022__SRENext2022__Who owns the Service Level?]] | [[サービスレベル目標]] | [[エラーバジェット]] ## 概要 [[近藤武士]]（[[Recruit]]、Engineering Manager / SRE）が SRE NEXT 2022（2022-05-15）で発表したスライド資料。2020 年 SRE NEXT の「SLO Review」発表から 2 年後の振り返りとして、SLI/SLO 導入は成功したが Error Budget Policy に従った行動が定着しなかった失敗の理由と、技術戦略グループの発足による構造的解決を論じる。結論として「Service Level はプロダクトに関わる全員のもの」と提示する。[[スタディサプリ]]（旧 Quipper 日本法人、現 Recruit）小中高プロダクト開発部の事例に基づく。 ## 主要メッセージ - **SRE 実現の再定義**: SRE 実現とは「開発チームが信頼性をコントロールする Capability を身につけていること」であり、高い稼働率の維持でも SLO 達成でもない（p.8-9）。 - **Team Topologies との接続**: SRE チームは Platform Team と Enabling Team の両方として振る舞い、開発チーム（Stream Aligned Team）の自己完結化を支える（p.14-16）。 - **SLO Review の達成と失敗**: 2019-2020 年に 2 プロダクト 15 チームへボトムアップで SLI/SLO を導入した。定義・観察の文化は定着したが、Error Budget Policy に従う「行動する」ステップが未実現だった（p.33-36）。 - **行動できなかった構造的理由**: 非機能要求へ対処する予算・権限が開発チームになかった。機能開発の優先度が常に高く、SLO 違反時のアーキテクチャ変更・インフラ分離などの根本対処に着手できなかった（p.40-41）。 - **技術戦略による解決**: 2021 年に技術戦略グループを発足し、新規:エンハンス:技術的負債解消 = 1:1:1 の予算宣言、課題管理の仕組み、DevOps WG による自己診断能力の獲得を実現した（p.46-70）。 - **Who owns the Service Level?**: 答えは「プロダクトに関わる全員」。全員が関心を持てる信頼性指標（クライアントサイド SLI 等）への進化と、「指標を見て行動する」サイクル自体の改善が次のステップ（p.77-78）。 ## 視覚的に重要な図表 **p.14 SRE と開発チームの役割関係** ![[_attachments/srenext2022-chaspy-who-owns-service-level/page-014.png]] SRE（左）が開発チームの信頼性 Capability 取得を支援し、開発チーム（右）が自サービスの信頼性を自律的にコントロールする理想状態を示す。 **p.16 Team Topologies マッピング** ![[_attachments/srenext2022-chaspy-who-owns-service-level/page-016.png]] SRE を Platform Team / Enabling Team、開発チームを Stream Aligned Team として位置づける。SRE の目標は開発チームの「自己完結化（self-contained）」であり、「自分たちで必要なものを自分たちで用意できる」状態。 **p.35 SLO Review の成果と課題** ![[_attachments/srenext2022-chaspy-who-owns-service-level/page-035.png]] SLI/SLO の「定義する / 定期的に見直す」は「できた」（橙色）、Error Budget Policy に「従って行動する」は「うまくいかなかった」（グレー）という二分を視覚化した循環図。 **p.57 技術課題優先順位付けマップ** ![[_attachments/srenext2022-chaspy-who-owns-service-level/page-057.png]] 横軸にペイン強度（-100〜100）、縦軸にペイン頻度（-100〜100）をとり、課題を付箋でマッピングして相対評価する。高頻度かつ強度の高い右上ゾーン（自動化・廃止済み機能削除等）が優先課題として可視化される。 **p.58 来期開発ロードマップ接続テーブル** ![[_attachments/srenext2022-chaspy-who-owns-service-level/page-058.png]] タイトル・状況・ペイン頻度・ペイン強度・ペイン頻度+強度の 5 列で課題を並べ、開発ロードマップへの接続状況を管理する。「決済基盤切り離し」（頻度20・強度90・計110）のように、頻度は低くても強度が高い課題を逃さない。 ## 組織規模の変遷 スタディサプリ小中高プロダクト開発部の開発者・SRE 人数推移（スライド実測値、2022 年）: | 年 | 開発者 | SRE | |----|--------|-----| | 2018 | 35 | 4 | | 2019 | 53 | 5 | | 2020 | 54 | 7 | | 2021 | 73 | 7 | | 2022 | 114 | 7 | 開発者が 3 倍以上に増えた一方、SRE は 7 名で固定されている。SRE の Enabling 活動と Platform 化が不可欠な背景がわかる。 ## 技術課題管理の仕組み 技術戦略グループが構築した課題管理フロー: 1. **投げ込み口の設計**: スプレッドシート（誰でも記入可）と Slack の reacji（特定絵文字をつけると WG が自動収集）の二系統。気軽さを重視。 2. **リファインメント**: 「つらさ = ペイン」を言語化し、現時点の How（解決策の仮説）を任意で記載。 3. **優先順位付け**: ペイン頻度 × ペイン強度の 2 軸マトリクスで相対評価。メンバー全員の投票結果の重心に置く。 4. **ロードマップ接続**: 優先度付き課題を開発ロードマップに組み込み、状況（来期やる・進行中等）を管理。 限界として認識されている点: 技術課題は定性的であり数値化に限界がある、参加メンバーの偏りがある可能性、開発リソース・難易度・リスクですぐに着手できない課題がある。 ## DevOps WG の活動 開発チームの「自己診断能力の獲得」を目的とする横断ワーキンググループ: - バリューストリームマッピング: Meta Issue 作成〜開発、QA〜本番リリース、開発完了〜スプリントレビューの 3 フェーズを計測。 - 候補 Metrics / Indicator の洗い出しと計測（p.65 に詳細テーブル）: `PR マージ待ち時間`、`master ブランチ workflow 時間`、`Single Release リリース回数`、`プロダクションコードカバレッジ` など多数を hypothesis / issue 付きで管理。 - DX Criteria の実施（DX Criteria は外部フレームワーク）。 - BtoC All Hands での広報: 「はじめての SRE」として開発部外にも SRE の考え方を発信。 ## 概念・実体への接続 - [[サービスレベル目標]] — SLI/SLO 定義・観察の文化醸成と Error Budget Policy の行動定着が分離した事例 - [[エラーバジェット]] — Error Budget Policy を定義したが行動まで至らなかった構造的理由 - [[Team Topologies]] — SRE を Platform / Enabling Team として明示的に位置づけた実践 - [[近藤武士]] — 発表者 - [[Recruit]] — 所属組織 - [[スタディサプリ]] — 事例プロダクト ## 限界・不確実点 - p.65 の Metrics / Indicator テーブルはメンバー名がモザイク処理されており、所属チームや著者を特定できない（プライバシー配慮による）。 - 技術戦略グループの立ち上げは「前任マネージャが行ったもの」と Disclaimer にあり（p.38）、@chaspy は DevOps WG Lead → EM/Lead として参画。立ち上げの意思決定経緯の詳細は不明。 - SLO 違反後のアクション事例（QB Day での対応内容）は定性的な言及にとどまり、具体的な対処事例は示されていない。 - transcript なし。口頭説明の補足はない。 ---