トーク

■ 発表カテゴリ
Tech: SREを支える具体的な技術や手法

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

■ 発表の詳細（1000字程度）
このセッションでは、SREが担うべき広範な技術領域について、具体的な方法論と実践事例を交えて紹介します。

まず、モニタリングの重要性を中心に、システムの健全性を常に把握するための効果的なモニタリング手法について議論します。どのようなツールを使うかに依存せず、システムの状態を適切に監視し、早期に問題を発見するための最適なアプローチを考察します。さらに、アプリケーションの動作状況を可視化し、パフォーマンスボトルネックを特定するためのテクニックも紹介します。オブザーバビリティの観点から、システム全体の信頼性を高める方法に焦点を当てます。

次に、パフォーマンス最適化の分野について、実際の経験を基にした具体的な事例を紹介します。Linuxカーネルのパラメーター調整によるシステムの最適化や、アプリケーションコードにおけるN+1問題の解消など、システムの性能を向上させるための実践的な手法を掘り下げます。また、過剰なトラフィックを効率的に制御し、システムの安定性を維持するための対策についても説明します。

最後に、セキュリティの側面について議論します。可用性を確保するためには、システムが常にセキュアであることが前提条件です。SREとして、どのようなセキュリティ対策が求められるのか、特に攻撃や不正アクセスに対する防御がシステム全体の信頼性にどのように寄与するかを解説します。これらの課題を通して、SREが技術的な観点だけでなく、運用とセキュリティの両方を統合的に管理する必要性を再認識します。

■ 対象聴衆とその人たちが得られるもの
このセッションは、中堅のSREエンジニアや、SREを目指すエンジニアを対象としています。彼らは、SREが対応すべき幅広い技術領域についての体系的な知識を得るとともに、現場で実際に使える具体的なモニタリング手法やパフォーマンス最適化の技術、さらにセキュリティ対策の重要性を学ぶことができます。特定のツールに依存しない柔軟な方法論を知ることで、各自の職場に適したSREのベストプラクティスを取り入れることができるようになるでしょう。

■ なぜこのトピックについて話したいのか（モチベーション）
SREとしての役割が多岐にわたる一方で、その守備範囲が明確でない場合が多いと感じています。日常の運用業務だけでなく、パフォーマンスの最適化やセキュリティ対策にも深く関わるべきだと考えています。私自身が直面してきた実務上の課題やその解決方法を共有することで、多くのエンジニアがより幅広い視点を持ち、SREとしての職責を再定義できるようになることを目指しています。このトピックを通じて、SREがシステム信頼性の中核を担う役割を再認識し、より効果的な運用を支援したいと考えています。

■ 発表カテゴリ
募集要項（https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9） にある6つの発表カテゴリからお選びください

・Tech: SREを支える具体的な技術や手法

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

■ 発表の詳細（1000字程度）
本セッションでは、Kubernetes環境におけるSRE実践の高度化について解説します。現代のシステム運用でKubernetesが中心的役割を果たす中、SRE原則の効果的な適用がますます重要になっています。我々は、オープンソースツールを活用して信頼性の高いインフラを構築し、組織全体のソフトウェアデリバリーを加速させる方法を探ります。主要なオープンソースツール（Helm、Tekton、Argo CD、Crossplane、Knative）の特徴と、SRE実践への統合方法を紹介します。これらのツールの選定基準や、組織のニーズに合わせたカスタマイズ方法にも触れ、最適なソリューション構築を支援します。SRE視点からの効率的な運用API設計原則を解説し、開発・運用チームの協働促進方法を具体例と共に紹介します。自動化と標準化によるヒューマンエラー削減事例も共有し、信頼性向上への道筋を示します。マルチクラウド環境でのSRE戦略として、Crossplaneを用いたクラウドリソース管理の統一や、クラウド間でのSLO一貫管理技術を紹介します。障害シナリオにおけるマルチクラウドの利点活用についても実践的アプローチを共有します。プログレッシブデリバリーによる信頼性向上として、Knative ServingとArgo Rolloutsを用いたカナリアリリース、段階的トラフィック制御、リアルタイムモニタリング統合、自動ロールバックメカニズムの構築方法を解説します。開発・運用チームの生産性と信頼性の同時向上のため、共通基盤による開発者体験向上とSRE原則浸透、自動化による認知負荷軽減、エラーバジェットの概念導入とその活用について説明します。SRE実践の効果測定と継続的改善のフレームワークとして、DORAメトリクスの活用、カスタムSLI/SLOの設定・追跡、データ駆動型改善サイクルの確立方法を紹介します。大規模システムでのSRE導入事例、課題と克服方法、得られた教訓を共有します。長期的な信頼性向上と運用効率化の両立戦略についても議論します。さらに、Kubernetesが適さないケースについても触れます。例えば、小規模で単純なアプリケーション、リソース制約の厳しい環境、レガシーシステムとの統合が困難な場合、特殊なハードウェア要件がある場合などです。これらの状況では、より軽量なコンテナオーケストレーションツールや従来型のデプロイメント方法が適している可能性があります。Kubernetesの採用を検討する際の評価基準や、代替ソリューションの選択方法についても議論し、技術選択の重要性を強調します。

■ 対象聴衆とその人たちが得られるもの

• SRE実践者や運用エンジニア
• Kubernetesを用いたシステム運用に携わる開発者やアーキテクト
• 信頼性向上とDevOps文化の導入を推進する技術リーダー
• クラウドネイティブ環境での運用最適化を目指すチーム
• システムアーキテクチャの選定に関わる意思決定者

得られるもの：

1. Kubernetes環境でのSRE実践を高度化するための具体的な手法と工夫
2. オープンソースツールを活用した信頼性向上と運用効率化の実践的アプローチ
3. マルチクラウド環境での一貫したSRE戦略の立案と実装方法
4. プログレッシブデリバリーによるリスク軽減と信頼性向上の実現手法
5. SRE実践の効果を定量的に測定し、継続的に改善するためのフレームワーク
6. 実際の導入事例から学ぶ、SRE実践の課題克服とベストプラクティス
7. Kubernetesが適さないケースの理解と、代替ソリューションの評価基準
8. 技術選択におけるトレードオフの分析と、組織のニーズに合わせた最適な意思決定の方法

