以下の内容はhttps://namonakimichi.hatenablog.com/entry/2026/02/01/025854より取得しました。


SRE Kaigi 2026 に参加した

SREやその関連領域については、どちらかといえば参加者として情報をもっと得ていきたいと考えていたので、今年は一般参加して情報を収集することにしました。

午前は予定あったので午後から聞いています。午前1個聞きたかったものがあったけど、後で資料探そう…。

イベントページ

https://2026.srekaigi.net/

メモ

ブース

  • スタディストさんのブースのクイズが面白かった
    • AIで生成したロゴを当てる遊び
    • 終了後に QR コードからシェアできたのだが、QR コードが動的に変化するのが面白く、そういうのをちょっと作ってみたい気持ちになった
      • 小さいプログラムなので1, 2時間くらいあればできそう
      • 自分用の QR コードツールを自作してみるのも良さそう
  • ヘンリーさん主催の勉強会気になる
  • AEONさんの取り組みが面白かった、大きい食品物流を担う社会インフラの信頼性が強く求められるエンジニアリングを感じた
  • コドモンさんのノベルティの絆創膏、いい感じだった
  • SmartHRさんのノベルティ、どんどん増えていくアクセサリになっているのちょっと面白い
    • そのためのワイヤーが存在することを知った、手元にあるやつもうまく再生できそうな気がする
    • これちょっと個人的にいくつかほしい
  • Google Cloud Community Tech Surge 2026 気になる
    • 平日だけどオンラインなので休憩時間に少し聞くこともできそう
    • https://conference.findy-code.io/ から探せたが、なかなか見つけられずに苦労した
  • プレーリーカードさんではプレーリーカード持ってたのでネームホルダーをもらいました、気分に合わせてあとなんまいか作ってみようかな。年1で新しいものを作ってみるのも良さそう。

トーク

レガシー共有バッチ基盤への挑戦 - SREドリブンなリアーキテクチャリングの取り組み

資料を見つけました

https://speakerdeck.com/codmoninc/tackling-the-legacy-shared-batch-infrastructure-an-sre-driven-re-architecting-initiative

  • 現状がわからないところがあり、情報収集から進めていた
  • 要件を整理し、システム的にできること・できないことの整理
    • バッチシステムで高頻度に回っているものがあるが、今回脱却が難しいものもあった
    • 独自の作り込みを避けて、マネージドサービスの機能に寄せる
      • 単純で理解しやすい、誰でも対応しやすい環境づくり
  • バッチシステムに対する負荷テスト
    • ちょっとこれ深く聞きたかった、データ量の用意とか、計測方法とか
    • 割とざっくりな説明だったが、夜間バッチがクリティカルなサービスも世の中には色々あり、バッチの負荷テストの方法論や計測方法、分析方法についてはいろいろな可能性やディスカッションがありそう
      • 1つで4時間かかるバッチの測定とか、並列でバッチ建てる必要がありそうなので IaC 進んでないと環境の複製自体が難しそうだなとか
      • ここだけの話だけで1トーク分できそうな気がする

堅実なアプローチで対応しながらも、バッチの負荷テストを実施しているという点が個人的には興味深いポイントでした。

認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名のSREが200名のプロダクトエンジニアを支援

資料を見つけました https://speakerdeck.com/higuchi_takashi/sre-kaigi-2026-ren-zhi-fu-he-wozui-xiao-hua-suruobuzababiriteitoslonodao-ru-4ming-srega200ming-nokodoenziniawozhi-yuan

  • 社会インフラ企業になる=信頼性とアジリティの両立が不可欠
  • 200人40チームを4人のSREで支えている
  • SREロードマップを引き、あれこれ手当り次第やるのではなくゴールを決めてそこに向かっていくように進めている
  • RICE(Reach, Impact, Confidence, Effort)スコアを活用した優先度決定
  • SLOを広げていくために…?
    • なぜ必要なのかを CUJ(Critical User Journey)から考えて、SLO作成に活かす
    • SLOガイドブックの作成、ワークショップの実施
    • アプリケーションチームもSLOについて知り、活動してもらう

CUJ っていうのを知らなかったので勉強になりました。下記記事も似たような取り組みをしていて参考になりそうですね。

またワークショップの実施とかはかなり聞きそうな気がします。 話を聞く・共有してもらうだけではなかなか自分自身の頭では考えきれない部分もありますし、手を動かしてそのことについて人と議論することで見えてくるものも多く、学びが多そうです。

ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立

資料を見つけました https://speakerdeck.com/rvirus0817/huaindeinoheng-duan-sregatakumi-bygmotoqu-rizu-mu-sekiyuriteitokai-fa-supidonoliang-li

  • AI により攻撃手法も多様化している、サプライチェーンによる攻撃も増えている
  • プロンプトに対する特有の攻撃もあるので、AIで対策をしていく
  • SOC2 Type2 の対応?
    • そういうサービス統制に関する規格があるらしい
    • https://dev.classmethod.jp/articles/soc2_overview/ とかにざっくり概要が乗っていた
    • グローバル展開する際に説明や導入をするため、対応して置けるとかなり良いもの
  • SAST(静的解析)、DAST(動的解析)
    • ソースコード分析をするのがSAST
    • 稼働しているアプリケーションに攻撃を加えるのがDAST
  • Takumi がこのあたりかなりいい感じにカバーしている
    • (ブースの方の話になるけど)ClaudeCode と比べて、かなり性能が良い

