なぜ私たちのSREプラクティスは なかなか機能しないのか ~ システムより先に組織を見る ~ Topotal, Inc － VTRyo SRE NEXT 2026 | VTRyo 1 

このスライドのターゲット SREプラクティスについてある程度知っている人 導入したが、 つまづきやプラクティス自体に違和感を抱いている人 これからSREを育成する予定の人 SRE NEXT 2026 | VTRyo 2 

自己紹介 VTRyo／2015年インフラエンジニアとしてキャリアスタート。 2018年頃から本格的に SRE として活動 スタートアップ・メガベンチャーで SRE を経験 ㈱マツリカ／㈱マネーフォワード など 2025年9月より株式会社 Topotal にて SRE as a Service に従事。 Cross-Company Embedded SRE としてお客様を支援中 SRE NEXT 2026 | VTRyo 3 

SRE as a Service - 技術支援 私たちは Cross-Company Embedded SRE として、 課題を解決する。 クライアントが変わっても、 SRE と してやるべきことは変わらない。 SRE NEXT 2026 | VTRyo 4 

Waroom - SaaS Slack で完結できる AI による情報自動収集・ポストモーテム自動生成 蓄積したインシデント情報の可視化と分析・各ツールとのインテグレーション SRE NEXT 2026 | VTRyo 5 

耳の痛いタイトルです。 心当たりがありますか SRE NEXT 2026 | VTRyo 6 

まず、 SREプラクティス導入の"あるある"を見ていく サービスの安定・運用課題を解決すべく SREチームのリーダーとなったあなた 障害が起きればすぐ駆けつけ、 SREとして率先してポストモーテムを書いてチームに導入した モニタリングを改善しましょう、 ということで 「まずは私がやります」 と整備を実施 SLI を見つけ SLO を設定 リリースフローが複雑で変更が遅いと修正に遅れると気づき CI/CD を整備 → 現場の課題を解決するプラクティスの導入例 SRE NEXT 2026 | VTRyo 7 

SREをはじめた直後は、 まず見えている本番環境のために多くの施策を打つ 障害が発生した → ポストモーテム導入 モニタリングが不十分 → 設定やアラートを整備 運用作業が時間を取りすぎ → トイルの削減に注力 etc... SRE NEXT 2026 | VTRyo 8 

SREプラクティスを 導入した!! SRE NEXT 2026 | VTRyo 9 

安心してください。 これはすばらしいことです 何もない状態より、 SREはまず立ち上げることが何より良い 本番環境の問題を、 より良くするために動いている SRE NEXT 2026 | VTRyo 10 

おそらく、 問題はここから SRE NEXT 2026 | VTRyo 11 

おや、 導入したSREプラクティスの様子が……？ SRE以外がポストモーテムを書いていない？ SLOを設定したけど、 SRE以外はSLOを意識していない？ 気づいたらインフラ関連のタスク、 全部SREがやってない？ SRE NEXT 2026 | VTRyo 12 

SREしかやっていない、 もしくは誰も意識しなくなる 扱い方がわからず塩漬けになる 初期メンバーがいなくなって文化が消える （Embedded解除で誰もやらなくなる、 等） SRE NEXT 2026 | VTRyo 13 

どうしてだよおお SRE NEXT 2026 | VTRyo 14 

「SRE」 を もう一度考えてみる SRE NEXT 2026 | VTRyo 15 

Googleはなぜ SLOやエラーバジェットポリシーなどを つくったのだろう SRE NEXT 2026 | VTRyo 16 

SLO ＝ 「信頼性」 をデータで見えるようにするため 「どれだけの信頼性があれば十分か」 を、 ユーザが気にかけることに基づいて、 測れる目標として決める。 SLO は、 SRE と開発の作業の優先順位を決める主要因になりうるし、 そうあるべきだ。 ユーザが 気にかけることを反映しているのだから。 "SLOs can—and should—be a major driver in prioritizing work for SREs and product developers, because they reflect what users care about." → もともと彼らは強いデータドリブンの意思決定文化が存在する。 例 「41種類の青から最適な青を選ぶ」 参考：Google SRE Book — Service Level Objectives SRE NEXT 2026 | VTRyo 17 