■ なぜこのトピックについて話したいのか（モチベーション）
Kubernetesの普及に伴い、多くの組織が複雑性の増大と信頼性維持の難しさに直面しています。SREの原則と実践は、これらの課題を解決し、システムの信頼性と運用効率を飛躍的に向上させる可能性を秘めています。同時に、Kubernetesが全てのユースケースに適しているわけではないという現実も認識しています。
私自身、複数の大規模プロジェクトでKubernetesベースのシステム運用とSRE導入に携わり、その過程で得た知見と成功事例を共有したいと考えています。特に、オープンソースツールの効果的な組み合わせによる柔軟なソリューションの構築方法や、開発・運用チームの協働を促進するAPIの設計について、具体的な実装例を交えて解説することで、聴衆の皆様に実践的な価値を提供できると確信しています。同時に、Kubernetesの採用を見送った事例や、採用後に直面した課題についても率直に共有したいと考えています。これにより、技術選択の重要性と、各組織の特性に応じた適切な判断の必要性を強調できると考えています。このセッションを通じて、参加者の皆様がKubernetes環境でのSRE実践に関する新たな視点と具体的なアプローチを得られ、より信頼性の高いシステムと組織の実現に向けた一歩を踏み出せることを願っています。また、Kubernetesの適用範囲と限界を正しく理解し、各自の環境に最適なアーキテクチャを選択する力を養っていただければと思います。技術の進化が急速な現代において、特定の技術に固執せず、常に最適な選択を追求する姿勢が重要です。このセッションが、参加者の皆様にとって、技術選択の指針となり、より良いシステム設計と運用の実現につながることを願っています。

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

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

■ 発表の詳細（1000字程度）
本セッションでは以下のアジェンダでの発表を想定しています

・Park Directが当時抱えていた課題
・実施したプラクティスの紹介
　・ブランチ戦略
　・Feature環境（プルリクエスト単位の専用環境）の導入
　・DBマイグレーションのリハーサル
　・開発DB複製の自動化
　・リリーストグル管理ツールの構築
　・パラレルテストの導入
・プラクティスによって得られた効果
・今後の取り組み

概要に記載のとおり、Park Directでは当時、リリース頻度と変更障害率について大きな課題を抱えていました。

SRE、開発、QAのチームが協業することで、どのように品質を高めながら高頻度のリリースができるようになったかの歩みをプラクティスとともに紹介します。

▼ 改善効果
・リリース頻度：2週間に1回　→　毎日（複数回も可能）
・変更障害率：Low　→　Elite

▼ 取り組んだ主なプラクティスの概要
・ブランチ戦略
　Park Directではfeature、dev、stg、prodの4つの環境を運用しています。これらの環境をどのようなブランチ戦略で実現しているのかを紹介します。

・Feature環境（Pull Reqeust単位の専用環境）の導入
　開発者がPull Reqeustの単位で専用の検証環境を作成できる仕組みを構築することで、開発生産性の向上に寄与しています。Feature環境をどのような仕組みで実現しているのかを紹介します。

・DBマイグレーションのリハーサル
　以前まではDBのマイグレーションを伴うリリースをおこなう場合、サービスを停止したうえで実施していました。マイグレーションを事前にリハーサルできる仕組みを構築することで、サービス影響を把握できるようになったのでその仕組みを紹介します。

・開発DB複製の自動化
Feature環境の導入に伴い各環境毎に開発用DBが必要となるケースが増加しました。Pull Reqeustにラベルを付与することで開発用DBを複製できる仕組みを構築したのでどのように実現したのかを紹介します。

・リリーストグル管理ツールの構築
機能のリリースを柔軟に制御するためにリリーストグルを活用してきました。しかし、トグルの数が増加するにつれ、その管理にかかる運用負荷が大きな課題となっていました。独自にリリーストグルを管理する仕組みを構築することで解決したのでその内容を紹介します。

・パラレルテストの導入
　以前まではQAによるテストはdev環境にデプロイ後に実施していたため、QAリードタイムが長く発生していました。Feature環境と合わせて、パラレルテストを開発プロセスに導入することで、QAテストのシフトレフトを実現し、QAリードタイムの短縮が行えたのでその取り組みを紹介します。

■ 対象聴衆とその人たちが得られるもの
・リリース頻度や品質に課題を持っている方
　・実際に実践し高い成果を得られたプラクティスを紹介するため、課題解決のヒントにしていただけると考えています。
・開発生産性を向上させたい方
　・Feautre環境の仕組みは機能開発以外にも汎用性が高く利用できる仕組みのため、聞かれた方の課題解決の選択肢になると考えています。

■ なぜこのトピックについて話したいのか（モチベーション）
リリース頻度や品質の向上は多くのサービスがかえる課題かと思います。ニーリーで実践したプラクティスを紹介することで、同じ課題を抱えるサービスの一助になればと考えています。

■ 発表カテゴリ

・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

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

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

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

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

■ 発表の詳細（1000字程度）

弊社は金融アプリBloomoを開発しています。バックエンドは、お金を計算するGoで実装されたコンポーネントと、顧客周りを含めてお金以外の全てを処理するRuby on Railsで実装されたコンポーネントの大きく2つがGKE上で稼働しています。その他の背景として、インフラ経験豊富なメンバーが社内にいない中、手探りで整備を進めていたことも付け加えておきます。

アプリは2024年の5月にリリースされました。金融商品を扱うアプリのため、インシデントが一つ起こることの影響が非常に大きく、リスクを潰すために考えられる機能的なテストや試験的な運用は実施していたので、機能観点ではある程度の自信を持っていました。一方で、横断的関心事に関するテストの実施は部分的であり、その点に関しては不安を抱えつつも楽観的な想定を持ってリリースに臨んでいました。監視可視化についても最低限必要と思われるものを整備した状況で、それらを実際に閲覧できる人間は多くありませんでした。

リリース直後にテレビ番組WBSにてアプリを紹介していただける機会を得ました。テレビの影響は絶大で、想定を遥かに上回るトラフィックが押し寄せた結果、弊社アプリのサーバーは過負荷によってつながりにくい状態になってしまいました。横断的関心事に関するテストが疎かになっていたこと、テレビの影響を甘く見て特別な準備をしていなかったことなど反省点は枚挙にいとまがありません。メンバーがちょうど拠点である東京から離れ、ある人は大阪へ、ある人は沖縄へと旅立ってしまっていたため、むしろ対応が数時間でできたことは奇跡だったかもしれません。

リソース増強による復旧と監視周りの運用体制の整備をしてメディア露出を乗り越えた後は、増大したリソースによるコスト増加に対応する必要がありました。どこでコストが掛かっているのか、どこまでの事象に耐えられるサーバーにする必要があるのか、簡単にコストを下げられる箇所はどこか、大きくコストを下げられる箇所はどこかなど、ひたすら現状を整理していきました。その中で、SLOによるサービスレベルの擦り合わせを経営陣と行うことの重要性に気づきました。コストの抑制は喫緊度の高い課題であったためSLOを全面導入するには至らなかったものの、サービスレベルに焦点を合わせてタスクに取り組んみ始めてからスムーズに意思決定ができるようになりました。

