先日、2026年1月31日に開催されたSRE Kaigi 2026のショートセッションにSREの木村が登壇しました。
本記事ではショートセッションに登壇した木村の登壇レポート、現地参加したメンバーの参加レポートをお送りします。
登壇レポート
SREの木村が、本イベントのショートセッションに登壇しましたので、その様子をご紹介します。
「30万人の同時アクセスに耐えたい！新サービスの盤石なリリースを支える負荷試験」木村奈美
こんにちは。SRE/インフラエンジニアの木村です。
今回ショートセッションにて貴重な1枠をいただくことができました。
ショートセッションの応募は 発表タイトルだけで選考される という思い切ったもので、私は「30万人の同時アクセスに耐えたい！新サービスの盤石なリリースを支える負荷試験」というタイトルで応募し、採択されました。
発表内容を考え始めた時点では、教科書通りの思想を並べており、自分自身の経験談があまり含まれていない内容でした。しかし、この「タイトルだけで採択された」という事実を思い出し、何を期待されて採択されたのだろうと考え直してみました。すると、「"30万人"という具体的な数字が含まれていることから、具体的なエピソードを期待されて採択されたのではないか？」という結論に至り、自分自身が実際に考えたことや体験したことを軸にして話す方向にシフトしました。
時間の制約もあり、さらに具体的なJMeterのテスト計画ファイル（.jmx）の設定などは紹介に至りませんでしたが、追って記事にする予定です。
発表後は、参加者の方から「Distributed Load Testing on AWS使いやすいですか？」と声をかけていただいたり、Xや参加レポートで感想を寄せていただいたりと、多くの反響をいただけて励みになりました。
参加レポート
当日参加したメンバーの感想と印象に残ったセッションをピックアップしてお届けします。
木村
感想
登壇者としてだけでなく、いち参加者としても楽しめたイベントでした。
特に今回は、過去に参加したイベントの中でも自分たちの状況に刺さるセッションが多かったです。
また、こういったイベントでは珍しい 託児所 やクローク、寒い時期にうれしい使い捨てカイロ、SREの理解を促すマンガ冊子 の無料配布など、より多くの人が参加しやすくなるようなサービスが充実しており、随所に運営チームやサポーターの皆様の思いやりを感じました。
印象に残ったセッション1: 「レガシー共有バッチ基盤への挑戦 - SREドリブンなリアーキテクチャリングの取り組み」
全体を通して非常に共感できるセッションでした。
GENDAでも、ブラックボックスな環境を理解し、モダナイゼーションしていく作業が必要となることがあります。M&Aによって未知のプロダクトが運用対象になり、その中にはレガシーなものもあり得る環境なためです。ブラックボックスをチーム全員で解き明かしていく方法は、ぜひ真似したいと思いました。
バッチサーバーをECSに移行した事例も参考になりました。私も過去に同様の課題にぶつかり、うまく解決できずにバッチ処理をEC2に残してきた苦い経験があります。自分自身の悔いの残る経験に対し、見事に解決された事例を教えていただいて、こんな活路があったのかと感動しました。ふたたび改修のチャンスがあれば今回の事例を参考にしたいです。
印象に残ったセッション2: 「学生・新卒・ジュニアから目指すSRE」
私と同じRoom Aでのショートセッションです。実は、登壇者の尾上さんとは2週間前に Road to SRE NEXT @京都 で同席していたことを登壇直前に知り、同じ部屋でショートセッションをする奇遇さに驚きました。
他のセッションで紹介された手法の多くは、ある程度の権限がないと実践できないものも多いのですが、本セッションではSREの業務を分解して若手メンバーが現実的に着手できる領域を提示しており、他のセッションとは異なる切り口の価値を提供していると感じました。新卒1年目でありながら、ここまで組織を俯瞰的に見て分析されていることにも脱帽です。
「意思決定を支援する」という点は、我々も他のチームのサポートをするうえで意識しています。一般的にジュニアメンバーには細部の作業をお任せすることが多いと思いますが、細部を見ているからこそ、意思決定の材料として渡せる情報があると思います。SREのみならず、すべての若手エンジニアに届いてほしい内容だと思いました。
大澤
感想
会場の熱気とセッションの質の高さに圧倒されつつも、各社のリアルな取り組みを聞くことができ、非常に学びの多い1日でした。
印象的だったのは「完璧を目指さず小さく始める」「認知負荷を下げる工夫をする」といった、現実的かつ実践的なアプローチを紹介するセッションが多かったことです。
GENDAのSREも少人数で複数のプロダクトを横断的に支援する立場にあるため、同じような課題感を持つ他社の事例は非常に参考になりました。 特に「いかに開発チームの認知負荷を上げずに新しい取り組みを導入するか」「完璧を目指さず小さく始めて改善を続けるか」といった考え方は、今後の活動に取り入れていきたいです。
印象に残ったセッション1: 「認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名のSREが200名のプロダクトエンジニアを支援」
SmartHRさんのSREチームは、4名で約40チーム、200名のエンジニアを横断的に支援するイネイブリング型の組織として、オブザーバビリティやSLOの策定に対してどのように取り組んでいるのかというセッションでした。
限られたSREチームの人的リソースを活かして、各プロダクトのエンジニアの認知負荷を上げずに、オブザーバビリティとSLOの導入にチャレンジしていくプロセスが非常に参考になりました。
特に、SREと開発チームのそれぞれの責任分界点を明確化するアプローチについて、文書化し、期待値を調整しているという点が良い取り組みだと感じました。
また、SLO導入にあたり、いきなりプロダクトの開発チームに対して、SLI/SLOの導入を推進するというのはハードルが高いため、「SLO導入ガイド」というドキュメントを準備し、エンジニアだけではなく、QAやPMなどの幅広い関係者に対して理解してもらう取り組みが素晴らしく、このセッションにおける考え方をもとに、自社における導入のあり方を考えていきたいです。
印象に残ったセッション2: 「小さく始めるBCP ― 多プロダクト環境で始める最初の一歩」
SREとしてBCPを意識した動き方や実例についてのセッションでした。
突如発生する災害に対して予測することは不可能であるという前提に、「完璧な復旧目標は求めない」方針として、復旧を優先するべきプロダクトの選定、現状の構成を変えずにDRを実装、最小限度の労力で訓練を行う手順を踏んでいるとのことで、非常に参考になる実例でした。
BCPの計画というと多くの考慮するべき条件を整理するという段階で非常に時間がかかってしまい大変ではないかという印象を持っていたのですが、最初から完璧を求めずに動き始めていくという姿勢がとても良かったです。
布田
感想
まだSREとしての経験は浅いですが、自分自身で積んできた経験もいくつかあったおかげで、SRE Kaigiから大きな学びを得ることができました。視点の解像度が上がったことで、他の参加者が抱える悩みをより身近に感じられ、今後は自身もどんどん発信していきたいと思います。
印象に残ったセッション1: 「IaaS/SaaS管理におけるSREの実践」
本セッションは、横断的な開発本部が抱えていた管理上の課題を具体的にどのように解決したかを示す事例紹介で、弊社と非常に似た環境で同様の課題を抱えていたため強く共感しました。
Ask the Speakerにも伺わせていただき、プロダクト側でユーザーの権限申請・承認が完結する運用において「横断的な組織がどこまでプロダクトを守るのか、そしてどのように守るのか」という、実務上の責任範囲と運用手法について詳しくお話を伺えました。「自由にやってよいが、異常には気づけるようにする」という方針は理念としては分かりやすいものの、具体的にどの範囲まで許容し、どのように検知・対応の責任を持たせるかは設計・運用が難しい点です。その “どこまで / どうやって” についての話がとても示唆があり今後のセルフサービス化を見据えた実務的な学びを得られました。
印象に残ったセッション2: 「予期せぬコストの急増を障害のように扱う――「コスト版ポストモーテム」の導入とその後の改善」
発表概要 | スライド
システム障害については監視・通知・対応フローが整備されていることが一般的ですが、コストに関しては「なんとなく増えてきた」「リリースで増えたけれど本当に正当か？」といった疑問が意外と精査されずに残ることが多いと感じています。「とりあえず運用して適正化を目指す」と口では言っていても、実際にはなかなか見直しが進まないこともあります。また、インフラに詳しい人が入って一時的に解決することはあるものの、その知見がナレッジとして残らず、プロダクトごとのコンテキストが大きく異なるため共有・再利用が難しいという問題もあると感じています。こうした事情が、コスト増の問題を解決しにくくしている要因だと思います。
本セッションで提案されていたポストモーテムの導入は、コストの急増を単なる「気づき」に留めず、原因分析と再発防止までつなげる有効な手段だと感じました。特に少人数で複数プロダクトを支える状況では、ポストモーテムを通じたナレッジ蓄積とイネーブリング（再現可能な対処法 / ドキュメント化）が重要になります。今回の内容は、我々が今後コスト管理を組織的に整備していくうえで大いに参考になるものでした。
弓場
感想
SREではなくプロダクト開発を行うエンジニアですが、SRE Kaigiに参加しました。SRE Kaigiでの発表内容は自分自身が知らなかった知見やSRE以外のエンジニアでも参考にできる部分が沢山あると感じました。
また、技術イベントとしての設計がよくなされており、発表ブース、スポンサーブース、懇親会など含めとても体験の良いイベントでした。
印象に残ったセッション: 「SREとプロダクトエンジニアは なぜ、分断されてしまうのか」
SREとプロダクトの実装に関わるエンジニアがなぜ分断されてしまうのかという内容についてのセッションでした。
スライドにも記載されているSREとプロダクトサイドのエンジニアの関係性については、オフライン会場の聴講者数が多かったことからも、似たような課題感を持っている人は多いのではと感じました。
発表の中でブロードリスニングを用いた、受発注の関係をやめて、知識の同期を行っていくSREのプラクティスやReflecting（反射）とSLI/SLOの策定やフィードバックループを行っていくMobilizing（結集）は各個人の中で持ち帰って小さなことから行っていける方法だと感じました。
「インフラはSREに任せよう・・・」「SLI/SLO、 SREプラクティスって何？」という状態にプロダクト開発を担うエンジニアがなってしまわず、お互いに歩み寄ってコミュニケーションを取り、ユーザーに価値を届けるアプリケーションを作っていくことが大事だと思いました。
おわりに
今回のSRE Kaigiも多くの学びを得られるイベントでした。
引き続き、自社が学んできたことや得られた知見は登壇という形で技術コミュニティに還元していきたいと思います。
Discussion