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

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

■ 発表概要（400字程度）

国内のSREとPlatform Engineeringに従事している人はそれほど多くなく、その人口の少なさと担当する領域の近さからそれらを兼業している組織が多い印象です。

そのような中でメルペイは、メルカリのPlatform Engineeringチームが構築・運用しているPlatform上でマイクロサービスを運用しており、SREとPlatform Enginneringを分業しています。

本セッションでは、SREチームとPlatform Enginneringチームを分業している組織の一例として、それらのチームの役割の違いや、SREチームの活動について詳しくお話しいたします。

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

• メルカリの Platform Enginnering チームについて
• メルペイの SRE チームについて
• SRE チームと Platform Enginnering チームの役割について
• SRE チームの活動について、なぜそれらを行うのか
  --> マイグレーションのサポート
  --> プロダクトチームのサポート
• 分業することの pros/cons

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

国内のSREとPlatform Enginnering従事者は多くなく、その人口の少なさからそれらを兼業している組織が多い印象です。それらを分業している組織の事例の一つとしてご紹介できればと思います。

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

専業SREの事例を共有したい。

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

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

■ 発表概要（400字程度）

OpenAPI や Protocol Buffer を活用し、API スキーマを管理する重要性はすでに広く浸透している。さらには OpenAPI Generator や gRPC において自動生成を活用することによって、複数領域間で合意の取れたスキーマ定義からコードを自動生成することによる、認識齟齬の軽減と実装コストの削減を実現してきた。しかしながら、このアプローチが可能なのは API スキーマに限らない。より抽象化・拡張をして解釈すると「一つのドメインを複数から参照しうるもの」「複数に対して類似した処理を行っているもの」に対しての適用が効果的であると捉えることができ、より多くの事象に対しても適用することができる。
この解釈のもと、プロジェクト全体の多くの場所で自動生成活用することで、トイル徹底削減・情報集約・高保守性を実現した。
本セッションでは、自動生成の対象とすべきものの見極め方をはじめとし、実際に受けた開発速度・保守性に対する恩恵や、情報を集約することによる大幅な拡張性について紹介する。

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

本セッションでは、まず既存で活用されている API 開発におけるスキーマベースの恩恵について再度振り返りながら、その利点について整理する。その後、このアプローチをより抽象化していくことによって、API スキーマ以外での自動生成の転用に繋げるためのヒントを得る。これを元に解釈をより拡張することで、今までは自動生成の範囲外だと思っていた領域にも積極的に活用していくアプローチを確立するまでの流れを説明する。そしてこれらによって、今までの手動実装では実現できなかった新たなアイデアを実現した具体的な実装例を紹介する。最後にこの実装を運用することによって得られた具体的な恩恵を述べる。

以下のような流れでのセッションを予定している。

1. 既存のスキーマベース開発
2. スキーマベース開発における自動生成の活用状況
3. スキーマベースにおける自動生成の抽象化と拡張
4. 自動生成を中心とした開発における思考
5. 事例：「一つのドメインを複数から参照しうるもの」
6. 事例：「複数に対して類似した処理を行っているもの」
7. 自動生成によって得られた恩恵

「feature flag の横断的管理」「負荷試験シナリオの自動生成」「フロント・バックエンド・オブザーバビリティツールを跨る共通エラーコードと Runbook」「センシティブデータのマスキング実装」など、多岐にわたるより具体的な応用例を紹介する。これによって、実際に抽象化したアプローチから実装を実現するまでの流れをよりイメージすることが可能となる。

参考事例：

• 自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理
  https://speakerdeck.com/biwashi/runbook-to-minimize-operational-costs-using-automated-code-generation
• OpenFeatureと自動生成を活用したフィーチャーフラグの宣言的集約管理
  https://speakerdeck.com/biwashi/cloudnative-days-summer-2024-declarative-aggregated-management-of-feature-flags-using-openfeature-and-auto-generation
• k6を活用した再現性・拡張性の高い負荷試験基盤の構築 - Speaker Deck
  https://speakerdeck.com/biwashi/k6-protoc-gen-scenario

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

数多くの自動生成活用事例を知ることができるだけではなく、自動生成の対象をどのように見極めるかの根本のアプローチを知ることができるため、既存では実現し得なかった全く新しいアイデアによって、困難な課題を解決するための糸口を得ることができる。

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

これまで多くのカンファレンスやイベントなどで、様々な領域への自動生成を活用した事例について紹介してきました。今回のトピックではその根底となる「自動生成の対象となるものをどのように見極め、それをどう応用しているのか」といった部分について述べることで、自分だけでは想像していなかったような活用事例が今後より出てくることを期待しています。

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

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

■ 発表概要（400字程度）

株式会社メルペイでは、マイクロサービスのデータベースに Cloud Spanner を採用しています。
今まで、オートスケーラーやスケジュールドスケーリング機能の開発、Backup job の改善、ベストプラクティスの共有など、データベースの信頼性を高める活動を行ってきました。
それらの活動をどのような思想で行い、どのような成果を得たのかお話しいたします。

Cloud Spanner についての詳細な説明、運用上の tips など、信頼性改善の活動と関連が薄いトピックは本セッションで取り扱いません。

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

1. Cloud Spanner について(軽く)
2. Cloud Spanner の運用における問題
3. Autoscaler の開発と導入の効果
4. Scheduled Autoscaling の開発と導入の効果
5. Backup 改善の取り組み
6. ベストプラクティスの共有

3 ~ 6 における SRE の取り組みとして、以下をお話しする予定です。

• SRE チームの取り組みとして、Kubernetes Controllerの開発、Terraformモジュールの開発を行っている話し、それらをFinOpsと少し絡めてお話しします。
• プロダクトチームがオーナーシップを持って運用できるようにする仕組みについて

Cloud Spanner については SRE の取り組みに関わる最低限の話しだけします。

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

以下の知見を得ることができます。

• データベースの信頼性改善を題材に、どのようなことが改善を行うことが可能で、どのような思想でそれを行っているのか
• プロダクトチームがオーナーシップを持って運用できるようにする仕組みについて

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

SREの取り組みの一つとして共有したいため。

■ 発表カテゴリ

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

■ 発表概要（400字程度）

弊社ではInfrastructure as Code（IaC）を活用しており、仮想サーバで構築・運用しているサービスに対してはAnsibleを用いてセットアップ（インストール）、運用保守（アプリ更新や設定変更）を行っています。
しかし、組織として改善は多く試みたものの理想には到達せず、Ansibleは塩漬け状態に陥っていました。触ることができるメンバーが限られ、文化の浸透が進まないことによる心理的ハードルが高い状況となっていました。