振り返ってリリースまでに最低限準備しておかなけれなばならなかったことと、その後もレジリエンスの高いサービスを運用するためにやって良かったことなどを交えつつ、リリース前後の弊社インフラチームの死闘をお話しできればと考えています。

■ 対象聴衆とその人たちが得られるもの

対象聴衆は以下のような人たちを想定しています。

• これからSREを企業に浸透させたい方
• 新規でサービスを立ち上げる方
• 初心者の失敗談を聞いてみたい方

得られるものは以下のとおりです。

• 新規サービスをリリースする前のSRE観点で最低限の準備
• トラフィックの増加が予想されるイベントへの対処方法
• サービスレベルを軸にしたコストの適正化方法

■ なぜこのトピックについて話したいのか（モチベーション）

個人の経歴として、エンジニアを入社してからバックエンドエンジニアとして働いてきました。今もメインの業務内容はバックエンドの開発です。一方で、新卒で担当した業務がPrometheusへの移行であったり、チーム横断の生産性改善への取り組み担当を任せていただいたりと、バックエンドの中でもSREに近しいところで働いてきたと感じています。昨年に今のスタートアップ企業へ転職してからはより直接的にSREへ関わることになり、テレビによるインシデントを契機に今では業務の2~3割をインフラ領域へ割り当てています。

このインシデントから連なる一連の取り組みでSREの重要性や面白さを発見できたことが、今の自分の原動力となっています。聴衆の方々へ、具体的な知見と一緒にSREに対する情熱を共有することで、一緒にSREを盛り上げていきたいと思い、応募させていただきました。

また、実際の経験談特に失敗談は貴重なものだと感じています。自身の経験を共有することで、同様の課題に直面する可能性のある企業やエンジニアの助けになったり、業界全体のプラクティス向上へ貢献できればと考えています。

■ 発表カテゴリ
募集要項（https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9） にある6つの発表カテゴリからお選びください

・Tech: SREを支える具体的な技術や手法

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

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

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

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

■ 発表の詳細（1000字程度）
前提として現段階の私たちは Platform を提供することで、「プロダクトのエンジニアと伴奏しながら彼らの自律性を高めること」を目的に活動しています。
なぜそのような動きをしているのか、その効果は？について具体例を用いて紹介させていただきます。

• DBRE とは
  • Database に対する専門知識と判断を用いてサービスの信頼性を担保するのが役割
  • クラウドが普及してきた現代ではゲートキーパーとしての役割ではなく、現場のエンジニアが事業成長に注力できる環境をどのように提供したらよいか
• DBRE は自分たちに本当に必要なのか
  • DBRE が向いている組織とそうでない組織にはどのような違いがあるのか
• DBRE の目標、ゴール設定はどのように定義しているのか
  • DBRE のミッション, ビジョン
  • 3年戦略
• プロジェクトはどのように進めているのか
  • DBRE を支える技術
    • エンジニアリング
    • monorepo 管理
    • スクラム
• 実際のアウトプットの例
  • データベースパスワードの安全なローテーション
  • 生成 AI を活用したスキーマレビュー
    • プロジェクト開始前に作成したインセプションデッキとデモを用いて共有します

■ 対象聴衆とその人たちが得られるもの
特にデータベースの運用や信頼性に関心を持つSREエンジニア、システム設計者、エンジニアリーダーを対象としています。
参加者は、データベースを軸とした Reliability Engineering について実践的なアプローチを学び、実際の導入事例から得られた教訓を自身の組織に応用するための具体的な手法とアイデアを得ることができます。

■ なぜこのトピックについて話したいのか（モチベーション）
私たちは、DBRE を実践するために様々な挑戦をしてきました。DBREという分野において、単なる技術的な解決策だけでなく、チームの文化や組織としての取り組みも重要です。
これまでの経験を共有することで、同じような課題に直面している他のエンジニアやチームの助けになりたいと考えています。
また、データベースを軸とした Reliability Engineering という視点を広め、SREコミュニティにも知見の共有と改善に貢献したいという思いから、このトピックを選択しました。

■ 発表カテゴリ

・Practices: SREの実践例と得られた教訓
・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）

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

■ 発表の詳細（1000字程度）

あなたが一人目のSREだった場合、どんなことから始めるでしょうか。
そして、その一人目のSREにはどんなスキルセットが求められるのでしょうか。
ではチームが拡大したとき、あなたは次にどんなSREに来てほしいですか。
チームが安定しプロダクトが成長してきたら、どんなSREチームになっているのが良いのでしょうか。

3年を通じて見てきたことは、プロダクトのフェーズ、チームのフェーズ、企業のフェーズによってSREのあり方は変わるのだということです。
一人目のSREに求められることは、思い切った決断や意思決定の速さ、それから浅くとも広い経験かもしれません。
しかし5人〜10人とチームが拡大すれば、そこで求められるのは狭くともより高い専門性やチームワーク、慎重であっても的確な意思決定だったりします。

本セッションでは主に次のようなことについてお話します。

• マネーフォワードの多様なSREチームについて
• プロダクトSREチームの立ち上げ草創期の状況と、当時の取り組み
  • ミッション
  • 文化醸成
  • Practices
• 今振り返って、どんなスキルセットが求められていたのか（※採用時のコメントも聞いた）
• チーム拡大期〜安定期のSREチーム状況と、取り組み
  • 高い専門性
  • 潜在的な課題
  • 目の前の課題
  • 他チームとのコミュニケーション
  • あらゆる角度、チームから飛んでくる依頼に対応するフットワーク
  • この時期のSREにどんなスキルセットが求められるのか
• SREチームは3年でどのように変わっていったのか
  • チーム体制
  • ミッションの変化
• 安定期より先では、どのようなSREが求められるのか（予想）

■ 対象聴衆とその人たちが得られるも

• 企業やチームのフェーズによってSREのあり方が変わるということ
• 草創期、拡大期、安定期があったとして、自分がどの規模のSREとして適任か
• どのフェーズにどんなスキルセットを持ったSREがいるとよいのか

■ なぜこのトピックについて話したいのか（モチベーション）

ある程度この仕事をしていると、「自分はSREとしての価値を発揮できてないのでは」と悩むことがあります。それにはスキルセットが合わなかったり、文化が合わなかったり、様々な要因があると思います。
これは自分がSREとしての向き不向きではなく、組織やプロダクトフェーズによって得手不得手の場面が異なるからだろうと考えました。
その根拠が、3年間で変化を遂げたSREチームの歩みです。
これを読んでいる方にも同じような感覚があるのではないかと考えています。昨今多様化したからこそ、どのフェーズのSREとしてフィットするのかを確認できる機会になればと思います。

