SREは、本来「開発を前に進めるための仕組み」として導入されるはずのロールです。
けれど現場を見ていると、ときどき真逆の評価をされてしまうことがあります。「SREがいるとリリースが遅くなる」「またチェックが増えた」「開発の邪魔をしているだけじゃないか」──そんな空気が、じわじわとチームに広がっていくケースです。
この記事では、SREチームがなぜ「邪魔者」として扱われてしまうのかを、技術だけでなく「関係性」と「文化」という視点から紐解いていきます。
なぜSREが「邪魔者」になってしまうのか
現場で本当に起きているすれ違い
SREが導入された最初のうちは、開発チームも期待を込めて受け入れてくれます。「これで障害が減るかもしれない」「リリースが安心になるかもしれない」。ところが、数カ月もすると雲行きが変わってきます。「SREレビューが終わらないとリリースできない」「また新しいルールが増えた」「結局、手間だけ増えていないか」。こうした声が、Slackの裏側や1on1の場で聞こえ始めます。
SRE側から見ると、もちろん邪魔をしようとしているわけではありません。
SLOを守るためにリスクの高い変更にブレーキをかけたり、運用負荷を増やさないために手戻りが出そうな部分に指摘を入れたりしているだけです。どれも「信頼性を守るため」にやっていることです。
しかし開発チームから見ると、こうした動きは「目の前の仕事を止める存在」として映りやすい。SREが増やしたレビューやチェックリストは、彼らの目標（期日までにリリースする、売上に貢献する）に直接ひもづいていません。
その結果、善意でやっているはずの取り組みが、いつの間にか「摩擦」として積み上がっていきます。
善意が衝突する「開発スピード」と「信頼性」
この状況を単純に「開発が悪い」「SREが悪い」と切り分けてしまうと、本質を見誤ります。どちらも自分の正義に基づいて動いているからです。
開発は「ユーザーに価値を届けるスピード」を守ろうとし、SREは「ユーザーの信頼を裏切らないこと」を守ろうとしています。どちらの正義も間違っていません。
問題は、両者の正義を調停する「共通の判断軸」がないまま、個々の案件ごとに殴り合いのような議論をしてしまう点にあります。
SLOもエラーバジェットも共有できていない。ビジネス側との合意もない。そんな状況で「このリリースは止めるべきか？」「どこまで品質を求めるべきか？」を毎回ゼロから議論すれば、疲弊と苛立ちだけが残るのは当然です。
その結果、「信頼性を守るはずのSRE」が、「開発を止める人」「口うるさいチェック担当」として認識されていきます。善意同士の衝突が、静かに関係性をすり減らしていくのです。
役割の誤解がチームの摩擦を生む
「SRE＝レビューの門番」になりがちな構造
多くの組織で見かけるのが、SREを「リリース前の最終ゲート」にしてしまうパターンです。リリースのフロー図を書くと、最後の箱に「SREチェック」と書かれている。PRのテンプレートには「SRE承認」のチェックボックスが増える。
こうして、SREは自然と「通らないと先に進めないゲート」のような存在になっていきます。
もちろん意図としては、「信頼性の観点で抜け漏れがないかを確認するため」の仕組みです。しかし、開発チームから見れば「最後にボトルネックになりうる存在」が増えたことになります。
SREはゲートではなく、信頼性を一緒に設計するパートナーであるはずなのに、その構造自体が「門番」として振る舞う方向に働いてしまうのです。
この状態が続くと、開発チームの心理も変化していきます。「SREにどう見られるか」を気にするあまり、本音を出しづらくなったり、リリース直前まで相談しないまま進めてしまったりする。
結果として、SREが入るタイミングはますます遅くなり、「指摘が重くなる→嫌われる」という悪循環に陥ります。
プロセスが目的化すると、SREは拒絶される
もうひとつ、摩擦を加速させる要因が「プロセスの目的化」です。SREとして「こういうチェックリストがあった方がいい」「この承認フローは必要だ」と考えたことが、いつの間にか「それを守ること自体」が目的になってしまうことがあります。
たとえば、SLOを守るために導入したリリース判定プロセスが、いつの間にか「SLOの数字をきれいに見せるための儀式」になってしまう。ポストモーテムを始めたのに、「テンプレートを埋めること」だけがゴールになってしまう。
こうした状態では、現場は当然「また面倒なルールが増えた」と感じます。
プロセスは本来、「信頼性を高めるための手段」でしかありません。しかし、その意味が共有されないまま形式だけが積み上がると、SREが提案するものすべてが「開発を縛るもの」として受け取られてしまいます。
そして気づけば、「SREに関わると仕事がやりづらくなる」というレッテルが貼られてしまうのです。
開発とSREの対話が途切れる瞬間
Slackに“相談”ではなく“依頼”が来る現場
関係性が悪化し始めると、Slackでのやりとりの空気が変わってきます。最初の頃は「この仕様どう思う？」「この設計で不安なところないかな？」といった相談ベースのメンションが多かったのに、いつの間にか「このPRレビューお願いします」「この変更のリスク評価ください」といった依頼だけになっていくのです。
依頼ベースのコミュニケーションが悪いわけではありません。ただ、「決まったものをチェックするだけ」のやりとりが増えると、SREは後追い対応ばかりになり、開発は「またSREに見てもらわないといけないのか」と感じます。ここには「一緒に信頼性を作る対話」がありません。
相談ではなく依頼だけが飛んでくる状態は、すでに関係性が硬直し始めているサインです。SREが議論の初期から参加できていないため、レビューの場で初めてリスクを指摘せざるを得なくなる。その結果、「また土壇場で止められた」という印象だけが残ります。
SLOや基準が共有されていないまま判定だけ求められる問題
もうひとつよくあるのが、「基準を共有しないまま判定だけを求められる」パターンです。
SLOもエラーバジェットも十分に合意されていない状態で、「この変更ってSLO的に大丈夫ですか？」「このリリース、SRE的にはOKなんですか？」といった問いだけが飛んできます。
このときSREは、プロダクトやビジネス側と共有したわけでもない「なんとなくの安全ライン」を元に判断せざるを得ません。そうすると、開発側からは「結局、SREの気分次第じゃないか」「あのときはOKで今回はダメなの？」と見えてしまいます。SRE自身も、毎回の判断に自信が持てません。
本来であれば、SLOやエラーバジェットは「どこまでリスクを許容するか」をチームで共有するための共通言語です。
それがないまま、SREだけに“最後の判定役”を押しつけてしまうと、関係性は必ず歪みます。ここでもまた、「SRE＝開発の邪魔をする人」という印象が強化されてしまうのです。
どうすれば「開発の味方」に戻れるのか
まずは「相談される存在」になること
では、一度「邪魔者」のラベルを貼られてしまったSREチームが、どうやって「開発の味方」に戻っていけるのでしょうか。
私が現場を観測していて感じるのは、その出発点はいつも「相談される存在に戻ること」から始まる、ということです。
リリース直前のチェックではなく、仕様や設計の検討段階で声をかけてもらえるようにする。そのためには、SRE側からも態度を変える必要があります。
レビューの場で「ダメ出しをする人」として振る舞うのではなく、「一緒にリスクを洗い出して、落としどころを探す人」として振る舞う。相談に対しては、できるだけ「No」ではなく「こうすればYesに近づける」という形で返す。
この積み重ねが、「SREに言うと止められる」から「SREに相談すると安心できる」へと感情を変えていきます。関係性は、一回の大きな施策ではなく、こうした小さな対話の積み重ねでしか変えられません。
小さな成功と共通言語が関係性を変える
もうひとつ重要なのが、「小さな成功を一緒に経験すること」と「共通言語を増やすこと」です。たとえば、ひとつのチームと組んでオンコール負荷の削減に取り組み、「夜間アラートが半分になった」「障害対応のMTTRが大きく改善した」といった成功を一緒に味わう。
この経験は、「SREと組むと仕事が楽になる」という実感につながります。
同時に、SLOやエラーバジェット、ポストモーテムの考え方を押しつけるのではなく、開発側と一緒に「自分たちに合った形」をデザインしていく。それによって、「リリースしてもいいライン」「これはさすがに危ないライン」といった共通の物差しが、少しずつチーム内に根づいていきます。
共通言語が増えれば増えるほど、SREと開発の議論は感情論から離れ、「同じ前提に立ったうえでの意見の違い」に変わっていきます。
この状態まで到達すると、SREはもう「邪魔者」ではありません。むしろ「一緒に判断してくれる存在」として認識されるようになります。
現場のリアルな転換点
「断る」のではなく「伴走する」姿勢の効果
最後に、私が現場で見てきた転換点の一例を書いておきます。あるチームでは、SREがリリースの最終ゲートになっていて、開発からはかなり煙たがられていました。
レビューのたびに「それは危ない」「ここは再検討したほうがいい」と指摘し、そのたびにリリースが遅れる。どちらも正しいことをしているはずなのに、関係性は悪化するばかりでした。
そこでSREが変えたのは、「断る」スタンスから「伴走する」スタンスへの転換でした。
具体的には、リリース判定の場ではなく、企画や設計の段階からミーティングに参加し、「この条件ならSLOを守れそう」「こういう条件をつければリスクを減らせる」といった話を一緒に考えるようにしたのです。
最初はぎこちなくても、「一緒にどうするかを考えてくれる人」として認識され始めると、声のかけられ方が変わっていきます。「この仕様、ちょっと怖い気がするんだけど、一緒に見てもらえますか？」。この一言が出てきた瞬間、SREはもう“邪魔者”ではなくなっています。
文化は仕組みではなく、関係性から始まる
0章でも書いたように、私は「信頼性は関係性である」と考えています。SREが扱うのは、サービスの稼働率やレイテンシ、エラーレートといった数値だけではありません。それらを支えるチームの関係性、対話の質、判断のプロセスもまた、信頼性の一部です。
どれだけ立派なSLOを掲げても、どれだけ高度な自動化を導入しても、「SREと開発の関係性」が壊れていれば、文化としての信頼性は育ちません。逆に言えば、関係性さえ回復できれば、仕組みやプロセスはあとからいくらでも改善していけます。
SREチームが一度“邪魔者”になってしまったとしても、そこからやり直せないわけではありません。
観測し、対話し、小さな成功を一緒に積み重ねることで、SREは再び「開発の味方」として信頼されるようになります。そのプロセス自体が、まさに信頼性エンジニアリングの実践なのだと、私は思っています。
