SRE Kaigi 2025に続いて今年も参加してきました。去年の記事はこちら。
去年と同じ1日開催で会場も去年と同じ中野、特に戸惑うことなく参加できました。いつも通り印象に残ったセッションのことを書き連ねていきます。当日の勢いのまま公開したいので一旦公開しますが、後でスライド見て足すかもしれません（足したらXに書きます）。
もくじ！
個別セッションの感想
「30万人の同時アクセスに耐えたい！新サービスの盤石なリリースを支える負荷試験」
※資料週明けに公開されるとのことなので公開されたら貼ります
共通ポイントサービスの負荷試験を題材に、負荷試験で意識しておくべきポイントをまとめたショートセッションでした。内容が自分で負荷試験やるときに考えていることとほぼ合致してて、「このスライド公開されたらこのまま負荷試験のガイドラインとしてチームの人に渡そう～」って思うぐらい。たとえばAWSだったらトラフィックをインターネットに出さずVPC内で完結させましょうねとか、「負荷試験やりました、大丈夫でした！」じゃなくてきちんと報告するまでが負荷試験ですよねとか。
あと結構見逃しがちなのがタイムアウト周りだとか。
「10秒かかって200 OKが返ったとしてそれは耐えたと言えるのか？」タイムアウト値の設定見落としがち #srekaigi_a
— karia (@karia2nd) 2026年1月31日
こういった発表を通じて負荷試験がもっとエンジニアの共通スキルになっていくと良いなと思いました。
「クレジットカード決済基盤を支えるSRE - 厳格な監査とSRE運用の両立」
自分は監査対応に関わった経験が比較的浅く、監査の話聞きたいなと思って聞きに行ったのですが、実務的な話よりも「なぜSREが監査対応するのか」のほうが印象に残りました。ポジティブな関わり方として言語化しているのが良かった。
そうそう、言われたからやってるとかじゃなくて、SREとしての普段の仕事の積み重ねが結果として監査対応に効いてくると良いよね。
「全ての仕事に対してこういうスタンスでありたいよね～」と書いたところで（別のセッションですが）このツイートを思い出した。
「SREは役職ではなく魂！」 #srekaigi #srekaigi_b pic.twitter.com/38vBGlswpE
— Yoshi Yamaguchi (@ymotongpoo) 2026年1月31日
SREは役職ではなく魂、分かりすぎる。SREというポジションが存在するんじゃなく、システムや仕事そのものについての考え方、プラクティスなんだよね。
「M&A 後の統合をどう進めるか ─ ナレッジワーク × Poetics が実践した組織とシステムの融合」
この記事をお読みの全国3500万人のエンジニアの皆さんは、「合併対応」というものを経験したことが人生に一度や二度はあるかと思います。
M&Aの話聞く。「M&Aの経験者いますか」と聞かれたので一応手を上げた #srekaigi_a
— karia (@karia2nd) 2026年1月31日
しかし思い返してみると合併対応というものは経営レベルで決定され、ある日突然現場に降ってくるものであります。ということで今後そのようなことが発生したときに備えようと思ってこのセッションを聞きにいきました。1つ前の監査の話もそうだけど、自分の経験が薄めの分野の話を聞きに行くのは楽しいよね。
印象的な点としては、最初からワンチームにするぞという目標設定が明確に示されている点が良いなと思いました。システムの融合は時間がかかるから、融合するのは先に組織で次にシステムの順なんだよね。しかしかなり早い段階でリポジトリをモノレポに統合しているのが凄いですね。Git Subtreeを使ってスッと統合できるのね。
以下余談。現場でこのようなツイートをしたのですが、
Project Uniteかっこいい #srekaigi_a
— karia (@karia2nd) 2026年1月31日
家に帰ってから去年の記事を読み返したら『一番良かったのが「竹を割ったような美しいサービス分割からProject bambooと名付けました」ってところ』と書いていたのを思い出しました。カッコいい名前は重要。
全体を通しての感想
たまたま自分が参加したセッションが偏っているだけかもしれないけれど、SRE Kaigiは実践寄りなセッションが数多く聞けるのが良いなと思います。セッションを通して普段の仕事にない分野の知識を積んだり、なぜそれをやるのかを言語化したり、そして懇親会で交流したり。今後も参加し続けていきたいですね。
あと懇親会で「Xで実況してた方だ～」って言われたのも覚えてます。みんな実況しようよ！！
