# 組織の信頼性マインドセット Navigation: [[index]] | [[concepts/_index]] ## 定義 組織の信頼性マインドセットとは、組織が信頼性をどのように捉え、実践しているかを表す5段階のフェーズモデルである。Google SREs の知見（"What's your org's reliability mindset? Insights from Google SREs"）に基づく分類で、[[Narimichi Takamura]] が複数の SRE 発表でコンテキスト把握の枠組みとして引用している（Source: [[@2022__SRE NEXT__How We Foster Reliability in Diversity]] p.37）: | フェーズ | 説明 | |---|---| | **Absent** | 組織にとって信頼性は後回しになっている状態 | | **Reactive** | 直近で生じた信頼性問題のフォローは行われるが、システムへの長期的投資はほぼない | | **Proactive** | 定期的な組織プロセスを通じて潜在的な信頼性リスクが特定され対処される | | **Strategic** | アーキテクチャ・プロダクト・プロセスを体系的に変更することでリスクのクラスを管理する | | **Visionary** | 信頼性の最高位に到達しており、信頼性への幅広い取り組みをベストプラクティスと経験に基づいて社内外で推進できる | ## 横断的知見 - **SRE 導入の切り口を特定するための診断ツールとして機能する**: Takamura は5フェーズを「組織コンテキスト把握」ステップ（SRE 実践の5ステップのうち第1ステップ）における「組織の信頼性への意識」評価に使う。どのフェーズかによって SRE が最初に取り組むべき活動が変わる（Absent なら経営層への教育から、Reactive なら SLO 計測の小さな試行から）。(Source: [[@2022__SRE NEXT__How We Foster Reliability in Diversity]]) - **インシデント対応成熟度モデルとの連続性**: Takamura の SRE NEXT 2024 発表（[[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]）では、Google の信頼性マインドセットを出発点に「インシデント対応成熟度モデル（3フェーズ×9プロセス×4段階）」を提案した。単なる引用を超え、自社フレームワークとして発展させている点が特徴。複数ソースを並べると、Topotal は Google の原典フレームワークを実務適用する形で発展させていることが見える。(Source: [[@2022__SRE NEXT__How We Foster Reliability in Diversity]], [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]) - **横軸（関わり方）との掛け合わせによる2次元マップ化**: Yoshikawa の発表（[[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]]）は、同じ5フェーズの縦軸に、Google Cloud が観察した4つの関わり方（[[SREエンゲージメントモデル]]）を横軸として組み合わせ、SRE チームの「作り方」を2次元平面上の初期配置と目的地の選択として再定義した。Takamura がフェーズを診断ツールや派生フレームワークの起点として使ったのに対し、Yoshikawa は関わり方の軸を加えて「フェーズをどう上げるか」だけでなく「誰がその仕事をする形にするか」まで同じ地図で扱える形に拡張している。さらに移動には「上げてから、右へ」という定石の順序があり、低いフェーズでは引き受ける関わり方（Kitchen Sink/Product・Embedded）しか効かないとする。(Source: [[@2022__SRE NEXT__How We Foster Reliability in Diversity]], [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]]) - **「感覚ではなく証拠」という診断姿勢が、Google 由来のフェーズモデルと第28章の5つのテストで独立に強調される**: Google のフェーズモデル(Absent〜Visionary)は組織の信頼性への意識を段階として静的に分類するのに対し、『Observability Engineering』第2版第28章の5つのテスト(Ownership・Two-or-Three People・Mystery・Arbitrary Question・Deployment Confidence)は「後から質問して答えを引き出す」形式の動的な診断手続きである。両者とも「感覚や印象ではなく証拠に基づいて現状を把握してから介入を設計する」という順序を共有しており、フェーズモデルが示す位置(例えば Reactive)を、5つのテストの個々の結果(例えば Two-or-Three People Test で判明する属人化)がより具体的に裏付ける関係にあると読める。(Source: [[@2022__SRE NEXT__How We Foster Reliability in Diversity]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **Deployment Confidence Test は「恐怖」を診断信号として明示的に用いる点で、フェーズモデルの Reactive/Proactive 境界を行動面から補強する**: 第28章は「エンジニアがデプロイを恐れているなら、それは暗闇の中で運用していると教えてくれているシグナルだ」と述べる。Google のフェーズモデルは「直近の問題への場当たり対応(Reactive)」と「定期的なプロセスによる先回り(Proactive)」を組織プロセスの有無で区別するが、第28章はこれを個々のエンジニアの感情(恐怖の有無)という観測可能な代理指標に変換しており、フェーズを外部から診断する具体的な質問項目を補う。(Source: [[@2022__SRE NEXT__How We Foster Reliability in Diversity]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **13 章の「アラート無視」シナリオは Reactive フェーズの具体的な一人称ナラティブとして読める**: 『SLO サービスレベル目標』13 章は、アラートが鳴っても無視し、顧客からの苦情で初めて障害に気づき対症療法的に再起動して終わる、という具体的な一日の情景を描く(§13.1)。これは Google のフェーズモデルにおける Reactive(「直近で生じた信頼性問題のフォローは行われるが、システムへの長期的投資はほぼない」)の定義を、抽象的な組織診断カテゴリから当事者視点の物語へ翻訳したものと読める。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] §13.1) - **13 章の「過剰投資」シナリオは、5 段階フェーズモデルのどこにも綺麗に収まらず、モデルの潜在的な欠落を示唆する**: 13 章はもう一方の極端として、テストカバレッジ 100%・常時オンコール・厳密な QA で障害をほぼ根絶する一方、単純な変更のリリースに数週間かかる組織を描く。Strategic/Visionary はいずれも「体系的なリスク管理」を肯定的に描くが、13 章のシナリオは体系的な管理をしているにもかかわらず機能開発が停止するという意味で不健全であり、上位 2 段階のどちらとも単純には対応しない。フェーズモデルが「信頼性への意識の高さ」を単調に善いものとして扱う一方、13 章は信頼性投資にも過剰の閾値があることを示しており、両者を並べるとフェーズモデルに「機能開発とのバランス」という第 2 の評価軸が欠けている可能性が見えてくる。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] §13.1) - **Google のコンポーネント応答者/SoS 応答者という組織アーキテクチャは、Strategic フェーズの定義(「アーキテクチャ・プロダクト・プロセスを体系的に変更することでリスクのクラスを管理する」)を具体的な組織設計として例示する**: [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]] は、単一コンポーネント専任のコンポーネント応答者と、複数コンポーネントを横断する SoS 応答者(プロダクト特化 IRT・Tech IRT)という階層構造、およびそれを支える共通プロトコル(ICS 内部変種)・信頼(現場専門家への権限委譲)・敬意(エスカレーションを咎めない文化)・透明性(ポストモーテムの全社週次共有)という 4 特性を記述する。これらは個別インシデントへの反応ではなく、組織構造そのものを体系的に設計することでインシデント対応能力という「リスクのクラス」を管理する取り組みであり、Google のフェーズモデルが定義する Strategic(「アーキテクチャ・プロダクト・プロセスを体系的に変更することでリスクのクラスを管理する」)の具体的な実装例として読める。ただし本書 ch.3 はフェーズモデル自体には言及しておらず、この対応づけは本 wiki 側の解釈である点に留意が必要——特に Trust/Respect/Transparency という組織文化的特性は、Strategic フェーズの定義文が主眼を置く「アーキテクチャ・プロセスの体系的変更」よりもむしろ Visionary の「ベストプラクティスの社内外への展開」に近い側面も持つ、複数フェーズにまたがる特性である可能性がある。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]], [[@2022__SRE NEXT__How We Foster Reliability in Diversity]]) - **「戦略的レベルへの到達に3〜5年」という具体的年数が、フェーズ移行期間に関する既存の未解決の問いへ独立した第2のデータ点を与える**: 『SREエンタープライズロードマップ』第5章は「Google では、製品の信頼性を戦略的なレベルにまで高めるには、3年から5年かかると考えられている」と述べる。これは、Yoshikawa の発表が示す「真に proactive な状態に移るのに2〜3年かかるのは珍しくない」という既存の知見(下記未解決の問いを参照)とは異なる到達点(Strategic 対 Proactive)を指しているにもかかわらず、いずれも「数年単位」という同じオーダーの期間を示す。2つの独立したソースが同程度の時間スケールに収束していることは、フェーズ移行が短期間では起こらないという傾向を裏付けるが、正確な移行元・移行先フェーズの対応関係は依然として特定できない。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 5 積極的な成功体験の育成]]「SRE を育てるとはどういうことか」4. 信頼性マインドセットのレベルと組織内の目標を評価する, [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]] p.13) - **「進捗には常に後退が伴う」という非線形性の主張は、静的なフェーズ分類に「一度上がったフェーズは維持され続けるとは限らない」という動的な注意点を加える**: Google のフェーズモデル(Absent〜Visionary)は組織の信頼性への意識を静的な段階として分類する。第5章は「SRE プラクティスの採用が非線形であるということは、進捗には常に後退が伴うということであり、これもプロセスの通常の部分として扱われるべき」と述べ、「絶え間ない努力を考えると、古い習慣に逆戻りすることもよくある」とも付け加える。これは、フェーズモデルを「一方向に上昇するはしご」ではなく「維持のための継続的な努力を要する状態」として読み替える必要があることを示唆する。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 5 積極的な成功体験の育成]]「大きく考え、小さく行動する」「SRE を育てるとはどういうことか」4.) - **『SREの探求』3章の「危険を感じると情報を隠す」という指摘は、Reactive フェーズに留まり続ける心理的機序を Google のフェーズモデルより早く(原書2018年)言語化していた**: Google のフェーズモデルは Reactive を「直近で生じた信頼性問題のフォローは行われるが、システムへの長期的投資はほぼない」という行動面の記述にとどめ、なぜ組織がそこに留まり続けるかの機序には踏み込まない。『SREの探求』3章は、「エンジニアリングの問題に感情論で反応する組織はSREを導入する準備ができていません」「人は危ないと感じると情報を隠そうとする意識が働く」と述べ、事実に基づく根本原因の究明を妨げる心理的な自己防衛反応を名指しする。これは、既出の Deployment Confidence Test(恐怖を診断信号とする、第28章)と同じ「感情・恐怖が診断可能なシグナルになる」という着眼点を、フェーズモデルの原典より先に、しかも「情報を隠す」という具体的な行動として示していた点で先駆的である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] §3.2, [[@2022__SRE NEXT__How We Foster Reliability in Diversity]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **「100%未満の信頼性を受け入れられないことがSRE導入の最大の障壁」という診断は、13章が描く「過剰投資」シナリオの発生原因を名指しする**: 既出の知見は、13章の「過剰投資」シナリオ(テストカバレッジ100%・常時オンコールで単純な変更のリリースに数週間かかる組織)が5段階フェーズモデルのどこにも綺麗に収まらず、モデルの潜在的な欠落を示唆すると指摘していた。『SREの探求』3章は、「完璧なシステムは存在しないため、組織では100%未満の信頼性を受け入れることができなければならない」「この現実に直面するのを嫌うことが、SREの導入に対する最大の障壁となっています」と明言し、13章の過剰投資シナリオがまさにこの「100%信頼性への固執」から生じる帰結であることを示す。フェーズモデルが記述する Strategic/Visionary の「体系的なリスク管理」は、100%未満の信頼性を前提として初めて成立するのであり、この前提を欠いたまま体系的な管理だけを推し進めると13章の過剰投資状態に陥る、という因果関係が2ソースを結ぶと見えてくる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] §3.3, [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] §13.1) - **Stone の3つの動機診断(かっこよさ・データ駆動志向・コミットメント)は、Takamura の3層モデル(企業方針/サービス/組織)より早く(原書2018年)、動機ベースの読み替えという別角度から組織診断を行っていた**: Takamura(SRE NEXT 2022)は企業方針・サービス・組織という構造的な3層で組織コンテキストを把握する診断枠組みを提示する。『SREの探求』3章は同じく「SREが自組織に適しているか」を診断する目的を持ちながら、リーダーが語る3つの動機(SREのかっこよさへの憧れ・障害対応への感情的反応・予測可能な信頼性への投資意欲)を出発点とし、それぞれの動機の背後にある組織的準備状況(文化醸成の時間軸・事実重視の文化・リソース投資へのコミットメント)を掘り下げる。両者は「組織を理解してから実践を設計する」という既出の共通姿勢を共有しつつ、Takamura が組織の構造(企業方針・サービス・組織)から出発するのに対し、Stone はリーダーの動機(なぜSREが欲しいか)から出発するという、入り口が逆方向の診断アプローチである。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] §3.1-§3.3, [[@2022__SRE NEXT__How We Foster Reliability in Diversity]]) - **『SREの探求』8章のGollapalliは、Takamura(構造からの診断)・Stone(動機からの診断)とは異なる第3の入口として、非公式な同業者調査による「意欲のあるリーダー候補」の特定を提示する**: 既出の知見は、Takamura(SRE NEXT 2022)が企業方針/サービス/組織という3層の構造的コンテキストから、Stone(『SREの探求』3章)がリーダーの3つの動機(かっこよさ・データ駆動志向・コミットメント)から、それぞれ組織の信頼性マインドセットを診断するアプローチを持つことを示していた。8章のGollapalliは、同じ規模の大企業で働く知人を対象とした非公式調査を通じて、「SRE のグループにとって本拠地となる場所は必ずしも明確ではない」ことを確認したうえで、「運用業務の経験や新しいアプローチを運用に取り入れようとする意欲」を基準に、上層部のリーダー候補(CIO・運用担当VP・サポート担当VP・クラウド担当VP・エンジニアリング担当VPなど)を特定する手法を取る。これは、組織の構造でも個人の動機でもなく、「誰が変化を受け入れる意欲を持つか」という人物本位の診断であり、大企業のマトリックス型組織構造(SREの本拠地が自明でない)という条件下で、構造分析だけでは答えが出ない場合の代替診断経路として機能する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] §8.2.1.1, [[@2022__SRE NEXT__How We Foster Reliability in Diversity]], [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]]) ## 未解決の問い - 8章の「意欲のあるリーダー候補の特定」という人物本位の診断は、Takamuraの構造診断・Stoneの動機診断とどのように組み合わせるべきか。3つの診断入口(構造・動機・人物)を統合するフレームワークは本 concept の現ソース群にはまだ無い。 - 13 章が示す「過剰投資による機能開発の停滞」状態は、Google の 5 段階フェーズモデルのどこに位置づけられるべきか。フェーズモデルへ「機能開発とのバランス」軸を追加すべきかは、他ソースでの検証が必要。 - Google 原典の "What's your org's reliability mindset?" 記事の全文はどこで参照できるか。Yoshikawa の発表では類似の Google Cloud ブログ記事「The five phases of organizational reliability」（cloud.google.com/blog/products/devops-sre/the-five-phases-of-organizational-reliability）が引用されており、同一の記事かは要確認（[[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]] p.6）。 - Absent から Reactive、Reactive から Proactive へのフェーズ移行に要する典型的な期間はどれくらいか。Yoshikawa の発表では「真に proactive な状態に移るのに2〜3年かかるのは珍しくない」という言及があり、『SREエンタープライズロードマップ』第5章は「戦略的レベルへの到達に3〜5年」という近い数値を独立に示す（[[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]] p.13、[[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 5 積極的な成功体験の育成]]）が、両者が指すフェーズ境界(Proactive と Strategic)が異なるため、他フェーズ間の遷移期間との対応づけはなお未確認。 - 「進捗には常に後退が伴う」「古い習慣に逆戻りすることもよくある」という非線形性は、フェーズモデル上でどのように表現すべきか(例: 一度到達したフェーズからの後退を許容する遷移図)。維持コストがフェーズごとに異なるかも未検証。 - フェーズ評価は定量的に行えるのか、それとも定性的なヒアリングに頼るのか。 - 「上げてから、右へ」という定石の順序は、AI 時代には「上げながら、右へ」も可能になったと Yoshikawa は主張する（[[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]] p.24）が、自社事例に基づくものか一般化可能な観察かは他ソースでの裏付けが必要。 - Google のコンポーネント応答者/SoS 応答者という組織アーキテクチャ(ch.3)は Strategic フェーズの例示として読めるが、Trust/Respect/Transparency という文化的特性は Strategic と Visionary のどちらに主に対応するのか、あるいはフェーズを問わず必要な基盤条件なのか。フェーズモデルの原典("What's your org's reliability mindset?")を参照できれば、この対応関係を検証できる可能性がある。 ## 関連 - [[SRE組織変革]] — 組織変革プロセス全体の文脈 - [[ダイナミックケイパビリティ]] — Sensing 能力としての位置付け - [[SREエンゲージメントモデル]] — 本フレームワークと組み合わされる横軸(関わり方の4区分) - [[Narimichi Takamura]] — 複数発表で引用・発展させた人物 - [[Ryota Yoshikawa]] — 横軸との2次元マップ化を提唱した人物 - [[インシデント対応成熟度モデル]] — 派生フレームワーク - [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]] — 「証拠に基づく診断」を5つのテストとして独立に具体化したソース - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] — Reactive フェーズの一人称ナラティブと、フェーズモデルに欠ける「過剰投資」シナリオを提供するソース - [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]] — Strategic フェーズの組織設計例(コンポーネント応答者/SoS 応答者、共通プロトコル・信頼・敬意・透明性) - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 5 積極的な成功体験の育成]] — 戦略的レベル到達に3〜5年かかるという年数、SRE 採用の非線形性(進捗には後退が伴う) - [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] — Reactive に留まる心理的機序(危険を感じると情報を隠す)、100%未満の信頼性受容という導入の最大の障壁、動機ベースの組織診断 - エンティティ: [[Luke Stone]] - [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] — 非公式な同業者調査による「意欲のあるリーダー候補」特定という人物本位の診断入口 - エンティティ: [[Sriram Gollapalli]] ## 出典 - [[@2022__SRE NEXT__How We Foster Reliability in Diversity]]（SRE NEXT 2022、2022-05-14）— p.37 で初引用 - [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]（SRE NEXT 2024、2024-08-03）— 派生フレームワークに発展 - [[@2026__SpeakerDeck__もう一度考える SRE チームの作り方・育て方]]（もう一度考える SRE #1、2026-07-31）— 横軸(関わり方)との2次元マップ化、AI による移行ルートの変化 - [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]（Rick Clark, Observability Engineering 2E, 2026, Chapter 28）— 5つの診断テストによる証拠ベースの現状把握 - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]]（Alex Hidalgo(編)、Harold Treen(執筆)、『SLO サービスレベル目標』, オライリー・ジャパン, 2023, 13章）— SLO のない文化の2つの極端な事例 - [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]]（Ayelet Sachto, Adrienne Walcer, Jessie Yang, *Anatomy of an Incident*, O'Reilly Media, 2022, Chapter 3）— コンポーネント応答者/SoS 応答者の組織アーキテクチャ、共通プロトコル・信頼・敬意・透明性の4特性 - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 5 積極的な成功体験の育成]]（James Brookbank, Steve McGhee 著, 山口 能迪 訳, 『SREエンタープライズロードマップ』, Google Japan G.K., 2022, 第5章）— 戦略的レベル到達に3〜5年、SRE 採用の非線形性 - Luke Stone, 「なるほど、SRE チームを作りたいのですね」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 3 章. - Sriram Gollapalli, 「大企業における SRE の導入」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 8 章.