エラーバジェットポリシー ＝ 政治でなく 「データ」 で行動を決めるため エラーバジェットを使い切ったら何をするか事前に合意しておく 「ポリシー」 。 動機 こうした決定は、 政治・恐怖・希望で左右されるべきではない。 交渉力に左右される非公式なバ ランスでなく、 双方が合意できる客観的な指標が要る。 "…Nor should such decisions be driven by politics, fear, or hope." 利点 SRE と開発のインセンティブを整合させ、 共同責任を強調する。 複数チームがわだかまりなく本 番リスクについて同じ結論に達せる。 "An error budget aligns incentives and emphasizes joint ownership…" 参考：Google SRE Book — Embracing Risk （Motivation for Error Budgets） SRE NEXT 2026 | VTRyo 18 

ポストモーテム ＝ 失敗を 「学び」 として次に活かすため 失敗の代償は、 学びである "The cost of failure is education." インシデントから学ぶための正式なプロセスがなければ、 インシデントは際限なく繰り返される 可能性があります。 "Unless we have some formalized process of learning from these incidents in place, they may recur ad infinitum." ポストモーテム文化を定着させるには、 エンジニアリングリーダーが率先して 「非難しない」 姿 勢を体現する必要がある。 "…engineering leaders should consistently exemplify blameless behavior…" 参考：Google SRE Book — Postmortem Culture: Learning from Failure SRE NEXT 2026 | VTRyo 19 

トイルの削減 = 効率的にサービスを管理し、 エンジニアリングに集中するため GoogleのSREはトイル （運用作業） を各自の時間の50%未満に抑える。 トイルが少ない方がいい理由 SREの時間の少なくとも50%は、 将来のトイルを減らすか、 サービスに機能を加えるエンジニア リング作業に充てるべきだ。 "At least 50% of each SRE's time should be spent on engineering project work that will either reduce future toil or add service features." 雑務を減らし、 サービスを拡張する作業こそが、 サイト信頼性エンジニアリング （SRE） における 「エンジニアリング」 である "The work of reducing toil and scaling up services is the "Engineering" in Site Reliability Engineering." SREが運用に埋没するのを防ぐ この上限は、 SREが運用作業に埋没せず、 チームの構成が純粋な運用チームへ傾かないことを 保証する仕組みとして働く。 "This cap acts as a mechanism that ensures that the SRE team members do not become entrenched in operational work, and that the team makeup does not drift toward a pure operations team." 参考：Google SRE Book — Eliminating Toil ／ Why Less Toil Is Better 20 

Googleは SRE を設計し、 各プラクティスに根付かせたい文化を持たせた SRE NEXT 2026 | VTRyo 21 

各プラクティスと組織文化の対応 Googleは、 守りたい価値観や文化を維持するために、 SREプラクティスとして設計していると考えられる。 プラクティス 組織の文化 組織の価値観 SLO / エラーバジェッ トポリシー データによる意思決定 データに基づいて判断したい ポストモーテム 正直かつ率直に意見を述べて フィードバックループを回す 常にユーザに焦点を当てたい。 （ユーザに集中するより、 自分自身や同僚を非難か ら守ることが最優先事項になるような状況を防ぐ） *1 トイルの削減 （SREの運用作業は全 体の50%未満に） *2 SREをエンジニアリング組織 に保つ。 運用過多で人が離れるのを 防ぐ （エンジニアリングによってスケールに耐え） ビジネスの成長を止めない 参考： *1 Google Cloud Blog — Shrinking the impact of production incidents using SRE principles—CRE Life Lessons *2 Google SRE Book — Eliminating Toil 22 

自組織の価値観はSREプラクティスと 合致しているだろうか？ SRE NEXT 2026 | VTRyo 23 

文化が無いままプラクティスだけ導入しても、 うまく機能しない SRE NEXT 2026 | VTRyo 24 

うまくいっていたパターンと そうでない分かれ目は？ SRE NEXT 2026 | VTRyo 25 