■ 発表カテゴリ
募集要項（ https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9 ） にある6つの発表カテゴリからお選びください

・Practices: SREの実践例と得られた教訓

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

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

■ 発表の詳細（1000字程度）
本セッションではローンチ直前のサービスにSREとして参加したと仮定して、どういった優先順位付けで信頼性向上に向けてアプローチしていくのか議論していきます。

1 レポートラインの確認
決めるべき項目を誰と合意する必要があるのか、誰にヒアリングすることで必要な情報を得られるのかを確認します。

2 Production Readiness Checklistに基づく初期評価と優先順位付け
Production Readiness Checklistの紹介と重要性を説明します。
新しいサービスのアーキテクチャと依存関係を迅速に把握し、Production Readiness Checklistに基づく初期評価を行います。
評価に応じて、追加対応が必要な項目のアクションプランを作成し、実施する優先度を決めます。

3 モニタリングとアラート設定
重要なメトリクスを定義し、適切なモニタリングツールを選択します。
アラートポリシーを策定し、アラートが発火したときのRunBookを作成します。

4 インシデント管理体制の整備
インシデント対応プロセス(エスカレーションフロー、インシデントログ、Postmortemについて)を確立し、チーム全体に周知します。
障害対応訓練を行い、対応手順の確認と改善を行います。

5 負荷試験
負荷テストを実施し、ボトルネックを特定します。
必要なパフォーマンス改善策を実行し、再度テストを行います。
このタイミングでボトルネックが発覚しても改修までの時間が足りないケースが多いのではないでしょうか。そうならないためにも、事前にProduction Readiness Checklistを作成しサービスチームが継続的に準備を進めることが重要です。

6 セキュリティ対策
セキュリティ評価を行い、脆弱性対応やアクセスキーなどの整理を行います。

7 ローンチ後のコスト最適化戦略
ローンチ時に想定最大DAUに合わせてスケールアップしていた構成をダウンサイジングしていく戦略作成の方針を解説します。

これらのステップを通じて、1ヶ月という短期間でどのようにサービスの信頼性を高めるかを具体的に解説します。また、実際のプロジェクトでの経験や課題、学びを共有し、参加者が同様の状況に直面した際に役立つ実践的な知識を提供します。

■ 対象聴衆とその人たちが得られるもの

• Production Readiness Checklistを導入していないサービスチームの方
  • 導入することによりローンチ時の不安が可視化され、取り組むべき課題(あるいは他の何か？)の優先度を明確にできることをご紹介します
• SREsの中でも、横断組織からEmbedded SRE/Enabling SREとして短期間サービスチームに参加する方
  • 自分がローンチ直前に参加した場合にはどう動くか、検討材料にしていただければ幸いです

■ なぜこのトピックについて話したいのか（モチベーション）
SRE本 27章「大規模なプロダクトのローンチにおける信頼性」でも一章を使って説明されているようにサービスローンチ前に確認すべきことは多岐にわたります。限られた時間で効率よくアクションプランを作成し、実施していくための合意形成などについて、みなさんと意見交換させていただきたいです。また、私自身の経験から、短期間での信頼性向上の具体的な手法を共有することで、同様の課題に直面している方々の助けになればと思っています。

■ 発表カテゴリ

・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）

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

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

■ 発表の詳細（1000字程度）

このセッションでは、SREの知識と技能を初学者に効率的に導入するためのアイデアについて、私が実施に関わった研修の内容と結果に触れながら紹介していきます。

まず、現代のWebサービスの運用におけるSRE技術の重要性を確かめます。組織の形態によってSREの実践のされ方は異なるにせよ、特定のメンバーのみがSREというロールを担うのではなく、組織として技術者全員がSREの文化を理解している状態であることの有用性を議論します。

そして、SREに関する知識技能の習得に向けてとりうる方法を説明します。現状広く利用可能である教材と、私が関わった研修を紹介します。教材については複数の技術書やワークショップに触れながら、初学者にとってどこが躓きポイントであるかを解説します。研修については、Kubernetesで動くアプリケーションをGitHub ActionsとArgo CDでデプロイできるようになるための「コンテナ研修」や、Grafana + OpenTelemetryの技術スタックを使って監視と可観測性を中心にSREプラクティスの習得を目指した「オブザーバビリティ研修」、またWebサービスのパフォーマンスチューニングを複数社合同の競技形式で実施した研修を紹介します。この項では、研修の設計意図や詳細な内容を説明します。また、研修受講者からのフィードバックによって得られた、研修の質を向上させるためのポイント（すなわち失敗事例）を共有します。失敗事例は、前提となる知識や技能の共有不足によって受講者に不完全燃焼感を抱かせてしまった事例や、内容量に対する研修期間の見積もりを失敗した事例などを含みます。

最後に、まとめとして、新卒SREエンジニアとして社会に組み込まれた経験を持つ話者の視点から、「もっとSREの裾野を広げる」ために私たちが取りうるアクションアイデアを議論します。SREという簡単ではない思想を、特に初学者に対して定着させるための方法論、コミュニケーションデザインの観点から作り上げるアイデアと実践例を提供します。

■ 対象聴衆とその人たちが得られるもの

このセッションは新規メンバーを迎えうるSREエンジニアや、SREを目指すエンジニア、また技術組織における研修担当者を対象としています。聴衆はこのセッションによって、ソフトウェアエンジニアリングにおけるSRE思想を導入することの重要性を改めて認識するとともに、研修や教育といった観点からSRE思想をもっと広く導入・定着させるためのアイデアを得られるでしょう。

■ なぜこのトピックについて話したいのか（モチベーション）

SREの技術や考え方はWebサービスの継続的な提供において技術的に重要な役割を担います。しかし、私自身の経験から、初学者にとってSREの知識や技能の習得のための間口が十分には整備されていないと感じています。

私は新卒エンジニアとしてSREロールに配属されました。自身で学び、実務に携わる中で、SREの価値と難しさを身をもって体験しました。さらに、その経験を活かして研修の設計と提供にも携わることで、「教える側」と「学ぶ側」の両方の視点を獲得しました。

新卒SREエンジニアとして実務に従事しながら研修に関わってきた経験を基に、SRE思想の導入のための効果的な教育デザインを体系化し、共有することがこのセッションの目的です。SREの裾野を広げ、より多くの技術者がSREの価値を理解し実践できるようになることで、業界全体のサービス品質向上に貢献したいと考えています。

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

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

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

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

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

■ 発表の詳細（1000字程度）
以下の章立てでお話をします。

1. ココナラで抱えていたセキュリティの課題
2. セキュリティログ分析へのアプローチ
3. セキュリティの課題をどのように解決していったか？
4. SIEMの導入効果
5. 今後の取り組み

