SREエンゲージメントモデル - yuuk1's Digital Garden

# SREエンゲージメントモデル Navigation: [[index]] | [[concepts/_index]] ## 定義 SRE エンゲージメントモデルとは、SRE チームが開発チームと「どう関わるか」を、Google Cloud が観察した6つのチームの型を「誰がやる形か」で並べ直した4つの位置に整理するフレームワークである。Ryota Yoshikawa の発表では、以下の4区分として提示された(Source: [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]] p.8): | 位置 | 関わり方 | |---|---| | **Kitchen Sink / Product** | 引き受ける: 対象サービスの信頼性を、SRE チームが持つ | | **Embedded** | 一緒にやる: 開発チームの中でコードや設定を直接変える。期間で区切る | | **Consulting** | 助言する: 助言に徹し、相手のコードや設定は変えない | | **Infrastructure / Tools** | 配る: 共有基盤と、信頼性のためのツールを提供する | 信頼性の仕事を「誰がやる形にするか」は、[[組織の信頼性マインドセット]]が扱うフェーズ（信頼性がどう保たれているか）とは別の選択軸であり、Team Topologies の3モード（Collaboration / Facilitation / X-as-a-Service）とも重なるとされる。 ## 子概念 - [[コンテキスト対コントロール]] - [[セキュリティの責任分担]] - [[プロダクションエンジニアリング]] - [[レディネスレビュー]] - [[組織の信頼性マインドセット]] ## 横断的知見 - **『Observability Engineering』第2版第28章のオブザーバビリティチーム像は、独立ソースから「Infrastructure / Tools（配る）」位置に到達した実例である**: Yoshikawa の4区分は Google Cloud の観察に基づく分類学だが、第28章はオブザーバビリティ組織変革という別文脈から出発し、「オブザーバビリティチームは全サービスを自ら計装しない。それはスケールしないボトルネックへの最短路だ」「彼らの仕事は計装を、製品チームが英雄的努力なしに正しく行えるほど簡単にすることだ」と明言する。これは4区分のうち「Kitchen Sink / Product（引き受ける）」を明示的に否定し、「Infrastructure / Tools（配る）」を選び取る記述であり、SRE チームの関わり方についての分類学(Yoshikawa)と、オブザーバビリティチームの実務原則(第28章)という異なる語彙・異なる文脈の2ソースが、同一の組織設計上の結論に独立に到達したことを示す。(Source: [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **Google の実務者インタビュー(2024)は、Yoshikawa の4区分(2026)より先に「オフィスアワー・コンサルティング・スウォーム・専任配置」という段階的関与の実例を提示していた**: 『SREをはじめよう』第13章で Dave Rensin・Ben Lutch は、Google 社内の関与モデルとして、ふらっと質問できるオフィスアワー、SRE が来て助言するコンサルティング、経験豊富な3〜4人が四半期かけて調査支援するがページャーは開発チームが持つスウォーム、専任 SRE 配置(Kitchen Sink/Product 相当)を挙げる。オフィスアワー・コンサルティングは Yoshikawa の「Consulting(助言する)」に、スウォームは開発チームがページャーを持ち続ける点で「Embedded(一緒にやる)」と「Consulting」の中間的な形態に対応すると読める。Yoshikawa が「Google Cloud が観察した6つのチームの型」を出典未詳のまま4区分に整理したのに対し、第13章は Google 内部の実務者が各モデルの運用条件(スウォームは一般的ではない、専任化には SRE の早期関与が必須)を具体的に語っており、4区分の実例的な裏付けとして機能する (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]], [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]])。 - **「なぜ独立組織か」という問いに、Google は統一インフラの信頼性と独自ジョブラダーによるアイデンティティ維持という2つの理由を明示する**: 第13章 §13.3.2 で Ben Lutch は、SRE を開発チームに完全埋め込み(エンベデッド)にしない理由として、(1) 統一された本番インフラの方が信頼性面で有利、(2) 独自のジョブラダーがないと SRE が「ゆっくり軌道を低下させ、ただの運用チームとなって地球に落下する」ことを挙げる。Yoshikawa の4区分は「関わり方」を静的な分類として提示するが、第13章は「Embedded を選ばない理由」を組織設計の力学(キャリアパス・評価制度)として補足しており、4区分のうちなぜ Kitchen Sink/Product や Infrastructure/Tools が Embedded より選好されうるかの根拠を与える (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]])。 - **17章が挙げる「監視ライブラリ・権限付与ライブラリ・カナリアデプロイツール・RPCライブラリ」という4つの具体例は、Yoshikawaの「Infrastructure / Tools（配る）」位置と第28章の処方箋を、SREチームが実際に構築する成果物のレベルまで具体化する**: Yoshikawaの4区分は「配る」を「共有基盤と信頼性のためのツールを提供する」という抽象的な位置として定義し、第28章はオブザーバビリティチームが計装を製品チームに「英雄的努力なしに正しく行えるほど簡単にする」べきだと処方する。17章は、48から108人規模のSRE組織が実際に構築する成果物として、開発中の新サービスがリンクするだけで監視システムに「正しいことをする」ライブラリ、権限付与/アクセス制御の正規ライブラリ、カナリアデプロイの正規ツール、標準RPCフォーマット/ライブラリの4例を挙げる。これは「配る」位置の中身を、抽象的な役割規定(Yoshikawa)や実務原則(第28章)から、組織が実際に手にする具体的な成果物のカタログへ一段落とし込むものである。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]], [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **17章は「配る」位置への到達を、第13章が語る「専任配置(Kitchen Sink/Product)」からの規模的な進化として位置づけ、エンゲージメントモデルの選択がチーム規模と無関係な静的分類ではないことを示す**: 第13章のGoogle実務者インタビューは、専任SRE配置(Kitchen Sink/Product相当)を含む4つの関与モデルを並列の選択肢として提示するが、どの規模でどのモデルへ移行しやすいかには踏み込まない。17章は、SRE組織が0→1→6→18→48→108と拡大する過程で、小規模期(1から6人)は「個人またはペア/トリオが特定サービスの監視改善やSLI/SLO試験運用を行う」局所的な関与(Consulting/Embeddedに近い)から出発し、48から108人以上の規模で初めて組織全体で使われる正規ライブラリを構築する「Infrastructure/Tools」型の役割へ広がると描く。これは、Yoshikawaの4区分が暗黙に前提していた「どの位置を選ぶか」という問いに、「組織規模によってどの位置が可能になるか」という時間軸を加える。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]], [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]], [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]]) - **『SREエンタープライズロードマップ』第4章は、組み込み型・コンサルティング型・インフラ型という3区分を Yoshikawa より4年早く提示し、出典を Google の CRE ブログと SRE Book 第32章に明示的に求めている**: 第4章は「エンゲージメントモデルには、組み込み型、コンサルティング型、インフラ型など、いくつかの種類があり、これらは Google の Customer Reliability Engineering(CRE)チームのブログポストや SRE 本の第32章で紹介されているモデルでよく説明されている」と述べる。この3区分は Yoshikawa の4区分から「Kitchen Sink / Product(引き受ける)」を除いた3つとほぼ一致し、Yoshikawa が出典を明示しなかった「Google Cloud が観察した6つのチームの型」の系譜の少なくとも一部が、CRE ブログと SRE Book 第32章("The Evolving SRE Engagement Model")にあることを示唆する。ただし第4章も CRE ブログの具体的な URL や記事名までは示しておらず、6つの型から3(4)区分への正確な対応関係は依然として未確認である。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]], [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]]) - **第4章は「明確なメニュー化」を、エンゲージメントモデル論に新しい実務上の効能として追加する**: 既出のソース群はエンゲージメントモデルを「どの位置を選ぶか」「どの規模でどの位置へ移行するか」という選択・移行の観点で論じるのに対し、第4章は SRE チームが軌道に乗った後に依頼が過剰になる問題への対策として、組み込み型・コンサルティング型・インフラ型を明文化した「メニュー」を作ることで単発の依頼や持続不可能な関わりを組織的に断れると述べる。これは、4区分(または3区分)を静的な分類学としてだけでなく、需要超過に対する交渉のツールとして使うという、既存ソースにない実務上の用途を加える。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]]) - **『SREの探求』1章が語る Netflix SRE の「中枢神経系」役割は、Yoshikawa の4区分のどれとも完全には一致しない、横断的な障害トリアージ・ルーティング機能である**: Coburn Watson(当時 Netflix)は、コア SRE チームが個々のマイクロサービスの信頼性を直接所有するわけではなく、その代わりに外部・内部・CDN・ネットワークなど発生場所を問わずすべての障害を把握し、問題解決の対応に当たるべきチームを判断する社内唯一のチームだと説明する。これは「引き受ける(Kitchen Sink/Product)」のように対象サービスの信頼性を持つのでも、「配る(Infrastructure/Tools)」のように共有基盤を提供するのでもなく、「助言する(Consulting)」に近いが助言対象を自ら見つけ出しに行く点で異なる、横断的な障害ルーティング機能である。既出の『SREをはじめよう』第13章のスウォームモデル(経験豊富な数名が調査支援するがページャーは開発チームが持つ)も4区分の中間形態として指摘されていたが、Netflix の中枢神経系はさらに「誰が対応すべきかを判断すること自体」を主任務とする点で、スウォームより一段抽象度の高い調整機能である。Yoshikawa の4区分が「関わり方」を静的な位置として提示するのに対し、これは大規模・高複雑度なマイクロサービス環境で自然発生した第5の機能として読める (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]] ch.1 p.11, [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]])。 - **『SREの探求』6章のSoundCloudは、「専任チームを持てない」という制約から出発して「配る(Infrastructure/Tools)」位置へ独力で到達した、Yoshikawaの4区分より15年近く早い実例である**: SoundCloudはまず「引き受ける(Kitchen Sink/Product)」相当の専任SREチームを試みたが、エンジニア総数(約100名)に対しSREチームの最小規模(オンコール要件から8名)が5〜10%を占めてしまい破綻した。次に「一緒にやる(Embedded)」相当のSRE派遣を試みたが、1チームに割ける人数が最大1名にとどまり技術的方向性への影響力を持てず失敗した。最終的に到達したのは、開発チームへの直接介入をやめ、共通デプロイプラットフォーム(Bazooka)というインフラを全チームへ「配る」体制であり、プロダクションエンジニアリング(ProdEng)チームはこの基盤サービスの提供によってゲートキーパーにならずに全チームとの接点を維持した。Yoshikawaの4区分がGoogle Cloudの観察に基づく静的な分類学として2026年に提示されたのに対し、SoundCloudの事例(原書2018年)は「Kitchen Sink/Product→Embedded→Infrastructure/Tools」という3つの位置を実際に試行錯誤しながら順に失敗・成功した歴史的経路そのものであり、既出の『Observability Engineering』第2版第28章(独立ソースから同じ結論に到達した実例)よりもさらに早く、かつ「なぜ他の位置が機能しなかったか」という失敗の因果まで記録している点で類例のない厚みを持つ。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]], [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]]) - **ProdEngチームは「配る」と「助言する(Consulting)」の境界線上に位置し、Yoshikawaの4区分のどちらか一方には収まらない**: ProdEngはデプロイプラットフォームという共有基盤を「配る」一方、モニタリング・インシデント対応・ポストモーテムプロセスについては「コンサルテーションを受けるかどうかは開発チームの自由」であり、公式なレビュー権限もエラーバジェットのような強制力も持たない。これは既出の「『SREをはじめよう』第13章のスウォームモデルはEmbeddedとConsultingの中間形態」という知見と同型の問題を、「配る」と「助言する」の間で再現するものであり、4区分は互いに排他的な位置ではなく、実務上は複数の位置を同時に占める合成的な役割設計がありうることを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.2.3, [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]]) - **SoundCloudの「SRE派遣」失敗は、第13章がGoogle社内の実務者インタビューとして語る「なぜSREを開発チームに完全埋め込みにしないか」の理由(統一インフラの信頼性・独自ジョブラダーによるアイデンティティ維持)とは異なる、より単純な失敗原因——人数比の非現実性——を示す**: 第13章のBen Lutchは、Embeddedを選ばない理由を組織設計の力学(キャリアパス・評価制度)として説明したが、SoundCloudの事例はそれ以前の問題として、10名規模の開発チームに対しSREを1名ずつ配置しても、その1名が新サービスの設計や技術的方向性に対して発言力を持てないという単純な人数の非対称性を挙げる。派遣されたSREは「今から皆さんのSREです」と宣言しても、他のエンジニアやマネージャーの大多数がSREという概念を理解していない状況では無視されるか、また別のバックエンドエンジニアとして扱われるだけだった。既存の理論的な説明(ジョブラダー・キャリアパス)に対し、SoundCloudは「そもそも1人では影響力を持てない」という、より手前の実務的な失敗要因を加える。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.1.2, [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]]) - **『SREの探求』8章は、Yoshikawaの4区分やGoogle実務者インタビュー(13章)が扱う「誰がやる形か」に、「ライフサイクルのどの段階から関与するか」という時間軸の設計変数を加える**: 既出の知見群はいずれも静的な位置(Kitchen Sink/Product・Embedded・Consulting・Infrastructure/Tools)の選択と、規模に応じた移行(17章)を論じてきたが、開発ライフサイクル上のタイミングには踏み込んでいなかった。8章の図8-4は設計・構築・リリース・リリース後対応の全段階にSREが関与する責任・サンプル活動・メリットを描き、「SREの機能は各プロダクトに少しでも早く関与できるほど有効性が高まる」と明言する。これは、4区分のどの位置を選ぶかという問いとは独立に、選んだ位置をいつから発動させるかという第2の設計軸を追加するものであり、「配る」位置への到達が規模の関数である(17章)のと同様に、関与の深さがライフサイクル段階の関数でもあることを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] §8.2.4.4, [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]]) - **Matt Klein の「組み込むが直属しない」という報告ライン設計は、既出の「Embeddedを選ばない理由」(第13章、統一インフラ・ジョブラダー)とは異なる、Embeddedを選びつつ独立性を保つ第3の処方箋を示す**: 第13章のBen Lutchは、SREを開発チームに完全に埋め込まない(Embeddedにしない)理由を、統一された本番インフラの信頼性優位と独自ジョブラダーによるアイデンティティ維持から説明した。これに対し8章が引用するLyftの[[Matt Klein]]の指摘は、「SREはプロダクトチームに組み込む必要があるものの、プロダクトチームのエンジニアリングマネージャーに直属すべきではない」と述べ、Embeddedという配置形態そのものは採用しつつ、報告ライン(直属関係)だけを分離することで、信頼性と機能のどちらを優先するかの対話における中立性(チェック&バランス)を確保するという、既出の2択(埋め込むか埋め込まないか)とは異なる第3の設計を提示する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] §8.2.4.4, [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]]) - **『SREの探求』23章のBissetは、「プッシュ対プル」という語彙をSoundCloud(6章)より先に、業界横断のアンチパターンとして命名し、その処方箋をYoshikawaの4区分とは異なる「魅力度」という軸で説明する**: 既出の知見は、SoundCloudの事例(6章)がKip・Randyの「プッシュ対プル」モデル(第4章、2022年)より先行する具体的な失敗例だったことを示していた。23章のBissetは、アンチパターン10「設計の難所」とアンチパターン11「棒が多すぎてニンジンが不足」を通じて、この対立軸をさらに一段抽象化し、「プロダクションの門番になろうとするか、ツールを構築してその使用を人々に強制しようとするのでは、どのような目的地にもたどり着くことはない」「各チームが独自のツール構成を選択できる組織は、そうした意思決定を外部からチームに押し付けようとする組織よりも優れた結果を迅速に提供する」(Accelerate研究を引用)と述べる。これはYoshikawaの4区分(Kitchen Sink/Product・Embedded・Consulting・Infrastructure/Tools)が「誰がやる形か」という位置の分類であるのに対し、Bissetは位置そのものではなく「その位置への到達手段が強制(プッシュ)か魅力的選択肢の提示(プル)か」という、どの位置にも横断的に適用できる**提供様式の軸**を立てている点で異なる。Dropboxの「棒とニンジン」を象徴する宇宙飛行士のマスコット(図23-1)は、SRE組織が自らのツール・サービスを「80%のユースケースで十分に優秀」であり開発努力と運用負荷を大幅に軽減すると実感してもらうことで、プロダクトチームに「SREチームへエンジニアを追加する方が自分たちに追加するより業務遂行能力が高まる」と思わせる、プル型のインセンティブ設計の具体例である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 23 SREのアンチパターン]] §23.10, §23.11, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]], [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]]) - **『SREの探求』7章のSpotifyは、専任SREチームを一度も試みることなく「配る(Infrastructure/Tools)」位置へ到達した点で、既出のSoundCloud(6章)とは異なる経路を示す**: 既出の知見は、SoundCloud(6章)がKitchen Sink/Product(専任SREチーム)→Embedded(SRE派遣)→Infrastructure/Tools(デプロイプラットフォームBazooka)の3位置を順に試行錯誤した歴史的経路として、Yoshikawaの4区分の先行実例だと位置づけていた。Spotify(7章)はこれとは異なり、創業時(2006年)から運用エンジニアがチームに常駐する「デフォルトの運用」文化を出発点とし、2012年に集中型の運用/SREチームが機能チームの成長ペース(サーバープロビジョニング・Puppetレビュー・DNSレコード追加)に追い付けなくなったことを契機に、Kitchen Sink/Productを経由せず直接「配る」位置(分隊型運用+ゴールデンパス)へ移行した。SREの大多数はインフラ担当の分隊(IO/SA)に所属し続けている点で、「配る」位置は一過性の到達点ではなく組織構造として定常化している。これは、Yoshikawaの4区分のうちどの位置を経由するかが、専任チームを試みたか(SoundCloud)そもそも試みなかったか(Spotify)という初期条件に依存することを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] §7.1, §7.5, §7.6.2, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]]) - **SpotifyのIMOC(中央エスカレーション対応ローテーション、SREは半数)は、Netflixの「中枢神経系」(既出)とは異なる、SRE肩書きに依存しない越境調整の実装を示す**: 既出の知見は、Netflix SRE(1章)を「誰が対応すべきかを判断すること自体」を主任務とする、Yoshikawaの4区分に収まらない障害トリアージ・ルーティング機能として位置づけていた。SpotifyのIMOCも同様に大規模インシデントの調整・コミュニケーションを担う中央的な役割だが、担当者の半数はSREという肩書きを持たない幅広い役割のエンジニアで構成される点でNetflixの「コアSREチームが担う」構造と異なる。これは、越境的な障害調整機能が必ずしもSRE組織の専有物ではなく、肩書きを問わないローテーションとしても実装しうることを示す、既出のNetflix実例にない具体例である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] ch.7 冒頭, §7.8, [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]]) - **『SREの探求』11章のTom Limoncelli証言は、「早期関与が承認速度を上げる」という因果を、レビューゲートという制度に結びつけた形で示す**: 既出の知見群(8章の「ライフサイクル全段階への早期関与」、23章の「プッシュ対プル」)は、SREがいつ・どのように関わるべきかを組織設計・提供様式の観点から論じてきたが、その関与の効果が具体的にどの制度的タイミングで測定・可視化されるかには踏み込まなかった。11章でLimoncelliは「HRR(引き継ぎレディネスレビュー)でプロダクションの承認が最も早いチームは、早期の設計段階からローンチに至るまで、SREと最も早くから協力していたチームです」と述べ、SREが「誰もがプロジェクトチームに早い段階で助言することに価値があると考えているので、そのために数時間でも数日でも自発的に協力してくれる」というボランティア的な早期関与の文化を挙げる。これは、8章の「早期関与ほど有効性が高まる」という一般論に、[[レディネスレビュー]](LRR/HRR)という具体的な審査ゲートでの承認速度という測定可能な帰結を接続するものであり、23章の「プッシュ対プル」軸で言えば、SREが強制されてではなく自発的(プル/ボランティア)に早期関与する文化そのものが、後段のゲート通過を早めるという因果の輪をなす。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.2, [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] §8.2.4.4, [[@2021__OReillyJapan__SREの探求 - Chapter 23 SREのアンチパターン]] §23.10, §23.11) - **『SREの探求』13章のFacebook PEは、独立した報告ラインを維持したまま「一緒にやる(Embedded)」+完全なオンコール共有という位置に組織として定着し、SoundCloud(6章)・Spotify(7章)が到達した「配る(Infrastructure/Tools)」とは異なる第3の到達形態を示す**: 既出の知見は、SoundCloud が「引き受ける→一緒にやる→配る」の3位置を試行錯誤の末「配る」(共通デプロイプラットフォームBazooka)へ、Spotify が専任チームを経由せず直接「配る」(ゴールデンパス)へ到達したことを記録していた。13章のFacebook PEは、SWEのすぐ隣に配属される分散型の配属構造と、週単位のSWE/PEオンコール共有ローテーションという点でEmbeddedに位置しながら、報告構造自体は開発チームから独立したエンジニアリング責任者直下(集中型の報告構造)を保ち続ける。SoundCloud・Spotifyがいずれも「開発チームへの直接介入をやめて基盤を配る」方向へ収束したのに対し、Facebookは基盤提供(FBAR等、PEが完全所有する場合のみ「配る」位置を取る)と直接介入(SWEと同席してのオンコール・コードレビュー相当の関与)を並行して持続させる点で、既出の3社(SoundCloud・Spotify・Facebook)は同じ「専任SREチームを持たない」制約から出発しながら3通りの異なる定常状態に到達していることが分かる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.222-227, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]], [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]]) - **13章の「誰がオンコールを担当するか」という一次判定基準は、既出のNetflix「中枢神経系」(1章)と正反対の設計思想を体現する**: 既出の知見は、Netflix のコア SRE チームが個々のマイクロサービスの信頼性を自ら所有せず、発生場所を問わずすべての障害を横断的に把握し対応すべきチームを判断する「中枢神経系」として機能することを、Yoshikawaの4区分のどれにも収まらない第5の機能として位置づけていた。13章でPedro Canahuatiは、他組織が自社のPEモデルにどれだけ近いかを判定する最初の質問として「誰がオンコールを担当するのか」を挙げ、SWE(またはSWEと運用チームの共有)以外——SRE・PE・DevOpsといった別チームが一次対応する——であれば「私たちが定義したようなPEモデルを構築しようとしているのではない」と明言する。Netflixが「対応すべきチームを判断する専任機能」を横断的に持つのに対し、Facebookは「構築した者が対応する」という帰属の一致を原則とし、横断的な調整機能そのものを持たない点で、大規模組織における障害対応の設計思想が対極に分かれることを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.239-240, [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]]) - **『Building Secure and Reliable Systems』第20章のセキュリティチームの組織配置論は、Yoshikawaの4区分がSREに固有のものではなく、専門家チーム一般が直面する組織設計問題の一事例であることを示す**: 第20章は、専門家チーム(セキュリティ)の配置を「完全な組み込み」から「完全な中央集権」までの連続体として提示し、Googleは独立した報告系統を持つ中央セキュリティ組織と、各プロダクトチームに配置する「セキュリティチャンピオン」(コードや設定を直接変える権限を持たず、中央チームの標準・フレームワーク・インフラの実装を推進する役割)のハイブリッドを採用すると述べる。このセキュリティチャンピオンは、Yoshikawaの4区分のうち「Consulting(助言する)」に近いが、既出の『SREをはじめよう』第13章のスウォームモデルと同様、コードや設定を直接変えない点で「Embedded」との境界線上にある。SREのエンゲージメントモデル論は特定ドメインの理論として提示されてきたが、セキュリティという別ドメインが独立に同型の中間配置(助言役をプロダクトチーム内に置くが実装権限は与えない)へ到達したことは、4区分が「SREチームがどう関わるか」を超えて「専門家チーム一般の組織設計」の分類学として一般化できる可能性を示唆する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Integrating Security into the Organization, §Example - Embedding Security at Google, [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]]) - **第20章のAndroid/Chromeという「大規模化した製品専属の分散型チーム」は、既出の17章知見(規模とエンゲージメントモデルの対応)が示す「配る」位置への到達とは異なる、Kitchen Sink/Productへの回帰に近い到達点を示す**: 既出の知見は、SRE組織が0→108人以上へ拡大する過程で「Infrastructure/Tools(配る)」型の役割へ広がっていくという時間軸を17章から得ていた。これに対し第20章は、AndroidやChromeのように規模が大きい製品では、製品専属の分散型セキュリティチームが標準・フレームワーク・インフラを自前で決定し、製品のエンドツーエンドのセキュリティに責任を持つと述べる。これは「配る」(共有基盤の提供)ではなく、むしろ対象システムの信頼性(ここではセキュリティ)を専属チームが引き受ける「Kitchen Sink/Product」に近い形態への回帰であり、SRE領域の「規模が大きくなるほど配る位置に向かう」という単調な傾向とは異なる、セキュリティ領域固有の力学(製品固有の脅威モデルの複雑さが自己完結的な専門チームを要求する)を示唆する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Example - Embedding Security at Google, [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]]) ## 未解決の問い - 11章のHRR承認速度と早期SRE関与の相関は、Google社内の観察に基づく経験則として語られるが、定量的な検証(承認までの期間の分布、関与開始タイミングとの相関係数等)は本 concept の現ソース群では確認できない。8章の図8-4が示す「ライフサイクル全段階への関与」との対応関係も、11章のLRR/HRRという具体的な審査ゲートに落とし込んだ形での接続は未検証。 - Matt Kleinの「組み込むが直属しない」報告ライン設計は、Yoshikawaの4区分の「Embedded(一緒にやる)」の下位変種として扱うべきか、それとも報告ライン設計という独立した第5の軸として扱うべきか。本 concept の現ソース群では両者の関係が未整理。 - 8章の「ライフサイクル全段階への早期関与」という時間軸は、17章の「規模とエンゲージメントモデルの対応」という別の時間軸(組織拡大に伴う位置の移行)とどのように組み合わさるか。小規模なSREチームが大企業のレガシープロダクトのライフサイクル全段階に関与しようとした場合、どちらの制約が支配的になるかは未検証。 - SoundCloudのProdEngのように「配る」と「助言する」を同時に占める合成的な役割は、Yoshikawaの4区分に第5の位置として追加すべきか、それとも「配る」の下位変種として扱うべきか。既出のNetflix中枢神経系(第5の位置候補)とは異なる形の越境であり、両者を統一的に説明する枠組みは未検証。 - 引用元の「Google Cloud が観察した6つのチームの型」の原記事はどれか。スライドには URL のみ記載されず、6つの型から4区分への具体的な対応関係は明示されていない。『SREエンタープライズロードマップ』第4章が同種の3区分の出典として Google CRE ブログと SRE Book 第32章を挙げており(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]])、系譜を辿る手がかりにはなるが、具体的な記事名までは特定できていない。 - Team Topologies の3モード（Collaboration / Facilitation / X-as-a-Service）との厳密な対応関係はどうなっているか。「重なる」とされるのみで、4区分のどれがどのモードに対応するかは未検証。 - 「配る」側への移行コストが AI によって下がったという主張（[[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]] p.22）は、SRE 以外のプラットフォームチーム文脈にも一般化できるか。第28章はAIコード生成量の急増を「配る」型の必然性を高める強制関数として描いており、この主張を補強する材料になりうるが、明示的な接続はまだ検証していない。 - 『SREをはじめよう』第13章のスウォームモデル(ページャーは開発チーム保持・SREは調査支援のみ)は Yoshikawa の4区分のどれに最も近いか。「一緒にやる(Embedded)」と「助言する(Consulting)」の中間に見えるが、両者の境界(コードや設定を直接変えるか否か)で厳密にどちらに分類されるかは未検証。 - 17章が示す「規模とエンゲージメントモデルの対応」(小規模=局所的関与、48-108人以上=Infrastructure/Tools)は、Yoshikawaの4区分やTeam Topologiesの3モードのどれと厳密に対応するか。17章は規模の目安のみを示し、Consulting/Embeddedのどちらから始まりやすいかは明示していない。 - Netflix の「中枢神経系」役割(障害トリアージ・ルーティング)は、Yoshikawaの4区分に第5の位置として正式に追加すべきか、それとも「Consulting」の特殊形として扱うべきか。マイクロサービス数が非常に多い組織(40超のチームが関与する障害切り分け等)で共通して現れる機能なのか、Netflix 固有の解決策なのかは他ソースでの裏付けが必要。 - セキュリティ領域(BSRS第20章)が示す「大規模製品は専属分散型チームへ回帰する」という傾向は、SRE領域の17章知見(規模が大きくなるほど配る位置へ向かう)と正反対に見える。この違いはドメイン固有(セキュリティの脅威モデルは製品ごとに大きく異なるが、信頼性の要求はより横断的に共通化しやすい)なのか、それとも両ドメインとも同じ現象を異なる語彙で記述しているだけなのか、他ソースでの裏付けが必要。 - セキュリティチャンピオンモデル(BSRS第20章)とSREのスウォームモデル(既出、『SREをはじめよう』第13章)は、いずれも「Embedded」と「Consulting」の境界線上にあるとされたが、両者の運用条件(権限の範囲、報告先、期間の区切り方)を厳密に比較した突き合わせは未着手。 ## 関連 - [[組織の信頼性マインドセット]] — 縦軸(フェーズ)と組み合わせて2次元マップを構成する - [[エラーバジェット]] — フェーズが上がったことを示す行動指標の一つ - [[Ryota Yoshikawa]] — 本フレームワークの提唱者 - [[Topotal]] — 提唱者の所属企業 - [[プラットフォームエンジニアリング]] — 「配る」位置の実務的な設計原則(ゴールデンパス等) - [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]] — 独立ソースから「Infrastructure / Tools」位置に到達した実例 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]] — Google 内部の実務者インタビューによる段階的関与モデルの実例 - [[Ben Lutch]] / [[Dave Rensin]] — 段階的関与モデルと独立組織論を語った人物 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]] — 「配る」位置の具体的な成果物(監視/権限付与/カナリア/RPCの各ライブラリ)、規模とエンゲージメントモデルの対応 - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]] — 組み込み型・コンサルティング型・インフラ型の3区分と、その出典(CRE ブログ・SRE Book 第32章)、メニュー化による需要超過対策 - [[コンテキスト対コントロール]] / [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]] — Netflix SRE の「中枢神経系」役割という、4区分に収まらない障害トリアージ・ルーティング機能 - [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] — SoundCloudが「引き受ける→一緒にやる→配る」を試行錯誤した歴史的経路、「配る」と「助言する」の境界に位置するProdEng - [[SoundCloud]] / [[Björn Rabenstein]] / [[Matthias Rampke]] - [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] — ライフサイクル全段階への早期関与という時間軸の設計変数、Matt Kleinの「組み込むが直属しない」報告ライン設計 - [[Matt Klein]] / [[Sriram Gollapalli]] / [[Agilent Technologies]] - [[@2021__OReillyJapan__SREの探求 - Chapter 23 SREのアンチパターン]] — 「プッシュ対プル」を業界横断のアンチパターンとして命名、提供様式という位置に横断する軸、Dropboxの「棒とニンジン」マスコット - [[Blake Bisset]] / [[Dropbox]] - [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] — 専任SREチームを経由せず「配る」位置へ到達したSpotifyの分隊型運用、SRE肩書きに依存しないIMOCという越境調整の実装 - [[分隊型運用]] / [[Spotify]] / [[Drew Michel]] / [[Lynn Root]] / [[Johannes Russek]] - [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] — 早期関与とレディネスレビュー承認速度の相関、SREのボランティア的な早期助言文化 - [[レディネスレビュー]] / [[Gene Kim]] - [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] — 独立報告ラインを保ったままEmbedded+完全なオンコール共有に定着したFacebook PE、Netflix「中枢神経系」と対極の判定基準 - [[プロダクションエンジニアリング]] / [[Facebook]] / [[Pedro Canahuati]] - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] — セキュリティチャンピオンモデル、Android/Chromeの製品専属分散型チーム、[[セキュリティの責任分担]] ## 出典 - [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]](もう一度考える SRE #1、2026-07-31)— p.8 で4区分を提示、p.16-17 で移動の定石とコスト構造を論じる - [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]（Rick Clark, Observability Engineering 2E, 2026, Chapter 28）— オブザーバビリティチームは「配る」位置を取るべきという独立した実務規範 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]](David N. Blank-Edelman, 2024, 第13章)— オフィスアワー・コンサルティング・スウォーム・専任配置の実例と、独立組織であるべき理由(統一インフラ・ジョブラダー) - [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]](David N. Blank-Edelman, 2024, 第17章)— 組織全体の信頼性の階層(監視/権限付与/カナリア/RPCの各正規ライブラリ)、規模とエンゲージメントモデルの対応 - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]](James Brookbank, Steve McGhee, 2022, 第4章)— 組み込み型・コンサルティング型・インフラ型の3区分、CRE ブログ・SRE Book 第32章への出典明示、メニュー化による需要超過対策 - [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]](Coburn Watson, David N. Blank-Edelman, 『SREの探求』, オライリー・ジャパン, 2021, 1章)— Netflix SRE を「中枢神経系」と位置づける、4区分に収まらない障害トリアージ・ルーティング機能 - [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]](Björn Rabenstein, Matthias Rampke, 『SREの探求』, オライリー・ジャパン, 2021, 6章)— SoundCloudが「引き受ける(専任SREチーム)→一緒にやる(SRE派遣)→配る(デプロイプラットフォーム)」の順に試行錯誤した歴史的経路、リリース権限を持たないProdEngという「配る」と「助言する」の合成的な役割 - [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]](Sriram Gollapalli, 『SREの探求』, オライリー・ジャパン, 2021, 8章)— プロダクト開発ライフサイクル全段階への早期関与という時間軸の設計変数(図8-4)、Matt Kleinの報告ライン設計への言及 - [[@2021__OReillyJapan__SREの探求 - Chapter 23 SREのアンチパターン]](Blake Bisset, 『SREの探求』, オライリー・ジャパン, 2021, 23章)— アンチパターン10「設計の難所」・11「棒が多すぎてニンジンが不足」、プッシュ対プルの提供様式軸 - [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]](Daniel Prata Almeida ほか, 『SREの探求』, オライリー・ジャパン, 2021, 7章)— 専任SREチームを経由せず「配る」位置へ到達した分隊型運用(Ops-in-Squads)とゴールデンパス、SRE肩書きに依存しないIMOCという越境調整の実装 - [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]](Gene Kim, 『SREの探求』, オライリー・ジャパン, 2021, 11章; 原典『The DevOps Handbook』2016)— HRR承認速度と設計段階からの早期SRE協力の相関、SREのボランティア的な早期助言文化 - Pedro Canahuati, David N. Blank-Edelman, 「Facebook におけるプロダクションエンジニアリング」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 13 章. - Heather Adkins, Cyrus Vesuna, Hunter King, Felix Gröbert, and David Challoner, in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 20 — セキュリティチャンピオンモデル、Android/Chromeの製品専属分散型チーム。