分かれ目は 「SRE内で閉じる」 かどうか SRE内で閉じる内容は、 比較的すぐに成果が見える。 一方で、 ステークホルダーが増えるほど組織にある文化や構造が SREプラクティスの機能に影響し始める。 SRE内で完結 課題意識が共通で持ちやすく、 チーム内で小さく素早く開 始できる。 スモールスタートはこちらの方法にメリットが ある SRE以外のステークホルダーと協働する 調整コスト、 コミュニケーションコスト、 事前合意といった 縛りも発生するため難易度が高い トイル削減や運用作業率も、 開発チームと調整が必要な 場面になると難易度が上がる SRE内で完結することが、 すべて悪いわけではないので注意。 スモールスタートは大事 「どうもSREプラクティスがうまく機能してないのでは」 と思うときは、 SRE以外の関係者が必要な領域で起きがち SRE NEXT 2026 | VTRyo 26 

うまく機能しなかった例を ご紹介 SRE NEXT 2026 | VTRyo 27 

実際にあったフィクション① 目的もなく導入したプラクティス — Dev環境のポストモーテム 当時の私 「開発環境でもポストモーテムを書くといいらしい」 と読み聞きして導入した。 しかし、 まったく定 着しなかった。 この Dev環境には、 学ぶべき差し迫ったことも無く、 目的意識も伝えられなかった。 メンバーはDev環境へのポストモーテムに時間を割く理由を持てず、 時間をつくる調整ができなかった なんならSREも結局書くことなはく、 無に帰った SRE NEXT 2026 | VTRyo 28 

何のためにあるのか。 どうなるべきなのか明確にすると？ — Dev環境のポストモーテム ポストモーテムは失敗から学ぶための SREプラクティスであり、 同時に人を非難しない場作りの練習にもなり得る。 新人育成の場として利用する。 「失敗を学びに変える」 「非難しない」 を習慣や雰囲気をオンボーディングか ら意識してもらう場 本番環境のポストモーテムを初めから書くのは難易度が高いため、 執筆練習として使う 社内ユーザに影響がある環境 （Platform / QAなど） として利用する。 実際に信頼性が必要な環境であれば意味がある SRE NEXT 2026 | VTRyo 29 

実際にあったフィクション② 運用作業が集中する — SREがやった方が速い件 クラウドインフラ、 CI/CD、 モニタリング設定などなど。 ついついSREチームが対応してしまう トイルを潰しても、 インフラに発生する不具合や変更依頼など溢れていく運用タスク 開発チームが運用作業を学ぶスキマがなく、 SREがやった方が速かった SREが持つロードマップが逼迫。 将来のために対処すべきことが後手に SRE NEXT 2026 | VTRyo 30 

自律的に信頼性と開発速度を最大化できる状態をつくる — SREがやった方が速い件 SREが開発チームに対してボトルネックになるような構成になると、 必然的に 「開発チームがSREと同じスキルを持っていたほうが良い」 ことになる SREの実装、 レビュー、 リリースを待つなら開発チーム自身で回せる方が効率的 *1 どうしても対処不能、 あるいは相談したい事を依頼式にする *1 ロードマップ進捗と運用作業の比率をタスク数や消費時間で割合を算出する SREと開発チームが異なるSLOに責任を持つことで、 互いに開発から運用を担当するインセンティブをつくる *2 *1 参考：SRE Kaigi 2025 — 一人から始めたSREチーム3年の歩み - 求められるスキルの変化とチームのあり方 - *2 参考: クラウドネイティブ会議 — そのSLO 99.9%、 本当に必要ですか？ 〜優先度付きSLOによる責任共有の設計思想〜 31 

システムより先に組織を見る SREプラクティスに組み込まれた文化が組織になければ機能しない 前提となる文化が必要ならまずはそこを変える取り組みが必要となる SRE NEXT 2026 | VTRyo 32 

SREプラクティスを機能させ続けるために 必要な文化を整えていこう SRE NEXT 2026 | VTRyo 33 

おまけの話 SRE NEXT 2026 | VTRyo 34 

