もう一度考える SRE チームの作り方・育て方 もう一度考える SRE #1 株式会社 Topotal / Ryota Yoshikawa (@rrreeeyyy) 

Ryota Yoshikawa @rrreeeyyy ( https://x.com/rrreeeyyy ) CTO @ Topotal, Inc. ( https://topotal.com/ ) 「SRE as a Service™」を運営 ( https://sre-as-a-service.com/ ) 複数の組織の SRE を横断して支援する立場 「Waroom™」を開発 ( https://waroom.com/ ) AI も活用したインシデントマネジメント SaaS 久しぶりのガーデンプレイスで嬉しいです 

Agenda 本日話すこと 01: SRE チームの作り方 02: SRE チームの育て方 03: 今改めて考える、作り方・育て方 04: まとめ 

0 1 / H ow Tea m s A re B u i l t SRE チームの 作り方 

When & Why SRE チームは、いつ・なぜ作られるか SRE チームが作られるきっかけの例: 信頼性の限界: 少数の英雄の頑張りで、保てなくなった 事業の要請: 新プロダクト・急成長・SLA や監査への約束 組織の意思: Ops チームの改名、SRE を掲げた採用、DevOps 推進の受け皿 自然発生: 開発の中で誰かが信頼性を引き受け続け、いつのまにかロールになった 作られるきっかけに応じて、チームがやるべき仕事が異なる どのきっかけで SRE チームが作られても、最初には以下を行うべき 組織の信頼性の現在地を、正直に知ること そして、目指すべき地点を決めること（高いほどよい、ではない） 

Organizational Reliability 組織の信頼性の状態の整理 フェーズ その組織で起きていること Absent 信頼性は二の次。問題の大半をユーザーやテスターが見つける Reactive 直近の障害に反応して動く。可用性は少数の英雄的な努力で保たれている Proactive リスクを定常プロセスで洗い出し、設計の段階で「どう壊れうるか」を確認する Strategic 障害を 1 件ずつではなく、同種のリスクをまとめてアーキテクチャの変更で潰す Visionary システムは人手を介さず自動復旧する。信頼性の知識が全エンジニアに行き渡る 目指す地点は、プロダクトの要求とユーザーの期待から決める [1] 多くのプロダクトには proactive が健全な目標: 上げるにも保つにもコストが大きい [1] https://cloud.google.com/blog/products/devops-sre/the-five-phases-of-organizational-reliability 

What the Team Does 何をやるチームとして作るか: フェーズによって決める フェーズ SRE チームがやること Absent まず信頼性を計測する。SLO の合意を作り、障害対応の型を整える Reactive オンコールとポストモーテムを整備し、英雄の仕事を仕組みに置き換える Proactive SLO を運用し、設計の早い段階から参加し、トイルを削減する Strategic アーキテクチャの変更や標準化で、同種のリスクをまとめて潰す Visionary 信頼性の知識を、組織の全エンジニアへ広げていく チームの仕事の中身は、現在地と、目指すフェーズで決まる [1] 何を目指すかが決まっても、どのように実施するかには、まだ検討の余地がある [1] https://cloud.google.com/blog/products/devops-sre/the-five-phases-of-organizational-reliability 

How It Engages どう関わるチームとして作るか: 4 つの位置 Google Cloud が観察した 6 つのチームの型を、 「誰がやる形か」で並べ直したもの [2] 位置 関わり方 Kitchen Sink / Product 引き受ける: 対象サービスの信頼性を、SRE チームが持つ Embedded 一緒にやる: 開発チームの中でコードや設定を直接変える。期間で区切る Consulting 助言する: 助言に徹し、相手のコードや設定は変えない Infrastructure / Tools 配る: 共有基盤と、信頼性のためのツールを提供する 信頼性の仕事を「誰がやる形にするか」は、フェーズとは別の選択 Team Topologies の 3 モード（Collaboration / Facilitation / X-as-a-Service）とも重なる [3] [2] https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started [3] https://teamtopologies.com/key-concepts 

The Map 「作る」とは、この平面で初期配置と目的地を決めること Visionary 全員の知識で保たれる 信頼性の保たれ方 Strategic 仕組みで保たれる Proactive 目的地 プロセスで保たれる Reactive 英雄で保たれる Absent 保たれていない 関わり方 → 例: あるチーム Kitchen Sink / Product 引き受ける Embedded 一緒にやる Consulting 助言する Infrastructure / Tools 配る 

0 2 / H ow Tea m s G row SRE チームの 育て方 

What “Growing” Means 育てるとは、動かし続けられるようになること 目的地は一度決めたら終わりではない プロダクトの要求は変わり、フェーズには後退もある 「現在地を測る → 目的地を選ぶ → 動かす」を繰り返す Visionary Strategic 縦: フェーズを上げる Proactive Reactive Absent 横: 関わり方を組み替える Kitchen Sink / Product Embedded Consulting Infrastructure / Tools 

Growing the Phase 縦に動かす: フェーズを上げる フェーズは一段ずつ、次のフェーズの属性を混ぜながら上がる 「組織が複数フェーズの属性を併せ持つのは普通」 [1] 越えたかどうかは、行動に表れる 多くのチームが通る Reactive → Proactive なら、エラーバジェットポリシーが実際に行使されること [4] 重大インシデントの後に本当に発動し、マネジメントがそれを支持する 上げる仕事は、エンジニアリングだけでは終わらない [1] 一人の英雄が支えていたチームで、その人が抜けて障害が続発した実例がある 技術的な立て直しだけでは戻らず、必要だったのは文化を変えることだった 信頼性を第一の機能と位置づける / 障害対応の活躍だけでなく、地味な予防の仕事も評価して報いる 「真に proactive な状態に移るのに 2〜3 年かかるのは珍しくない」 [1] [1] https://cloud.google.com/blog/products/devops-sre/the-five-phases-of-organizational-reliability [4] https://sre.google/workbook/team-lifecycles/ 

What “Up” Looks Like フェーズの上がった SRE チームとして挙げられている例 [4] エラーバジェットポリシーが実際に行使される オンコールが持続可能になっている（報酬が支払われる） トイルが文書化され上限つきで管理されている ポストモーテム文化が確立し、訓練を定期実施している 開発チームがオンコールに関与し続けている すべての設計と変更にパートナーとして関わる 仕事量を自己決定できる どのサービスの運用を引き受けるかを、自分たちで選ぶ 過負荷なら、SLO を下げるか、開発チームに返す [4] https://sre.google/workbook/team-lifecycles/ 

Re-shaping the Engagement 横に動かす: 関わり方を組み替える 「引き受ける」のままでは続かない SRE 支援を求める開発チームの数は、SRE チームが応えられる量を構造的に超える [5] 引き受ける関わり方で上げた信頼性は借り物 SRE が代わりにやっている間だけ良い状態で、離れると元に戻ってしまうことがある 定着させるのは「助言する」「配る」側の関わり方 配る側へ動くには、一度引き受けた仕事を開発チームに返していくことになる 「SRE engagement is not perpetual（SRE の関与は永続的ではない）」 [4] [4] https://sre.google/workbook/team-lifecycles/ [5] https://sre.google/sre-book/evolving-sre-engagement-model/ 

Case Study 横に動いた例 [4] あるチームは、全社で使う共通基盤（DNS や CDN など）を 1 チームで引き受けていた 他チームの依頼をさばく受付窓口になり、チケットと障害対応に追われていた 特定の人しか知らない仕事が多く、その人が抜けると回らない（バス因子） 立て直しの方針: 開発チームが自分で変更できる形に変える やったこと まず SRE を 1 人、開発チームの中に入れて一緒に働いた 基盤の設定をチームごとに管理できる構造にし、変更は push で自動反映されるようにした 残るレビュー依頼は、毎日決まった相談時間にまとめて受けるようにした 結果: SRE チームの時間の 50% 以上を改善の仕事に使えるようになり、バス因子も改善した [4] https://sre.google/workbook/team-lifecycles/ 

The Route 定石は「上げてから、右へ」 順序には理由がある: 低いフェーズでは、引き受ける関わり方しか効かない 火が出ているサービスに、講義と基盤は効かない よくある失敗も、地図の上の動きとして説明できる 引き受けたまま動けない: 英雄の頑張りで保ち続けてしまう（Nobody can be a hero forever） [1] 上げる前に右へ行く: Reactive のまま基盤だけ作る 開発チームを感知し続けない Platform team は「誰も使わないもの」を作る [3] Visionary Strategic 上げてから、右へ Proactive Reactive Absent 動けない ✗ Kitchen Sink / Product 上げる前に右へ Embedded ✗ Consulting Infrastructure / Tools [1] https://cloud.google.com/blog/products/devops-sre/the-five-phases-of-organizational-reliability [3] https://teamtopologies.com/key-concepts 

The Cost Structure 引き受け続けるコストと、配る側へ動くコスト 引き受ける側の位置ほど、居続けるのに人手のコストがかかる 開発チームとのコミュニケーションと、コンテキストの獲得に時間がかかる 対象のサービスが増えたぶんだけ人手が要り、スケールしない 人手を足そうにも、適格な SRE の採用はもともと難しい [4] 抜け出す道は配る側への移動。ただし、それ自体が大仕事 開発チームへの知識の委譲・権限の移譲と、そのための仕組みづくり 作って終わりではなく、継続的に関わってアップデートし続ける必要がある [5] 小さい SRE チームでは、この投資に踏み出しにくかった 日々の運用に時間を取られ、仕組みづくりに割く時間を確保しにくい 結果として、引き受ける位置に留まることが多かった [4] https://sre.google/workbook/team-lifecycles/ [5] https://sre.google/sre-book/evolving-sre-engagement-model/ 

0 3 / Ret h i n k i n g , N ow 今改めて考える 作り方・育て方 

Reliability Needs AI Too 信頼性を守る側にも、AI が要る AI で変更の量と速度が増え、レビューと検証のコストが高まっている AI による変更の 15〜29% が不具合を持ち込み、セキュリティ問題の 41.1% は直されず残った、という分析がある [6] AI のコードは、人のコードより書き換えられずに残りやすいという分析もある [7] 増えた変更を人手のレビューだけで受け止めるのは、引き受ける位置に居続けるのと同じ構図 信頼性を守り、フェーズを上げるためにも、AI を活用する必要がある レビューの下読み、ガードレール、検証の自動化: 縦の移動にも AI を使う [6] https://arxiv.org/abs/2603.28592 [7] https://arxiv.org/abs/2601.16809 

The Exit Got Cheaper 配る側へ移るコストが下がった 引き受ける側のコストだった「コミュニケーション」の一部を、AI が肩代わりできる場所が増えた 質問への一次回答、ドキュメントの案内、レビューの下読み、コンテキストの要約 人が張り付いていた仕事を、部分的に自動で適用できる ソフトウェアを作るコストも下がり続けている マネージドサービスと OSS の成熟で、自作する範囲が狭くなった AI で、社内ツールや自動チェックが安く作れるようになった 知識の委譲・権限の移譲と仕組みづくりが、小さいチームにも手が届く仕事になってきた 

No Longer Optional 配る側への移行が必須になるケースも出てきている AI で開発の速度が上がり、サービスも変更も増えていく 引き受けたまま人手で受けていては、この速度に構造的に追いつけない 「支援の需要は、応えられる量を構造的に超える」が、さらに加速する [5] 開発速度の速い組織では、仕組みとして配ることが前提になっていく [5] https://sre.google/sre-book/evolving-sre-engagement-model/ 

Small Teams, Doing It 数人の SRE チームでも、配る側を実践する例が増えている 実際に取り組まれている例 SLI / SLO の設計支援 リポジトリを読ませて候補を提案し、PR のたびに追加の要否を確認する Production-Readiness Check の AI 化 リリース差分をリスクの観点でレビューし、人間が承認する 障害対応とポストモーテムの補助 調査・状況整理・下書きを AI が受け持ち、最終判断は人間が持つ どれも、AI が提案して人間が最終判断する形 使われるかどうかは、置き場所で決まる PR レビュー、CI、インシデント対応のチャンネルなど、仕事が通る場所に組み込む 

Proof of Concept 実証実験: SLI / SLO の設計と運用を AI と回す Web アプリ AI が CUJ → SLI → SLO を提案し、人間が確認して確定する エラーバジェットの状況を集計し、注目ポイントを AI が要約する 

The New Route 「上げながら、右へ」もできるようになった 順番にやっていたのは、配る仕組みへの投資が大きく、両方は同時にできなかったから いまは、上げる手段そのものが配る道具になってきた ポストモーテムの学びを自動チェックに、SLO 設計をテンプレートに、Readiness Check を AI に 開発速度が上がる中では、順番にやっていては追いつかない ただし「上げる前に、右だけ」の失敗は今も残る 需要から離れた大きな基盤ではなく、仕事の流れの中の小さな道具から始める Visionary Strategic Proactive 定石: 上げてから、右へ Reactive いま: 上げながら、右へ Absent Kitchen Sink / Product Embedded Consulting Infrastructure / Tools 

Summary 本日のまとめ 作るとは、地図の上で初期配置と目的地を決めること 縦 = 信頼性が何によって保たれているか / 横 = 開発チームとの関わり方 育てるとは、目的地を選び直しながら動かし続けられるようになること 定石は「上げてから、右へ」 いまは配る側へ移るコストが下がり、「上げながら、右へ」もできるようになった フェーズを上げるために作った仕組みが、そのまま配る道具になる