そこで今回は、Ansibleの課題に焦点を当て、CI/CDパイプラインの改善を通じて開発者体験と品質向上を実現したプロセス改善を紹介します。
具体的には、CTOとチームでPath to Productionを議論し、パイプライン戦略を決定したこと、有識者からのレビューを元に更新した取り組みをお話しします。
CI/CDパイプライン整備することで開発者体験の向上と品質改善が向上され、クラウド移行プロジェクトでの恩恵もありました。

IaCのCI/CD周りに課題感を持っている方に改善事例や取り組みのポイントを持ち帰っていただけると幸いです。

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

Ansible CI/CDパイプラインのプロセス改善をどのように進めていったのかを中心に話し、組織やプロダクトにどのような影響を与えたのかを話します。

1: 長年塩漬けされたAnsibleの歴史と課題（課題発見、原因分析）

組織として過去に何度かAnsibleをはじめとした構成管理ツールを導入しましたが、運用に対して向き合うことができず、何度も塩漬けされることになりました。
こういった状況からメンテナンスもされておら開発者体験や品質が悪く、開発難易度も上がっていました。（テスト、CI/CDがない）
上記のような課題を抱える状況ではプロダクト開発・運用に悪い影響を与えてしまうため課題解消が必要でした。

2: 課題を解消するための解決方法（取り組んだこと）

CI/CDパイプラインの改善は簡単にキックオフ→あるべき姿を考える→フェーズ分割→実装→レビュー会という流れで進めました。
とくに解決に向けて良かった点が3点あります。

a: Path to ProductionをCTOのたたき台をもとにチームとCTOで考えることができたこと（効率的な進め方とフェーズ分け）

IaCのあるべき姿について、たたき台を作ってもらい共有の機会をもらいました。
チームとしては先行して必要になるであろうOffline Testsの整備を先に進めていたので解像度がすこし上がっている状態でした。
その上で過去運用ができていなかった点も実際の体験から議題に上げ、考慮するべき点を洗い出し、あるべき姿を全員で議論して作ることができました。

b: 見積もり結果を元に、まずは最小の独立したシナリオ（複数プレイブック）での実現を目指すことにした

初期見積もり時点では複数のシナリオに対してあるべき姿を適用しようとしました。
ですが長年運用しているサービスのため、シナリオ数も多くすべて適用しようとするとクラウド移行プロジェクトをはじめとして中長期のロードマップに影響が出てしまいます。
議論した結果、CI/CDパイプラインを最小の独立したシナリオ（複数プレイブック）で動かすことをまずは目指すことにしました。
最小の独立したシナリオを構築することで、他シナリオの展開もスムーズに行うことができ、クラウド移行プロジェクトにおいても円滑に進めることができるという判断です。

c: 第三者のレビュー・フィードバック会を途中で行い、あるべき姿の更新ができたこと（より品質の向上へ）

当初考えていた理想のパイプラインを独立したシナリオ（複数プレイブック）でほぼほぼ動かせる見通しが経ったタイミングで実施をしました。
パブリッククラウドサービスでSolution Architectを担当している方、社内でAnsibleを積極的に利用しているSREチームのエンジニアに見てもらいました。
その結果、Stack Tests周りでの提案をもらい、1日で実装を行い品質向上に繋げることができました。

3: 開発プロセスや組織に対する影響（取り組んだ結果や効果、今後の展望）

IaCにおいてもCI/CDを当たり前の状態に持っていくことで、セットアップ（インストール）、運用保守（アプリ更新や設定変更）においての開発者体験の向上や品質の向上を行うことができました。
また、運用ができていなかった塩漬け状態からあるべき姿を徹底的に考えることで、社内システムや運用状況に合わせたCI/CDパイプラインを構築することができました。
改善する土台を作ることができたので、品質向上においてまだまだ取り組むべきことや他プロダクトの展開を行っていきます。

4: まとめ（結論）

昔から存在しているサービスはオンプレミスでの運用が続いており、長年問題を抱えていたIaC（Ansible）の課題に向き合いました。
課題を解決するために、パイプライン戦略についてあるべき姿を議論したり、有識者のレビュー・フィードバックを得て、開発者体験の向上・品質の向上ができるCI/CDパイプラインを作ることができました。
CI/CDパイプラインを作ることで、クラウド移行プロジェクトにおける仮想サーバのセットアップを早め、運用保守を行いやすい体制を整えられるという恩恵を受けることができました。

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

• 対象聴衆
  • IaCにおけるCI/CDパイプライン戦略に興味がある、課題感を持っている、実際に改善に取り組んでいる方
  • Ansibleを利用しているエンジニア
• 得られるもの
  • どのような課題があって、実際に取り組みを行ったのか、実践的な改善事例を知ることができる
  • IaCにおけるCI/CDパイプライン戦略の考え方、CI/CDパイプライン構築の進め方

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

長年塩漬け状態にあったAnsibleの運用から脱却し、あるべき姿のCI/CDパイプラインを議論・構築することで、IaCでの開発者体験と品質を向上させることができました。
AnsibleのCI/CDパイプラインの事例が少ない中、最小の独立したシナリオ（複数プレイブック）にて、あるべき姿を約1か月半という短い期間で構築することができ、現在進めているクラウド移行プロジェクトにおいても活用することができています。
短い期間ではあるものの内容として濃い期間を過ごすことができ、学びも多かったので、他の組織やチームの参考となるように事例を共有したいと考えています。また、IaCにおけるCI/CDパイプライン戦略についてどうあるべきかも議論してみたいです。

■ 発表カテゴリ
・Culture: SRE文化の醸成と組織変革
SREsとソフトウェア開発チームの協働事例

■ 発表概要（400字程度）
SREの目標設計において、技術改善チーム（SRE）は「挑戦する全てのプロダクトチームのエンジニアの背中を支える」ことをミッションとしています。組織はプロダクトチームと技術改善チームで構成され、SREチームはプロダクト戦略と技術戦略の双方の意図を汲み込んだ「プロダクト技術戦術」を中心に活動します。
そうすることで、SREチームがどう技術改善を行い、事業貢献につなげていくかを考えており、単なる技術の改善だけでなく、プロダクトチームの生産性向上・事業貢献することを意識しています。具体的には、SLI/SLO策定やレガシーシステムのモダナイズ、DevOpsのパイプライン改善、技術的なガイドライン策定などを行います。

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

技術改善チーム（SRE）のミッション紹介

技術改善チーム（SRE）のミッションは「挑戦する全てのプロダクトチームのエンジニアの背中を支える」ことです。
SREはプロダクトチームを陰で支え、その生産性や開発速度を向上させる役割を担っています。
このミッションを達成するために、SREが事業貢献を目指し、プロダクト技術戦術に基づいて活動しています。