SOC2 Type2 自体を知らなかったのですが、国際的なサービスを展開していくにあたっては結構重要視される内容なんだなと思いました。もう少し調べてみようと思います。

また SAST, DAST についても言葉を知らなかったので、これまで一緒くたにセキュリティ対策として扱っているもの、と思っていたものの解像度が少し上がり、得意不得意がある箇所があるのかなと思いました。 これからツール選定やツール名を見たときは、どういった部分に強みがあるのか、どういう分析方法をとっているのかを意識して見てみようと思います。

これってSRE?:いい部屋ネットを1,760%成長させた開発とインフラのコラボレーション

資料見当たらず…

  • リリースなどを更にやりやすくするためにリアーキテクチャした、という話だった気がする
  • 途中、移行しない機能整理として、利用率などをみてログイン機能を消した、という話が衝撃的だった
    • そもそもログインという処理は、認証認可・ログインセッションの管理・ステート管理・ストレージ管理の観点からも負荷が高い作業である
    • ただサービス性質的に実は利用率が低くて不要だった、という分析自体は本当に大事だと思う
      • ユーザージャーニーとか考えても、申込み時にわざわざアカウントを作って、となりにくいサービスモデルなので実際はユーザーの再分析とか行動の分析とか行った上で、不要と判断したのかなとか

機能の整理あたりのところが衝撃的すぎて、記憶が曖昧になっています。 資料が公開されたら見直してみようかな。

ベテランCTOからのメッセージ:AIとか組織とかキャリアとか気になることはあるけどさ、個人の技術力から目を背けないでやっていきましょうよ

資料を見つけました https://speakerdeck.com/netmarkjp/beteranctokaranometusezi-aitokazu-zhi-tokakiyariatokaqi-ninarukotohaarukedosa-ge-ren-noji-shu-li-karamu-wobei-kenaideyatuteikimasiyouyo

  • 心持ち的なフォローな話?だったように思う
  • 自分が比較すべきところは、世界でも社外の人でもAIでもなく、組織の中で少しだけ優れた人であること
    • いろいろなことを任せてもらえる責任感
    • いろいろなことに挑戦できる
    • そういった組織内の信頼が少しずつユニークでやりがいのある経験に変わっていく
  • 「ちょっとだけ突出した個になる」

戦略っぽい話?だったなあと思いつつ、改めて比較しても仕方がないところと比較しないというのも大事なのかなと思いました。

確かに社外や世界のエンジニアはすごいし、AIの速度や出してくるナレッジも強いので、自分自身の力や居場所を見失いがちですが、組織の中でしっかりと成果を出すリアルな向き合いが大事であるということを改めて感じました。

これまで自分が見てきた中で一番大きい変化の局面を迎えていると感じていますが、そういう中でも自分が組織の中でしっかりと手を動かして成果を出すことが大事であるということを改めて感じました。

ほか

SRE Kaigi 2026 延長戦 ~ ゆるSRE勉強会もあるよ! ~ というイベントもあるので、参加しようか悩む。

ハッピがあたったので家で使うかも。コースターもあたったので家で… なんかすごくあたってしまったけど大丈夫かな?

あと SRE のまんがもついてて良かったですね。 すごくわかりやすくSREが何をしているか? がわかりやすくて良かったです。 Toil の擬人化は… こわいですね。おすすめの書籍も乗っていたので、まずここに書いてある本を抑えておきたいですね。

まとめ

参加者視点で見て、色々知らなかったものやブースで色々やり取りができ、自分が今所属してる会社のことをもっと知らないといけないなという問題意識が生まれました。

大方針としてこうなっていくといいよね、というのはあるかもしれませんが、今回全体的に聞いている感じ下記の印象が強いです。

  • ビジネスやサービスが先に走っている(ビジネスの継続上必要である)
  • 走っていく中で認知負荷が高い作業が増えていく(引き継ぎ・メンテナンスがされてないものとか、新技術・セキュリティチェックなど)
  • 一旦現状について冷静に状況を整理
  • その上で少しづつ対応を開始、試行錯誤と失敗したものを小さくすぐ改善するを繰り返す
  • 組織として大きめの問題をだんだんと崩して、認知負荷を改善し、より良く早いアウトプットを出せる体制を整える

仮説もある程度立てつつも、現状がどうなっているかという事実に基づいた情報を集めることをまずは進めていきたいなと思いました。 幸いいろいろなことをしている組織ではあるので誰かが知ってるかもな〜と思ってはいるのですが、自分自身の視野を広げる意味でもそこのメリット・デメリットを正確に把握し、その後の改善を考えていきたいなと思いました。

今はインプットを増やしていきたいなと思ったので、大きくなっている組織のテックブログなどを参考に学習と、少しづつできそうなことから行動できるようにしていきたいと思います。

あとは去年SRE Kaigiは去年は当日スタッフとして参加しましたが、今はもう少し学びを深めたい時期なのかも、と思ったので余裕が出てきたら当日スタッフで参加してみるとかもしてみたいですね。




以上の内容はhttps://namonakimichi.hatenablog.com/entry/2026/02/01/025854より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14