「エラーバジェットポリシーをやるべきだとは思うが、 現時点で運用が回ってるのでできてない」 教科書的な使い方をすべきだと思ってはいるが、 現実そうしなくても問題になっておらずSREとしてはモヤモヤする。 そのケースの例を見ていく。 例1. SLOが仮で設定されており、 その数値が悪化した段階で対処しているのでそれで十分である 例2. エラーバジェットポリシーを決めるにしても、 関係者と合意を取るコストが高いため後回しになってい る → ここでは、 やるべきと思っているがうまく運用できている、 という状態を想定する SRE NEXT 2026 | VTRyo 35 

例1. SLOが仮で設定されており、 その数値が悪化した段階で 対処しているのでそれで十分 これは設定したSLOを検知として使っている例。 SLO違反まで行かなくとも、 数値が悪化した段階で気がつく 悪化した段階で、 何かが悪いことを理解できるので調査が始まる 実質的に行動が促されているため、 ポリシーとして明文化するメリットが見えにくい 暗黙の裁量によって運用が回せている → SREと開発チーム間で対立したり、 行動が先送りになっていないのであれば問題ない 暗黙の裁量が届いているなら十分である SRE NEXT 2026 | VTRyo 36 

例2. エラーバジェットポリシーを決めるにしても、 関係者と合意を取るコストが高いため後回しになっている 関係者が多いと調整や合意コストが高くなる。 一方でエラーバジェットポリシーのメリットを振り返ると、 気がつくことがある エラーバジェットポリシーがなくても回るケース → 暗黙の裁量が機能するとき （先述の仮説） 合意コストが高いとき → 関係者が多く越境や説明が必要になるとき ＝ 暗黙の裁量が破綻する可能性あり 「後回しにしているコストの高さ自体が、 ポリシーが必要なとき」 → 小さく始めたいときは、 関係者数よりも 「暗黙の裁量が届かない最小単位」 「かつ行動を約束させられる権限がある」 境界を探すと良さそう 暗黙の裁量が届いていないなら施策を打つ余地がある 37 

おまけのおまけ SRE NEXT 2026 | VTRyo 38 

「エラーバジェットポリシーがユーザのためになる」 わかりやすい例 — ファミレスのエラーバジェットポリシー 某黄色いファミレスの厨房では、 オーダー状況が色分け表示されていた。 顧客影響度が可視化されており、 現場リーダーが即時判断 できるようになっている 5分以内 許容 （目標内） 5〜10分 注意 （バジェット減り始め） 15分経過 至急 （バジェット枯渇） 。 他作業を止めてで も対応 時間を基準に、 優先度が明確に決まっている このルールに従うことで、 アルバイトでも自然とユーザに価値を提供できる バイトだろうと店長だろうと、 15分を超えたときは優先的にリソースを割く → 待たされる時間は顧客満足度に直結する重要な指標 39 

そうはいっても、 現実では実践が難しそう…… SRE NEXT 2026 | VTRyo 40 

そんなときは、 SRE支援の Topotal にご相談ください！ ！ お客さまが持つ個別のお悩み、 壁打ちから伴走します！ We are waiting!! SRE NEXT 2026 | VTRyo 41 

本日と明日、 スポンサブースにTopotal社員がたくさん来ている！ ！ SREコミュニティに特化したメンバーともカジュアルにお話！ ゆっくりしていってね！ 過去 SRE NEXTを始めとしたカンファレンスで登壇した現役SREの CEO nari_ex, CTO rrreeeyyy 本日 「事業価値を生み出すSREへ ー SREが担うべき意思決定の5層」 で登壇した COO kenta_hi （過去 SRE NEXT で Co-Chair を担当） 本日 「Tamachi.sre 地域SREコミュニティ最前線」 にて広島代表として登壇する gr1m0h （過去 SRE NEXT の Chair を担当しながら同時に登壇） 過去 SRE NEXT、 SRE Kaigi、 クラウドネイティブ会議で登壇した VTRyo ← ここに載っていない、 SRE最前線で活躍するメンバー多数もブースに！ SRE NEXT 2026 | VTRyo 42 

ご清聴ありがとうございました なぜ私たちのSREプラクティスはなかなか機能しないのか 43