ココナラはもともとSREチームがスキマ時間でセキュリティ対応を行っており、後手後手に回っていたり、体系立てた対応ができませんでした。
そこを改善すべく、SIEM（Amazon OpenSearch Serviceを利用した分析基盤）を導入し、試行錯誤の結果、セキュリティログの可視化と分析を行える状態を作りました。

また、「セキュリティログ分析はセキュリティの仕事」になりがちですが、SREも入ることによって運用改善・効率化の結果、信頼性向上（攻撃予兆 〜 傾向分析を行い、WAFのルールやアプリケーションを改善することでSuccess Rateを99.95% → 99.998%へ向上）を実現できました。
SREやセキュリティエンジニアの協業・キャリア形成の取り組みにも触れて話をします。

DevOpsDays Tokyo 2024ではOpsの話をしたので、今回はセキュリティログ分析を起点としたSREのプラクティスやSRE・セキュリティエンジニアのキャリア形成にもつながる話をします。
■SREのプラクティス
・日々のメトリクスモニタリングへ装着し、攻撃の予兆検知 〜 遮断対応の高速化
・ログ分析による予防のアクション創出〜実践

■SRE・セキュリティエンジニアのキャリア形成
・SREから見ると
　　DevSecOpsの実践
　　セキュリティ運用のトイル削減、既存設定の見直しなどIaC以外の効率化・自動化
・セキュリティエンジニアから見ると
　　セキュリティ × SREのプラクティスによるプロアクティブな運用改善実践
　　組織としてサービスに貢献できることの楽しさによるIaCへの取り組みや監視改善

https://speakerdeck.com/coconala_engineer/siemwoyong-ite-sekiyuriteirogufen-xi-noke-shi-hua-tofen-xi-woshi-xian-si-pdcasaikuruwohui-sitemita-3c3b6400-1e46-45d1-adcc-f619843328d7

■ 対象聴衆とその人たちが得られるもの
・信頼性向上に向けたSRE × セキュリティ観点のアプローチ、キャリアパスの広がり
・特にAWS環境におけるセキュリティログ分析・モニタリングの取り組みと実践
・SIEMでできること、SIEM on Amazon Open SearchServiceのより良い使い方

■ なぜこのトピックについて話したいのか（モチベーション）
セキュリティの専門組織を持っていない会社、持っていてもプロダクトのセキュリティログ分析に工数が割けない会社が多いと思います。

SREは1つのロールなので、職種横断で取り組むべきプラクティスですし、セキュリティという切り口でSREの裾野を広げることがこのイベントの趣旨にあっていると考えたからです。

SREに対しては、
・SRE × セキュリティのプラクティスで技術もキャリアも幅が広がる
を伝えていき、セキュリティエンジニアに対しても
・実は業務の一部がSREを実践している
・セキュリティ起点でプロダクトの価値向上に大いに貢献できる
というのを伝えることで、キャリアパスの広がりや業務のシナジーを生み出していきます。

■ 発表カテゴリ
・Architecture: SREの視点からのシステム設計

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

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

■ 発表の詳細（1000字程度）
本セッションでは以下の流れで発表を行います。

1. OpenTelemetryを用いたテレメトリーパイプラインにおける主要素
2. OpenTelemetryを用いたテレメトリーパイプラインの大まかなパターン
3. 各パターンにおける利点、欠点、検討事項
4. OpenTelemetryの今後のタイムライン

まず、本セッションのおける「テレメトリーパイプライン」の解説を行うために、それに関わる主要な構成要素に関して共通認識を持てるよう、OpenTelemetryにおける各要素の解説を行います。これを行うことで、OpenTelemetryを用いていない参加者も自身のシステムにおける構成要素と比較しながら、これ以降の内容を理解できるようにします。

次に1を踏まえて、OpenTelemetryを用いたテレメトリーパイプラインの典型的なパターンを紹介します。OpenTelemetry SDKおよびCollectorを用いたテレメトリーパイプラインを構成する場合、元のシステムの構成によって、そのパターンは大きく影響を受けます。現代において主要なシステム構成（コンテナオーケストレーション、サーバレスなど含む）に触れながら、パイプラインの構成パターンを分類します。

テレメトリーパイプラインをシステムに導入すると、システムにも何らかの影響があります。ここでは、リソース消費の観点からそれぞれのパターンにおける利点と欠点を整理し、実際に導入する際の検討事項を整理します。

最後に、本セッション登壇時点でのOpenTelemetryプロジェクトの動向などから、テレメトリーパイプライン構成に関係しそうなトピックを紹介し、聴衆のみなさんが最新の知識を持ってその導入に活かせるようにします。

■ 対象聴衆とその人たちが得られるもの
本セッションは以下の方々を対象として想定しています。
・SRE
・プラットフォームエンジニア
・アプリケーション開発者
・インフラエンジニア
・運用担当者

また本セッションから得られるものは以下です。
・OpenTelemetryに関する基礎知識（主にテレメトリー取得、収集に関する構成要素）
・OpenTelemetryに限らないテレメトリーパイプラインの構成パターンとその特徴

全体として、まったくの初心者向けの内容というよりは、テレメトリー収集について何かしらの経験があり、課題感を持っている初級から中級者向けの内容になると思います。

■ なぜこのトピックについて話したいのか（モチベーション）
・SREにおいてテレメトリーシグナルの取得は要であり、SRE Kaigiの記念すべき初回にふさわしいテーマだと思ったから
・テレメトリーパイプラインに関する発表を見かけることはまだ多くなく、横断的に整理して紹介することでより多くの組織でのテレメトリー取得の助けにしたいと思ったから
・SRE KaigiにおいてSREに直結する製品であるOpenTelemetryをより広く普及したいと思ったから

■ 発表カテゴリ

・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）

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

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

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

■ 発表の詳細（1000字程度）

本セッションは、品質保証エンジニアリングプラットフォームAutifyを題材に、サービス信頼性向上のために実施してきたリアーキテクチャリングに焦点をあてます。

Autifyは2019年にサービスローンチ後、顧客数に比例して増加するインフラコストや、複数のサービスインシデントから、アーキテクチャ自体にいくつか課題があることが明瞭化してきました。以下、SREチームによって実施されたアーキテクチャ課題を抜粋、エッセンスを議論します。

• コスト最適化のためのAmazon ECSからEKSへのワークロードの移行
  1. 最もコスト高なワーカーサーバーの移行
     1. サーバー要求数にリアルタイムに応答するpod scalerの実装
  2. 新規マイクロサービスをhelm-chartリポジトリを活用したスピーディーな立ち上げ
  3. ノードサーバーのコスト効率化のためのKarpenter導入