組織体制の概要

組織は「プロダクトチーム」と「技術改善チーム」の二つで構成されており、それぞれ異なる役割を持ちます。
プロダクトチームはプロダクト戦略の遂行を、SREはそのプロダクト戦略と技術戦略の両方に貢献するためのプロダクト技術戦術を担います。

目標設計の仕組み：プロダクト技術戦術の定義と位置付け

目標設計には「プロダクト戦略」と「技術戦略」が存在し、技術改善チームの活動は「プロダクト技術戦術」として具現化されます。
「プロダクト技術戦術」とは、プロダクト戦略に対して技術的な側面からどう貢献するかを具体化したものです。
これにより、技術改善チームはプロダクト戦略と技術戦略の橋渡しとして活動し、技術改善を事業貢献に結びつけています。

プロダクト技術戦術の具体例

SREの具体的な活動として、以下が挙げられます：
モダナイズとSLI/SLO策定：
レガシーシステムのモダナイズをイベントストーミングなどで行い、システムの信頼性指標（SLI/SLO）を策定（Perlの20年超のシステムの例）。
https://blog.engineer.adways.net/entry/2024/04/26/170000

DevOpsパイプライン改善：
Ansibleパイプラインの再定義やTerraformリポジトリの分割、フロントエンドへのFeature Flagの導入など。

テンプレートリポジトリ運用：
プログラミング言語ごとにテンプレートリポジトリを整備し、開発効率を向上。

プロダクト技術戦術の重要性と推進メンバー

「プロダクト技術戦術」を推進するためには、プロダクトチームのエンジニアや技術責任者、
PdE（プロダクトエンジニア）などが協力し、技術戦術の策定・実行をリードします。
議論・合意のプロセスには、プロダクト戦略と市場状況への理解、技術選定能力が求められます。

技術改善活動の共有とプロダクト技術戦術運用のポイント

技術改善活動の成果は、プロダクトチームと共有されることが重要です。
技術改善によってプロダクトの品質や速度がどう変わるのかを定期的に伝え、改善活動の重要性を理解してもらいます。
また、プロダクト戦略や技術戦略に変更があった際には、プロダクト技術戦術の見直しと更新が求められます。

SREチームでのガイドライン策定と役割

SREチームは、プロダクト開発への技術的貢献を意識し、開発ガイドラインの策定やプロダクトチームの開発体験の改善をリードします。技術改善のプロジェクトのタスクを単に遂行するだけでなくプロダクトチームの生産性向上や未来への開発サポートを重視します。そのため、プロジェクトの最後にドキュメント（ガイドライン整備や仕様書整備）と向き合うことを各チームで行っております。また、PdMと共感を形成し、プロダクト戦略と技術戦略の理解を深めることが求められます。

■ 対象聴衆とその人たちが得られるもの
・SREチームの目標設計を考えるエンジニアリングマネージャー

■ なぜこのトピックについて話したいのか（モチベーション）
・SREや技術改善を通した行動がどう事業貢献につながるかを考えているのかを共有したい

■ 発表カテゴリ
・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）
SRE の文化の醸成は単一の組織内で達成できるものではなく、様々な組織での SRE プラクティスや知見の共有により深まります。特に、大規模なエンタープライズで SRE の文化やプラクティスを適用することは難しく、複雑な知見やプロセスを必要とします。そのため、エンタープライズ特有のアプローチや知見の共有するコミュニティやイベントの場は、 SRE の文化を取り入れて組織の変革を促すために重要な機会となります。

本セッションでは、多様なテーマを扱うエンタープライズ技術コミュニティにおいて、SRE・オブザーバビリティにフォーカスしたイベントを主導した経験をもとに、運営としての苦悩と複数回のイベントの結果と得られた効果や与えられた影響をまとめます。最後に結論として、エンタープライズに求められる SRE の文化の形を考察し、エンタープライズを対象とした SRE イベント運営の意義をお話しします。

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

1. 一般的な SRE コミュニティの整理
2. Jagu'e'r Observability-SRE 分科会の紹介
3. SRE イベント活動の目的と振り返り
4. SRE イベント運営の苦悩
5. SRE イベントの結果とフィードバック
6. エンタープライズに求められる SRE 文化

本セッションでは、2024年を通して Google Cloud 公式のエンタープライズ技術コミュニティである、Jagu'e'r(Japan Google Cloud Usergroup for Enterprise) 内でオブザーバビリティや SRE をテーマとする Observability-SRE 分科会の立て直しと運営行った経験をもとにその知見を共有します。

Jagu'e'r Observability-SRE 分科会は、日本でいくつかある SRE コミュニティの中でも、エンタープライズにフォーカスをしたクローズドグループ内で組織された特殊なコミュニティです。こうしたコミュニティで、複数回のイベント開催し経験した苦悩と得られたものを赤裸々にご紹介し、今後のエンタープライズに所属する SRE に関わる方々に求められるコミュニティを通した SRE 文化の伝搬とコミュニティのあり方についてお話しします。

さらに、こうしたコミュニティ運営を通して得られた知見から、エンタープライズに求められる SRE 文化を考察し共有します。

■ 対象聴衆とその人たちが得られるもの
対象
・SRE の文化とプラクティスの共有を目的とする、SRE コミュニティに関わるすべての方々
・エンタープライズに所属する、システム提案・開発・運用・ビジネス分析などの IT システムに関わる方々
・組織内で SRE の文化とプラクティスの醸成に苦労している方々

得られるもの
・SRE 文化とプラクティスを共有する上で障壁となるエンタープライズ組織への理解
・SRE 文化とプラクティスを広める意義と方法
・エンタープライズに求められる SRE 文化の知見

■ なぜこのトピックについて話したいのか（モチベーション）
・エンタープライズ × SRE × コミュニティという特殊な組み合わせの知見を持つ個人として、さらにその知見を広める意義があるため
・SRE の文化やそのコミュニティの形態について、現状を整理し最適な将来像を模索するため
・Jagu'e'r Observablitiy-SRE 分科会の紹介と今後の活動方針を考察し提示する機会を得るため

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

■ 発表概要（400字程度）
この発表では、GCPのマネージドサービスとサーバーレスアーキテクチャを活用して構築した、ゼロトラストプロキシの設計と実装について紹介します。
本システムは、認証処理をGCPマネージドサービスに任せることで運用・開発負荷を軽減し、認可処理のみをサーバーレスで独自実装することで、柔軟かつ動的なアクセス制御を実現しています。
まず、システム開発の背景と複数の設計案を検討した上で、今回のアプローチを選択した理由を解説します。その後、システム全体の構成、採用技術のメリット・デメリットを詳述し、実際の開発経験を振り返ります。
この発表を通じて、ゼロトラストとSREの観点から、運用負荷を最小化しつつセキュリティを維持するシステム設計の実践的な知見を提供します。

