SRE Kaigi 2025 参加レポート

# はじめに
私は株式会社GENEROSITYのSREエンジニアです。
今回2025/01/26に開催された`SRE Kaigi 2025`というイベントに参加しましたのでレポートにまとめます！
少しでもSREについて知見を増やしたい！という思いで参加しましたが、有益な情報がたくさんあり、また新たな発見もたくさんありました。

Xで[@srekaigi](https://x.com/srekaigi)というアカウントがありますので、そちらもご覧ください。

# SRE Kaigi 2025とは
以下[SRE Kaigi 2025公式ページ](https://2025.srekaigi.net/#about)引用です。
> SREは世界的に注目され続けている領域であり、現場によって抱える課題や取り組みはそれぞれ異なります。
> そうした多様な事例から得られた知見を共有する場は、まだまだ不足している現状です。
> 
> 「さらにSREに関わる技術者の活躍の場を増やすため」
> 「さらにSREを理解し、興味を持っていただける技術者を増やすため」
> 
> この2つの“More”を目指し、参加者の皆様とコミュニティをより盛り上げていけたらと思います。

# こんな人に読んでほしい
- SRE初心者の人
- SREベテランの人
- SREに興味がある人
- SRE Kaigiに興味がある人

# 登壇資料まとめ
各セッションについてまとめます。
[公式タイムテーブル](https://2025.srekaigi.net/#timetable)から、各セッションの概要が確認できます。
登壇者の方が公開されている各セッション資料を載せますのでご覧ください。(資料が展開されていない場合は概要のみ載せています。)

[Re:Define 可用性を支えるモニタリング、パフォーマンス最適化、そしてセキュリティ](https://speakerdeck.com/pyama86/re-define-ke-yong-xing-wozhi-eru-monitaringu-pahuomansuzui-shi-hua-sositesekiyuritei)
<details><summary>概要</summary>

SREは、システムの安定運用だけでなく、幅広い技術的な課題に対応する責任を持ちます。このセッションでは、モニタリング、パフォーマンス改善、そしてセキュリティの観点から、SREがどのようにシステムの信頼性を確保すべきかを体系的に解説します。システムの健全性を把握するためのモニタリング手法、パフォーマンス最適化に必要な実践的なアプローチ、さらにセキュリティ対策を通じて可用性を守るための戦略を取り上げます。特定のツールに依存せず、柔軟な運用方法と幅広い適用可能性を意識した内容を提供します。SREとして直面する日常の課題を深く掘り下げ、より包括的な視点での実践的なアドバイスを得ることができます。
</details>

[Site Reliability Engineering on Kubernetes](https://speakerdeck.com/nwiizo/site-reliability-engineering-on-kubernetes)
<details><summary>概要</summary>

Kubernetesを基盤とした現代のシステム運用において、SREの実践は重要な役割を果たしています。本セッションでは、オープンソースツールを活用してKubernetes上に信頼性の高いインフラストラクチャを構築し、組織全体のソフトウェアデリバリーを加速させる方法を探ります。Helm、Tekton、Argo CD、Crossplane、Knativeなどの主要ツールの統合方法や、運用効率を高めるアプリケーションの設計、マルチクラウド戦略の実装、プログレッシブデリバリーの実現方法について具体的に解説します。これらの技術と手法を通じて、開発チームと運用チームの連携を強化し、システムの信頼性を向上させながら、ソフトウェアデリバリーの効率を大幅に改善する方法を学びます。さらに、SREの効果を測定するためのメトリクスと、継続的な改善サイクルの確立方法についても触れ、長期的な運用戦略を提示します。また、Kubernetesが適さないケースについても議論し、適切な技術選択の重要性を強調します。
</details>

[SRE、開発、QAが協業して挑んだリリースプロセス改革](https://speakerdeck.com/nealle/sre-kai-fa-qagaxie-ye-sitetiao-ndaririsupurosesugai-ge-at-sre-kaigi-2025)
<details><summary>概要</summary>

株式会社ニーリーは、月極駐車場のオンライン契約サービス「Park Direct」を提供するスタートアップ企業です。約2年前まで、Park Directの本番リリースは2週間に1度の頻度で行われ、必ずサービスのダウンタイムを伴っていました。また、変更による障害率も高い状態でした。
しかし、SRE、開発、QAのチームが協業して改善に取り組んだことで、現在では毎日複数回のリリースが可能になり、また、変更障害率も大幅に下げることに成功しました。
このセッションではこうした改善をおこなうために実施したプラクティスとその歩みついて紹介します。
</details>

可用性とコストのリバランス：テレビ砲の過負荷へ対応した話と増強したリソースを適正化した話
<details><summary>概要</summary>

トラフィック急増によるサーバーの可用性低下に対する応急対応と、その後の恒久対応およびコストの適正化について発表します。

弊社が開発している金融アプリBloomoは、リリース直後にテレビ番組WBSにて紹介いただけました。テレビの影響は我々の予想を遥かに超え、トラフィックの増加による過負荷でサーバーへ繋がりづらい状況が続いてしまいました。

インシデント対応後の安息も束の間で、今度はコストが問題となりました。インシデント対応としてリソースを増強した結果、コストが予算の数倍まで膨れ上がってしまったためです。しかしながら、リリース前に実施できていた負荷試験は部分的で、削れるリソースがどこにあるのかわからない状況でした。

本発表の前半では、インシデントの止血や追加の対応などについて、どのような状況だったかをお話しいたします。後半では肥大化したリソースとコストをなるだけ早く適正化するために実施した取り組みについて紹介いたします。
</details>

[実践: Database Reliability Engineering ~ クラウド時代のデータベースエンジニアの役割 ~](https://speakerdeck.com/_awache/srekaigi)
<details><summary>概要</summary>

日本ではまだ馴染みの薄い DBRE。
おそらく DBRE ってそもそも必要なのか？やろうとしてもどうやって始めたらいいの？具体的に何をやっているの？という方が数多くいると思います。
このセッションでは私たちはなぜ DBRE という道を選んだのか、DBRE は何をしているのか？について実践的な内容を含めて共有させていただくことで皆様の疑問にお答えします。

具体的には下記を提供することで参加者の皆様に下記を通じて DBRE の実践を感じ取っていただきます。

- DBRE は自分たちに本当に必要なのか
- DBRE の目標、ゴール設定はどのように定義しているのか
- プロジェクトの進め方はどのようにしているのか
- 実際のアウトプットのデモ

ここまで聞くと、DBRE ではないけれど、実は自分たちも同じような仕組みを構築している、自分たちも同じようなプラットフォームが欲しい、という共感を持っていただけるかもしれません。
そんなあなたはもう DBRE です。
ぜひ日本の DBRE も一緒に盛り上げて行きましょう。
</details>

[一人から始めたSREチーム3年間の歩み -求められるスキルの変化とチームのあり方-](https://speakerdeck.com/vtryo/how-to-start-sre-in-a-product-team-all-by-yourself)
<details><summary>概要</summary>

2021年、一人でプロダクトSREの取り組みを開始しました。
それから3年が経過し、プロダクトやチームの成長に伴って求められるSREのスキルセットの変化や、SREのあり方自体にも大きな変革がありました。
本セッションでは、一人SREから始まり、サービスの成長と組織の変化でどのようにSREも変化していったか。60以上のサービスが直接的、間接的に連携し合う規模の環境ならではのSRE活動の特徴も踏まえて紹介します。
</details>

[サービスローンチを成功させろ！〜SREが教える30日間の攻略ガイド〜](https://speakerdeck.com/mmmatsuda/sabisurontiwocheng-gong-sasero-sregajiao-eru30ri-jian-nogong-lue-gaido)
<details><summary>概要</summary>

サービスの信頼性を担保するためにSREがやるべきことは多岐にわたります。そんな中、ローンチまで限られた時間しか与えられなかった場合あなたは何を優先しますか？

このセッションでは、もともと関わりがなかったサービスのローンチ1か月前にEmbedded SREとして参加したスピーカーが、自身の実体験を基に、短期間で新規サービスの信頼性を確保するための具体的なアプローチや戦略を紹介します。限られた1か月の間に、SREとしてどのように優先順位を決め、サービスを成功させるための行動を取るのか、どのようなツールや手法を使って問題を予測し解決するのかを具体例を交えて説明します。特に、モニタリング、インシデント対応、負荷試験、セキュリティ対策、コスト最適化戦略、などに焦点を当てます。
</details>

[もっとSREの裾野を広げるための初学者向け技術研修設計](https://speakerdeck.com/kesompochy/motutosrewoguang-kerutamenochu-xue-zhe-xiang-keji-shu-yan-xiu-she-ji)
<details><summary>概要</summary>

人間は、高いスキルを持って生まれるわけではありません。ソフトウェア技術者としてキャリアを始める人たちは人間です。そのため、ソフトウェア技術者が高いスキルを持つに至るには鍛錬や教育が必要です。
SREという領域においても同様です。何もせずに高い技術力を持ったSREが生えてくるならばどんなによかったでしょうか。

このセッションでは、技術組織における効果的なSRE研修の設計・実施方法を議論します。特に新卒エンジニアに向けた研修に焦点をあてながら、私が実際に提供したSREに関する技術研修の内容とその結果を紹介します。また、新卒エンジニアとしてSREロールを与えられた話者の視点から、SREの知識や技能を習得するにあたって有用だったことと苦痛だったことを説明しながら、初学者に対してSREの思想を導入するための設計アイデアを議論します。
</details>

[SIEMによるセキュリティログの可視化と分析を通じた信頼性向上プロセスと実践](https://speakerdeck.com/coconala_engineer/siemniyorusekiyuriteirogunoke-shi-hua-tofen-xi-wotong-zitaxin-lai-xing-xiang-shang-purosesutoshi-jian)
<details><summary>概要</summary>

昨今、DDoS攻撃や不正アクセスなど、Webサービスが攻撃にさらされる機会は増加の一途を辿っています。
セキュリティ運用の温度感は高くなっており、SREチームが兼務している企業も少なくないのではないでしょうか。

一般的なセキュリティ対策として、問題特定や予兆検知に用いるセキュリティログ管理が重要です。
セキュリティ領域でのログやイベント管理をSIEMと呼びます。

ココナラではセキュリティチームだけでなく、SREチームもセキュリティ運用に取り組んでいます。
以前は何も動けていませんでしたが、今では日々のメトリクスモニタリングに運用を組み込み、信頼性向上に寄与しています。

セキュリティ運用整備をSREチームがやることで信頼性向上に繋げた事例や、SIEM運用のつまづき・メリット / デメリットを紹介します。
この発表でチームの垣根を超えた信頼性向上の取り組みやSIEMのノウハウを得られると幸いです。
</details>

[ブロックチェーンR&D企業におけるSREの実態](https://speakerdeck.com/datachain/sre-kaigi-2025)
<details><summary>概要</summary>

Datachainは、より多くの資産が様々なブロックチェーンネットワークでデジタル化される時代に向けて、インターオペラビリティ（相互運用性）を「技術」によって実現し、世界をあたかもひとつのネットワークとして扱えるインフラを開発しています。
現在、これまでのR&Dの成果を活かし、グローバルな取引の常識を変える下記の二つの事業に取り組んでいます。

- 国際送金の決済ソリューション
- クロスチェーンブリッジ
  - 異なるブロックチェーン間で簡単にデジタル資産を交換できる仕組み

この発表ではクロスチェーンブリッジを実現するTOKIを具体例に、ブロックチェーン x R&D x SREというまだ事例の少ない領域におけるSRE実装事例をご紹介します。
</details>

[信頼性を支えるテレメトリーパイプラインの構築](https://speakerdeck.com/ymotongpoo/building-telemetry-pipeline-with-opentelemetry)
<details><summary>概要</summary>

SREにおいて、信頼性そのものあるいはその回復のためにオブザーバビリティは最重要要素の1つです。オブザーバビリティの構成要素にはテレメトリーシグナルがありますが、その獲得にはテレメトリー取得に必要な計算リソースの確保、アプリケーションに影響を与えない構成、障害時におけるシグナルの喪失の回避、データポイントを保持するコストなど、数多くの懸念点があります。

本セッションではオブザーバビリティの中でも、OpenTelemetryを中心としたテレメトリーパイプラインの構成パターンを検討します。さらに、各構成パターンにおける利点や欠点、検討事項を確認し、みなさんのシステムにおいてより良いテレメトリー取得のためのきっかけを提供します。
</details>

[インフラコストとセキュリティ課題解決のためのリアーキテクチャリング](https://speakerdeck.com/hgsgtk/srekaigi2025)
<details><summary>概要</summary>

サービス信頼性向上の為のボトルネックは、サービスのアーキテクチャ自体の見直しなくしては解消できないことがあります。

品質保証エンジニアリングプラットフォームAutifyのSREチームは、プロダクトのコアに手を入れなくても最適化できるコスト効率化を終えた後、コスト効率化・潜在的なセキュリティ課題解消のため、Kubernetesへの移行、Karpenterの導入、MLワークロードが稼働するGKEクラスターの運用改善、そして、SPOFを解消するリアーキテクチャリングに取り組みました。

テスト自動化ツールのインフラストラクチャは典型的なWEBサービスとはトラフィックやスケーリング要件が異なるため、教科書通りのクラウドネイティブ技術の適用では収まらない面白みがあります。本セッションで紹介される事例は、独自性のある事例であるともに、様々なサービス開発現場で再利用可能なナレッジとなるでしょう。
</details>

[どうやればインシデント対応能力を鍛えられるのか？](https://speakerdeck.com/takaishi/sre-kaigi-2025)
<details><summary>概要</summary>

Site Reliability Enginneringに関する重要なトピックの一つにインシデント対応（障害対応）があります。サービスの開発・運用において、インシデント発生時には迅速かつ効果的な対応が求められるため、インシデント対応能力の向上は非常に重要です。本セッションでは、個々のエンジニアがどのようにしてインシデント対応能力を高めることができるかについて紹介します。インシデント対応能力を「ハードスキル」や「ソフトスキル」、「対応経験」、「システム理解」、「ツールや仕組み」など複数の要素に分け、それぞれの要素がどのように相互に影響するのか、それぞれの要素をどのように向上させることができるのかを考察します。このセッションを聴講することで、聴講者が自身のインシデント対応能力を向上させるための方法を学べます。
</details>

[横断SREの立ち上げと、AWSセキュリティへの取り組みの軌跡](https://speakerdeck.com/rvirus0817/heng-duan-srenoli-tishang-geto-awssekiyuriteihenoqu-rizu-minogui-ji)
<details><summary>概要</summary>

Flatt Securityは「エンジニアの背中を預かる」をミッションに、開発組織におけるセキュリティを支援しています。
中でもAWS等クラウドのセキュリティ運用においては、セキュリティ機能を有効化しているものの運用体制が形骸化してしまう、人的・時間的リソースが限られており運用が難しいなどの課題も多くいただきます。

本セッションでは、Flatt Security CTOの米内が、FindyにてSRE組織の立ち上げからAWSのセキュリティ体制構築を推進されている安達氏に、Findyが直面するAWSのセキュリティの課題をどう解決しようとしているか。脆弱性診断SaaS「Shisho Cloud」を活用した取り組みや今後の展望を伺うことで、SRE組織がAWSセキュリティに取り組む際の第一歩について考えます。
</details>

インフラおじさんがSREになるお話
<details><summary>概要</summary>

1年半前、開発部内ではSREがインフラ専任の役割という印象がありました。しかし、そこからEmbedded SREとして開発チームと連携し、SREの文化を浸透させる取り組みを始めました。その後、全社のSREから独立した、開発部のSREチームを立ち上げ、オブザーバビリティの導入やインフラ管理のイネイブリングを進めてきました。また、システムの信頼性を高めるためにSLI/SLOを導入し、開発と運用の両面から品質向上に取り組んできました。本発表では、これまでの取り組みの成果と課題、そして今後の展望についてお話しします。
</details>

[Improving Incident Response using Incident Key Metrics](https://speakerdeck.com/nari_ex/improving-incident-response-using-incident-key-metrics)
<details><summary>概要</summary>

SREの提唱をきっかけにポストモーテムカルチャーが浸透しはじめ、個々のインシデントに対する改善が進みつつあります。一方で、インシデント対応のプロセス全体の改善にはなかなか着手できていない組織が多いのではないでしょうか。

本講演では、データドリブンなアプローチを用いたインシデント対応プロセスの改善手法について解説します。
具体的には、ベストプラクティスに基づてインシデント対応プロセスにおける各マイルストーン（発生→検知→認知...）を整理し、各フェーズ間でのTTXメトリクスの活用方法を説明します。

また、システムの迅速な復旧だけでなく、組織間の連携や顧客とのコミュニケーションも重要であることにも触れながら、インシデントコマンダーやコミュニケーション担当（Liaison）など、さまざまな役割にも焦点を当てつつ、組織全体のインシデント対応能力を向上させるためのアプローチを提案します。
</details>

[ガバメントクラウドに向けた開発と変化するSRE組織のあり方](https://speakerdeck.com/kazeburo/development-for-government-cloud-and-the-evolving-role-of-sre-teams)
<details><summary>概要</summary>

さくらインターネットの「さくらのクラウド」は2023年度にデジタル庁が募集したガバメントクラウドに2025年度末までに全ての技術要件を満たすことを前提に認定されました。2024年9月現在、デジタル庁の技術要件を満たすため、パブリッククラウドとしての機能強化とサービスの開発に取り組んでいます。
数多くの技術要件を満たすために、開発力の大幅な強化とエンジニアリング組織の拡大、また一人一人のメンバーの変化と成長が鍵となっています。

さくらインターネットのSRE室はクラウドサービスの信頼性向上とそれによる価値提供を目的に設立したチームですが、大規模な開発の中で役割を変化させてきています。
本セッションでは、大きなチャレンジをする開発組織とSREのあり方の一つの事例として紹介するとともに、議論のきっかけとなれば幸いです。
</details>

[SREじゃなくてもできる！インシデント対応で鍛えたCREチームの5年史](https://speakerdeck.com/mayuzo/five-year-history-of-cres-hard-work-in-incident-response)
<details><summary>概要</summary>

「ANDPAD」は現場の効率化から経営改善まで一元管理できるクラウド型建設プロジェクト管理サービスです。主に建築・建設業界向けに適切なソリューションを提供するためマルチプロダクト戦略を展開しており、導入社数の増加とともにプロダクト数も増えています。
障害発生時のインシデント指揮や障害収束後のポストモーテムの取りまとめは一般的にSREが担当することが多いですが、アンドパッドではそれをCRE（Customer Reliability Engineer）が担当しています。より顧客に近いCREが担当することで、インシデント発生時のコミュニケーションの円滑化やプロダクト個別で閉じない横断的なナレッジの共有といったメリットが生まれました。
本発表では、2020年から2024年にかけてCREがSREの手法を取り入れながら徐々にインシデント対応の方法を改善してきた経緯や、その中での気付き、および現在直面している新たな課題などをお話しします。
</details>

[2,000万ユーザーを支えるSREチームの6年間のスクラムのカイゼン](https://speakerdeck.com/honmarkhunt/2500mo-yuzawozhi-erusretimuno6nian-jian-nosukuramunokaizen)
<details><summary>概要</summary>

『家族アルバム みてね』(以下、みてね)は2015年のリリース以降、現在ではグローバルで2,000万人以上の方々にご利用していただいております。
そんなみてねの安定稼働を支えるためSREチームが2018年に発足しました。

チーム発足時から現在までアジャイル開発/スクラムを取り入れて開発を進めてまいりましたが、サービスの成長や組織の拡大に伴いSREチームの課題・体制も大きく変化してまいりました。
試行錯誤しながらカイゼンを続けてきたみてねのSREにおけるスクラムの実践の歴史をお話しします。
</details>

[2週に1度のビッグバンリリースをデイリーリリース化するまでの苦悩 ~急成長するスタートアップのリアルな裏側~](https://speakerdeck.com/kworkdev/agony-of-converting-a-bi-weekly-big-bang-release-into-a-daily-release)
<details><summary>概要</summary>

スタートアップでは、生き残りをかけて機能開発のスピードが最も重要視されます。
そのため、弊社においてもデプロイフローの改善は後回しにされ、急成長期におけるビッグバンリリースが大きな足枷となってしまいました。
事業が拡大しプロダクトやチームが増えていく中で、リリースの頻度を上げるための技術的課題やチーム間の調整問題など様々な障壁に直面しましたが、綿密な計画とチーム全体の協力を通じてこれらを解決してきました。
本発表では、具体的にどのようなステップを踏み、どのような工夫を行って理想的なリリース体制を構築したのか、そしてその過程で得た教訓や成功のポイントについて詳しくご紹介します。
</details>

[AWSにおける横断的なログ分析とコストの管理](https://speakerdeck.com/naomichi/awsniokeruheng-duan-de-narogufen-xi-to-kosutonoguan-li)
<details><summary>概要</summary>

複数のAWSアカウントを運用する上では、サービスを横断したアラートの管理やコストの可視化、そして運用効率の向上が求められます。
メタップスのSREチームは、コスト最適化の観点から、ログとコストを統合的に可視化できるダッシュボードを開発しました。
本登壇では、その開発背景とアーキテクチャ、具体的な活用事例について紹介します。
</details>

[SREとしてスタッフエンジニアを目指す](https://speakerdeck.com/tjun/sre-kaigi-2025)
<details><summary>概要</summary>

近年、日本でもスタッフエンジニアという名称が広まってきました。スタッフエンジニアは管理職ではなく、技術面でのリーダーシップを発揮するキャリアパスです。しかし、SREの分野でスタッフエンジニアとなって活躍するには、どのような能力や役割が求められるのでしょうか。
本セッションでは、前職のメルカリでプリンシパルエンジニアおよびエンジニアリングマネージャーを経験した視点から、SREにおけるテクニカルリーダーシップと、キャリアパスについて解説します。技術力と組織への影響力を両立させるための動き方や、SREならではの課題と機会についても触れます。
管理職以外のキャリアパスを模索するSREの方々、そしてSRE組織でのリーダーシップに関心のある方々にとって、有意義なセッションになるとうれしいです。
</details>

[Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは](https://speakerdeck.com/mshibuya/platform-engineeringgaarebasrehairanai-xin-shi-dai-nosreniqiu-merareruyi-ge-toha)
<details><summary>概要</summary>

「Platform Engineeringが成熟している組織ではSREは不要ではないか」という疑問が存在します。確かに、Platformが成熟すると、開発者とPlatformだけでReliabilityを担保できるように見えますが、実際にはさまざまな課題が存在します。本発表では、Platform EngineeringとSREの役割を共に考える必要性について探求します。メルカリでの新規事業立ち上げの具体例を通じて、SREがどのように関与し、どのような方向性を持っているのかを紹介します。これにより、Platform Engineering時代に求められるSREの効果的な役割を考察し、未来へのビジョンを共有します。
</details>

[監視SaaSの運用におけるObservability改善の歩み](https://speakerdeck.com/taxin/jian-shi-saasnoyun-yong-niokeruobservabilitygai-shan-nobu-mi)
<details><summary>概要</summary>

サービスの信頼性を維持し、ユーザーに機能を提供するためには、サービスがユーザーの期待通りに動作しているかを観測することが不可欠です。これを実現する上で、テレメトリーの計装は重要な役割を果たします。
本セッションでは、監視SaaSの運用を例に、メトリクスを中心にしたテレメトリーの計装を通じてObservability (可観測性) をどのように改善してきたかについてお話しします。
また、その過程で直面した一般的な課題や、監視SaaSのサービス固有の課題を解決したアプローチについて監視SaaSの提供者側の視点で取り上げます。
</details>

SplunkとObservabilityを活用したSREの未来：データドリブンなシステム運用
<details><summary>概要</summary>

「SplunkとObservabilityを活用したSREの未来：データドリブンなシステム運用」では、SREにおけるデータ活用の重要性とその未来像について解説します。私の今までのキャリアでのコンテナ運用やSplunkを用いた経験をもとに、インシデント対応を効率化し、信頼性向上に貢献した実例を紹介します。また、SLOやSLIを用いた顧客体験の改善方法や、Splunkを活用したインシデントの根本原因分析、自動化対応の進展も取り上げます。さらに、データドリブンなアプローチが顧客満足度向上にどのように寄与するかを探り、SRE業務の未来におけるSplunkの役割を展望します。
</details>

[コード化されていない稼働中のサーバを移設/再構築する技術](https://speakerdeck.com/ryuichi1208/kodohua-sareteinaijia-dong-zhong-nosabawoyi-she-zai-gou-zhu-suruji-shu)
<details><summary>概要</summary>

コード化されていない稼働中のサーバを移設/再構築する必要が出てきたことはないでしょうか？私はこれまで4度ほど経験してきました。この経験を通じて、手動設定が多いシステムや長期間運用されているサーバの移設/再構築がいかに難しいかを実感しました。

現代のIT運用では、インフラのコード化（IaC）が主流ですが、すべてのサーバがコード化されているわけではありません。本セッションでは、コード化されていない稼働中のサーバを安全かつ効率的に移設するための技術と手法について解説します。今後の長期に渡るインフラ運用を見据え、移設後の最適化と信頼性に関する考察や実例を交えながら、具体的な移設方法を共有し、参加者が今後のシステム運用を行う上での一助となることを目指します。
</details>

[あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢](https://speakerdeck.com/jacopen/anatanoxing-wei-haxin-lai-xing-soretomosheng-chan-xing-sretositenokiyarianinao-muminasamanichuan-etaixuan-ze-zhi)
<details><summary>概要</summary>

みなさんのSREとの日々は、納得感を持って進められていますか？SREは今や、業種業態問わずシステムの信頼性を高めるための重要なポジションとしての認識が広がり、実践例が増えていますよね。多くの方は満足感・納得感を得ながら仕事をできていると思います。ですが、中にはもしかすると「なにか思っていたのとは違うな」と感じている方もいるかもしれません。その違和感は、もしかすると信頼性と生産性のバランスの違いから来ているのかもしれません。
ソフトウェアエンジニアリングを元に運用を改善していくSREは、信頼性と生産性の両方にアプローチできます。それはとても良いことなのですが、その2要素は場合によっては相反することもある概念です。SREのプラクティスは信頼性を高めることにプライオリティがおかれているため、生産性のほうに興味が強い方には、もしかすると違和感を覚えることもあるかもしれません。
そんな中で出てきたのかPlatform Engineeringです。生産性を高めることにフォーカスしたこの分野は、SREと似ているポイントもあれば、異なる部分もあります。本セッションでは、その違いに着目しながら、キャリアとしてのPlatform EngineerとSREを分ける要素は何なのか、みなさんがどちらに向いているのかを判断するためのエッセンスとキャリアについてお話します。
</details>

# 感想
今の自分にとって、特に勉強になったなと感じた内容を一部抜粋し所感を交えてご紹介します。

### 研修により「刷り込み」を受けた新卒エンジニアが良いプラクティスを組織に広げる
- 私は「SREをどのように組織に広めるか」を課題としていますが、これからどんどん成長していく若手に「良い知識、良い文化」を研修を通して学んでもらうことで、その後の配属先で広めてもらう。将来的に組織へ広がっていくという活動に目から鱗が落ちた思いでした
- ベテランの方々へ伝えることももちろん大切ですが、このような広め方もあるのだなと勉強になりました

### セキュリティ強化とは「潜在的なリスクを発見し、システムをより安全な状態に保つ」ことで「現状把握し、優先して対処すべきリスクを特定すること」が第一歩である
- 「セキュリティ強化」も課題のひとつですが、まずはやはり現状のセキュリティを可視化すること
- こちらは今まさに取り組んでいる活動ですので、このアプローチは正しいと思うことができました。具体的な手法も紹介されていたので参考にしたいと思います

### 長らく続いた文化を変えるためにはビジョンを語り続けて実行していく必要がある
- 私も今後より良い文化を築くため、今まで続いてきた組織の文化や在り方を変える必要があるだろうと考えています。しかし、今まで続いてきたものを変えることは容易でないことが想像できます
- 「何が実現できるのか、なぜ必要なのか、そのために何をする必要があるのか」をビジョンとして語り、そしてこれを行動で示すことが大事だと感じました

# まとめ
今回はSRE Kaigi 2025に参加してきました。

セッションは並行開催されていたのですべてを聴くことはできませんでしたが、どれも素晴らしい内容でした。
またいくつかの企業がブースを展開し、クイズやツールの利用状況アンケート、各企業がリリースしているサービスの紹介など、セッション以外にも参考になるものがたくさんありました。

たくさんの有益な情報を得ることができました。
またその時々で感じるもの得られるものはそれぞれですので、次回も参加したいと思います。

ここまで読んでくださり、ありがとうございました！