こんにちは！株式会社スタメン、プラットフォーム部のもりしたです。
7月10日（金）・11日（土）の2日間、東京のTOC有明で開催された SRE NEXT 2026 に参加してきました！
昨年の SRE NEXT 2025（昨年のブログはこちら）ではLOGOスポンサーとしての参加でしたが、今年はSILVERスポンサーとしてブース出展を行いました。
本記事では、ブース企画の様子と印象に残ったセッションについてレポートします。
SRE NEXT 2026 の雰囲気
昨年に引き続き、TOC有明での開催でしたが、ブース会場の部屋が変わったこともあってか、昨年よりも広く感じました。
公式の来場者数は確認できていませんが、昨年と比べて参加者が増えた印象で、ブース会場全体に活気がありました。
懇親会は昨年と同じ会場でした。
食事もお酒も充実しており、楽しい時間を過ごせました。
スタメンのブース出展
SRE関連カンファレンスでのスポンサーは、今年5月に名古屋で開催した クラウドネイティブ会議 に続き2回目です。
2日間で約 180名 の方にお越しいただきました！
カンファレンス中の運営メンバーはすべて東京本社で働いているスタメンのエンジニアです。写真には載っていないメンバーを含めて、合計 6名 でブースを運営しました。
ブースに設置したパネルはデザイン部が担当。複数の部署が協力してカンファレンスの準備を進めています。
ブース企画：アンケートに答えてスタメンオリジナルのノベルティをGETしよう！
ブースでは、アンケートにお答えいただいた方にスタメンオリジナルのノベルティをお渡しする企画を実施しました。
ノベルティ
- キーキャップキーホルダー（スタメンの s, t, m, n の文字入り）
- スタメンロゴ入りマイクロファイバークロス
アンケート結果
アンケートは2問で、以下のような結果になりました。
Q1. 今年カンファレンスに参加した回数は？
| 選択肢 | 結果 |
|---|---|
| 2〜3回 | 🥇 1番多い |
| 1回（SRE NEXT 2026 が初） | 🥈 2番目に多い |
| 4〜5回 | 🥉 3番目 |
| 6回以上 | 4番目 |
1月に開催された SRE Kaigi 2026 に参加され、今回の SRE NEXT 2026 が2回目という方が多かったです。中には クラウドネイティブ会議にも参加されたという方もいらっしゃいました。
Q2. あなたの組織の「SRE」の現状は？
| 選択肢 | 結果 |
|---|---|
| 独立したSREチームがある | 🥇 圧倒的に多い |
| 各開発チームにSRE担当がいる | 🥈 2番目に多い |
| これからSREを立ち上げる・検討中 | 🥉 3番目 |
| SREチームの立ち上げ予定がない | 4番目 |
SREのカンファレンスということもあり、「独立したSREチームがある」が圧倒的に多い結果でした（笑）。
「各開発チームにSRE担当がいる」は 『独立したSREチームも別にあるんですよね』というお話をいただくことが多く、開発チームにSRE担当がいる場合でも、横断的なSREチームが存在するケースが多いと感じました。
「SREチームの立ち上げ予定がない」は、エンジニア組織の規模的にSRE相当の役割を兼務で担っているケースや、SRE立ち上げの支援を行っている企業のため自社にはチームがないというケースがありました。
学びがあったセッション
Day1・Day2 を通じていくつかのセッションを聴講しました。
すべて学びがありましたが、それぞれ1つずつピックアップしてご紹介します。
Day1：ABEMAにおける Incident Management 再設計
株式会社AbemaTV SRE/EM 宮﨑 大芽さんによるセッション speakerdeck.com
障害対応自体は回っているものの、「誰が指揮をとるのか」「役割が明確でない」といった課題を抱えていた AbemaTV 社が、Incident Management を再設計した事例のお話でした。
障害対応に関わる定義の明確化や、障害対応をサポートする Bot のブラッシュアップが紹介されました。
Bot では SEV（Severity：障害重大度）判定を直感的に行える仕組みが導入されるなど、実践的な改善が印象的でした。
特に心に残ったのは、「仕組みを提供しただけでは組織に浸透しない」 というお話です。
Incident Commander の役割を明確に定義したにもかかわらず、実際に障害が発生すると、メンバーは慣れた動き方でぱぱっと対応を進めてしまい、再設計した定義に沿った動きにはならなかったそうです。
私自身も昨年、障害対応の流れや Incident Commander の担当ルールなどを整理した障害対応マニュアルを作成しましたが、現実にはその通りに運用できていない部分があります。
組織への浸透の難しさ、そして難しくても地道に浸透させていくことの大切さに改めて気付かされたセッションでした。
Day2：SREとQA、二人三脚で進めるSLO運用
株式会社estie SRE 杉田 毅博さんによるセッション speakerdeck.com
マルチプロダクト体制への移行期に障害が多発する中、SRE と QAE（QA Engineer）が協力して CUJ（Critical User Journey）を定めた事例のお話でした。
発表タイトルは「SLO運用」でしたが、セッションの内容は CUJ の整備と SRE・QAE の協力体制が中心でした。
SRE と QAE は同じ「顧客価値」という目標を異なる視点から見ており、協力し合うことでお互いの強みを活かし、品質を高めていけるという内容に学びがありました。
この事例では、Platform 型の SRE は多くのプロダクトを横断的に見ているため、個々のプロダクトへの理解は深くありません。
一方、QAE はプロダクトのチームに深く入り込み、CUS（Core User Scenarios）という最重要ユーザーシナリオをチームとの合意のもとに作成していました。
SRE は QAE と協力して CUS の中から最も重要なものを CUJ として選定することで、本来最も難しい「チームとの合意」を経た CUJ を整備することができたのです。
私自身もこの事例の Platform 型 SRE と同様の立場にあり、プロダクトに深く入り込めているとは言えません。
深い知見はプロダクト開発メンバーや QAE の方が持っています。
互いの強みや視点の違いは対立するものではなく、補完し合うもの。1つのチームに閉じていたら進まなかった課題も、チームを越えた協力で解決できるという学びを得たセッションでした。
ブース運営を経験して
私自身は今年に入って RubyKaigi 2026、クラウドネイティブ会議、そして SRE NEXT 2026 と、7月時点で3回のブース運営を経験しました。
長くエンジニアをやっていても、ブース運営の経験がある人は意外と少ないのではないでしょうか。今年だけで3回も担当できたことは、とても貴重な経験だと感じています。
普段お話しする機会のない他社のエンジニアや学生の皆さんとの会話はいつも楽しく、よい刺激をいただいています。
さいごに
SRE NEXT 2026 では、ブース出展を通じて多くの方と交流でき、セッションからも実践的な学びを得ることができました。今回の学びを日々の業務に活かし、スタメンのプラットフォームをより信頼性の高いものにしていきたいと思います。
今回レポートした Site Reliability Engineer (SRE) や Platform Engineering の領域にご興味のある方は、ぜひご応募ください！