■ 発表の詳細（1000字程度）
今回構築したシステムは、ゼロトラストセキュリティを小規模なユーザー向けに適用しつつ、開発と運用の効率化を実現するためのものです。
背景として、本システムを利用するユーザーは数十人程度と限られたユーザーしかアクセスしないため、大規模なインフラ管理や複雑な認証システムは不要と考えられました。
一方で、一定の要件を満たしつつ、HTTPプロトコルでの柔軟なアクセス制御を行う必要がありました。この背景のもと、いくつかの設計案を検討しました。

設計案は、主にAWSのマネージドサービスで開発した場合、GCPのマネージドサービスで開発をした場合、Tailscaleなどのゼロトラストサービスを利用した場合を検討しました。
これらの検討の結果、本システムはGCPのマネージドサービスでの開発を選択しました。

本システムでは、ユーザー認証をGCPのIdentity-Aware Proxy（IAP）に任せることで、ユーザープールの管理や認証ロジックの実装を簡素化し、セキュリティと信頼性を強化しています。
IAPの利用により、認証処理の独自実装を省くことで、開発・運用コストの削減とエンバグのリスク低減を目指しました。

認可処理においては、HTTPパスベースのアクセス制御を実現するため、Cloud Functionsを用いて独自の認可ロジックをサーバーレス環境で実装しています。
このアプローチにより、アクセス制御を動的かつ柔軟に行うことができ、システム全体のスケーラビリティと柔軟性を確保しました。

さらに、本システムの特徴として、Cloud NATを使用してプロキシからの出口IPを固定しています。
これにより、IPアドレスによるアクセス制御しかサポートしていないようなレガシーなシステムでも、このゼロトラストプロキシを簡易的に導入可能にしています。
この設計により、既存のサーバーに簡単にゼロトラストプロキシを導入できるようになりました。

本発表では、これらのシステムの背景や要件、複数の設計案の検討過程を紹介し、今回選択したアーキテクチャのメリット・デメリットを説明します。
具体的な技術選定や実装のポイント、運用時に得られた知見、今後の課題についても述べ、システム開発と運用における知見を共有します。

■ 対象聴衆とその人たちが得られるもの
この発表は、SREやクラウドインフラのエンジニアが対象です。
特に、マネージドサービスを活用してシステム運用の効率化を図りたい方や、サーバーレスアーキテクチャを導入して柔軟なアクセス制御を実現したい方にとって有益です。
聴衆は、ゼロトラストセキュリティを小規模システムにおける最適なアーキテクチャ設計や、実際の運用におけるメリットと課題について学ぶことができます。

■ なぜこのトピックについて話したいのか（モチベーション）
通常ゼロトラストプロキシの開発は、一定の開発コストがかかるため、大規模なシステムでしか実現が難しいと考えられます。
一方で小規模なシステムにおいては、Tailscaleなどの便利なゼロトラストサービスを利用することでシステムをゼロトラストにすることが可能ですが、認可制御が柔軟ではありません。
本発表を通して、小規模なシステムでも少しの開発と運用負荷で、効果的にゼロトラストセキュリティを導入できることを実証したいと考えています。

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

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

■ 発表概要（400字程度）

私たちの組織では、2024 年 1 月に一人目の SRE 担当を設け、私がその担当者となりました。
当初は手つかずだった課題への対応を進めていきましたが、その中で一人でおこなうことによる「属人化」と「スループットの限界」が課題になりました。
その経験と課題から、組織や体制づくりも必要と感じ、組織内で様々な施策を企画し、実行しました。
具体的には、全メンバーとの 1 on 1 形式でのヒアリングや輪読会、プロダクト開発チームへの介入と共有などを行っていきました。

今回の話では、一人の SRE が組織・体制づくりを進めるにあたってのきっかけや、組織づくりのために検討したこととやったことについてお話します。
また、進めていく中で気をつけたほうがいいことや、得られた結果についても併せてお話しいたします。

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

（１）私たちの組織について
ここでは、話の前提となる一人目 SRE の担当になった当初の組織の状況についてお話します。
具体的には、以下の内容です。
・発足当初の組織構成（プロダクト別の担当メンバーの人数、役割）
・発足当初に抱えていた課題やタスク

（２）一人目 SRE 担当としてのトライと学び
つづいて、発足当初で担当者として進めていたときの話とその経験での学びについてお話します。
具体的には、以下の内容です。
・担当者としてどのようにタスクを進めていたか
・どのようなタスクを対応していたか
・対応した結果のふりかえり
・そこからの学びと気づき
　- 属人化
　- スループットの限界

（３）学びと気づきへの対応：組織・体制づくりに向けて
一人でやっていくと、前述の気づきにもある超えられない壁（属人化とスループットの限界）が出てきます。
ここではその気付きと対策について検討した結果について共有します。
具体的には、以下の内容です。
・属人化への対応
　- チームに潜り込む
　- チームのスクラムイベントへの積極的な参加
　- 課題・タスクの移譲
・スループットの限界への対応
　- 文化醸成のための勉強会・輪読会
　- 将来的な体制の未来予想図とそのマイルストーンの作成
　- 担当メンバー候補検討のためのエンジニア全員との 1on1 形式のヒアリングの実施

（４）上記の対応に置いて、得られたものと課題
検討・遂行した施策において得られたものと今後の課題についてお話します。
具体的には、以下の内容です。
・得られたもの
　- 属人化の解消やその風土の醸成
　- メンバーの興味関心にフォーカスした相互理解 など
・今後の課題
　- 知識・素養のベースラインの向上
　- 取り組みの継続運用 など

（５）まとめ
最後に、今回の話のサマリ・まとめについて話します。

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

【対象聴衆】
・組織内で一人 SRE になっている方
・組織に対して SRE 文化の醸成を考えている方

【得られるもの】
・組織内で SRE を根付かせていくためのヒント
・SRE 担当を複数名でスケールアウトさせていくための施策の例

■ なぜこのトピックについて話したいのか（モチベーション）
モチベーションとしては、大きく以下の2点の理由です。
・自分が主担当で取り組んでいる活動であるから
・組織内に SRE 文化を展開していく中で、０→１の立ち上げ期や１→２、３といった成長の初期段階の事例は求められるものと考えているから

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

■ 発表概要（400字程度）
estieは「産業の真価を、さらに拓く。」をPurposeとして商業用不動産のDXを推進している100名規模のスタートアップです。
estieではSREを含めたPlatform Engineeringを実践し、開発生産性と信頼性を同時に追っています。本セッションでは、この活動で得られたナレッジやプラクティスを紹介します。