• MLワークロードが稼働するKubernetes (GKE) クラスタの引き継ぎと改善
  1. TerraformによるIaCと移行
  2. Savings Planを適用するコスト効率化
  3. GKEのauto-upgradeを安全に本番適用するRollout sequencing
• 既知のセキュリティ課題を解消するためのテスト実行インフラのリアーキテクチャリング
  1. ゼロダウンタイムでテスト実行のSPOF (Single Point of Failure)なコンポーネントSelenium Hubのメンテナンスアップデートを行うTooling
  2. SPOFを解消するインハウスのテストノードマネジメントマイクロサービスの開発
     1. ロジックの堅牢性をテストするrobustnessテストの導入
     2. 様々なエラーケースを実際に検証するFault Injection Testingの実践

これらは、Autifyという、いちSeries-Bグローバルスタートアップに留まらない再利用可能なナレッジとして共有します。

■ 対象聴衆とその人たちが得られるもの

• Kubernetes移行を検討している運用担当者
• AWS EKSやGoogle Cloud GKEの適用・運用事例を知りたいインフラエンジニア
• サービスのリアーキテクチャリングの必要性を感じているSREエンジニア・アプリケーションエンジニア
• Resilience engineeringやFault Injection Testingに興味のあるエンジニア

本セッションを通じて以下が得られます。

• Kubernetesへの移行事例
• 再利用可能なhelm chartの実装方法
• AWS EKSにおけるKarpenterの導入事例
• production-readyなGKE clusterの運用
• SPOFなシステムコンポーネントのメンテナンス改善とSPOF自体を排除するリアーキテクチャリングのアイデア

■ なぜこのトピックについて話したいのか（モチベーション）

• 典型的なWebサービスの運用とは異なるからこそ、少し特殊なサービスにおけるSRE実践例の議論はこうしたカンファレンスにとって非常に有用であると信じているから。
• 本サービスは、E2Eテストという分野ですが、一般化すると、任意のタイミングで実行されるが、その実行時間や使用リソースはバッチ的であるという扱いの難しいリクエストに対し、迅速、かつ、コストを抑えながら応答するかという要求にSREエンジニアとしてどう高い信頼性を担保していくか、という議論は聴講者の方々にとって興味深いテーマになるはずです。
• また、Autifyに蓄積された大量のデータを用いて構築されたビジュアルリグレッションテスト等様々なAI-drivenな機能を支えるMLインフラのMLOpsやKubernetesクラスタ運用の事例は、AIが広くサービスに適用される昨今においてはあまねく参考になるでしょう。

■ 発表カテゴリ

Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）

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

■ 発表の詳細（1000字程度）

本セッションでは、個々のエンジニアがインシデント対応能力を高めるために必要な要素を具体的に考察し、その向上方法を提案します。インシデント対応能力とは単なるハードスキル（技術スキル）だけではなく、いわゆるソフトスキルや対応経験、システム・サービスの理解、ツールや仕組みといった複数要素のかけ算で決まると考えます。

ハードスキルはインシデント対応に必要な技術や知識を指します。例えば、データベースやコマンドラインツール、パフォーマンスチューニングなどです。インシデントの種類はサービスに応じて多種多様です。適切な知識や技術、ノウハウ、テクニックがないと問題収束までの時間は長引くでしょう。

ソフトスキルはコミュニケーション能力やリーダーシップ、判断力、インシデントマネジメントなど非技術的な能力です。複数チームが関わるインシデントの場合、ソフトスキルが重要な役割を果たします。

対応経験も重要です。インシデント対応の実戦経験を通じて、エンジニアは緊急時でも冷静に行動できるようになります。インシデント対応経験が少ない場合でも、トレーニングや競技に参加することで向上を見込めます。

システム・サービスの理解は、自分が担当するシステム・アーキテクチャのドメイン知識や設計、コード、データベースについて知ることです。スキルや対応経験が抱負だとしても、システムサービスへの理解が浅ければ適切なインシデント対応は難しくなるでしょう。

本セッションでは、これらの要素がどのように相互に作用し、エンジニアのインシデント対応能力を総合的に高めるのかを考察し、向上方法を提案します。最終的には、個々のエンジニアの得意・不得意を理解し、補完し合うことでチーム全体のインシデント対応能力を高めることを目指します。

■ 対象聴衆とその人たちが得られるもの

インシデントや障害対応を行う全ての人が対象で、対応能力を高めるための指針を得られます。

■ なぜこのトピックについて話したいのか（モチベーション）

自身やチームの状況からインシデント対応能力をさらに強化したいと考え、手法について整理・検討した。せっかくなのでカンファレンスで話してフィードバックをもらいたいというモチベーションです。

■ 発表カテゴリ
募集要項（ https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9 ） にある6つの発表カテゴリからお選びください

・Practices: SREの実践例と得られた教訓
・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）

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

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

■ 発表の詳細（1000字程度）

• ガバメントクラウドとは何か

デジタル庁が整備するガバメントクラウドについて、クラウドサービスプロバイダの立場から簡単に紹介します

• さくらインターネットの取り組みと開発の現状

さくらインターネットがガバメントクラウドの技術要件を満たすために取り組んでいること。開発の課題とその変化

• さくらインターネット SRE室のあり方とその変化

SRE室設立の背景や当初の取り組み、開発組織支援や機能開発が主となっている現在との差分とその背景
開発は今後も継続して行われていく中で、SRE室のあり方をどう変化させていくのか

• チャレンジする組織にとってのSREとは

  SREとは組織が変化や適応を行なっていくためのプラクティスであるとした上で、SREをどのように実践していくのかを検討します

■ 対象聴衆とその人たちが得られるもの

SREや開発者およびそのマネジメント
大規模な開発現場におけるSREの実践についての一つの事例として、さまざまな可能性の中の一つとなることを期待しています

■ なぜこのトピックについて話したいのか（モチベーション）

現在、多くの開発や他チームの支援を行いながらSREチームのあり方について模索を続けています。
本来のSREができていないのではないかという疑問を抱えながらも、バリューやWHYに基づきこれも一つのあり方として取り組んでいます。
組織の数だけSREがあってもいいではと考えのもと、事例の一つとして紹介し、議論のきっかけとなれば幸いです

■ 発表カテゴリ
募集要項（ https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9 ） にある6つの発表カテゴリからお選びください

・Practices: SREの実践例と得られた教訓

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

■ 発表の詳細（1000字程度）
CREがインシデント指揮の役割を担う前の2020年頃の状況から、徐々に移行してきた経緯ややってきたことを中心にお話しします。
具体的には以下のような内容を予定しています。

1. ANDPADのターゲットの多角化
   • 多様化するユースケース
   • マルチプロダクト展開
2. 開発組織とCRE
   • 開発組織のチーム編成
   • 3つのReliabilityチーム
   • アンドパッドにおけるSREとCREの違い
   • カスタマーサポートとの違い
