こんにちは！Eight Engineering Unit Platformグループで名刺アプリ「Eight」のSREをしている峯岸です。
2026年1月31日に開催されたSRE Kaigi 2026へ初めて参加してきました。SRE Kaigiは日本国内のSREコミュニティーが集まる年次カンファレンスで、多くのSREプラクティスや組織論に関するセッションが行われています。
Eightでも、SLOの策定・改善や AI活用によるトイル削減など、SREに関する取り組みを進めています。本記事では、特に印象的だったセッションの内容とそこから得られた学び、そしてEightで実践したいことについて共有します。
目次
- 気になったセッションとEightで実践したいこと
- 生成AI時代にこそ求められるSRE
- SREとプロダクトエンジニアは何故分断されてしまうのか
- Embedded SREの終わりを設計する
- チームを巻き込みエラーと向き合う技術
- イベント会場の様子
- まとめ
気になったセッションとEightで実践したいこと
生成AI時代にこそ求められるSRE
「AI時代にSREは不要になるのでは？」という問いに対し、「必要である」と明確に答えるセッションでした。
セッションの内容とそこから得られた学び
AIはアンプである
「AIは組織の能力を増幅するアンプであり、優れた組織はより強化され、課題のある組織は弱点を増幅させる」という考え方のもと、「SREの責務はAIの爆発的な生産性を、カオスではなく、持続可能なユーザー価値へと変換する」という話が印象的でした。
その中でも一番心を惹かれたのは、SREのプラクティスがAIにもたらす価値は以下の2点だと定義していたことです。
- コンテキスト：AIがよりよく動作するための下地
- ガードレール：AIの失敗を予防・回復するための保険
このコンテキストとガードレールの考え方自体がSREが常に求めてきたものであり、「自分が学んできた・実践してきたSREのプラクティスはAI時代にも必要なんだ」と感じることができました。
AIの出力結果に対してノーと言える文化
その中でもさらに印象的だったのは「AIの出力結果に対してノーと言える文化と組織づくり」という言葉です。
セッションの中で航空業界の「自動化バイアス」の概念を引用し、自動化された意思決定システムの提案を人間が盲目的に優先しないことの重要性が説かれていました。
確かにAIの提案をすんなり受け取ってしまったり、否定できなかったりするケースが多々ありますが、それをノーと言える文化を作っていきたいです。
Eightで実践したいこと
EightでもDatadog MCPを活用したアラート初期調査の自動化、オブザーバビリティの強化やテレメトリーデータの一元化などを検討しています。このセッションで学んだ「コンテキストの補強」という観点は、まさにこれらの設計指針として参考になります。
また、IaCの重要性を改めて実感しました。Eightでは現在Terraformを活用していますが、最終的にはガードレールを整えて誰でもTerraformによるインフラ構築ができる状態を目指したいと考えています。
Eightでも正しいコンテキストとガードレールを設定して、AI時代に活躍できるSREチームへ成長していきたいと思います。
SREとプロダクトエンジニアは何故分断されてしまうのか
SREチームとプロダクトチームの「分断」がなぜ起きるのか、そしてどう解消するのかを体系的に整理したセッションでした。
Product TeamsとSRE Teamの関係性について、両者の間に分断が起こる構造的要因とどうすれば分断を防げるのかについての話されておりました。
※ここでは各チームをProduct Teams（複数のプロダクトチーム）とSRE Team（単一のSREチーム）で記載されていたため、本項目でもその言葉を引用して記載しております
セッションの内容とそこから得られた学び
分断が起きる原因
まず、分断が起きる原因として次のようなことが言及されていました。
- 受発注関係の固定化：役割分担がいつの間にか心理的障壁を生み、責任の押し付け合いや現場の無関心が構造的に醸成される
- 目指すベクトルのずれ：Product Teamsは「新しい価値提供・スピード」、SRE Teamは「信頼性・安定」を軸にするため、価値観の相反が生じやすい
- 1対多が生む情報の非対称性：複数のプロダクトチームが持つドメイン知識はSRE Teamには共有されにくい
「プロダクトの価値を向上させていく」という共通の目標があるにもかかわらず、受発注関係の固定化になってしまうことは多々あると感じました。
バウンダリー・スパニングの手法
分断を解決する方法として「バウンダリー・スパニング」というアプローチが紹介されました。
- Reflecting（反射）：ポストモーテムの標準化やTerraformのモジュール化など、SREプラクティスを「真似られる」環境づくり
- Mobilizing（結集）：人事目標としてプロダクトとSREで共通の目標を立て、月次SLO定例で計測・議論・改善のサイクルを仕組み化
- Transforming（変形）：戦略的な人材配置による情報の非対称性の解消
初めて聞く概念で非常に興味深い内容でしたが、その中で「Transforming（変形）：戦略的な人材配置による情報の非対称性の解消」ができている組織は実質的に分断は起きていないと言及がありました。
その話を聞いて、EightではすでにSREチームからプロダクトチームへの異動実績があり、Transforming（変形）のアプローチを実践できていると感じました。
その際にEight SREチームのメンバーが書いたSREエンジニアがアプリケーション開発チームへ短期留学した話というブログのリンクを載せておきます。
分断が起きないような取り組みを意識せずできていることが、個人としてもチームとしても大きな自信となりました。
Eightで実践したいこと
分断は起きていないと言える状態でも、EightではSREとプロダクトチーム間でまだまだ壁があるように感じることは多々あります。まずはこのセッションで紹介されたReflecting（反射）におけるSREプラクティスの体系化とポストモーテムの拡充・活用を進めていきたいと感じています。
Embedded SREの終わりを設計する：「なんとなく」から計画的な自立支援へ
弊社Sansanメンバーによる登壇セッションで、Embedded SREの「Exit戦略」をどう設計するかという実践的な内容でした。
セッションの内容とそこから得られた学び
なぜExit戦略が必要なのか
まず最初に「私たち、Embedded SREのゴールをExitにしようと思います。」と宣言したところから驚きました。
その上でなぜExit戦略が必要なのかについて話されており、以下のような課題が挙げられていました。
- SREチームのスケーラビリティの限界
- SREのリソースが開発のボトルネックになるリスク
確かにSREのリソースが開発のボトルネックになり得るケースは多いと思います。
これらについて「皆さん（=開発者）が自立して私たち（=SRE）が不要になることを目指します」と宣言し、「Exit戦略」を設計し進めていったようです。
SRE Knowledge Transfer Matrix
Exit戦略を進める上で、開発者への知識移転の進捗を定量化するために「SRE Knowledge Transfer Matrix」というツールを作成し、以下を定義したと話されていました。
- スキルマトリクスをベースに「自信度」と「経験」の2軸で評価
- 個人の目標は60%で十分、チームとしては100%を目指す
- チームカバレッジと個人ダッシュボードで可視化
知識を可視化することで「可視化が対話を生む」「自己評価が主体性を引き出す」「小さな成功体験の積み重ね」という効果が報告されていました。
Eightで実践したいこと
SRE Knowledge Transfer Matrixは、私個人としても「自分のスキルがSREエンジニアとしてどれくらい身についているか」を知るために必要であると感じていたところでした。
また個人だけではなくEight SREメンバーのスキル評価にも活用できそうなため、今の業務内容を参考にSRE Knowledge Transfer Matrixを作成し、スキルの可視化を進めていくことは有効であると感じました。
ゆくゆくは同じように、開発チームの自立を促すためにも活用していきたいと考えます。
チームを巻き込みエラーと向き合う技術
Embedded SREと開発チームとの「対話」を通じて信頼性を高めるアプローチについてのセッションでした。
セッションの内容とそこから得られた学び
「信頼性は会話です」
この言葉がセッション全体を貫くメッセージでした。SREが「見えない変更の発信源」になってしまい、開発チームから「SREが何をやっているかわからない」と言われた失敗談から発表は始まりました。
SREが背景・意図・運用の勘所を自分たちの中に閉じてしまい、「チェスタトンのフェンス（理由がわからない柵）」を立ててしまっていたとのことです。これは非常に身に覚えのある話で、仕組みを増やすことに注力するあまり、なぜその仕組みが必要なのかを伝えきれていないケースは多々あります。
開発チームとの議論事例
セッションでは具体的な議論事例が複数紹介されました。
- APIレスポンスに独自エラーコードを持つべきか → トレーシングIDを使う結論に
- サーキットブレイカーの発動単位 → パス単位で設定
- カナリアリリースの対象範囲 → 社内IPのみに限定
- エラーメッセージのポリシー → エラーの文脈に応じて責務を分ける
これらの議論において、SREは「正解」を押し付けるのではなく、判断軸を提供し、開発チームの自立性を促すことが大切だと強調されていました。
信頼性は「正解」を当てることではなく、会話で決め続けること
この言葉が最も印象に残りました。正解を探し続けるのはしんどいですし、そもそも信頼性に唯一の正解などないのだと思います。継続的な対話を通じて、その時々のベストを決めていく姿勢が大切なのだと感じました。
Eightで実践したいこと
EightでもSREと開発チーム間での対話をより増やしていきたいと感じました。特に「振り返りのために議論の背景、選択肢、決定を残す」という点は、すぐにでも取り入れたいプラクティスです。また、FacebookのProduction Engineeringのエンゲージモデルを参考にしたという話もあったので、こちらも調べてみたいと思います。
イベント会場の様子
スポンサーブースエリアではさまざまなコミュニケーションが行われ、活発な議論が交わされていました。ブース以外でも参加者同士の深い技術トークを耳にすることが多く、オフラインイベントならではの熱量を感じることができました。
また休憩場には屋台が登場しており、おでん、たこ焼き、唐揚げ、おにぎりなどが提供されていました。どれも非常においしく、参加者へのホスピタリティや愛を感じました。
まとめ
SRE Kaigi 2026は、AI時代のSREの役割から組織論まで、幅広いテーマで学びの多いカンファレンスでした。特に印象的だったのは、多くのセッションで「SRE文化」「対話」「開発チームの自立」といったソフトスキルの重要性が強調されていたことです。
技術的なプラクティスだけでなく、チームとの関わり方や組織への浸透のさせ方まで含めて「SRE」なのだと改めて感じました。
今回得られた知見を生かして、Eight SREチームでもより信頼性の高いサービス運用と、開発チームとの協働を進めていきます。
また今回オフラインでイベントに参加し、SRE業界・SREエンジニア全体の盛り上がりを非常に強く感じました。今後SREがより多くの人に広まっていくように私もできることをやっていきたいと考えています。
その上で来年は登壇者として参加できるように精一杯頑張っていきたいと思います。
最後に、運営の皆さま、登壇者の皆さま、会場のスタッフの皆さま、素晴らしい時間をありがとうございました！
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
