# カーゴカルトSRE ## 定義 カーゴカルトSRE（Cargo Cult SRE）とは、Googleが生み出したSREモデルの**表面的な形式**（チーム名・役割名・実践名）を、その背景にある文脈的必然性を理解せずに模倣する組織行動のアンチパターンである。「カーゴカルト」とは、太平洋の島民が軍用機が物資を運んでくるのを見て、滑走路や飛行機の模型を作ることで物資が届くと信じた現象に由来する。 ## 背景と文脈 [[SRE]]はGoogleが2004年頃に開発した組織モデルである。その誕生には以下の固有条件があった： 1. **前例なき規模の問題** — 当時、Googleが直面していたスケールの課題を解決するツールが存在しなかった 2. **ツール不在** — Prometheus・Docker・Terraformのような現代のインフラツールが存在せず、内製が必要だった 3. **無限の資本** — 専用チームを設置するための投資が可能だった これらの条件が揃っていたために、SREという解法が「正解」となった。現代の中小規模組織では、これらの条件の多くが消えている。(Gerro Wadat) ## カーゴカルトSREの症状 [[Gerro Wadat]]（2023）は以下の兆候を指摘する： - **チャーターの曖昧さ** — SREチームが何をすべきかが組織内で合意されていない - **責任の転嫁** — 「SREがいるからプロダクト開発者は信頼性を考えなくていい」という誤解 - **恐怖反応としての採用** — 大規模インシデント後に問題の本質解決なくSREチームを設置する - **赤いニシン化** — SREチームの存在が技術的負債の先送り口実になる ## 対比：文脈固有の信頼性投資 カーゴカルトSREの対極は、以下の問いに基づく意思決定である： 1. 信頼性は事業において実際に最優先事項か？ 2. SREチームに明確なチャーターを与えられるか？ 3. 信頼性の責任を組織全体に分散させる文化的準備ができているか？ ## 横断的知見 - [[6 Reasons You Don't Need an SRE Team]] は「私たちはGoogleではない」という文脈条件の欠落を症状の起点として捉えるのに対し、『SREをはじめよう』6章の「肩書きのフリップ、やってはいけない」は個人・組織どちらの視点からも同じアンチパターンを裏側から照らす。フォーカス・スキル・ミッション・優先順位・目標を変えずにチーム名や役職名だけを「SRE」に変更しても、サイトリライアビリティエンジニアリングの便益は得られないと明言しており、Wadatの「恐怖反応としての採用」「チャーターの曖昧さ」と同じ現象を、採用側・応募側双方の行動として具体化している。(Source: [[6 Reasons You Don't Need an SRE Team]], [[@2024__OReillyJapan__SREをはじめよう - Chapter 6 …からSREになる]]) - 『SREをはじめよう』6章は、名ばかりの求人広告(「SRE」と書きつつ組織に変化がない)の帰結を2通りに整理する。すなわち経験者は面接の早い段階で離脱し、未経験者が採用されて同質な組織が再生産される。これはカーゴカルトSREの「症状」が採用フェイズで自己強化的に固定化する経路として、Wadatの症状リストを補強する具体例である。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 6 …からSREになる]]) - 『SREをはじめよう』12章は、肩書きフリップを「組織のSRE導入失敗」という章全体の枠組みの中に位置づけ直し、6章とは異なる2つの角度を加える。(1) 3次サポートチームをそのまま「SREチーム」と呼び替える変種を示し、問題の所在は人材の経験・スキル・アクセス権限ではなく、そのチームが信頼性向上のフィードバックループを作り育てる機能を持たない点にあると特定する。(2) 「二本足の椅子」という寓話(ヘロイン依存からの離脱に例え、旧機能を無視した急な役割変更は失敗する)を用いて、Wadatの「責任の転嫁」症状が起きる機序を、旧チームが担っていた機能の消失という観点から説明する。6章が採用フェイズの自己強化ループを描いたのに対し、12章は既存チームの転換フェイズに焦点を当てており、両章を合わせるとカーゴカルトSREが「新規採用」と「既存チーム再編」の2つの経路それぞれで別の固定化メカニズムを持つことが見える。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 12 SREはいかにして失敗するか]], [[@2024__OReillyJapan__SREをはじめよう - Chapter 6 …からSREになる]]) - **『SREエンタープライズロードマップ』第1章「自分らしさを大切にする」は、カーゴカルトSREの症状の裏返しを、禁止でなく肯定的な指針として提示する**: 同章は「特定の組織でSRE導入のベストプラクティスは1つではなく、正しい方法はあなたが成功した方法だけだ」と述べ、他組織の研究の恩恵を受けつつも、そこで見つかっていない新たな間違いを経験することは避けられないと認めたうえで、組織の経験を学習ツールとして改善の好循環を構築するよう促す。これは[[6 Reasons You Don't Need an SRE Team]]の「私たちはGoogleではない」という警句や『SREをはじめよう』6章の「肩書きのフリップ」批判が描く「他組織の形式をそのまま模倣する危険」と同じ問題意識を共有するが、症状の記述ではなく代替戦略の提示という逆方向からこの概念を補強する。カーゴカルトSREが「模倣の失敗パターン」を描くのに対し、本章は「模倣しないための考え方」を提示する点で相補的である。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 1 エンタープライズSREことはじめ]], [[6 Reasons You Don't Need an SRE Team]]) - **第6章のThe Home Depot(THD)事例は、Wadatの4症状とは異なる第5の経路——「成功への便乗による強制」——を実例で示す**: Wadatの4症状(チャーターの曖昧さ・責任の転嫁・恐怖反応としての採用・赤いニシン化)はいずれもインシデントや不信頼性への対処として発生するアンチパターンを描くが、第6章のTHD事例([[Kip Primous]]・[[Randall Lee]])は正反対の経路を示す。ドットコム部門のSRE導入が成功し社内で「高パフォーマンスの同義語」になったことで、他の多くのチームがこのモデルをコピーしようとし、中にはSLOの要件に関係なくSREの導入を強制されたチームもあった。しかしドットコムチームのようにクラウドネイティブから始められなかったチームは信頼性エンジニアリングの価値を認識するのに苦労した。これは「失敗への恐怖反応」ではなく「成功への便乗(コピー)」が同じカーゴカルト的帰結(チャーターの曖昧さ・価値の誤解)を生む、既存の症状リストにない経路である。(Source: [[6 Reasons You Don't Need an SRE Team]], [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]]) - **KipとRandyの「プッシュ」対「プル」モデルは、本ページの「対比:文脈固有の信頼性投資」節が示す3つの意思決定的な問いに、具体的な提供様式という第4の軸を加える**: 本ページの当該節は、信頼性が事業の最優先事項か・SREチームに明確なチャーターを与えられるか・組織文化の準備ができているかという3つの問いを示すが、実際にどう導入するかという提供様式は扱わない。第6章のKip・Randyは、配送センターの物理ハードウェアにSREを適用するよう言われた経験から、SREを「プッシュ」でチームに押し付けるのではなく、サービスとして提供し必要とするチームに「プル」してもらう提供様式こそが、SLOの要件を伴わない強制導入(本ページに既出の「成功への便乗による強制」)を避ける実務的な処方箋だと提案する。3つの意思決定的な問いに「Yes」と答えられない状況でSREを提供する場合、プルモデルは強制導入という失敗経路そのものを構造的に回避する手段になる。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]]) - **『SREの探求』3章の「名前だけのSRE」は、Wadatや『SREをはじめよう』より前に、Google内部の人物がこのアンチパターンを明示的に警告していたことを示す**: Wadat(2023)・『SREをはじめよう』6/12章(2024)・『SREエンタープライズロードマップ』(2022)はいずれも外部からの事後的な失敗分析としてカーゴカルトSREの症状を描くが、『SREの探求』原書は2018年刊(邦訳2021年)であり、Google Cloud Platform で SRE 導入相談を担当していた Luke Stone が、既存チームに「SRE というラベルを貼り、肩書きをいくつか変更して、ともかく SRE チームを立ち上げたと主張したくなるかもしれません」が「信頼性管理のシステム自体を何か変えているわけではないので、成功しそうにない」と、後年の批判とほぼ同一の構造を先に指摘していた。これは、カーゴカルトSREが外部観察者による事後診断ではなく、SREの発祥企業自身が導入相談の現場で早くから認識していたリスクであったことを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] §3.1, [[@2024__OReillyJapan__SREをはじめよう - Chapter 6 …からSREになる]]) - **Stone は「名前だけのSRE」の原因をチャーターの曖昧さや採用行動ではなく、環境的前提の欠落そのものに置く**: Wadatの症状リスト(チャーターの曖昧さ・責任の転嫁・恐怖反応としての採用・赤いニシン化)や『SREをはじめよう』6/12章の採用フェイズ・転換フェイズの自己強化ループは、いずれも組織行動としてカーゴカルトSREがどう固定化するかを描く。これに対し『SREの探求』3章は、SREチームが「根本的に信頼性の問題に取り組むソフトウェアエンジニアのチーム」である以上、「ソフトウェアエンジニアが活動できる環境にない組織はSREには向いていません」と述べ、名前だけのSREを固定化の帰結ではなく、そもそも導入前提(ソフトウェアエンジニアリング能力を持つ組織であること)が満たされていなかったことの表れとして位置づける。既存ソース群が「なぜ固定化するか」を扱うのに対し、Stone は「そもそも導入資格があったか」という一段手前の問いを加える。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] §3.1) - **§3.4 の事前情報収集ステップは、本ページの未解決の問いが指摘する「症状固定化からの脱出」ではなく、固定化そのものを避ける事前予防策として機能する**: 本ページの未解決の問いは、カーゴカルトSREの症状が固定化した組織がそこから抜け出す転換点を問うが、既存ソース群にはこれへの回答がない。『SREの探求』3章 §3.4 は、SRE本の輪読・SLOブレインストーミング・対象システムの選定・成功時の想像という4つの事前ステップを、SRE導入の意思決定を「一人で抱え込むには重大すぎる」として同僚・ステークホルダーを巻き込みながら行う具体的な手順として提示する。これは第6章のプル型提供モデル(需要側からの要求を待つ)とは異なる、導入を検討する側が主体的に行う事前診断という第3のアプローチである。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] §3.4, [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]]) - **『SREの探求』6章のSoundCloudは、模倣が「肩書きのフリップ」ではなく本気の実装であっても、環境条件(要員規模)を無視すれば失敗するという、Wadatの症状リストにない第6の経路を示す**: 既出の知見群(6 Reasons You Don't Need an SRE Team、『SREをはじめよう』6/12章)が扱うカーゴカルトSREは、いずれも「チーム名や役職名だけを変える」「実質を伴わない表面的な模倣」を問題視する。これに対しSoundCloudの事例は逆で、元Google SREのエンジニア2名を実際に採用し「定石どおりのSRE」を本気で実装しようとした点で表面的な模倣ではない。それでも失敗したのは、オンコールローテーションのベストプラクティス(最小8名)が要求するSREチームの最小規模が、SoundCloud規模(エンジニア約100名)ではエンジニア総数の5〜10%を占めてしまうという、定量的に検証可能な要員数のミスマッチが原因だった。これは、カーゴカルトSREが「意図の欠如」だけでなく「意図が本物でも成立しない規模の算術」という、Wadatの4症状(チャーターの曖昧さ・責任の転嫁・恐怖反応としての採用・赤いニシン化)のいずれにも当てはまらない失敗経路を持つことを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.1.1, [[6 Reasons You Don't Need an SRE Team]]) - **SoundCloudの「SRE派遣」失敗は、6章のKip・Randyの「プッシュ対プル」モデルにおける「プッシュ」の具体的な失敗事例として読める**: 第6章(既出)のKip PrimousとRandall Leeは、SREをチームに押し付ける「プッシュ」ではなく、サービスとして提供し必要とするチームに「プル」してもらう提供様式こそがカーゴカルト的帰結を避ける処方箋だと述べた。SoundCloudのSRE派遣(embedded)は、派遣先の開発チームや他のエンジニア・マネージャーの合意なしに「ある日ふいに現れて『今から皆さんのSREです』と宣言する」という、まさにプッシュ型の典型例であり、派遣されたSREは無視されるか単なるバックエンドエンジニアとして扱われるだけだった。これは、「プッシュ」の失敗が抽象的なリスクにとどまらず、具体的な組織で実際に起きた事例として先行(SoundCloud原書2018年)していたことを示し、Kip・Randyの処方箋(2022年)がすでに実証済みだった問題への回答であったことを裏づける。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.1.2, [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]]) - **『SREの探求』23章のBissetは、「サイトリライアビリティオペレーション」と「運用チームの修復」という対になる2つのアンチパターンとして、カーゴカルトSREの両極を実務者の語彙で明示的に命名する**: 既出の知見群はStone(3章)の「名前だけのSRE」やWadatの4症状を通じてカーゴカルトSREの発生機序を分析してきたが、23章はこれと同じ現象を、より広いアンチパターン体系の中の2つの独立した名前付きパターンとして位置づけ直す。アンチパターン1「サイトリライアビリティオペレーション」は、NOCの技術者にGitHubアカウントとクラウド予算を与えて「あれやこれやをコンテナへ移行するように指示すれば、魔法のようにSREと看板だけ掛け替えることができると思ったら大間違い」だと述べ、Stoneの「名前だけのSRE」と同一の現象(業務の性質を変えずに看板だけ掛け替える)を指す。一方アンチパターン18「運用チームの修復」はその対極であり、運用チームそのものに問題があるから「秘伝のたれ」を持つSREで単純に置き換えれば大企業のような結果が得られるという誤信を指す──これは既出の「成功への便乗による強制」(第6章のTHD事例)が示す、チーム名を変えずに他チームの実装を強制コピーする経路の裏返しに当たる。Bissetは前者を「看板だけの掛け替え」、後者を「中身の入れ替えだけで構造を変えない」誤りとして明確に区別しており、既出のソース群が暗黙に扱っていた「模倣の失敗」を、SREという看板の掛け替え(1)とSREという駒の投入(18)という2つの独立した軸に分解する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 23 SREのアンチパターン]] §23.1, §23.18, [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] §3.1) ## 未解決の問い - 「肩書きだけの変更」と「移行途上にある善意の変更」を、外部の観察者はどの指標で見分けられるか。Blank-Edelmanは後者に「ソフトなスタンス」を取るべきだとするが、判定基準は両ソースとも明確でない。 - カーゴカルトSREの症状が固定化した組織が、そこから抜け出す典型的な転換点(何がトリガーになって文化的・戦略的変化が始まるか)は何か。 - 「成功への便乗による強制」(第6章)と「恐怖反応としての採用」(Wadat)は発生トリガーが正反対だが、同じチャーター曖昧化・価値の誤解という帰結に至る。この収束は偶然か、それとも「トップダウンの強制導入」自体がトリガーによらずカーゴカルト化を招く構造的要因なのか。 - プルモデル(サービスとして提供し、必要なチームが来る)への転換は、既にプッシュで導入してしまった組織でどう実現できるか。第6章はプルモデルを予防策として提示するが、事後の是正手順には踏み込まない。 ## 関連 - [[SRE組織変革]] — SRE導入の文化的・組織的側面 - [[SRE]] — SREの定義と原則 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 6 …からSREになる]] — 「肩書きのフリップ」への警鐘 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 12 SREはいかにして失敗するか]] — 3次サポートのSRE化、「二本足の椅子」寓話 - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 1 エンタープライズSREことはじめ]] — 「自分らしさを大切にする」、模倣しないための肯定的な指針 - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]] — THDの「成功への便乗による強制」、プッシュ対プルモデル - [[Kip Primous]] / [[Randall Lee]] — プル型SRE提供モデルの提唱者 - [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] — 「名前だけのSRE」への最初期の内部警告、環境的前提の欠落という視点、事前情報収集による予防策 - [[Luke Stone]] — 「名前だけのSRE」の警告者 - [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] — 本気の実装でも規模の算術で失敗するSoundCloudの事例、SRE派遣という「プッシュ」型の具体的失敗 - [[Björn Rabenstein]] / [[Matthias Rampke]] / [[SoundCloud]] - [[@2021__OReillyJapan__SREの探求 - Chapter 23 SREのアンチパターン]] — 「サイトリライアビリティオペレーション」(看板の掛け替え)と「運用チームの修復」(駒の入れ替え)という対になる2つの名前付きアンチパターン - [[Blake Bisset]] / [[Dropbox]] > [!key-insight] 警句 > 「私たちはGoogleではない」という認識は、SRE導入の必要性を問い直すための出発点として機能する。(Source: [[6 Reasons You Don't Need an SRE Team]]) ## 出典 - Gerro Wadat, "6 Reasons You Don't Need an SRE Team" - David N. Blank-Edelman(山口能迪 訳), 『SREをはじめよう』, オライリー・ジャパン, 2024, 6章. - James Brookbank, Steve McGhee 著, 山口 能迪 訳, 『SREエンタープライズロードマップ』, Google Japan G.K., 2022, 第 1 章. - James Brookbank, Steve McGhee 著, 山口 能迪 訳, 『SREエンタープライズロードマップ』, Google Japan G.K., 2022, 第 6 章. - Luke Stone, 「なるほど、SRE チームを作りたいのですね」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 3 章. - Björn Rabenstein, Matthias Rampke, 「専任 SRE チームなしで SRE の原則を適用する方法」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 6 章. - Blake Bisset, 「SRE のアンチパターン」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 23 章.