2026 年 1 月 31 日に開催された SRE Kaigi 2026 に参加してきました。 SRE 関連のカンファレンス参加は初めてだったので、学んだことや感じたことを忘れないうちに記録しておきます。
SRE Kaigi 2026
はじめに
どうして参加したのか
SRE のプラクティスを学び、日頃の Platform Engineering に活かしたいと思ったのが今回の参加理由です。
現在は Platform Engineering の活動をメインでやっていて、カンファレンスのテーマである SRE という分野ではありません。 とはいえ、SRE Kaigi でも「Embedded SRE」と「Platform Engineer」というチーム構成を紹介されているセッションもあったように、SRE と Platform Engineering は密接に関わる領域だと考えています。
あと、裏の理由としては「現地イベントに参加したい！」というのがあります。 地方在住なので現地イベントに参加する機会が少なく、定期的に現地イベントに参加して熱量を持って帰ることが必要なのです。
さらに裏の裏の理由として、杉田智和さんのナレーションを聞いてみたかったというのもあります。
セッションの選び方
どのセッションを見るかはとても悩みましたが、その中でも今回は「開発チームとの関わり方」に関するセッションを中心に選びました。 SRE チームの目的である「システムの信頼性をあげたい、そのプラクティスを開発チームに Enabling したい」を実現するために、どのように開発チームと関わっているのかという点に興味があったからです。
Platform Engineering の活動をやる中でも「開発チームの生産性を上げる・認知負荷を下げるプラットフォームを用意して使ってもらう」ことは、ただ技術的に優れているプラットフォームを構築するだけでは達成できない、開発チームに寄り添うこと・協業することが大切です（最近痛感してきた）。
言わば「他人のやり方を変えることの難しさ」が見えてきている中で、SRE でも同じような課題があってそれにどうアプローチしているのか知ることは Platform Engineering の面でも学びがあるのでは、と考えて選びました。
学んだこと、感じたこと
はじめは「学んだこと」と「感じたこと」を分けて書こうと思っていましたが、学んだことを書いていくうちにお気持ち表明的な内容が多くなってきたので 1 つのセクションにまとめちゃいました。 自分が特に学んだことにフォーカスして簡単にまとめます。
SRE チームと開発チームの分断
ワンキャリア 渡邉 美希パウラさんによる「SRE とプロダクトエンジニアは何故分断されてしまうのか」というセッションでは、SRE チームと開発チームの分断がなぜ起こるのか、その構造的要因と解決アプローチについて紹介されていました。
SRE チームと開発チーム（プロダクトエンジニア）の間で分断が起こるのは以下の 3 つの構造的要因があります。
- 受発注関係の固定化：Product → SRE への依頼構造が受発注関係になってしまう
- 目指すベクトルのズレ：開発チームの「価値提供・スピード」と SRE チームの「信頼性・安定」という価値観が相反する
- 1 対多が生む情報の非対称性：開発側のドメイン知識が SRE に共有されにくく、文脈を伝えるコミュニケーションコストが発生 → 億劫になる → 責任の分断へ
分断を解決するアプローチとして「バウンダリー・スパニング」が紹介されていました。 参考書籍『組織の壁を越える――「バウンダリー・スパニング」6つの実践』では 6 の手法が紹介されているそうですが、ワンキャリアさんは以下の 3 つに絞って取り組んでいました。
- Reflecting（反射）：SRE プラクティスを真似られる環境づくり（マニュアル化、Terraform モジュール化、ペアプロ）
- Mobilizing（結集）：共通の評価指標（SLO）をもとに対話を繰り返す仕組みの構築
- Transforming（変形）：SRE チームと開発チームのメンバーを入れ替えによる情報の非対称性の解消
アプローチ方法も大事ですが、特に重要なのは「境界は常に発生して無意識に広がるので、境界を埋める継続的なアプローチが必要」ということです。
Platform Engineering でも Platform チームと開発チームの関係を築くのにバウンダリー・スパニングが使えないでしょうか。
ここからは持論ですが、チームトポロジーのインタラクションモードでは Platform チームは開発チーム（ストリームアラインドチーム）に対して「X-as-a-Service」として関わることになりますが、その前段として「開発チームが求めるプラットフォームを探るフェーズ」が必要です。 開発チームが求めるプラットフォームというのは、開発におけるトイルを削減してくれるプラットフォームと言えます。
Platform チームが提供するプラットフォームをいきなり開発チームに使ってもらえることは限定的で、使ってもらえるパターンってのは既に組織の中でいくつかの開発チームがプラットフォームを使っていて、その成功事例が他の開発チームに伝わっている、という状況なんじゃないかなと。
SRE チームと開発チームの関係と同じように、Platform チームと開発チームも目指すベクトルがズレていますし、やっぱり情報の非対称性は存在してしまいます。 受発注関係については Platform Engineering では開発者と Platform チームの間にプラットフォームが挟まることで受発注からセルフサービスへと変えることが望ましいのかな。
ファーストペンギンとしての開発チームにプラットフォームを使ってもらうには、Platform チームが開発チームの文脈を理解して寄り添い、信頼関係を築くことが重要です。 構造的な要因は同じようなので、バウンダリー・スパニングを用いて信頼関係を築くことができないかと考えました。 今回セッションで紹介された『組織の壁を越える――「バウンダリー・スパニング」6つの実践』 の 3 つ以外の手法でも Platform Engineering に応用できるものがあるかもなので、ぜひ読んでみたいですね。
Embedded SRE の Exit 戦略
Sansan 鷹箸 孝典さんによる「Embedded SREの終わりを設計する 「なんとなく」から計画的な自立支援へ」というセッションでは、Embedded SRE の Exit 戦略について紹介されていました。
SRE の本質的な役割は会社の価値を上げること、だけど SRE は直接貢献に寄与できないから、組織を効率的なものにして価値を上げることが求められます。 各開発チームに対して Embedded して行かなければならないので、SRE チームが次のチームに Embedded していくためにも Embedded にゴールを設定する、それが Exit 戦略というわけですね。
その Exit 戦略として以下の 3 つのフェーズが紹介されていました。
- Phase 1：基盤構築期（SRE チーム主導）
- Phase 2：自立移行期（開発チーム主導）
- Phase 3：サポート期
そうやって各チームに SRE チームが Embedded してプラクティスを根付かせることを続けていくと、最終的には SRE チームが不要になる、SRE チームがその状態を目指すことが大事。 知り合いの SRE の方も「SRE チームを無くすことがゴール」と言っていました。 「SRE は魂」という言葉も聞きます。
Platform Engineering、Platform チームにおいてはどうでしょう。
Platform Engineering では開発チームの生産性を上げるために Platform チームが各開発チームに対してなにが生産性を妨げているのか理解し、トイルを削減していくフェーズが一定必要かと思います。
そのフェーズでは Platform チームが開発チームに深く関わることになりますが、最終的には各開発チームがプラットフォームを使って自走できるようになることが望ましいです。 なので、Platform チームが各チームに向き合うときには Exit 戦略、「どうなったら Platform チームの関与が不要になるのか？」を考えておくことが重要だと感じました。
組織全体としての Platform Engineering には終わりがあるのか。 SRE と同じく Platform Engineering も魂のようなもので、Platform チームが宿していくべきものなのかなと。
SRE チームとの違いは、Platform チームは残り続けるということ。 開発チームからのフィードバックを受け続けて、プラットフォームを進化させ続ける必要があるからです。 終わりがあるとすれば、プラットフォームの成長を止め、プラットフォームが使われなくなったときだと考えています。
「とっつきやすさ」と「相談しやすさ」
イオンスマートテクノロジー 川田 雅彦さん、久保 翔馬さんによる「SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル」というセッションで興味深かったところは、Enabling を進める SRE チームの方だけでなく、Enabling を受ける開発チームの方も登壇している点です。
Enabling される側の視点で、どんな施策が効果的だったのかを聞けたのはとても参考になりました。 また、SRE チームとして Enabling できるようになるまでのオンボーディングの取り組みについても、SRE を知らない状態でジョインした方のオンボーディングを受けた側の視点で聞けたのは良かったです。
全体を通して感じたのは、まとめとしても紹介されている「とっつきやすさ」と「相談しやすさ」を意識されてオンボーディングや Enabling の仕組みを作られているところです。
とっつきやすくすることは名前のつけるところから始まります。 オンボーディングは「オンボーディングクエスト」、開発チーム・SRE チーム合同の定例は「だっしゅぼーどを眺める会」という名前にして、堅苦しくならないようにされていました。 そのうえで定例については「報告会ではなく眺める会なので事前準備は不要」として、打ち合わせに参加するハードルを下げています。
相談しやすさは自主性を促すために必要なもので、オンボーディングや眺める会それぞれ異なるアプローチですが、共通して「いつでもチームメンバーや SRE チームがサポートしてくれる安心感」を与える仕組み、雰囲気を作っています。
Platform Engineering においても「とっつきやすさ」と「相談しやすさ」は重要です。
プラットフォームは開発チームに提供するプロダクトです。 組織としての Platform チームのとっつきやすさや相談しやすさも大事ですし、プロダクトとしても開発チームに使ってもらって、フィードバックをもらうためにプラットフォームのハードルを下げる必要があります。
「とっつきやすさ」とは「親しみやすさ」でもあると思います。 プロダクトであるプラットフォームに親しみを感じてもらえるネーミングをつけるのも一つの手だと考えてます。 いわゆるブランディングです。
個人的には JAL デジタルさんの社内ブランディング戦略が好きです。 Ansible を使った自動化プラットフォーム「ATLAS」、HashiCorp Vault を使ったシークレット管理プラットフォーム「ALTER」など、自分たちのプラットフォームに名前をつけることで Platform チームと開発チームの双方が愛着を持てるようにしています。 ロゴまで作っているのは力の入れようが違います。
このブランディングによって社内でプラットフォームの認知が上がり、「他のチームが使ってる◯◯（プラットフォーム名）をうちでも使ってみたいんだけど」と相談しやすくなるんじゃないか、と考えています。 根拠が乏しいので、そうなってほしいなぁという願望に近いですが。
これから何ができるか
開発チームとの接点を見直す
SRE であれ Platform Engineering であれ、開発チームとどう関わるかが重要ということが分かりました。 今の活動の中での開発チームとの接点について振り返ると、十分なものになっていないかもと不安になりました。
Platform チームとして開発チームからの信頼を得られるように、まずは開発チームとの接点を見直してみようと思います。 そもそも今の立場でどこまでできるの？という悩みもあるけど、それは追々。
ブランディングを考える
現在携わっているプラットフォームはブランディングという観点では何もできていないことに気づきました。
ネーミングについては全体的な方針にも依るので個人の裁量で決められない部分もありますが、Platform チームとしての親しみやすさ・相談しやすさを高めるためにできることはないか考えてみます。
Enabling と Embedded の違いを理解する
Platform Engineering ではなく SRE の話。
自分の中で「Enabling」と「Embedded」というワードの違いがよく分かってないことに気づきました。 分かってないというか、理解しようとしてなかったというのが正しいかも。
セッションごとに使われているワードが違いますが、意図してそのワードを選択しているはず。 自分の中で Enabling と Embedded が曖昧になったまま話を聞いていたので、セッションで伝えたいことを正しく受け取れてない可能性もあります。 なので、両者の違いは言語化できるようにしておかなければ。
おわりに
SRE Kaigi 2026 に参加して、SRE チームが開発チームとどのように関わり、信頼関係を築いて SRE のプラクティスの導入を進めているのか学ぶことができました。
そのうえで、SRE との対比的な形で Platform Engineering についても自分なりの言語化をしてみました。 いやぁ、言葉にするのは難しい。 いかに日頃は曖昧な考えの中で Platform Engineering を捉えているかが分かりました。
現地参加したことでも熱量を持って帰ることができました。 早速仕事で活かしたいです。 SRE 界隈の方とはあまり面識がないのでボッチ感のある参加になると思っていたのですが、知り合いとも会えてお話しすることができました。 込み入った話ができたのも良かったし、偶然横に座って声を掛けてもらえたのも嬉しかったです。
杉田さんに登壇者紹介してもらえるのも羨ましかったです。 もし早見沙織さんに紹介されるチャンスがあれば絶対に登壇します。