SRE Kaigi 2026
SRE とプロダクトエンジニアは何故分断されてしまうのか
渡邉 美希パウラ
PwatanabeMiki
■ 発表カテゴリ
募集要項（https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2） にある6つの発表カテゴリからお選びください
・Culture: SRE文化の醸成と組織変革
■ 発表概要（400字程度）
伝えたいことの結論：SRE とプロダクトエンジニアの分断を防ぐにはプロダクトエンジニアが SRE 観点を持つことが重要である。プロダクトエンジニアも SRE の観点を持つことで、分断を超え、信頼性向上の重要な推進力となり得る。
このセッションでは、「SRE とプロダクトエンジニアは何故分断されてしまうのか」というテーマで、元 SRE で現在プロダクトエンジニアとして両者の分断の原因を掘り下げ、解決策を紹介します。プロダクトエンジニアが SRE の観点を持つことで、信頼性向上とプロダクト開発のバランスを取る重要性を実体験を交えて解説します。
■ 発表の詳細（1000字程度）
私自身、以前は SRE チームに所属していましたが、当時はプロダクトチームに対して「何故 SLO 達成に向けて時間を割いて動いてくれないのか」「データベースのバージョンアップに対してオーナーシップを持とうとする人が何故こんなにも少ないのか」と感じることがありました。
しかし、いざプロダクトチームに所属し、エンジニアとして機能開発に携わるようになってみると、分断が発生する理由が明確化しました。
【なぜ分断は起きるのか？〜3 つの原因〜】
- SRE チーム → プロダクトチームという依頼構造が固定化しやすい
- 「SRE チーム 対 プロダクトチーム」 = 「1 対 多」 の構造になりがちなため、SRE が各プロダクトチームの内情を把握する難易度が高い
- 共にユーザーに対する価値提供を目的としているが、重視する観点が異なる
【分断をなくすための 2 つのアプローチ】
上述した 3 つの理由を踏まえると、分断を改善するためのアプローチは以下のようになります。
-
「依頼待ち」から「自発的実行」へ: プロダクトチームが SRE 関連タスクを自ら発見し、実施する
一方向での依頼関係を解消し、プロダクトチームに対して SRE チームがリスペクトを感じるシーンが増えますし、プロダクトチームの状況を踏まえて SRE チームに関わるタスクを余裕を持って進めることができます。
一方で、この構造では「SRE チームは不要なのでは？」という疑念を抱きがちになるため、SRE チームとしては、プロダクトチームが自発的に SRE 関連のタスクを進めやすいようなプラットフォームづくりを行うことが大切です。 -
「共通の目標」を持つ: SLO やデプロイ回数など共通する目標を設定し、優先順位のズレをなくす 重視する観点が異なるのは、基本的には目標に由来することです。
プロダクトチームも SRE チームも、SLO やデプロイ回数のような目標をお互いに部分的に持つことにより、観点が統一され、優先順位の決め方も統一化されていくことになります。
【成果】
プロダクトチーム主導で以下の活動に取り組み、SRE チームを巻き込みながら以下のことを達成することができました。
- SLO の自律的監視と改善: 10 秒以上かかっていた API を 1 秒以下に短縮し、エラーバジェットを回復
- デプロイフローの高速化: GitHub Actions のワークフローを改善したり変更をこまめにリリースできる仕組みを作り、リリース起因のインシデントの影響を削減
■ 対象聴衆とその人たちが得られるもの
【対象聴衆】
- プロダクト開発エンジニア
- SRE
- 開発チームリーダー
【このセッションで得られるもの】
- SRE とプロダクト開発の分断を解消する具体的なアプローチ
- 信頼性向上と開発効率のバランスを取るための実践的手法
- SRE の観点をチームに浸透させ、変化を生み出すためのヒント
■ なぜこのトピックについて話したいのか（モチベーション）
SRE とプロダクト開発チーム間の「分断」は、多くの組織が直面する共通の課題で、私自身 SRE として活動する中でプロダクトチームとの連携の難しさを痛感しました。このセッションでは SRE の専門知識がプロダクト開発に浸透し、チーム間の自律的な連携が生まれる文化を醸成したことにより、「分断」を解消できた経験をお話します。そして、参加者の皆様にこの普遍的な課題への具体的な解決策と信頼性向上への新たな視点を提供できればと思います。