発表内容:

• 横断課題組織とSRE組織が一つに統合。そのPlatformチームに起きた変化とは
• プロダクトチームにどのような好影響があったか
• SREを進める上で再認識できた課題と、その解決ができるPlatform Engineeringとは

■ 発表の詳細（1000字程度）
2024年、estieでは、横断課題組織とSRE組織を統合し、新たにPlatformチームを発足しました。本発表では、このチームで取り組んできたSREおよびPlatform Engineeringの活動、そして得られた知見を共有し、スタートアップにおけるSRE/Platform Engineeringの一つの姿を提示できればと思います。

発表内容:

これまで、横断課題組織では以下のような開発生産性向上の取り組みを行ってきました。

• 開発環境を5分で立ち上げるツール開発
• 複数プロダクト間の連携が増える中、手元PCでの開発効率化を支えるツール開発
• Pull RequestをトリガーにPreview環境を立ち上げる仕組みの導入

これにより、プロダクト開発のスピードを大幅に向上させることができました。一方、SREは、顧客に安定した環境を提供するため以下の対応に取り組んできました。

• インフラ構成の見直し
• 監視・モニタリングの適正化
• Datadog管理やログの一元管理

当初、これらの組織は独立して運営されていましたが、時間が経つにつれて、カバーする領域の重複や協力が必要な場面が増え、プロダクト開発チームからも相談先がわかりにくいという課題が顕在化してきました。そこで、両組織を統合し、信頼性と開発生産性の両軸を担う「Platformチーム」が誕生しました。
2024年にこのチームでは、サービスローンチ前後のプロダクトに対して、横断課題組織とSRE組織が持っていたツールをプロダクト開発チームに定着させ、開発チームが独立して動ける体制を整えてきました。この取り組みを通じて得られた学びは次のとおりです。

• 信頼性向上のためにPlatform Engineeringの手法は非常に有効である(SREとPlatform Engineeringは高い親和性を持つ)
• SREは「片手間」でできるものではない
• 信頼性と開発生産性の二軸を追うことの重要性。一つのチームでこれらの指標を同時に追求することは、大きな成果を生む。

これらの知見を具体的に紹介し、セッションでは参加者とのディスカッションを通じて、より良いSREの実践方法を探っていきたいと考えています。

■ 対象聴衆とその人たちが得られるもの
対象:
SRE初学者(SREが気になっているソフトウェア開発者含む)

得られるもの:
信頼性を高める上でPlatform Engineeringの手法は使える
SREは片手間でできないよという一つの教訓
信頼性と開発生産性の2軸を一つのチームで指標として追うのは良いぞ

■ なぜこのトピックについて話したいのか（モチベーション）
スタートアップで少人数ながらSREを担っている人は多くいます。私自身も初めてスタートアップに転職し、SREとして働き始めましたが、スタートアップ特有のスピード感と同時に求められる高い信頼性の維持という課題に直面しました。その中で、SREとPlatform Engineeringの両方を実践することで、大きな成果を上げることができると確信しました。この経験をぜひ皆さんに伝えたいと考えています。

■ 発表カテゴリ

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

■ 発表概要（400字程度）

MOSH株式会社(以降MOSH)はAPIの実行基盤としてAWS APIGateway + Lambda + DynamoDB で動作し、SeverlessFrameworkで管理される形が取られている。
この構成のまま創業当初から継続して拡大したことでAPIの数は執筆時点で240個ほどに膨らみ、数が増えるにつれて様々な問題が起こった。
それらの問題を受けてMOSHでは現状の技術基盤が負債になっていると判断しAPIの実行基盤をLambdaからECSに移行するために基盤の改善を行うことにした。
その移行過程としてLambda-lithという1つのLambdaで複数のエンドポイントを捌けるアーキテクチャを採用し、APIに関するLambdaの数を減らす動きをしている。
本稿ではLambda-lithを採用するまでの技術的な意思決定の事例を紹介し、その後の複数のAPIのLambdaを1つにまとめてどのように移行したのかという実施方法とそれによって得た知見について話をする。

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

MOSHは「情熱をめぐる経済をつくる」をミッションにクリエイターがWeb上に店舗を作成し、スケジュールのマッチングやスキル・コンテンツの販売、会員向けページなどを提供しているWebサービスである。

MOSHはAPIの実行基盤としてサーバーレスアーキテクチャを採用しており、AWSサービスのAPI Gateway + Lambda + DynamoDBを組み合わせてバックエンドが構成されている。
またSeverlessFrameworkをIaCとして採用しており、Lambdaに関わるリソースがServerlessFrameworkを通して作成されたCloudFormationで管理されている状況になっている。

創業当初から上記の実行基盤と管理構成のまま継続して拡大したことでAPIの数が増えるにつれてLambdaの数も増加し(執筆時点で240個、API以外のものも含めると300個程度)して以下のような問題が起こった。

• CloudFormationのQuotasの上限に到達しデプロイができない
• 監視SaaSのコストの肥大化
• Lambdaのコードが肥大化することでZipのサイズ上限を迎えることになってデプロイができない
• ColdStartによるAPIの速度の低下