3. インシデントとCRE
   • インシデント時の役割分担
   • インシデント時にCREがやること
   • アンドパッドにおけるポストモーテム
4. インシデント対応における変遷
   • 2021年：CREによるインシデント対応業務の本格始動
   • 2022年：ポストモーテムの棚卸し
   • 2023年：インシデント内容の横展開
   • 2024年：ポストモーテムの分析力強化
5. 課題と今後に向けて
   • マルチプロダクト展開に伴う副作用
   • インシデント対応の平準化による信頼性の向上

まずはCREがインシデント対応を行う背景となる、アンドパッドのサービス展開や開発組織についてお話しします。
次にSREの手法と比較しながらアンドパッドCREのインシデント対応における役割やポストモーテムの取り組み・そこに至るまでの変遷をお話しします。特にマルチプロダクト戦略を取る開発組織では、いかにその知識を開発組織全体の学び・ナレッジとして平準化していくかが一つの課題となるのではないでしょうか。私たち自身はこれまでも、そして現在もこの課題感を持っており、どのように取り組んでいるかの実践例をお話しできればと考えています。

■ 対象聴衆とその人たちが得られるもの
対象聴衆

• インシデント対応をする全ての方

得られるもの

• 熟達したSRE以外の担当者がインシデント対応を主導する実践例
• 特にtoBのマルチプロダクト戦略を取っている開発チームでの手法

■ なぜこのトピックについて話したいのか（モチベーション）
ANDPADがより良いプロダクトになるよう、インシデント対応から振り返りまでの改善をCREは日々行っています。その中の一つの解として現在行っている手法をお話しすることで、インシデント対応に悩まれている皆さんの一助になればと思います。また、私たち自身も何が最善かをまだまだ模索している段階ですので、発表と質疑応答を通してよりよいアイディアがあるか話し合い、気付きが得られる場にしたいと考えています。

■ 発表カテゴリ
募集要項（ https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9 ） にある6つの発表カテゴリからお選びください

・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）

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

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

■ 発表の詳細（1000字程度）

以下のような発表を想定しています。

◻️ みてねのSREチームの概要
まず、どのような組織・チーム体制をとっているかご説明します

◻️スクラム導入の経緯
なぜスクラムを採用することになったのか、また現在はどのようなモチベーションでスクラムを採用しているかついてご説明します

◻️スクラムの変遷
サービス・組織の変遷に合わせてたくさんの課題が生じてきましたが、それに合わせてスクラムのプロセスをどのように変更してきたかについて説明します。
主にツールの変遷、組織体制の変遷、マインドの変遷にフォーカスして時系列でお話しさせていただき、最終的に現在どのような形で開発しているかについても紹介する予定です

◻️ SREがスクラムを行う難しさに向き合う
SREはさまざまな原因からスクラムとは相性が悪いと言われていますが、みてねのSREチームも同様に様々な課題に衝突してきました。それぞれの課題にどのように対応・取り扱っているかについてお話しします

主なトピックはこちらになります

• 不確実性(差し込みタスク)と向き合う
• HOWの固定化されたタスクと向き合う(アップデート作業など)
• 他チームとの協業と向き合う

◻️現在の課題
最後に今現在抱えている課題に感じていることとそれに対する向き合い方についてやこれまでの取り組みをチームメンバーがどのように感じているかなどについてお話します

■ 対象聴衆とその人たちが得られるもの

チーム開発をしているSREの方々全般が対象で、スクラムを採用している方々は自分たちのチームと比較して、採用していない方々は導入の検討材料として参考にしていただけるのではないかと思います。

■ なぜこのトピックについて話したいのか（モチベーション）

スクラムには完全な型はなく、実際のチーム・組織に委ねられるケースが多いと思います。特にSREは他職種に比べてスクラムの導入・浸透が難しいと言われています。
そんな中で他社のSREの具体的に実践した試みなどはブログなどで発信されることは多いですが、開発体制やスクラムの進め方そのものの知見が発表されることはそんなに多くないと感じています。
今の自分たちは(ある程度)納得のいく形でスクラムを進めていけているという自信があります。悩んでる方々へ1つの事例としての参考になればと思い応募させていただきました。

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

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

■ 発表の詳細（1000字程度）

本セッションでは、SREのキャリアパスを考えている人に向けて、スピーカーの実体験に基づいた具体的な事例や実践的なアドバイスを伝えたいと思っています。どのような人がスタッフエンジニアのような役割を担っていたのか、他社の事例なども含めて共有します。
また、エンジニアリングマネージャーの経験を持つスピーカーならではの視点で、管理職とスタッフエンジニアの役割や実際の働き方の違いや、それぞれのキャリアパスの特徴についても言及します。これにより、参加者が自身のキャリアを考える上での新たな視点を提供します。

以下のような構成を考えています。

1. はじめに
   スタッフエンジニアについて、一般的な定義や役割を説明し、エンジニアリングマネージャーなどのキャリアとの比較を行います。
   また、SREという組織におけるリーダーシップの特殊性について説明します。

2. SREスタッフエンジニアの役割
   スタッフエンジニアとしての役割や動き方を、実際の事例などを含めて紹介します。

   • 技術的な課題解決
   • システムの設計とレビュー
   • チーム横断的なプロジェクトのリード
   • 組織におけるSRE文化の醸成

3. 必要なスキルと能力
   求められるマインドや技術的な知識・経験について説明します。以下のようなトピックについて話す予定です。

   • 責任感と信頼感
   • システムアーキテクチャと依存関係の理解
   • クラウド・セキュリティ・コスト
   • 社内外のコミュニケーション
   • 意思決定
   • 長期的な視点
   • インシデント対応

4. キャリアパスの構築
   実際にどのようにしたらSREとしてキャリアを築くことができるか、考えを共有します。

   • スキルアップの方法
   • 組織内での認知度を高める方法

各トピックでは、理論的な説明だけでなく実際の業務シーンを想定したシナリオや、スピーカーが直面した具体的な課題とその解決策を紹介します。

■ 対象聴衆とその人たちが得られるもの

SREとしてのキャリアをより良くしたいと考えている人が、新たな視点を持つことができることを期待しています

■ なぜこのトピックについて話したいのか（モチベーション）
より多くのSREの人がエンジニアリングを続けて、現場で活躍して欲しいから

■ 発表カテゴリ
・Future: SREの未来と新しいトレンド

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

■ 発表の詳細（1000字程度）
「Platform Engineeringが成熟している組織ではSREは不要ではないか」という疑問が存在します。確かに、Platformが成熟すると、開発者とPlatformだけでReliabilityを担保できるように見えますが、実際にはさまざまな課題が潜んでいます。

