はじめに
2026年1月31日、中野セントラルパークカンファレンスで開催された SRE Kaigi 2026 に、学生支援制度を利用して参加しました。
はじめまして、角鹿翔和（@t0waxx）です。情報工学を学びつつ、北海道を拠点に、研究・スタートアップ・学生コミュニティ運営（Q-PIT）・インターンを掛け持ちしている学生エンジニアです。
北海道からの参加ということもあり、学生支援で旅費までカバーしていただけたのは本当にありがたかったです。X でことみんさんの投稿を見かけたのがきっかけで、北海道から友人を一人誘って東京まで出向きました。
「SRE＝守る人」というイメージを持っていた自分が、現地でそれを完全に覆された話です。
聴いたセッションの感想
SREのプラクティスを用いた3領域同時マネジメントへの挑戦（川崎 雄太さん / ココナラ）
SRE・情シス・セキュリティという別々の職種を、SLO/SLI・ポストモーテム・エラーバジェットで横串に刺してマネジメントするという話でした。
聴きながら思ったのは、「このフレームワークが転用できるということは、もとのSREの概念が特定の技術領域に依存していないということだ」という点でした。エラーバジェットが「失敗をどこまで許容するか」の合意ツールとして機能するなら、情シスやセキュリティにも当然使えます。SREが汎用性を持つのは、本質的に 「測定と合意」の技法だからなのだと理解しました。
CISO/CIOへのキャリアパスという話も出ていて、技術職と組織設計職の境界が思ったより薄いことを知りました。
制約が導く迷わない設計（内藤 翔太さん / Dress Code）
マイナンバー管理という制約の多い題材で、「制約を洗い出す → 除外・比較で絞る」という手順を実演していました。制約の五分類（法令・ビジネス・技術・体制・運用）と、除外と比較という二つの効き方で選択肢を整理していました。
このフレームワークの価値が「正しい答えを出すこと」より「なぜこれを選んだかを後で説明できること」にあると感じました。設計の意思決定を後から言語化しようとして詰まる経験は何度もあります。制約を先に並べておけば、選択の理由が自動的に残るというところは真似したいと思いました。
ただ、制約を「正確に洗い出せる」前提には相応の経験が必要で、自分がいきなりこれをやろうとしたとき、「法令」と「ビジネス」の境界がどこかすら分からない場面が来そうだとも思いました。フレームワークを持つことと、それを使いこなすことの間には、まだ距離がありました。
SREとプロダクトエンジニアは何故分断されてしまうのか（渡辺 美希パウラさん / ワンキャリア）
「仲が良いのに業務では分断される」という問いの立て方が面白かったです。感情的な対立ではなく、構造として起きるという整理で、受発注関係の固定化・ベクトルのズレ・1対多の情報非対称という三要因が挙げられていました。
Reflecting → Mobilizing → Synthesizing というバウンダリー・スパニングのステップは概念として分かりやすかったです。
SLO定例とは、月1回程度、SLOの達成率をSREとプロダクトチームが一緒に確認する場のことらしく、「先月のエラーバジェット消費率は何%で、このまま行くと残りどのくらい」という数字を一緒に見るだけでも、「自分たちのサービスの状態」を共通認識にできます。意識改革や動機の醸成を先に求めるのではなく、「まず場を作る」こと。場を「設計」することで、動機より先に接点を作る——という逆転の発想が、一番実践的な部分でした。
Embedded SREの終わりを設計する（鷹箸 孝典さん / Sansan）
今回、最も長く考えさせられたセッションでした。
「いつまでこのチームにいるのか」という問いを支援の開始時点で設定し、Exit を設計しながら撤退する。Phase 1〜3 で段階的に自立度を上げ、Knowledge Transfer Matrix で測定する。構造として説明されると当たり前に聞こえますが、「Hope is not a strategy」という言葉が指している実態——なんとなく続けていれば成長するはずという空気感——は、支援の現場に普通に存在すると思います。
このセッションで考えたのは、支援の失敗パターンに二種類あるのではないかということでした。一つは「早く撤退しすぎる」失敗。もう一つは「いつまでもいてしまう」失敗。後者の方が発見しにくいと思います。支援が機能しているように見えながら、実は依存が深まっているだけ、という状態は、本人が気づかないまま続きます。そのために数値化が必要で、それが Knowledge Transfer Matrix でした。
Knowledge Transfer Matrix は、「誰が・何のタスクを・どの程度自分でできるか」を表にして自立度を可視化するものです。「説明を受ければできる」「一人でできる」「他者に教えられる」のような段階で測ることで、感覚ではなく数字として「まだ依存している」「もう手を離せる」が判断できます。SRE に限らず、支援役ならそのまま使える道具だと感じました。
「支援のゴールは自分が不要になること」——この一文の重さは、実際に誰かを支援する立場に立ってみないと分からないかもしれません。
SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル（川田 雅彦さん・久保 翔馬さん / イオンスマートテクノロジー）
フロントエンドエンジニアとインフラエンジニアという、もともとSREではなかった二人が、Enabling を受けて実践者になるまでの軌跡が語られていました。
「眺める会」の Phase 1→2→3 の進化が面白かったです。Phase 1 は「一緒に画面を見るだけ」、Phase 2 では「なぜこうなっているか」を話し始め、Phase 3 で初めて「自分たちで判断する」になります。いきなり「自律して動いてほしい」と言っても動けないのは、判断に必要な文脈が積み上がっていないからで、それを積み上げる場として「眺める会」が機能したのだと理解しました。
「転職を考えたほど不安だった」という正直な言葉も印象に残っています。壇上にいる人が今の姿になるまでに、相当の混乱があったと分かる話は、聞けてよかったですし、とても参考になりました。
チームを巻き込みエラーと向き合う技術（maruさん / LINEヤフー）
優秀すぎておこったサイクルのずれについてのお話でした。
SRE が優秀に動きすぎると、開発チームはエラーを「SREが何とかしてくれる」と思い始めます。速く回すほど不透明になり、不透明なほど当事者意識が失われます。SRE の「決めない・判断軸を渡す」という立ち回りは、この構造への意識的な抵抗だと理解しました。
「判断軸を渡す」とは、具体的な操作手順を指示することではなく、「どの状況を問題と見なすか」「何を優先して守るか」といった考え方の基準を共有することだと理解しました。SREがその場で正解を提示するのではなく、チームが自分たちで議論し判断できるための地図を先に置いておく。
セッションで語られていたのは、そういう役割の話でした。「正解を言う人より、問いと判断軸を用意する人の方がチームに効く場面がある」——ファシリテーションの話として聞いたことがありましたが、このセッションで「失敗の裏返し」として語られると、なぜそうなのかの理由が初めて腑に落ちました。
15年続くIoTサービスのSREエンジニアが挑む、可観測性向上（筧 万里さん・黒崎 耕平さん / パナソニック EW社）
「コストが想定の10倍になった」という数字が出た瞬間、会場の空気が一瞬引き締まっていました。
分散トレーシング導入の失敗が技術面・認識面で整理されていましたが、致命的だったのは認識面の失敗だったという話が核心でした。技術的には正しい判断をしていても、ビジネス価値として説明できなければ組織内で優先されません。「価値創出の時間」という指標を再定義してから再挑戦した、という話は、技術の価値を誰かに伝える言語を別に持つ必要があることを感じ取れました。
技術を「正しく作ること」と「組織に通すこと」は別の問題で、後者が先に失敗することがある——これは学生のうちはなかなか実感しにくい種類の話だと思うので、今のうちに聞けてよかったです。
クレジットカード決済基盤を支えるSRE（水口 洋介さん / スマートバンク）
PCI DSS という厳しい制約の下で、スコープ最小化・マネージドサービス活用・監査対応の3層自動化という方針が説明されていました。「監査＝年1回のイベント」ではなく BAU として組み込む、という一言が印象的でした。
FinTech は「規制が多くて大変」という印象でしたが、要求の多くがモダンな開発のベストプラクティスと重なるという話で、「制約の多い環境」と「良い設計の環境」が必ずしも対立しないと分かりました。制約が多いからこそ、設計の精度が上がる面もあるのかなと感じました。
セッション外で一番濃かった時間
会場の地下にふらっと降りたら、たこ焼き屋台が出ていました。（驚き）
そして、エンジニアの方と並んで食べることになりました。「さっきのセッション聴きました」と話しかけると、スライドでは省いた判断の経緯——「なぜあの設計でなくこちらを選んだか」——を話してもらえました。登壇後の本人から聞く「スライドの裏側」は、セッション本編とは別の密度がありました。
トイル撲滅ミッションで白熱した
ブースを回っているとき、トイル撲滅をテーマにしたエンジニアの方と議論になりました。
「どこまでをトイルと定義するか」という問いで、意見が分かれました。僕は「繰り返し発生する手作業全般」と答えたのですが、「価値を生んでいる反復はトイルではない」という返しが来て、そこから「価値の判断軸を誰が持つか」という話に広がっていきました。
僕は、開発環境のトイル撲滅として、NixOSを挙げておきました。
懇親会
懇親会では、「学生がSREになるには？」という悩みに、プロのエンジニアの方々が本気で向き合ってくれました。いろんな「正解」の形があることを知って、自分の将来に少し勇気が持てました。学生としてではなく、一人の「未来の仲間」として扱ってもらえたのが何より嬉しく、不思議な感覚でした。一緒に来た友人も同じように輪に引き込まれていて、帰り道ずっとその話をしていました。
同じように北海道の方とも交流できました。「地方のハンデ」みたいな話を一切しない方で、むしろその環境を面白がっているのが印象的でした。こういう人が北海道にもいると知れたのは、じわじわと効いてくる励みです。今後のカンファレンスなどの機会での再会が楽しみです。
SREは「守る人」ではなく「人と組織のハブ」だった
セッションを振り返ると、共通して出てきたのは「SREは答えを出さない」という姿勢でした。判断軸を渡す、Exitを設計する、当事者意識を広げる。SREが向いているのは、システムを守ることより、チームがシステムと向き合える状態を作ることだと僕なりに理解しました。
つまり、セキュリティ・情シス・開発チームなど「それぞれの正解」を持つ人たちの間に立ち、共通の言葉と判断軸を渡すハブになることです。「人と組織のハブ」という像は、技術力だけで説明できない役割です。どのセッションでも、SREが一番こだわっていたのは「誰と何を合意するか」でした。技術はその合意を支える道具として機能していました。
「守る専門家」という像は、この理解とはほぼ逆でした。影響力を広げるために存在感を消していく、という逆説的な構造がSREにあると、そう感じました。
そして正直に言うと、理解が深まるほど「自分がまだ何も分かっていなかった」という感覚も大きくなりました。SLOの設計、組織との合意形成、Exit の設計——どれも「概念は分かった、でも自分にはしっかりと時間をかけて詰んだ経験がない」という状態です。分かったつもりが増えるほど、見えていなかった輪郭が浮かんでくる。これが「深淵」の意味だったのかもしれません。
自分の開発にすぐ引き付けると、まずやることは一つに絞りました。OpenTelemetry でトレースとログを最初から仕込むことを、次のプロジェクトから最初のコミットに含めます。（ミニマムでも！）「動いたら後でログを足す」は、この記事を書いている今この瞬間もやっていた癖です。「見ようとする」を最初から設計に組み込む。それが今日の持ち帰りです。
おわりに
学生支援制度で参加の機会をくださった 一般社団法人クラウドネイティブイノベーターズ協会 様をはじめ、SRE Kaigi 2026の運営・登壇・ブース対応をしてくださった皆様に感謝します。
学生をはじめ、たくさんの方との交流が持てた一日でした。
壇上に立つ方々が、「こういうことをやった」だけでなく、「こう失敗し、どう考えて直したか」まで率直に語っていた姿が印象的でした。完成された成功談ではなく、試行錯誤の過程ごと共有する姿勢に、自分もそうありたいと思いました。
来年は、「こういうことをやりました」と話せる状態でショートセッションに応募したいです。
ありがとうございました！
付録：参加後のこと
当日は『わかばちゃんと学ぶSRE』もいただきました。あの「わかばちゃんと学ぶ」シリーズがもらえるとは——これも現地参加の特権です。帰りの飛行機でそのまま読み始めました。
後日、Road to SRE NEXT 2026 @札幌でLT登壇の機会をいただき、その場で SRE Kaigi 2026 実行委員会 委員長の井上さんにサインをいただきました。家宝です。
Discussion