これらの問題に対応するためMOSHでは技術基盤が負債になっていて今後のプロダクト開発の足かせになると判断しAPIの実行基盤をLambdaからECSに移行するために基盤の改善を行ってきた。
その移行過程としてLambda-lithという1つのLambdaで複数のエンドポイントを裁けるアーキテクチャを採用した。
Lambda-lithとはHandlerを直接呼び出すのではなく、WebFrameworkがルーティングできる形に変換して1つのLambdaで複数のエンドポイントの動作を実現することが出来る。
(参考 https://docs.aws.amazon.com/lambda/latest/operatorguide/monolith.html https://aws.amazon.com/jp/blogs/news/comparing-design-approaches-for-building-serverless-microservices/)

Lambda-lithを動かすフレームワークとして我々はFastAPIを採用し、handler側で行っていたリクエストのバリデーション・変換をコントローラー層に実装して従来のユースケース層以下を変更しないように移行を行った。
当日はフレームワークなどの技術の比較検討の判断軸やどのような意思決定を行ったのかに触れつつ、Lambda-lithへの段階的な移行の方法について具体的な話をする。

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

• 対応聴衆

  • AWSクラウドでAPIの実行基盤にLambdaを採用し、サービスの成長に伴い大量のLambdaを抱えているSRE・インフラエンジニア
  • Lambda-lithを採用しようとしているバックエンドエンジニア

• 得られるもの

  • 複数のLambdaハンドラをLambda-lithに移すための知見
  • API毎に乱立しているLambdaをまとめて管理・監視SaaSのコストを下げるための手法の知見

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

サーバーの管理コストを下げるためにサーバーレスアーキテクチャを採用している企業は数多くあるものの、300個近くのLambdaを管理している企業はおそらく他にあまり例がないのではないかと思います。
MOSHの事例を発表することで今後APIの実行基盤としてLambdaを採用も考慮に入れている方々の判断の一助になることや、多数のLambdaを管理している基盤チームに移行の1つの事例として参考になるのではないかと考え応募しました。

■ 発表カテゴリ
・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環境の仕組みは機能開発以外にも汎用性が高く利用できる仕組みのため、聞かれた方の課題解決の選択肢になると考えています。

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

■ 発表カテゴリ

• Culture: SRE文化の醸成と組織変革
• Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

MOSH株式会社(以降MOSH)は監視SaaSとしてSentryを採用していて、フロントエンド・バックエンド両方でエラーが発生するとSlackに通知される仕組みになっている。
しかしMOSHのSentryのエラーはまったく整理されていないため狼少年化していたことやSentryが起票したエラーのトリアージを1人しか行っていない状態だったため様々な課題を抱えていた。
エラー通知の対応体制が弱いとバグによってプロダクトに障害が発生していたりUXが悪化していることに気付くことが出来ずに改善のサイクルを回せないといった状況に陥ってしまう。
この状況になっていることを組織課題として捉え、現在進行形でエンジニア全体でエラー対応を行えるように様々な取り組みを行っている。
本稿では課題があるエラーの対応体制から様々な取り組みを行ってチームの意識を引き上げ文化を醸成していった方法や投稿者が得た知見について話をする。

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

◯ 背景

MOSHは「情熱をめぐる経済をつくる」をミッションにクリエイターがWeb上に店舗を作成し、スケジュールのマッチングやスキル・コンテンツの販売、会員向けページなどを提供しているWebサービスである。
MOSHではフロントエンド・バックエンド共にエラーの監視をSentryというエラー監視SaaSを通して行っていて、エラーのIssueが発生すると全てSlackのエラーチャンネルに通知される仕組みになっている。

◯ 現状

以下のような状況でその人が対応してくれているので他の人は完全に任せきりな状態になっていた。

• 通知されたエラーの詳細を確認する人が1人だけ
• エラーの対応についてどのような意思決定が行われたかが分からない
• 機能開発チームが発生したエラーに気付くのはその人にメンションがされた場合がほとんど
• 現状のシステムがSentryのグルーピングにうまくマッチせず似たようなエラーが通知される

◯ 課題

上記の状態から投稿者は以下を課題として捉えた。

• 対応する人が1名のみでバス係数が低い
• どのような意思決定を行ったかが分からないので判断の妥当性を検証できず、引き継ぎも難しい
• MOSHが目指しているフルサイクルな開発に反し、機能開発チームが監視・エラー対応に対する意識が低く改善するサイクルを回せていない
• エラーが狼少年化しているのでエラーへの関心度が低くなってしまっている

◯ 取り組み

現状の課題を受けて以下のような取り組みを現在も行っている最中である。

• 開発チーム全員の時間を取ってエラーを確認する会を設けて全員でエラーを確認する
• エラーを確認のうえで対応するチームをアサインし改善する動きを促進する
• 転職したばかりの筆者でもエラー対応を行えることを見せることで、エラー対応の心理的ハードルを下げる
• エラーのグルーピングを行うことで似たようなエラーが通知されない状況を作る

当日の発表でエラー確認会を通して得た知見・失敗談・改善する取り組みなどについて深堀りをおこなったり、開発チーム全体にエラーを確認して修正する文化をどのように作ろうとしたかの話をする。

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

対象聴衆

• エラーが放置されている状況を改善したいがどのように対応してよいか分からない人
• 特定人物ばかりがエラー対応をしている状況に危機感を覚えている人
• 開発だけでなく監視・エラー対応も行うフルサイクルな開発組織文化を作りたい人

得られる知見

• 開発チームにエラーへの関心を持ってもらうためにどのようなアプローチをすればいいかの1つのパターンを学べる
• エラー対応がされないチーム状況に対して仮説を立てて施策を行い、どのように文化を醸成させるかの改善のサイクルを学ぶ

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

MOSH内での事例を紹介して文化の醸成をする手法について聴衆の方に感じ取ってもらえるものがあれば嬉しいと思いがあります。
また文化の醸成は難しく今ある組織の文化によってアプローチする手段は仕組みで対応するドライな方法から個々人に焦点を当てて響く言動を投げかけるウェットな手法まで様々な幅があると考えています。
Ask the Speaker中に議論や意見交換を行うことでそれぞれの組織の背景を理解し、どのような手法が効果的だったのかを知ることでお互いにより良い方法を発見して改善できる場に出来ればと良いな思っています。

■ 発表カテゴリ
募集要項（ 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の改善事例を参加者が参考にする上で、計装手法などの改善の過程により比重を置いたセッションがあってもいいのではないかと思い、このような発表内容でプロポーザルを提出しました。

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

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

■ 発表概要（400字程度）

従来から開発環境やステージング環境にはテスト用のデータが少ししか入っておらず、試したい動作確認をするためのデータ作成に時間がかかったり、パフォーマンスに重大な欠陥があってもデータが少ないために開発・ステージング環境では問題が起きず、本番デプロイしてから気づくなど、本番データと違いすぎることの問題を抱えていました。
また、AWSのサービスを利用した挙動を開発環境で再現できない問題もありました。
そう入った問題や、locastackやAWSのサービスを駆使して、本番データを安全に日次でステージング環境・開発環境に持ってきて、全エンジニアの生産性を向上させた話をします。

■ 発表の詳細（1000字程度）
主に以下の内容について話したいと思います。

・開発環境について

AWSのSNS、SQSを使った機能がありましたが、これをローカルPCで動く開発環境内で動作させることができず、SQSが叩くはずのAPIを手動で作成して実行したり、DBの値を直接書き換えたりして、その動作が行われた結果を再現していました。
これをなくすため、localstackを無料利用の範囲で利用することで解決しました。
無料利用だとコンテナを停止するごとに全て消えてしまうので、その問題を解決する方法も含めてお話しします。
これを実装した結果、SNS、SQSを使った連携機能もローカル開発環境でも完全に再現させることができるようになりました。
そういったlocakstackのノウハウの話をします。

・ステージング環境について

テストデータの量や種類が少なく、パフォーマンスのテストができなかったり、本番で起きた不具合を再現するテストデータ作りに苦労していました。
そこで、本番DBの値をステージング環境に日次でコピーする案を考えましたが、機密情報はマスクし、強大なデータを30以上の環境にコピーするという作業を深夜帯だけで行うには普通にはできませんでした。
それを解決するために、ECSonEC2などをうまく利用することで解決し、ステージング環境で本番環境をほぼそのまま再現することができました。
そのノウハウの話をします。

■ 対象聴衆とその人たちが得られるもの
開発環境やステージング環境でのテストのやりにくさを抱えている人たちに、道標となる情報を与えてあげられると考えています。

■ なぜこのトピックについて話したいのか（モチベーション）
これまでの仕事でずっとこの問題を抱えていたので、その仕組みの素晴らしさを世に伝えたいです。

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

・Tech: SREを支える具体的な技術や手法
・Architecture: SREの視点からのシステム設計
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

私たちのチームでは、100を超えるKubernetesから構成される社内向けのPlatform as a Serviceを運用しています。この運用において、利用者の増加に伴い大量のメトリクスが課題となりました。特に既存の監視基盤が耐えられなくなることが懸念されました。この課題を解決するために、私たちは様々な構成を試み、改善を行いました。

本セッションでは、現状の構成に至るまでの運用者の課題と解決方法を説明します。そして、利用者増に耐えうるスケーラブルなメトリクス監視基盤の構築と効率的なメトリクス圧縮及び保存の実現方法について説明します。特にメトリクス収集の監視基盤や改善を行った際の知見、実際のアーキテクチャやメトリクス量などを用いながら説明を行います。

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

• プロダクトの概要と特徴
  私たちのチームでは、100を超えるKubernetesから構成される社内向けのPlatform as a Service（PaaS）を運用しています。このPaaS上では150K以上のPodが稼働し、750K rps以上のリクエストを処理しています。

• 課題
  しかし、このPaaSの運用において利用者の増加に伴い大量のメトリクスが課題となりました。具体的には、既存の監視基盤が耐えられなくなることが懸念されました。メトリクスはシステムの健全性を監視し、パフォーマンスのボトルネックを特定するために不可欠ですが、メトリクス量が増加するにつれて、メモリやストレージの容量やクエリのパフォーマンスが問題となりました。

• 解決方法
  このような課題を解決するために、私たちは様々な構成を試み、改善を行いました。まず、メトリクスの収集方法を見直し、PrometheusやGrafanaなどのツールを活用して効率的なデータ収集と可視化を実現しました。さらに、データのストレージには、スケーラブルなデータベースを採用しました。具体的には、VictoriaMetrics Single Version と VictoriaMetrics Cluster Version を導入し、短期的なメトリクスと長期的なメトリクスの特徴に応じた効率的なメトリクス保存を行いました。現在のアーキテクチャに至るまでの変遷、それぞれのメリットとデメリットを共有します。

• 成果
  これらの手段を講じた結果、メトリクスの収集と管理が効率化されました。具体的には、以下の成果が得られました。

  • スケーラブルなメトリクス監視基盤：PrometheusによるスクレイピングとGrafanaによる可視化により、スケーラブルな監視基盤を構築が可能となりました。
  • メトリクスの圧縮と効率的な保存：VictoriaMetricsの導入により、メトリクスの圧縮が実現できました。それに伴い効率的なメトリクス保存が実現しました。
  • オブザーバビリティの向上：効率的なメトリクス圧縮の実現により、今まで実現できていなかったオブザーバビリティの向上が実現しました。

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

対象聴衆は以下になります。

• SREエンジニア
• DevOpsエンジニア
• システム管理者
• Kubernetes運用者

また本セッションから得られるものは以下になります。

• 大規模分散システムにおけるメトリクス収集および永続化の手法
• Prometheus, Grafana, VictoriaMetricsの活用方法および導入事例

■ なぜこのトピックについて話したいのか（モチベーション）
安定的なシステム稼働において、メトリクスの収集・保存は重要な要素の一つです。特に大規模なシステムを運用する場合、スケーラビリティやパフォーマンスなどの課題が顕著になります。
私たちは、同様の課題に直面している他のチームやエンジニアに対して、有益な情報と具体的な解決策を提供したいと考えています。
また、私たちのチームで行った解決策や解決までの道のりを共有することで、コミュニティ全体の技術力向上に貢献できると考えています。

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

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

■ 発表概要（400字程度）
「AWSをちゃんと使ってほしい！」
そういった思いでガイドラインをぶち上げた私達は、それが広まらないことに焦燥感と危機感を感じていました。最新のAWSサービスに対応してガイドラインを積極的に構築したり、ガイドラインに従った参照実装をテンプレートとして整備したり、使えるものにしようと努力は続けていましたが、それは利用者を省みない、独りよがりな活動になりかけていました。
利用者や利用者候補から積極的にフィードバックをもらい、開発の現場に入り込んでサポートする、そういった活動を通じて、なんとか利用者に向き合った活動として実を結びつつあります。
本発表では、私達のSREに向き合うに至った活動をふりかえり、大企業にSRE文化を醸成していく1事例をお話します。

■ 発表の詳細（1000字程度）
ダイキン工業では、ダイキン情報技術大学（DICT）という社内大学の取り組みを中心に、ITエンジニアを育成・教育し、空調機器を活用したソリューションの構築を効率的に実現すべく活動しています。
私達のチームは研究開発部門であるテクノロジー・イノベーションセンター（TIC）に所属し、それらのチームがAWSを始めとしたインフラ基盤を活用していくため、基盤を運用やルールの策定を行いながら、個別の開発テーマに伴走してサポートを行う、プラットフォーム + イネイブリングのSRE体制を実行しています。

しかし、この形に行き着くまでには様々な試行錯誤がありました。

始まりは、部内のAWS知識が偏在していることに危機感を覚え、他社事例を参考にガイドラインを作成したところからでした。
半年ほどかけてガイドラインを書き上げた時、達成感とともに手元にあったのは、２００ページを超える詳細なガイドラインでした。
社内に展開したものの、「果たして何人がこれを読んでくれるのだろうか？」と自問しはじめたとき…、次に”ガイドラインを読まなくてもデプロイしたら作れるAWSのテンプレート"を作り始めてしまいました。

…こうして重厚長大なドキュメントとテンプレートが整備されましたが、相変わらずそれらは「そこにあるだけ」の状態。作っただけの文字通りの「負債」となりかけています。

ようやくこれでは駄目だ、と危機感を覚え、ようやく社内の他の開発チームについてヒアリングを始めます。
幸いにして、AWSガイドライン自体は有用と受け入れてもらう声が多かったものの、レベル感があっていない記載も多く確認されました。
テンプレートも置いておくだけではなく、実際に使ってもらえるように自分たちで困っているチームに声をかけ、チームで入り込んて実装をサポート。結果的にプロジェクト自体を成功させるとともに、社内ルールにうまく合わせるためのフィードバックを得ることに成功しました。

何かを作って終わりではなく、それを活用していく仕組みそのものを回していく。その活用が必要だと気づいた時が、私達が「SREをはじめた」時だったのかと思います。

それ以降、Githubやセキュリティについてもガイドラインやルールを策定しましたが、それを開発チームが自然に守れるような仕組みをつくり、構築した仕組みを実際に利用してもらいフィードバックを受ける流れが生まれ、SREとしての活動が回り始めました。

こういった我々の試行錯誤のジャーニーを、SRE Kaigiの場で共有したいと思います。

■ 対象聴衆とその人たちが得られるもの
システム開発が本業ではない、製造系の大企業において、SRE文化を始めた1事例を知ることで、特に大企業の方が自組織にSREを根付かさせていく一つの助けになれればと考えています。

■ なぜこのトピックについて話したいのか（モチベーション）
もともと頭でっかちに活動を始めてからおよそ2年。技術的に拘泥しがちだったチームがようやく組織全体を見据えて動けるようになってきました。この体験は自分の中で大きなチームの成長物語であり、1チームの事例で留めるのではなく、広く共有しフィードバックをもらっていきたいと考えています。

■ 発表カテゴリ
・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つの発表カテゴリからお選びください

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

■ 発表概要（400字程度）

エンジニア20名、社員数60名程度の組織で2つのサービスを運営していたような会社で。
「Googleが提唱するような大規模な会社にしかSREは必要ないんじゃない?」という意見がエンジニアでも主流、ビジネ\
スではその概念すら無かった中。

少しずつ考え方を取り入れたり、プラクティスを実践してきた経験を通して。
小さな会社でもサービスの信頼性をあげてより多くの価値を届けるために必要だということをお話したいです。

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

インフラエンジニア不在でアプリケーション開発者が片手間にAWSの開発環境・プロダクション環境を管理する中。
開発効率をもっとあげよう、ということを発端にインフラエンジニアを置こうという話になり、私自身に白羽の矢が立ちました。

私自身がアプリケーション開発やそのサービス運用も担ってDevOpsをちょこちょこと実践していたので、旧来のインフラエンジニアにとどまらずサービスの信頼性を上げてより多くの価値を顧客に届けるにはSREの考え方を導入していくのがいいのでは、と考えてSREチームを立ち上げることにしました。

社内で開発チームのなかまやサービス運営チーム、経営層に必要性を説き、実践に移してきた過程。

トイル化していた運用タスクをコードを書いて軽減してみたり。
マネージドサービスの効用を説いて運営チームを説得してみたり。
SREの考え方をISMS運営に持ち込むことで経営層にもその効果を見えるようにしたり。

といった実例をお話し。

また、その過程から見えた課題をこれからどのように解決していくかという考え方を共有したいです。

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

これからSREチームをたちあげようとしている人たちにひとつのやり方を提示できます
小さな会社でビジネス的な面からのSREの効用を説得する材料にできるのではと思います

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

自身の試行錯誤のときに、特に規模感で「どうすればいいのか」「やりようはあるのか」で困ったので、いま困っている人、これから試していきたい人に共有してみたい。

■ 発表カテゴリ

募集要項（リンク）にある6つの発表カテゴリからお選びください

• Architecture: SREの視点からのシステム設計
• Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

MOSHはクリエイターエコノミー市場において、クリエイターの業務を円滑にし事業成長を手助けするオールインワンサービスです。クリエイターの事業は多種多様なため、サービスの初期開発においてはトライ&エラーを繰り返す必要があり、サーバーレスアーキテクチャを採用しています。サーバーレスの恩恵を受け、運用コストを低減させ、素早い機能開発を実現した結果、前年同期比率3倍という成長を達成しました。しかし、サービス運営から8年が経ち、Lambdaの数も300を超え、様々な問題が顕在化しています。本発表ではこれまでのバックエンドアーキテクチャと顕在化している課題、そして現在行っている対策についてお話しします。

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

これまでのMOSHサービスのバックエンドアーキテクチャ MOSHサービスのバックエンドは以下のサービスを組み合わせたサーバーレスアーキテクチャにより構成されています。

• Amazon Cognito
• Amazon API Gateway
• AWS Lambda (Python)
• Amazon DynamoDB

これらの技術スタックはサービス初期において運用コストを低減し、素早い機能開発を支援しました。しかし、サービス運営から8年が経ち、Lambdaの数も300を超えており、様々な問題が顕在化しています。

■ 顕在化した課題

実際に顕在化した課題は以下の通りです。

• アーティファクト肥大化によるコールドスタート時のレイテンシ
• CloudFormationのリソース上限数に達し、デプロイができなくなった
• ZIP形式のLambdaアーティファクトのサイズ上限に達し、デプロイができなくなった
• 監視SaaSの課金体型がLambdaの数に比例するためコストが増加

これらの課題に対して、我々は半年にわたり改善を行っています。

■ 対応

以下のような対応を行っています。

• アーティファクトのDocker化
  • 上限サイズが緩和されるため
• Lambda-lith化
  • これまではAPI Gatewayから直接Handlerとして各Lambdaを呼び出していましたが、1つのLambdaに対してFacadeとしてのLambdaを設置しています。
  • RouterとしてFastAPIを使っています。
  • 参考: https://aws.amazon.com/jp/blogs/news/comparing-design-approaches-for-building-serverless-microservices/

■ これからのアーキテクチャ

• まずはシンプルなFastAPIとしてLambda-lithで動かすことにより、CloudFormationのリソース上限やコールドスタートの問題を解消します。
• 次にコンテナ技術をさらに活用するために、Amazon ECS・Amazon EKSへの移行を検討。
  • Docker上にFastAPIアプリが動いているシンプルなアプリケーション構成に移行した事で選択が視野に入ってきました。

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

• 成長期に300のLambdaを使用したWebサービスのリアルな問題と対応事例を知ることができます。
• サービス初期に活用したサーバーレスアーキテクチャに対し、今後のスケーラビリティを確保するためのアーキテクチャ変更の事例を知ることができます。

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

サーバーレスアーキテクチャを活用して高い生産性を得ているプロダクトは多いと考えています。
私自身も、300のLambdaを使用したWebサービスの運営に携わるのは初めてであり、多くの新しい学びがあります。
一方で、類似の事例やスケーラビリティを得るためのアーキテクチャの事例はまだ少ないと感じています。私たちが直面し、学んでいることが、皆様のお役に立つ事例になるのではないかと考え、応募に至りました。

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