まず、Platform Engineeringが様々なサービスやツールを提供するようになると、それに伴い認知負荷が増加します。開発者は多様なツールを効果的に使いこなすために時間を割く必要がありますが、その結果、もしサービス改善に充てる時間が減ってしまうと、本来の開発業務に集中できなくなります。このような状況は特に新しいツールやフレームワークが追加されるたびに起こりやすく、開発者の生産性に悪影響を及ぼすのです。

Platform Engineeringは多数のサービスチームを相手にするため、各サービスチームとの距離を縮めるのは非常に難しいという課題も抱えています。ユースケースや各チームのニーズを的確に吸い上げ、適切なソリューションを提供するのは容易ではありません。開発者が実際に求めている機能とPlatform Engineeringの将来的な方向性が必ずしも一致するとは限らないため、ミスマッチを生むリスクも存在します。

このような課題をBridgeとして埋めていくのがSREの役割であると我々は考えています。SREはEnabling Teamとして、サービスチームと一体となり、提供されるサービスに対する責任を持ちながらPlatform Engineeringと密に関わります。具体的には、サービスチームとのコミュニケーションを強化し、フィードバックを収集することで、実際のニーズや課題に基づいた改善を行うことが求められます。また、SREがPlatform Engineeringの一部の改善に関与することで、組織全体として効率的に機能するための仕組みを作り上げることが可能になります。

結果として、SREは単なる運用管理者ではなく、Platform Engineeringの成長とともに進化し、その中で重要な役割を果たす存在であることを示します。SREの活動を通じて、個々のサービスチームがより高い可用性と生産性を実現できるよう、さらに進化するための道筋を示したいと考えています。

■ 対象聴衆とその人たちが得られるもの
SREチームなどでSREのより効果的な実践を行う方法を模索しており、そのための手段としてPlatform Engineeringに注目している方々がターゲットとなります。
Platform Engineeringが確たるトレンドとなりつつある今、その中でSREだからこそ果たすことができる役割があることを認識し、その知見を持ってそれぞれのPlatform Engineering／SREの実践にフィードバックしていただけることを期待します。

■ なぜこのトピックについて話したいのか（モチベーション）
今回の発表では、メルカリSREとメルカリハロSREの2人が発表者となります。Platform Engineering時代のSREの新しい役割について、新規事業である「メルカリ ハロ」の立ち上げを具体例としてとりあげ、その裏側を紹介します。
もとよりメルカリグループではPlatform Engineeringの持つ力に注目し、比較的早い段階から注力してきました。一方、Platform Engineeringの進展とともにSREの果たすべき役割も徐々に変化しつつあると感じており、最適な姿がどうあるべきかを模索している段階です。
そういった状況の中、ゼロから新規事業を立ち上げる際に、どのように今までメルカリが10年間積み上げてきたPlatform Engineeringの資産を活用し、プロダクトのスピーディーな立ち上げにつなげた試みについて紹介し、フィードバックを得たいと考えています。
ハイレベルに抽象化されたas a serviceを提供するPlatformチームとビジネス価値をいち早く市場に届けるプロダクト開発チームの間で、開発者の現実課題をPlatformを駆使して解決に導き、安定稼働を実現するためにSREができることが何なのか。Platform Engineeringの持つポテンシャルを最大限に引き出すためのSREとしての関わり方について、活発な議論につなげていきたいです。

■ 発表カテゴリ
募集要項（ https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9 ） にある6つの発表カテゴリからお選びください

・Case Studies: 実際の導入事例や失敗談

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

■ 発表の詳細（1000字程度）
このセッションでは、監視SaaS 「Mackerel」 の運用において取り組んできたObservabilityの改善事例についてお話しします。セッションを通じて、Observabilityを改善する上での実践的な進め方やテレメトリーの計装に関する手法や知識を提供します。
まず、Mackerelのシステムを簡潔に紹介します。Mackerelでは、ユーザーの監視設定の不備や外部ネットワークの一時的な不調など、システム外の要因を考慮して監視機能を提供するシステムが正常に動作しているか観測する必要があり、システムの内部状態を正確に表現するテレメトリーの重要性について説明します。
次に、計装されているテレメトリー、特にメトリクスについて解説します。ここでは、メトリックの収集が容易なシステムメトリクスを利用していた状態から、テレメトリーの計装を進めたことによりObservabilityがどのように改善されてきたかを説明します。その過程で開発された、各種データベースへのクエリ結果をメトリックに変換・投稿するsql-metric-collectorやCloudWatch Logs に出力されたログを集計しメトリックとして投稿するcloudwatch-logs-aggregatorといったツール群や技術的なアプローチの変遷について紹介します。また、テレメトリーデータの計装・収集を目的としたプロジェクトであるOpenTelemetryの導入についても言及します。
加えて、テレメトリーの計装を通じたObservabilityの改善において実際に直面した課題、これに対するアプローチについても掘り下げます。具体的には、ログをメトリックを変換する際に気を付けるポイントやユーザー側の設定不備による異常を判別できるテレメトリーの計装といったサービス固有の課題への取り組みについてお話しする予定です。

■ 対象聴衆とその人たちが得られるもの
対象聴衆
Observabilityの改善に興味がある、あるいは現在進行形で取り組んでいるSRE、インフラエンジニア、アプリケーションエンジニア

得られるもの

1. Observabilityの改善事例
   サービスにおいて実際に直面したObservabilityに関する課題やそれに対するアプローチを共有することで、SREやソフトウェアエンジニアが自社のシステムにおけるObservabilityを改善する上での実践的な進め方を知ることができます。 計装手法も含めて改善の過程に焦点を当てることで、参加者自身がObservabilityの改善に向き合う上でのヒントを得る一助となればと考えています。

2. テレメトリー計装の具体的な手法や知識
   サービスで計装されている各種テレメトリーやその計装手法について解説します。参加者は、これらの計装手法や計装時のポイントからテレメトリーの計装に関する手法や知識を得ることができます。

■ なぜこのトピックについて話したいのか（モチベーション）
テレメトリーの計装、ひいてはObservabilityの改善はサービスの運用に携わるエンジニアの多くが一度は向き合ったことがある課題であると筆者は考えています。このようなトピックをセッションのメインテーマとして設定することで、カンファレンスでの対話や議論を促進し、セッションを通して参加者が直面している課題についても対話の場で掘り下げる機会を提供できればと考えています。
また、SREの実践事例ではテレメトリーの計装を通じた課題解決とその結果がフォーカスされることが多く、Observabilityの改善事例を参加者が参考にする上で、計装手法などの改善の過程により比重を置いたセッションがあってもいいのではないかと思い、このような発表内容でプロポーザルを提出しました。