プロポーザル

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

■ 発表概要（400字程度）
本発表では、現在所属する組織での Platform SRE への SRE 組織の変遷についてお話します。これまでは個別のサービスに対して信頼性エンジニアリングを行う Embedded SRE の体制を敷いていましたが、今年の後半から組織全体に向けての信頼性エンジニアリングを支援する体制に一部をシフトしました。

SRE は信頼性に対する考え方だけでなく、サービスを支えるサーバーインフラ、CI/CD、セキュリティ、オブザーバービリティ、AI など専門的な知識が求められ、把握しなければならないトピックが広くあります。組織の幅広いサービスに対して、Platform SRE としての支援を推進するためにどのトピックから始めたかを中心に、なぜ選んだか、どのように進めたか、進めた結果どうなったかについて話し、所属する組織の SRE の組織変革について共有します。

■ 発表の詳細（1000字程度）
スケールしない Embedded SRE としての働き方の限界

入社してからこれまで Embedded SRE として、複数の事業に関わり様々なサービスの信頼性エンジニアリングに携わってきました。しかし、サービス規模の拡大や他サービスとの連携が増加する中で、エンジニア間のサーバーインフラ、 CI/CD, オブザーバビリティといった特定のトピックでの考え方やスキルの差を感じたり、サービスごとの最適化を行うことによるコンテキストの増加の負担を感じ、 Embedded SRE としての限界に不安を抱くようになりました。部分最適が進む Embedded SRE としての問題が組織の認識するところの課題になり、解決すべき問題となりました。

Platform Engineering チームの誕生とゴール

これまではサービスの信頼性エンジニアリングに対する活動がサービス内部に閉じられており、 SRE のナレッジや活動を集約したり展開する仕組みがありませんでした。そこで Platform Engineering チームが誕生しました。Platform Engineering チームは部分最適化されたサービスの中でも成功した基盤技術を集約し、他のサービスへプラットフォームとして展開します。すでに確立された技術基盤をプラットフォームとして提供することで SRE のナレッジを組織全体のサービスの持続性のために役立てます。ゴールはすべてのサービスが繋がることで、持続的な共生関係が形作られ、サービスだけで信頼性エンジニアリングに取り組み続けられるようになることです。

Platform Engineering を始めるにあたって考えたことと始めた結果

様々な事業領域のサービスが存在する現在の組織では何からはじめるかが重要でした。このセクションでは SRE におけるどのトピックから、すでにある基盤技術をプラットフォームとして展開していくかといった判断の過程と、ゼロ地点からのスタートの取り組み、その後の展開、現在の状況について共有します。取り上げるトピックの一例には、サーバーインフラに対する考え方、オブザーバビリティがあります。

我々が Platform SRE という選択肢を取った挑戦の結果、何が起こったかを組織としての価値として振り返り、選択肢をとるに当たっての組織の段階や規模における SRE のアプローチのシフトについてお話してまとめます。

■ 対象聴衆とその人たちが得られるもの
SRE、エンジニアリングマネージャー、VPooE、CTO など、サービスの信頼性向上や生産性向上に携わるすべての人。

得られるもの:
・組織で SRE の働き方やサービスへの SRE のアプローチの変化を検討している人にとってのヒント。

■ なぜこのトピックについて話したいのか（モチベーション）
Platform Enineering, Platform SRE を始めるにあたり、すでに局所最適化が進みサービスを構成する要素がそれぞれ独立して確立している組織での進め方について、どう進めるべきかという疑問は少なくないと思っています。すでに動いているサービスに対して、どのように全体最適のアプローチを行っていくかというトピックについて一石を投じたく、今回の発表をしたいと思いました。

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

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

■ 発表概要（400字程度）

SRE文化を広めたい！と思っても、アプリケーションエンジニアにとってOps的な要素は「プロダクト開発を進めることを阻害する」ちょっと邪魔な存在として扱われることがあります。では、どうすればエンジニアがOpsに前向きに関わり、モチベーション高く取り組めるのでしょうか。本発表では、ポストモーテムを続ける中で見えてきた課題や、Sentryアラートのチューニング、DependabotのPRをマージしやすくする工夫など、実際の試行錯誤を交えながら紹介します。

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

1. ポストモーテムとインシデントマネジメント委員会の変遷

私たちは1年間ポストモーテムを継続的に実施してきましたが、次第に“ポストモーテム疲れ”が目立つようになりました。アプリケーションエンジニアにとっては義務的で負担の大きい活動に映り、Opsへの関心が下がったようでした。そこで、ポストモーテムのフォーマットを見直し、インシデントマネジメント委員会でのポストモーテムの管理方法を見直しを行いました。

2. Sentryアラートの改善

従来のSentry通知は件数が多すぎて“オオカミ少年アラート”状態になっていました。アプリケーションエンジニアが本当に対応すべきアラートが埋もれてしまい、結果的に信頼性向上にはつながらない状況でした。そこで、アラートを分類・整理し、重大度の高いものだけをSlackで共有するように調整しました。エンジニアが自発的にアラート対応を行えるよう、日々の見直しを行っています。

3. DependabotとAIエージェントの導入

Dependabot が作成するPRは、「PRを能動的に見に行かないといけない」「何をしていいかわからない」問題を抱えていました。そこで、AIエージェントを活用してPRの要約や修正を自動生成し、開発者が安心してレビュー・マージできる環境を整えました。単なる「ノイズ」だったPRを「品質を守る小さなOps活動」として受け止められるようにしてもらえるよう、働きかけを行っています。

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

自組織でSRE文化を広げたいSREやテックリード
SREとアプリケーションエンジニアの協働に課題を感じている方

アプリケーションエンジニアにモチベーション高くSRE文化を浸透させるための具体的なプラクティスを持ち帰っていただくことができます。

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

各社のSREの取り組みについて会話するときに、「アプリケーションエンジニアにOpsの文脈に興味を持ってほしい」という話を聞く機会が多いと感じました。所属組織でも直面している課題であります。そこで、私たちが試行錯誤してきたプラクティスを共有し、同じ悩みを持つ方々にヒントを持ち帰っていただきたいと思っています。

■ 発表概要（400字程度）

SREの実践は専門チームだけのものでしょうか？海外製の高機能なツールスタックが主流の今、あえて国産サービスを選ぶことで、組織全体でSREを実践する「SREの民主化」について提案します。
多くの組織では、高機能なツールの複雑さゆえにSREチームの専売特許となっています。しかし、国産サービスが持つ「ちょうどよさ」と「とっつきやすさ」により、開発者もプロダクトオーナーも誰もが信頼性向上に貢献できる文化を構築できます。
本セッションでは国産サービスを活用した「SREの民主化」の実践方法を紹介します。専門知識がなくてもダッシュボードを操作し、システムの健全性を理解できるようになることで、全員がSREマインドを持つ組織へと促しましょう。

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

従来のSREは特別な訓練を受けたエンジニアによって取り組まれており、海外製の高機能なツールスタックがその傾向を強めてきました。しかし、信頼性向上には組織全体の参画が不可欠です。本発表では、国産サービスの特性を活かしてSREを組織全体に広げる「SREの民主化」というアプローチを提案します。

なぜ国産サービスがSREの民主化を可能にするのでしょうか。海外製ツールの多機能性は、逆にSRE実践の参入障壁となっています。これらのツールは確かに強力ですが、その設定や運用には専門的な知識が必要です。一方、国産サービスは「必要十分な機能への絞り込み」「自然な日本語UI/UX」「充実した日本語ドキュメント」という3つの特性を持ちます。これにより、学習コストが大幅に削減されており、初心者でも迷わない設計になっています。

本セッションでは、国産サービスを活用してどのように「SREの民主化」をしていくのか示します。特に重要なのは、国産サービスのシンプルさと分かりやすさを活かして、開発チーム自身が主体的に実践できるようになるプロセスです。自分たちのサービスの信頼性に対する当事者意識を持ち、プロアクティブな改善活動を行うことで、組織全体でSRE文化が醸成されるのです。

実際に多くの日本企業が海外製ツールの導入後その複雑さに苦戦しており、一部の機能しか使いこなせていない、SREチーム以外は触れることすらできない、という声をよく耳にします。国産サービスは、日本の組織文化と開発現場の実情を理解した上で設計されているため、このような事象を回避できます。

SREの民主化は組織の信頼性文化を根本から変革する挑戦です。国産サービスの活用により、SREを「特別な人たちの仕事」から「全員で取り組む文化」へと転換できます。海外製品に依存しない「全員参加型のSRE」という取り組みで、SREの新たな可能性を切り開き、より多くの組織で信頼性向上を実現していきましょう。

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

対象聴衆

• SREチームを立ち上げたいが、専門人材の確保に悩んでいるエンジニアリングマネージャー
• SRE文化を組織全体に広げたいSREエンジニア
• 開発チームでもSREプラクティスを実践したい開発者
• 小規模チームでSREを始めたいスタートアップのエンジニア

得られるもの

• 国産サービスを活用したSRE実践の具体的な方法
• SREの専門知識がなくても始められる信頼性向上のアプローチ
• 組織全体でSRE文化を醸成するための実践的な施策
• 日本の組織文化に適したSREの導入・展開方法
• 高額な海外製ツールを使わずに始められるSREの第一歩

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

SREは本来、システムの信頼性を組織全体で向上させる取り組みです。しかし現実には、高度な専門知識と高額なツールが必要とされ、多くの組織でSREチームだけの活動に留まっています。

私はこの状況を挑戦すべき課題だと考えています。国産サービスの「わかりやすさ」と「使いやすさ」を活かすことで、SREを民主化し、全員が信頼性向上に貢献できる文化を作れると確信しています。

日本での文化的背景を活かし、海外とは異なる「全員参加型のSRE」というアプローチを提示をしたいです。

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

■ 発表概要（400字程度）
「SREプラクティスの全社導入、皆さんうまくいっていますか？」
SLOの横断的導入を進めていく中で見えた、SREとプロダクトチームのコミュニケーションの課題とその対策についてご紹介します。

SREは、単に技術だけやっていればいいわけではありません。これを開発者にも理解し、実践してもらうことも重要な仕事です。
今回、SLO導入を全社横断で進めていくミッションを行いましたが、結果的に未熟なSLOが多くできてしまい、また文化の根付きもイマイチな結果になってしました。
このような結果に至った中で、技術的な壁よりも大きかったのは、SREとプロダクトチーム間のコミュニケーションの課題でした。

SREプラクティスを全社へ広げるために必要な「対話の設計」「失敗からの学び」を通して、“Challenge SRE!”の本質に迫ります。

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

freeeでは、各種プロダクトや基盤などのマイクロサービスが多く存在しており、私はこの中でSREとして各プロダクトチームへEnablingを行っていました。
その中の一環として、全社の品質向上の指標の一つとして、SLOの導入を行うことになりました。SLOを導入することで、ユーザ体験を可視化し、プロダクトの課題を迅速に修正することで、最終的にユーザへ価値ある体験を届けることが目的です。
導入に当たっては、最終的に以下のような流れで進行しました。

1. 一部プロダクトへSLOの試験導入
2. 全プロダクトへ横断的に導入
3. 導入が進んでいないプロダクトへEmbededし導入を完了させる

今回の導入に当たっては以下のようなポイントが重要です。

• 全体の前に一部だけで小さく始める
• プロダクトチームが自走でき、SREがボトルネックにならない導入
• Embededを通してプロダクトを知り、完遂させる

これらに気をつけることで、最終的には全プロダクトへSLOを導入することができました。

しかし、実際に導入されたSLOを見ると、エラーバジェットが定期的に枯渇していたり、SLIが不適切であったりと、まだまだSLO自体の信頼性が低くかったり、そもそもプロダクトチームにおいてSLOの運用が定着していないなど、多くの課題が残りました。

各プロダクトチームそれぞれの眼の前の課題ややることがあり、その中でどのように導入をしてくのか、適切にコミュニケーションを取っていくのが重要でした。
また、SREプラクティスの理解についても、プロダクトチームごとにばらつきがあり、なぜSLOを導入するのか、それによって何が得られるのか、工数をかける価値があるのかなど、十分な考慮が必要です。

現在は、これらの課題を解決すべく、新たな挑戦を続けており、こちらについてもぜひご紹介させていただければと思います。
導入が完了した今だからこそわかる、失敗とその改善点を共有します。

本セッションでは、SLOそれ自体についてお話はしません。SLOをプロダクトチームへ横断的に導入するに当たって、どのように彼らとコミュニケーションを取り、どうすれば防げたのかなど、SREプラクティスを全社展開する事例をご紹介します。

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

SREプラクティスをプロダクトチーム/開発者へ導入する際の失敗やその改善点を得られます。
Enabling SREとして、SREプラクティスを全社展開したい方に、我々の失敗を通じて、より良い導入の進め方を知っていただけます。

■ なぜこのトピックについて話したいのか（モチベーション）
世の中、何事も成功だけではありません。多くの失敗の上に成功があり、その失敗から学ぶことが非常に重要です。
また、SREは、単に技術をやればよいのではなく、それを組織に浸透させることがとても重要です。
特に今回のような全社導入のケースはなかなか事例としても少なく、我々の失敗が他の方の参考になればと思い、お話させていただければと考えています。

■ 発表カテゴリ

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

■ 発表概要（400字程度）

医療分野のSaaSでは、サービス提供者、顧客、そして何よりも患者にとって、セキュリティと可用性が最重要です。

私たちカケハシは、4つ以上の薬局向けSaaSを開発・運用する中で、厳しい医療要件とマルチプロダクト展開の課題に直面しました。私たちの組織規模や事業フェーズでは、イネイブリングを担うSREチームのみならず、基盤システムを開発・運用する開発チーム自身が信頼性へのオーナーシップを持つことが最も効果的だと考えました。

このセッションでは、共通基盤の開発チームが主体となり、以下の課題にアーキテクチャレベルで取り組んだ事例を紹介します。

• 品質要求の相反
  高い可用性とセキュリティ要件を満たしつつ、データの整合性・一貫性も確保する必要がある
• 顧客データのトレーサビリティ欠如
  障害発生時の原因調査やコンプライアンス対応が困難

これらの取り組みにより、新プロダクト開発時の認証実装コストを大幅に削減し、障害発生時の原因特定にかかる時間を短縮することに成功しました。

本セッションを通じて、SREという役割を持たない開発チームが、いかにしてサービスの信頼性を向上させられるか、具体的な方法を提案します。

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

背景

医療業界の特性

カケハシが提供するプロダクトのほとんどは医療情報システムとして患者情報を取り扱うため、セキュリティ要件が非常に厳しいことが特徴です。
例えば、厚労省・経産省・総務省が策定する通称「3省2ガイドライン」では、多要素認証の必須化、各種データの長期保存、パスワードポリシーの厳格化、監査ログの記録などが求められています。また、薬機法や個人情報保護法などの法令遵守も必要です。

加えて、可用性の高いシステム設計も求められます。医療機関は24時間365日稼働しており、システム障害が業務に与える影響は非常に大きいためです。
また、患者情報は非常にセンシティブな情報であるため、情報漏洩や不正アクセスを防止するための厳格なセキュリティ対策も不可欠です。一方で、薬局業界は法人間の薬局グループの統廃合が頻繁に発生するため、堅牢なテナント分離と柔軟な組織管理の両立が求められます。

マルチプロダクト展開

カケハシでは複数のプロダクトを展開している一方で、各プロダクトは独立した開発チームが担当しています。これにより、各チームは自律的にプロダクトの開発・運用を行うことができますが、同時に共通の課題として以下の点が挙げられます。

• 品質のばらつき
  各チームが独自に共通機能を実装しているため、セキュリティ要件の解釈や実装方法にばらつきが生じ、全体としての品質が低下するリスクがあります。
• 開発コストの増大
  各チームが同じような機能をゼロから実装するため、開発リソースが分散し、効率的な開発が難しくなります。

課題

品質要求の相反

認証基盤の刷新プロジェクトでは高い稼働率とセキュリティ要件を満たす必要がある一方で、ユーザー・店舗・組織などのディレクトリサービスでは稼働率に加えデータの整合性・一貫性が求められます。これらを両立するために、インフラアーキテクチャとアプリケーションアーキテクチャの両面で工夫が必要でした。

トレーサビリティの欠如

既存の顧客基盤では、最新のデータのみが保存され、過去に顧客がどのようなユーザー・店舗・端末・ライセンスなどを保持していたかの履歴が保存されていませんでした。そのため、障害発生時の原因調査や、顧客のコンプライアンス要件への対応が困難でした。

解決策

インフラレイヤ - データの永続化と配信

• PostgreSQLの行レベルセキュリティ
  顧客データを他の顧客から参照・変更できないようにするため、PostgreSQLの行レベルセキュリティを活用し、テーブルの行ごとに権限を制御しています。
• DynamoDBとOutboxパターン
  認証基盤では、高い稼働率と障害時の復旧容易性を実現するため、セッション情報などをDynamoDBに保存しています。また、ログイン履歴などの変更データを他プロダクトに配信するためのOutboxパターンについても解説します。
• Delta Lake形式によるデータ配信
  頻繁な変更が少ない顧客データ（ユーザー・店舗・組織など）はDelta Lake形式でS3に保存し、データ基盤や他プロダクトから参照できるようにしています。これにより、データの整合性を保ちながら、可用性とスケーラビリティを確保しています。さらに、Delta Lakeのタイムトラベル機能を活用することで、過去の状態を容易に再現できるようにしています。

アプリケーションレイヤ - データの整合性・一貫性とトレーサビリティの担保

• ドメインイベントの永続化
  顧客のユーザー・店舗・端末・ライセンスなどの変更履歴をドメインイベントとして保存し、過去の状態を再現できるようにしています。これにより、障害発生時の原因調査やコンプライアンス要件への対応が容易になります。また、既存の顧客基盤に対してはデータ基盤を経由してスナップショットからドメインイベントを生成し、システムのフルリプレイスを避けつつ、トレーサビリティを確保しました。
• マイクロサービスではなくサービスベースアーキテクチャの採用
  共通基盤が抱える顧客データは相互に強く関連し、強い整合性が求められます。そのため、マイクロサービスではなく、サービスベースアーキテクチャを採用し、単一のデータベースを共有することでデータの整合性を確保しています。加えて、各サービスではサービス間通信を原則禁止し、必要な場合は読み込み専用のDBユーザーを介してデータを参照する設計としています。

結果と教訓

結果

• 開発効率の向上
  認証・認可基盤を共通化したことで、新規プロダクト開発時にセキュリティ要件をゼロから考慮する必要がなくなり、開発者は本来のビジネスロジックに集中できるようになりました。
• 基盤の品質向上
  テナント分離とデータの整合性・一貫性、そして開発効率を両立するアーキテクチャを採用したことで、基盤全体の品質向上へ寄与しました。
• 障害調査時間の短縮
  顧客データの変更履歴をドメインイベントとして完全に追跡できるようにした結果、データ不整合や意図しない変更が発生した際の調査が容易になり、原因特定までの時間が大幅に短縮されました。

教訓

• RLSのマイグレーションとパフォーマンス
  誤った権限を適用するとデータ漏洩や欠損のリスクが生じます。
• スナップショットからのイベント生成の課題
  既存システムのデータをドメインイベントに変換する際、データの一貫性を保つために、イベント生成の順序やタイミングに注意が必要です。
• サービスベースアーキテクチャにおける共通ライブラリの危険性
  安易に共通ライブラリを導入すると、サービス間の結合度が高まり、独立したデプロイやスケーリングが困難になるリスクがあります。
• 即時性とのトレードオフ
  顧客データの変更を即時に他プロダクトに反映する必要がある場合、Delta Lake形式での保存は適さないことがあります。

関連する過去の公開資料:

• https://findy-tools.io/companies/kakehashi/91/97
• https://speakerdeck.com/kakehashi/building-an-authentication-platform-using-authlete-and-aws
• https://kakehashi-dev.hatenablog.com/entry/2024/09/19/110000

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

• 非SREチームであっても主体的にサービスの信頼性を高めたいと考えている開発者、テックリード
  具体的なアーキテクチャ設計や実装例を通じて、信頼性向上のための実践的な手法を学べます。
• ミッションクリティカルなサービスにおいて、開発チームがどのようにセキュリティや可用性の向上に貢献できるかを知りたい方
  医療分野に限らず、厳しいセキュリティ要件や高可用性が求められるサービスにおいて、開発チームが果たすべき役割と具体的なアプローチを理解できます。

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

マルチプロダクトSaaS企業に限らず、プロダクト同士が相互に連携するコンパウンドスタートアップでは、共通基盤の重要性が増しています。

しかし、多くの共通基盤チームはあくまでアプリケーションの開発者から構成されているため、SREのような専門的な役割を持たないことが一般的です。

そのような状況下で、限られたリソースしか持たない組織においても、開発チームが主体的にサービスの信頼性を高めることが可能であることを広く伝えたいと考えています。

医療業界に限らず、ミッションクリティカルな領域で日本や世界を支える開発者が、自らの手でサービスの信頼性を向上させ、ひいては人々の暮らしへ安寧をもたらすための一助となれば幸いです。

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

■ 発表概要（400字程度）
SREを導入するための指針として知られる「Dickersonの信頼性の階層構造」では、インシデント後のレビューが重要なステップとして位置づけられています。私たちの組織でもインシデント後にレポートを作成していましたが、それらは対応チーム内に留まり、組織全体の学びに十分つながっていませんでした。

この課題を解決するため「ポストモーテム共有会」を四半期ごとに開催しました。しかし第1四半期での初回は、初の試みで会の設計に不備があり、参加者が学びを持ち帰る仕組みとしては十分に機能しませんでした。そこで会の形式や進め方を再設計し、第3四半期で再挑戦したところ、活発な議論と知識の組織的共有が実現しました。

本発表では、この失敗と改善のプロセスを紹介し、インシデントを組織全体の学びに変える仕組みづくりと、そこから広がるSRE文化醸成の実践知を共有します。

■ 発表の詳細（1000字程度）
「Dickersonの信頼性の階層構造」では、インシデント後のレビューがSREを推進するうえで重要なステップとして位置づけられています。しかし実際には、インシデントレポートが作成されても、その内容は対応チーム内に留まりがちで、組織全体に知見が広がらないという課題があります。

私たちの組織でも同様に、インシデント対応後にはレポートを作成していましたが、それを読むのは関係者に限られ、学びが十分に共有されていませんでした。そこで導入したのが「ポストモーテム共有会」です。レポートを題材に議論する場を四半期ごとに設け、組織全体で学びを共有する仕組みを目指しました。

しかし、第1四半期に実施した初回は、初の試みだったこともあり会の設計に不備がありました。形式が固く一方通行になり、参加者が議論に入りづらい場となってしまい、十分に機能しませんでした。

この失敗を踏まえ、第3四半期には形式を再設計しました。発表は要点紹介にとどめ、質疑やディスカッションを中心に据えました。また、インシデントから得られた学びを整理し、次のプロジェクトに活かせる改善点を洗い出す仕組みを導入しました。さらに、個別の案件にとどまらず、組織全体に関わる課題が見つかった場合はGitHub Discussionで共有し、誰でも議論に参加できるようにしました。こうしたアウトプットにより、インシデントを「単発の振り返り」で終わらせず、次の行動につなげる仕組みを整えました。

その結果、第3四半期の共有会では活発な議論が生まれ、システム理解の向上だけでなく、失敗をオープンに語り合う文化が育まれました。「責任追及ではなく学びに変える」という姿勢が共有され、SRE文化の醸成に大きな一歩を刻むことができました。

本発表では、この立ち上げから失敗、改善、成功に至るプロセスを紹介し、参加者が自組織に適した共有文化を築くためのヒントを持ち帰れるようにします。

■ 対象聴衆とその人たちが得られるもの
対象聴衆:
• インシデントレビューを全社的な学びに広げたいエンジニア
• 組織のSRE文化を醸成したいエンジニア
得られるもの:
• 継続的なポストモーテム共有会を運営する実践的な工夫
• 学びを文化として根付かせるための組織的アプローチ

■ なぜこのトピックについて話したいのか（モチベーション）
「失敗から学ぶこと」はSRE文化の根幹ですが、実際にはレポートが共有されず、組織全体の成長につながらないことが少なくありません。私たちも最初は同じ課題に直面し、共有会を導入するも失敗に終わりました。しかし、その反省をもとに再設計したことで、ようやく組織全体の学びにつながる形に進化させることができました。

この経験は「一度でうまくいかなくても、工夫次第で文化を根付かせられる」ことを示しています。本発表では、そのリアルな試行錯誤を共有することで、同じ課題に取り組む参加者にとって実践的なヒントとなることを目指しています。

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

■ 発表概要（400字程度）
NewRelicは強力なオブザーバビリティ基盤を提供しますが、ダッシュボードが乱立し、整備状況にばらつきが生じる課題を抱えることがあります。私たちの組織でも棚卸しを行った際、重要度や粒度が混在し、整理や優先順位付けが困難でした。さらに、エンジニアの知識差が監視品質の差につながっていました。

この課題解決を主導したのはSREではなくアプリケーションエンジニアでした。Terraformを用いてダッシュボード設定をコード化し、開発チームが自律的に監視を整備できる仕組みを構築し、それにより、再現性と一貫性、レビュー体制を確立し、監視文化を広げることができました。本発表では、その実践と得られた教訓を共有します。

■ 発表の詳細（1000字程度）
NewRelicは、メトリクスやログ、アラートを一元的に管理できる強力なオブザーバビリティ基盤です。しかし、実際の現場では「必要に応じて誰でもダッシュボードを作成できる」柔軟さが裏目に出ることがあります。私たちの組織でも、ダッシュボード棚卸しを行った際に、重要度や粒度の異なるものが混在しており、整理や優先順位付けに多大な工数を要しました。また、NewRelicに関する知識レベルがエンジニアごとに異なり、プロジェクトによって監視の品質にばらつきが見られました。

この状況を改善するため、SREではなくアプリケーションエンジニアが主体となり、TerraformによるNewRelicダッシュボード設定のコード化に挑戦し、以下の効果を得ることができました。

1. 再現性と一貫性の担保
   コードで管理することで、誰が作っても同じ品質のダッシュボードを構築できるようになりました。
2. 変更管理の透明性
   監視設定の変更はPRを通じてレビュー可能となり、属人化や独断的な設定が防止されました。
3. 文化の浸透
   ガイドラインを整備することで、開発チーム自身が主体的にダッシュボードを用意できるようになり、オブザーバビリティ文化が定着しました。

本発表では、Terraformを活用した具体的な実装方法、導入プロセスで直面した課題と解決策、導入前後での運用コストの変化を紹介します。参加者は、SRE専任でなくても監視基盤を改善できるアプローチや、開発チームに監視文化を根付かせるための実践的な手法を持ち帰ることができます。

■ 対象聴衆とその人たちが得られるもの
対象聴衆:
• SREとして開発チームと協働しながら監視文化を広げたいエンジニア
• 自チームで監視基盤の改善を進めたいアプリケーションエンジニア
• TerraformやNewRelicのコード化に興味がある技術者
得られるもの:
• 監視ダッシュボードをコード化する設計と運用の実践知
• 開発エンジニア主体で監視文化を定着させる具体的なプロセス

■ なぜこのトピックについて話したいのか（モチベーション）
SREカンファレンスでは、SREが中心となって推進する事例が多く発表されます。しかし、私たちが経験したのは「アプリケーションエンジニア自身がSRE的な課題に挑戦する」という少し異なるアプローチでした。専任のSREがいなくても監視基盤を改善できること、そしてその取り組みが組織全体の文化にまで広がり得ることを共有したいと考えています。

この発表を通じて、「SREだけに任せるのではなく、開発エンジニアもSRE的な視点を持ち、行動できる」という可能性を示し、聴衆が自分のチームに持ち帰って実践できるヒントを提供することを目的としています。

「サービス変遷期におけるTPM兼任SREの役割、サービスレベル維持しつつトイル削減して価値向上に集中できる環境づくり」

■ 発表カテゴリ

・Practices: SREの実践例と得られた教訓
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

転職してきて最初に配属された「建設業向けコミュニケーションツール・現場クラウドConne」の開発チーム。
ベータ版として数十ユーザー向けにサービスを運用していた時期から5万ユーザーまで伸長してきた現在に至るまで、インフラ構成に少しずつ手を入れながら変化してきました。。

小さくはじめて少しずつ育ててきた実践例を通して、それぞれの課題に通してどのように向き合って。
サービスレベルを維持しながら、開発者スピードを妨げず、に変更を加えてきたのか。
また、TPM兼任ということでDevと密に連携を取りながら、時には自身もDevとして機能開発しながらSREの役割として信頼性の確保とサービスの加速、増え続けるトイルの削減といかに向かい合ってきたか。

事例や教訓を共有したいとおもいます。

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

私たちが開発・運用する建設業向けコミュニケーションツール「現場クラウドConne」は、その成長の過程で幾度となくアーキテクチャの変遷と運用の課題に直面してきました。
当初Webアプリエンジニアとして参画し、テクニカルプロダクトマネージャーへ役割が加わり、元インフラエンジニアとしての経験を活かしながら未経験SREとしても関わっていくというチャレンジの連続にあふれていました。

ベータ~サービス開始期: EC2オールインワンとあふれるアラート

サービス開始当初(2018年頃)は、EC2ワンボックスのオールインワン構成というシンプルな状態でした。
自社を含む数社の限られたユーザーの利用に限られていたため必要十分な構成とも言えましたが。
初期システムにありがちな話ですが、開発と運用を兼任する中で、頻発するエラーログやメトリクスのスパイクにあたふたする日々でした。
無差別なノイズは監視疲れを招き、開発のための時間や集中力を削っていくため、重要度に応じて緊急のものはアラームを発し、そうでないものはまとめてレポート形式で確認するよう変更、そもそもinfoレベルやdebugレベルのものはログレベルを是正していきました。

この頃はまだSREという言葉に馴染みがなく、DevOpsという文脈から監視のあり方を考えているような状態でした。

サービス立ち上がり期: ファイルI/Oの改善

徐々にユーザー企業が増えていき、建設業独特とも言える利用形態、現場に行く前、帰った後の時間帯、雨の日にファイルのアップロード、ダウンロードが集中するといった事態に出くわすことが増えてきました。

まずはファイルを一時保管していたmongodb/GridFSがリバースプロキシやアプリケーションとリソースを食い合う状況を、インフラを使いこなすのではなくサービスとして使い倒すという考え方からDocumentDBへ移行していきました。
また、同様にクラウドリソースの活用と、セキュリティと開発運用コストのバランスを取りながら、S3に保管しているファイルの多くを署名付きURLをかつようすることで、ファイルI/OやネットワークI/Oをアプリケーションから分離していきました。

SREという考え方、方法論を徐々に取り込み始めたフェーズです。

サービス成長期: からみあったアプリケーションをほどいていく

当初メッセージサービス、ドライブサービスから始まった現場クラウドConneでしたが。
徐々に(建設現場)案件管理、スケジュール管理、ワークフロー機能、ダイレクトチャットサービスなどアプリケーションが増えていきました。
アクセス時間帯特性もですし、アプリ同士のリソース競合、デプロイ複雑化による属人化などの課題が出てきました。
これに対してはリソースの分散のためにEC2インスタンスを複数用意して分離、さらにBlue/Green構成とすることで安全性も高めました。

このとき一足飛びにイミュータブルにしたり、コンテナやサーバレス化を推し進めなかったのは、どんどん増えていくアプリケーション・機能に開発メンバーのキャッチアップが大変になってきたことも考慮してバランスを取ったからでした。

まとめ

これらの経緯や取り組みをあげて、課題に対してとった方法や考え方をあげています。
まだSREのいないプロダクト、所々の事情から工数が限られるSRE、小さなプロダクトを育てていこうとしている方の一助になればと思います。

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

• まだSREのいない小さなサービスに携わっている人、これから携わりたい人には手始めに出来ることの例をいくつか示すことができると思います
• エンジニア、マネージャーなど何らかの職務を兼ねながらSREを務めている人など、手数が限られている場合の手がかりになればと思います
• 建設業などの比較的ニッチな領域のプロダクトに関心のある人に小さなプロダクトにもSREの手法、考え方が有効だと知ってほしいです

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

サーバー運用やネットワークインフラの経験はあったものの、SaaS運用は実質初めてだったので、最初は途方に暮れていました。
事例は大規模なものも多く、DevOpsやSREも最初は規模感が違いすぎて、では実際にはどうすればいいの、と思うことも多かったです。
小規模事例で徐々にサービスの成長に合わせてインフラも育てていくようなSREとしての取り組みを同じような状況におかれた方々と共有したいです。

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

■ 発表概要（400字程度）
私は多少インフラ系の知識を持っているプログラマです。
最近、初めてSREという言葉に触れ、そして学ぶ機会を得ました。
その中で強く感じたことが３つあります。
・「ロールを横断した”ワンチーム”」で対応するマネジメントの話である
・語源は「サイト信頼性」だが、現代においては「サービス信頼性」ということもできる
・技術的視点に加えて、サービス提供者としてのガバナンスが不可欠になる
つまり、SREはインフラエンジニアだけのものではありません。これはDDDやアジャイル、DevOpsといった開発の潮流とも共通しています。
高い質のサービスを提供するためには、チームの壁を越え、多様な視点を持つ必要があります。
本トークでは、プログラマとしてSREを学んで得た気付きを共有し、皆さんの実践のヒントとなることを目指します。

■ 発表の詳細（1000字程度）
私の開発の中心はクラサバで、仕事でクラウドやインフラチームと関わる機会は多くありません。
それでも興味の範囲が広く、少しだけインフラや運用の経験もあります。
いわば「ちょっとだけフルスタック寄り」のプログラマです。

そんな私が最近、初めて「SRE（Site Reliability Engineering）」という言葉を知り学ぶ機会を得ました。
正直なところ、最初は「インフラチームが運用を自動化するための話」くらいに思っていました。
短時間でしたが、それだけでも大きな誤解に気付くには十分でした。
そして、その学びを元に様々な人と交流する中で更に理解を深めることができました。
これらを通して得た気付きや発見を、SREコミュニティへの感謝を込めて共有したいと考えています。

SREの本質はもっと広く、深いものでした。
特に強く印象付けられたのは、次の3つです。

1.ロールを横断した“ワンチーム”で取り組むマネジメント
　SREは単に信頼性を維持する仕組みではなく、開発・運用・企画など、異なる職能が同じ目的のもとに協働するための考え方の軸であると理解しました。

2. SREの「S」は“サイト”ではなく、“サービス”に広がりつつある
   　クラウド化・マイクロサービス化へ進んでいます。
   　信頼性の焦点は「サーバ/サイト」から「サービス全体の体験」に移っていると分析しています。

3. ガバナンスの視点が不可欠
   　あらゆるサービスにおいて、唯一絶対の正解はありません。
   　システムを安定稼働させるだけではなく、組織としてどうリスクを受け入れ、どう価値を継続的に届けていくか
   　この問いにSREは踏み込んでいるのだと感じました。

これらは、私がこれまで学んできたDDD（ドメイン駆動設計）やアジャイル開発、DevOpsとも強く響き合っていると感じました。
SREの本質は単なる技術領域ではなく、サービスをより良くするための文化的・構造的アプローチなのではないでしょうか。
むしろ、開発者やマネージャー、さらにはビジネスサイドをも巻き込み、組織全体で“信頼性をどう設計するか”を問い直し続ける実践とも言えるでしょう。

このトークでは、SRE初心者である私が「SREを学んで見えた世界」を率直に共有します。
・SREの考え方が、なぜ今の時代に多くのロールと親和性を持つのか
・「信頼性＝チームの文化」という発想が、多様なロールのエンジニア個々のキャリアにどうつながるのか
・そして、サービスづくりにおける“人と人のインターフェース”をどう設計できるのか

SREをすでに実践している方には「異なる視点からの再発見」を、SREをこれから学ぶ方には「入門のきっかけ」を提供できればと思います。

■ 対象聴衆とその人たちが得られるもの
SREチームと関わるエンジニアやマネージャー、
そして、きっと会場にいる「SREをまだよく知らない開発者」。
そんな皆さんに、SREの本質を“インフラの話”ではなく、“チームで信頼性を育てる文化”として捉える視点を持ち帰っていただけます。

■ なぜこのトピックについて話したいのか（モチベーション）
単一のモチベーションではなく、幾つかの思いが並行して存在しています。
・私が気付いた「SREの本質」について多くの方に伝え、フィードバックを通じて更に理解を深めたい
・SREを知らない開発者にも、むしろ開発者にこそその「本質」を届けたい
・インフラエンジニアとは違う立場から見たSREへの気付きを共有したい
・なにより、様々な体験を通して多くの学びをくれたSREコミュニティに、感謝を伝えたい

■ 発表カテゴリ
・Architecture: SREの視点からのシステム設計
・Culture: SRE文化の醸成と組織変革
・Future: SREの未来と新しいトレンド

■ 発表概要（400字程度）
生成AIを用いたシステム開発・運用が急速に普及してきましたが、一方で生成AIとの共存が課題となっています。本セッションでは、生成AIを用いたシステム開発・運用において、なぜこれまで以上にSREのプラクティスが重要になってくるのか、その理由を述べ、その対策として求められるSREのプラクティスを振り返ります。また同時に、生成AIがあるからこそ、よりその価値が高まるプラクティスについても解説します。本セッションを聞くことで、今後のシステム開発・運用において、生成AIとSREが両輪となって、開発者、運用担当者、さらには他の多くの部署の人々にとって大きな価値をもたらす枠組みを理解できます。

■ 発表の詳細（1000字程度）
2025年10月現在の生成AIツールは大規模言語モデル（LLM）ベースのものです。LLMベースの生成AIは、指示に対してもっともらしい出力を生成する一方で、注意深く利用しないと人間が期待しない結果を混入させるなど、まだまだその利用において課題が多い状況です。現在の生成AIツールの利用に関しての議論は、特に個人〜小規模チームでの開発（機能の実装）の話を中心としたものがほとんどで、その成果物をどのように安全に本番環境に導入し、そして安定して運用していくかについては多く語られていません。

本セッションでは、SREで挙げられている継続的インテグレーション（CI）、Infrastructure as Code、カナリアリリース、オブザーバビリティ、インシデントレスポンス、ポストモーテムといった各種プラクティスが、なぜ生成AIを前提とした開発・運用プロセスにおいて重要なのかを「生成」「分析・調査」「要約」の3つの点から解説します。

まず「生成」に関して。生成されたコードの安全性に大きく寄与するのはテストです。CIによって機能要件だけでなく、非機能要件（特に性能品質）にまで及んでテストを行うことが今後ますます重要となります。またIaCの設定も生成AIで行う事例が増えていますが、これも必ずテストが必要です。危険な設定項目が変更されていないかなど、SREにおいて推奨されている事前チェックが活きてきます。テスト後のリリースでも障害範囲を最小限に抑えるためにカナリアリリースといったSREが推奨するリリース戦略が効果を発揮します。

次に「分析・調査」です。先にも述べたように生成AIは、多くを出力することに目が向きがちですが、その結果の精度を上げるためには適切なコンテキストが必要です。その観点では、実は運用こそ有効に活用できます。IaCはまさにシステムの設計・仕様と実際をつなぐ重要なコンテキストです。IaCが静的なコンテキストとすれば、オブザーバビリティは動的なコンテキストです。何が起きているかを理解する上で、オブザーバビリティは障害の原因究明のための大きなヒントとなります。

最後に「要約」です。生成AIによりインシデントレスポンスやポストモーテムにおいて、雑多にメモされ、かつ様々な場所に置かれた情報を整理して要約することで、SREに必要な文書生成の効率が大きく向上します。

このようなさまざまなSREプラクティスが生成AIを前提とした開発・運用で、効果を発揮し、また効率を上げられるということを一つ一つ解説していきます。

■ 対象聴衆とその人たちが得られるもの
実際にSREをいま実践している人々も、SREを実践していない人も、また生成AIの活用を積極的に行っている人も、これから導入を検討している人も、すべての人々が生成AIが普及した新しい時代のシステム開発や運用において、SREの価値がより高まることを理解できるようになります。

■ なぜこのトピックについて話したいのか（モチベーション）
私は日本においてSREが普及しはじめるころから、その啓蒙を積極的に行い、そのために日本のSREコミュニティにとって普及する価値があると考える多くの英語版の関連技術書籍を翻訳してきました。そんな中、技術者は生成AIという新たな道具を手に入れ、その普及が広まる中で、開発者・運用者不要論を唱えるような人まで出てきました。しかし、実際にはそのためには生成AIを正しく振る舞わせるためのコンテキストが重要で、そのための活動は実はSREで言われているようなプラクティスそのものが意味をなすということはあまり知られていないように感じます。

このような背景から、SREを知っている人には改めて新たな価値を認識してもらい、SREを知らなかった人にも新たに関心を持ってもらいたいと考えて本セッションを応募しました。

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

■ 発表概要（400字程度）
これまで、千株式会社のはいチーズ！ フォトEC開発チームにおいて、横断SREチームから異動しEmbedded SREとしてチームに参画し、活動してきました。
このセッションでは、Embedded SREとして開発チームに参画し、SRE活動をどのように浸透・定着させていったのかを、具体的な事例を交えて紹介します。

また、横断的に支援していたEnabling SRE時代との違いや、チームの一員として取り組んだ課題を通して見えてきた、Embedded SREのメリット、デメリットについてもお話しします。

■ 発表の詳細（1000字程度）
以下のような内容を予定しています。

• なぜEmbedded SREを手法として採用したのか
  • サービスが抱えていた課題
  • 開発チームが抱えていた課題
  • 横断SREが抱えていた課題
  • 他のSREプラクティスとの比較
• Embedded SREとしての活動
  • 開発チームに入りこむ
  • SRE活動の取り組みと成果
• まとめ
  • Embedded SREのメリット・デメリット

まず、開発チームと横断SREがそれぞれ直面していた信頼性の課題を紹介します。これらの課題がなぜ生じたのかを含め、Embedded SREを採用した理由を詳しく説明します。
セッションの中盤では、Embedded SREの導入と継続について、我々のチームでの成功例と失敗例を共有します。具体的な取り組みとして、SLI/SLOの導入、OpenTelemetryを用いたオブザーバビリティ導入によるアラートと障害対応の改善、そしてTerraformを活用した開発チームによるAWSリソース管理の実現などを紹介します。
最後に、Embedded SREの導入におけるメリットとデメリット、そしてどのようなチームにこのプラクティスが適しているかを考察し、セッションをまとめます。

■ 対象聴衆とその人たちが得られるもの
このセッションでは、以下のような人たちを想定としています。

• Embedded SREとしての取り組みをこれから始める人
• Embedded SREを導入するか検討している人
• SRE活動を浸透させるうえで困っている人

SRE活動を浸透させる方法として少しでも今後の活動のヒントになればと思います。

■ なぜこのトピックについて話したいのか（モチベーション）
SRE活動を行う上で、チーム間の問題で様々な困難に直面してきました。
Enabling SREとして活動して失敗した経験を持ち、Embedded SREとして活動し、新たな気づきを得ました。
組織間の問題でSRE活動がうまくいかないという経験をしている方もいるかと思います。
開発チームに入り込むことで何が変わってどういうことに気づいたのか、少しでも自分の経験談が役に立てればと思います。

■ 発表カテゴリ
・ Case Studies: 実際の導入事例や失敗談
・ Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）
Sansanの経理DXサービス「Bill One」では、2023年に外部IDaaSからAmazon Cognitoと自前OIDCサーバーを組み合わせた認証基盤へ無停止移行を行い、インフラコストを9割削減しました。
この取り組みは急速なユーザー増加によって顕在化したコスト課題の解決を出発点としましたが、最終的には「セキュリティと利便性」を両立する認証基盤として全社展開を進めるプロジェクトへと発展しています。AI契約データベース「Contract One」への導入を皮切りに、今後はSansan全体の社内標準として広がっていく予定です。
本発表では、当時40万人規模のユーザーを抱える環境での無停止でのシステム移行のノウハウ、少数体制でも運用可能なシステム構成とコスト最適化の工夫、さらに横展開での課題や社内標準化に向けたロードマップを共有します。

■ 発表の詳細（1000字程度）
○ 少数精鋭で運用可能な認証基盤のシステム構成
Bill Oneの認証基盤は、開発チーム3〜4名という少人数体制で開発・運用を行ってきました。限られたリソースでも高い信頼性を維持するため、ECS FargateやAurora Serverless v2、ElastiCache Serverlessなどのマネージドサービスを積極的に活用し、運用負荷を最小化しました。特にAurora ServerlessのオートスケーリングはBill One特有の「月末月初にアクセスが集中する」という特性への対応で非常に役立っています。また、Aurora Serverlessではクエリのパフォーマンスがコストに直結しますが、運用開始後もクエリの改善を継続的に行うことでコストの最適化を実践しています。

○ 無停止で基盤移行をするためのノウハウ
認証基盤の移行は、サービス影響を最小限に抑えるため「無停止」で実施しました。
そのために重要だったのは以下の点です。

• OpenID Connectの採用によりIdPを切り替えるだけで移行を実現できる構成
• 段階的リリースとロールバック可能な仕組みを組み合わせたリスクコントロール
• 新基盤へのログイン情報の自動移行によるユーザー影響の最小化

この仕組みにより、ユーザー体験を損なうことなく基盤の全面切替に成功しました。

○ 認証基盤内製化の成果と課題

• コスト削減：従来のIDaaS利用時と比較してインフラコストを9割削減
• 内製化による自由度の向上：内製化により独自の機能が実装しやすくなりログイン体験の改善がスムーズに
• 横展開による効果：Contract Oneへの導入でさらにコスト削減、プロダクト横断で統一したログイン体験を提供
• 新たな課題：マルチテナント構成でのデータ偏りによる性能悪化などの問題が顕在化。これを契機にテナントごとのオブザーバビリティの整備やDBチューニングの重要性を再認識
• プロダクトセキュリティへの貢献：WAF運用や不正ログイン対策を共通基盤で集中管理することで、個別対応の運用負荷を削減

○ 社内標準化に向けたロードマップ
従来、Sansanの各プロダクトは独自に認証基盤を構築しており、セキュリティレベルやUXにばらつきがありました。今回の内製認証基盤を社内標準とすることで、以下のメリットを目指しています。

• 開発者にとっての効率性：共通基盤により認証機能実装の重複を排除しプロダクトの開発に集中できる環境へ
• エンドユーザーにとっての利便性：共通のログイン体験を提供
• セキュリティ強化：共通基盤として継続的に運用改善を行うことで最新の脅威に対応

認証基盤は一度作ると塩漬けにされがちですが、実際には攻撃の巧妙化や新しい要件に日々対応する必要があります。本取り組みを通じ、認証を「維持コストのかかる仕組み」ではなく「セキュリティと利便性を両立する社内プラットフォーム」へと進化させていきます。

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

• 認証・認可基盤を担当するプラットフォームエンジニア
• サービス開発側で認証基盤やプラットフォームとの連携責任を持つエンジニア
• SRE・インフラ担当者で信頼性・コスト最適化をテーマとする技術者
• システム移行や基盤横展開の実例を知りたい技術者

得られるもの

• 認証基盤を内製する際に直面する設計判断やトレードオフ・コスト最適化
• 大規模ユーザー向けシステムを無停止で移行する実践ノウハウ
• 認証基盤を横展開・標準化するための戦略と実際の課題

■ なぜこのトピックについて話したいのか（モチベーション）
認証・認可は多くのWebサービスにとって欠かせない仕組みでありながら、“作って終わり” になりがちです。しかし実際には、セキュリティ・利便性・コストのすべてに継続的な改善が求められる領域です。
Bill Oneの認証基盤の内製化に深く関わる中で多くの苦労や工夫を経験し、そこから得た知見を「成功体験」だけでなく「失敗や学び」も含めて共有し、Webサービスがより良い仕組みを整えていく上での参考になればと思っています。
また、この取り組みは単なるプロダクト内の改善にとどまらず、社内の複数プロダクトへの横展開・ひいては社内標準へと発展しようとしています。SREの視点から見れば、信頼性・コスト・運用性が交錯する非常に挑戦的な事例であり、「Challenge SRE!」という本カンファレンスのテーマにも直結しています。
この発表を通じて、認証という地味だが本質的に重い領域に挑戦する仲間に、新しい視点と実践的な知見を提供したいと考えています。

■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓
・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）

ウェルスナビは、100を超えるアプリケーションが単一のAurora MySQLに接続し、約700テーブル・100億レコードを扱う巨大なDBが稼働しています。しかし、専任のDBチームが存在しない中での運用は限界に達し、ピーク時には負荷が上限に張り付くことも珍しくない状態でした。

SREチームはこの課題に対し、開発チームと二人三脚で改善を推進しました。Datadogによる負荷の可視化を起点に、クエリやインデックスの最適化、バッチ処理の分散、DynamoDBへのデータ移行、Aurora I/O最適化など10件以上の施策を進めました。さらに、負荷検証環境のセルフサービス化や、改善を継続する文化の醸成にも挑戦しました。その結果、DB負荷を90%削減し、レスポンス速度を倍以上に改善することに成功しました。

本発表では、「SREが技術と組織をつなぎ、開発チームと共に"改善を文化に変えた"プロセス」をお届けします。

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

私たちウェルスナビは、2016年から資産運用サービスの提供をはじめ、現在は50万人弱のお客様の1兆6,000億円の資産をお預かりするサービスへと成長しました。
組織も1チームから6チームに拡大し、システム面では100以上のアプリケーションが単一のAurora MySQLに接続する巨大構成となり、約700テーブル・100億レコードを扱う規模に達しています。

その反面、専任DBチームが存在しないDB運用は困難を極め、ピーク時にはDB負荷が上限に到達する状況も珍しくありませんでした。

特に難しかったのは、オーナーシップが曖昧な共有テーブルの存在と、Webアプリの遅延がバッチ処理の負荷に隠れるといった「原因不明に見える状況」でした。改善を進めようにも、負荷要因の切り分けが困難なままだと、担当チーム間で調整が進まなくなる懸念がありました。

この状況を改善するため、SREチームと開発チームが協力し、直近1年で10件以上の施策を推進しました。

・ Datadog Database Monitoring + APMを活用した可視化（アプリごとの負荷を切り分け、ボトルネックを特定）
・ クエリ数・インデックス改善（実行計画を元にインデックス追加や、N+1の対応）
・ バッチ実行開始時間を意図的にずらす実験（メトリクスの変化から因果関係を切り分け）
・ データ特性に応じたデータストアの変更（時系列データのDynamoDB移行）
・ Reader振り分け（アノテーションを活用）
・ Aurora I/O Optimizedオプションの有効化（嬉しい誤算と悲しい誤算）
・ 将来シミュレーション（3年後にリクエスト・データ量が10倍になった場合のシナリオを提示し、経営層や開発チームを巻き込む材料に）
・ 負荷検証DBのセルフサービス化（特定日時断面のマスク済DBを作成し、負荷検証できる仕組みを提供）
・ 改善を文化として定着化（パフォーマンスに影響するリリースの共有や、リリース後の振り返りの場を設け、継続的に改善が回る仕組みを確立）

結果として、DB負荷は90%削減。バッチ処理時間が大幅に短縮され、ユーザー体験に直結するレスポンス速度も倍以上改善しました。共有テーブルについても、可視化と分析結果をもとに、改善対象や調整窓口を明確化できる状態になりました。

本発表では、 「DB専任チームが不在の中でSREがオーナーシップを取り、技術と組織をつなぐことで成果を出す」というプロセスを中心に共有します。単なるチューニング事例ではなく、SREが担える役割の広がりに挑戦した実践例です。

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

＜対象聴衆＞
・ オーナー不在のコンポーネントに関わるエンジニア
・ 専任DBA不在でSREや開発チームがDB負荷改善を担っている組織
・ 技術改善を組織的・文化的に定着させたいSREリーダー

＜得られるもの＞
・ Datadogなどのツールを活用した実践的な可視化・切り分け手法
・ 「オーナー不在の共有テーブル」「バッチ vs Webの干渉」といった現場で起こりやすい課題への具体的アプローチ
・ 技術改善を一過性で終わらせず、継続的な仕組みに変えるためのSREの立ち回り方

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

共有DBの負荷改善は、直接的にビジネス成果につながると説明しづらく、SLI/SLOの定義も難しいため、後回しにされがちです。しかし、それを放置すればいずれ顧客体験や運用負荷の悪化につながります。

今回の取り組みでは、専任DBチームが不在の中、SREがハブとなって開発チームを巻き込み、技術的改善と文化的改善を両輪で進めることで成果を出しました。
この経験を共有することで、同じように「説明が難しい課題」に直面しているSREの助けとなりたいと考えています。

私たちSREチームは、地道なチャレンジの先にこそ、新たな輝かしいチャレンジが待っていると信じています。

■ 発表カテゴリ

• Tech: SREを支える具体的な技術や手法
• Practices: SREの実践例と得られた教訓
• Architecture: SREの視点からのシステム設計
• Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

10年稼働するプロダクトの月間数億レコードのアクセスログが、プロダクト間共有RDB運用の限界に達し、無停止移行が急務となりました。この移行は組織・技術における領域横断的な能力が求められ、単一領域だけでは解決困難でした。そこでアプリケーションエンジニアの筆者がSRE精神を発揮し、自身のケイパビリティを拡張してこの困難な移行プロジェクトにチャレンジしました。

本セッションでは2つのトピックをお話しします。

1. 月間数億レコードのアクセスログ移行における技術的知見

CloudWatch Logs エージェント、Amazon Data Firehose、Athena、AWS Glueを駆使したParquet形式+Snappy圧縮による月間数億レコードの無停止移行設計と、データ重複・欠損問題の解決策。

2. 領域を超えたSRE精神の発揮

既存の役割を超えたSREマインドの実践と、組織を巻き込む信頼性向上の方法論を紹介します。

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

1. 背景：アクセスログのRDB運用の限界

筆者は10年稼働するプロダクトのテックリードとして、月間数億レコードを超えるアクセスログをプロダクト間共有RDBで運用していました。このログは開発者の障害調査だけでなく、カスタマーサービスの顧客対応などでも利用される重要なデータです。しかし運用が限界に達しており、さらに組織的な事情により数ヶ月以内での移行が求められる状況でした。

2. 挑戦：アプリケーションエンジニアのSREチャレンジ

この課題解決には組織の領域横断的なスキルが求められ、単一領域だけでは解決困難でした。筆者はSRE領域のケイパビリティが不足していましたが、「システムの信頼性に重要なアクセスログが失われる」という危機感からSRE精神を発揮し、自身のケイパビリティを拡張してこの移行プロジェクトにチャレンジしました。

2-1. アクセスログ移行の技術的詳細

• CloudWatch Logs エージェント、Amazon Data Firehose、Athena、リアルタイムログ収集・閲覧設計
• AWS Glueを駆使したParquet形式+Snappy圧縮によるデータ量・コスト削減
• 管理画面を維持するためk8s上のRailsアプリケーションからAthenaを使う
• 最難関のデータ重複・欠損問題への対策
  • 初めてのAWSサポートケース起票
  • Amazon Data Firehoseを用いたログ収集設計における見落としと教訓
  • k8s上のSidekiq運用におけるpreStop戦略

2-2. 領域を超えたSRE精神の発揮

• ステークホルダー分析と要件の可視化（共有RDB利用の他プロダクト、データチーム、インフラチーム）
• SREチームとの協業で足りないケイパビリティを補う
  • インフラ設計
  • 慣れないk8s/terraformを用いたインフラ構築
• 技術的な制約をビジネス要件に翻訳して関係者調整
• 段階的リリース戦略による無停止移行
• 既存の役割を超えて誰でもSREマインドで行動できること
• 組織を巻き込んで信頼性向上を実現する方法論
  • 普段から領域を横断して関係性を築くこと

本セッションでは、これらの技術実装の詳細と、アプリケーションエンジニアが領域を横断し、組織と協力して信頼性向上に取り組んだプロセスとプラクティスを実体験ベースでお話しします。

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

1. 技術的知見
   • 月間数億レコード規模のアクセスログを無停止で移行する具体的な戦略とアーキテクチャ
   • CloudWatch Logs エージェント、Amazon Data Firehose、Athena、AWS Glue を駆使したParquet形式+Snappy圧縮の実践的な活用法
   • Rails + Athena を用いたアクセスログ検索システムの構築
   • データ重複・欠損問題の対策
2. SRE実践のプラクティス
   • アプリケーションエンジニアでも、自身のケイパビリティを拡張してSRE精神を発揮できるという実例
   • 組織横断的なプロジェクトを推進するためのステークホルダーの巻き込み方、調整の仕方
   • 専門チームと連携して自身に足りないケイパビリティを拡張する方法

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

この移行プロジェクトで得られた技術的知見は、類似の課題に直面するエンジニアの参考になると考えています。月間数億レコード規模のアクセスログ基盤のアーキテクチャ移行という課題への実践的なアプローチを共有することで、コミュニティに貢献したいと思います。

また、筆者は「SREは役職ではなく、魂」だと考えています。
組織においてSREの役職ではない筆者が、信頼性の高いシステム構築・運用における課題に Challenge し、実際に解決した経験をお話しすることで、SREが役職に縛られない、より自由なものであるということをお伝えしたいです。

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

■ 発表概要（400字程度）
BCP（事業継続計画）は企業存続のために中長期的に必要な施策です。SmartHRではSREチームがプロダクト観点でのBCPを担当しており、主にリージョン障害時のDR（ディザスタリカバリ）戦略を検討しています。

通常、BCPではRTO（目標復旧時間）、RPO（目標復旧時点）といった復旧目標を先に設定し、それに基づいてDR戦略を検討するのがセオリーです。しかし、この復旧目標設定では「事業を止めたくない」という要求と「コストを抑えたい」という相反する要求の間でトレードオフが発生します。このバランス調整が難しく、BCPを進める上での大きな障壁となっています。

私たちは、このセオリーをあえて覆し、復旧目標を先に決めず、最小限のコストで実現できるDR戦略から着手する「小さく始めるBCP」を実践しました。これは挑戦的なアプローチでしたが、多プロダクトを抱える私たちにとっては、最短でBCPを進めるための最善策となりました。

BCPを策定する方々が直面する課題を解決する一つのアプローチとして、私たちの実践から得た学びをご紹介します。

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

1. BCPとは
   • BCPが企業にとって必要である理由
     • 緊急時でもサービスを提供ができるようにする
     • BCPを策定していることでお客様から信頼を得られる
   • BCPにおけるDR戦略の標準的なアプローチ
     • 一般的にRTO（目標復旧時間）とRPO（目標復旧時点）などの復旧目標を最初に設定し、それに基づいてDR戦略を立てていく
   • BCPの普及を妨げる現実的な課題
     • BCPは企業にとって重要な施策であるにもかかわらずスキルや人材の不足により、全体の企業の約20%しか対策を立てられていない
2. SmartHRのプロダクトの現状とBCPにおける課題
   • SmartHRの多数のプロダクトと相互依存関係
   • リージョン障害に対する対策が万全ではない状況
3. 復旧目標（RTO・RPO）を決めないという選択
   • 多プロダクトにおける復旧目標設定における課題
     • 課題1: 理想的な復旧目標と技術コストのトレードオフ
     • 課題2: 各プロダクトで必要な復旧レベルが異なる
     • その結果、DR戦略の方針やどの程度のコストをかけるべきか判断できない
   • 「最小限のコスト」で始める方針
     • 理想的な復旧目標は誰も正解を知らないため、復旧目標は決めず「最小限のコスト」で対策を考えていくことから始めた
     • セオリーに反して挑戦的なアプローチではあったが、小さく始めることでDR戦略も考えやすくなった
4. 最小限のコストで実現できるDR戦略
   • 最優先で行うべきプロダクトを選定
     • 全てのプロダクトに復旧対策を行うのは費用対効果が低い
     • プロダクト間の依存関係を整理し、すべてのプロダクトに影響を与えるコアプロダクトを特定して最優先で対応
     • 最終的に最優先と判断されたプロダクトを直近の対応スコープとして設定
   • 現状のアーキテクチャでマルチリージョンに対応をしていない箇所を特定
   • 最小限のコストで行うため、全体の方針としては「コールドスタンバイ」を採用
     • アプリケーションサーバー（Cloud Run）はTerraformを利用した別リージョンへの復旧
     • データベース（AlloyDB）は定期バックアップを取得しておき障害時にリストアを実行
   • 復旧手順書の作成
   • 復旧手順書に基づいた机上訓練の実施
5. 今後について
   • 現実的なDR戦略をベースにした復旧目標の設定
   • 優先度の高い次プロダクトに対するDR戦略の段階的検討

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

対象聴衆

• BCPの構築を検討している方
• DR戦略について考えている方

得られるもの

• 小さくBCPを始めるためのヒント
• 最小限のコストでDR戦略を立てる時のアプローチ

■ なぜこのトピックについて話したいのか（モチベーション）
BCPは企業の成長フェーズによって必要な対策が様々に変化します。また、プロダクトの特性によってもDR戦略も異なります。このような様々な変数がある中でBCPを構築するのは非常に困難で、参考情報も限られています。そのため、小さく始めるための最初の一歩として何をすべきかを実体験ベースで共有することで、今後BCPを検討する方々に少しでも役立つヒントを提供できればと考え、このトピックを選びました。

■ 発表カテゴリ

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

■ 発表概要（400字程度）
薬局の在庫管理を支援するAI在庫管理というプロダクトにおいて、エンタープライズ導入が進みユーザー数が増加する中、システムのスケール性とユニットエコノミクスの最適化が求められていました。

医療系プロダクトという特性上、システムの品質や安定性は特に重要であり、データベースのインスタンスサイズを下げることは、システムの心臓部に手を入れる極めて勇気のいる判断でした。

クエリ最適化などでデータベース負荷を削減し、リードレプリカ導入により読み取り負荷を分散させ、メトリクスに基づく慎重な判断とモニタリングでインスタンスサイズダウンを実施することで、クラウドコストの削減を実現しました。

本セッションでは、リードレプリカの導入とインスタンスサイズダウンを安全に実現し、スケール性の向上とコスト削減を同時に達成したアプローチを共有します。

■ 発表の詳細（1000字程度）
私たちが開発するAI在庫管理は、薬局の在庫管理を支援するプロダクトです。医薬品の発注業務を最適化し、欠品や過剰在庫を防ぐことで、薬局の業務効率化と患者さんへの安定した医薬品供給を支えています。エンタープライズ顧客の導入が進む中で、システムのスケール性の確保とユニットエコノミクスの最適化という相反する課題に直面していました。

医療系プロダクトという特性上、システムの品質と安定性には極めて高い水準が求められます。データベースのインスタンスサイズを下げることは、システムの心臓部に手を入れる極めて勇気のいる判断でした。CPU不足によるクエリ処理の遅延、接続数の上限到達、メモリ不足によるパフォーマンス悪化など、一つの判断ミスがシステム全体の安定性を脅かします。そこで私たちを支えてくれたのが、メトリクスでした。

重いクエリ負荷を最適化し、リードレプリカの導入によってインスタンスサイズを下げられると判断するためには、データベースのメトリクスだけ見ていれば良いわけでなく、システムが日々どのように使われているかを理解する必要がありました。そのために次の2点が重要でした。

• データベースのクエリと各機能を紐付けた分析による、機能ごとの利用状況の可視化
• 日常的なダッシュボード確認による、業務や利用状況とシステムメトリクスの関連性の理解

APIごとの実行回数や実行時間、スロークエリ数、データベース負荷を集計することで、どの機能がどれだけ負荷をかけているのかを明らかにしました。この分析により、ボトルネックを特定し、スロークエリの改善や適切なインデックスの追加などを優先度つけて実施できました。また、読み取り系と書き込み系の負荷の割合も確認し、リードレプリカ導入の判断を行いました。

実際のインスタンスサイズダウン時には、薬局の営業時間外である夜間を選び、確認すべきメトリクスと即座にロールバックできる判断基準を事前に整えました。実施中はデータベースのリソース状況や日常的に確認しているダッシュボードを監視し続け、サイズダウン後も分析に活用したAPIごとの利用状況を頻繁にチェックしました。

結果として、リードレプリカの追加コストを考慮しても月額コストを削減でき、スケーラブルな基盤を構築できました。各フェーズで適切なメトリクスを見極め、APIごとの利用状況を分析することでシステムの使われ方を深く理解し、データに基づく意思決定と徹底的なモニタリングが成功の鍵でした。その実践例を皆さんと共有したいと思います。

■ 対象聴衆とその人たちが得られるもの
コスト削減とシステムの安定性という相反する課題に直面しているSREやインフラエンジニアの方々を対象としています。

• メトリクスに基づく意思決定の具体的なアプローチ
• APIごとの利用状況を分析することでシステムの使われ方を可視化する手法

■ なぜこのトピックについて話したいのか（モチベーション）
データベースのインスタンスサイズを下げることは、確実にコストダウンに効くと分かっていても「怖い」と感じる施策だと思います。私自身もそうでした。しかし、適切なメトリクスの活用とデータに基づく意思決定により、その恐怖と上手に向き合って乗り越えることができました。

医療系プロダクトという特に慎重さが求められる環境で実践した経験を共有することで、同じような課題に直面している方々の何かのきっかけになると嬉しいです。

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

・Tech: SREを支える具体的な技術や手法
・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）

高可用性を実現するために冗長化の設計をしてみたものの、「机上の確認では問題なさそうだが、実際に障害が起きた時に本当に動作してくれるかわからない」と不安になることは誰しも経験があるのではないでしょうか。少なくとも自分はあります。特にKubernetesの設定は複雑で本当に機能するのかに自信が持てませんでした。
ではどうするか？という一つの回答として、できるだけ障害に近い状況を再現して試してみました。今回はKubernetesのPDBやトポロジー制約等のアプリケーションの可用性を担保する仕組みを諸々設定し、さらにAWS Fault Injection Simulator（FIS）を活用してカオスエンジニアリングとして意図的に障害を発生させ動作確認をしました。
本セッションでは、設定した可用性対策についての解説とそれを実際に検証して上手くいったことや上手くいかないことを赤裸々にお話しします。

■ 発表の詳細（1000字程度）
前半はEKSによるアプリケーションの可用性を担保する設定について紹介し、後半はFISでの検証を中心にお話しします。
詳細は以下のアジェンダを想定しております。

• EKSによるアプリケーションの可用性の確保の設定についての紹介

  • トポロジースプレッド制約を活用し、Podを複数のAZに分散配置することで、単一AZ障害時の影響を最小化する仕組みについて
  • Pod Disruption Budget（PDB）の設定により、意図しないPod削除を制御し、アプリケーションの可用性を保証する仕組みについて
  • その他EKSの可用性担保の設定等の紹介

• FISを使ったカオスエンジニアリングの実践。設定した冗長化が本当に機能するかを検証

  • そもそもカオスエンジニアリングとは
  • FISの基本的な考え方。実験テンプレート作成とシナリオについて
  • Stop-InstancesとPause Instance Launchesを使ってAZ障害を再現してみる
  • PDBやトポロジー制約の設定をしたEKSの動作確認方法

• 検証結果と学び

  • FISカオスエンジニアリングを通じて得られた知見と、実際の運用での気づき
  • 検証自体の上手くいったこと、ハマったこと
  • 今後の改善点と継続的な検証の重要性

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

• 自分の設計したシステムの信頼性・可用性に自信が持てない方
• Kubernetesにデプロイしているアプリケーションの可用性の設計に興味がある方
• カオスエンジニアリングに興味がある方

【得られるもの】

• KubernetesでのPDBとトポロジースプレッド制約の実装方法
• カオスエンジニアリングの考え方とアプローチ
• 設定した冗長化の検証方法と継続的な改善プロセス

EKSやFISなどのサービスを例に説明しますが、AWSを利用していなくても、実際に試してみることの普遍的な重要さについてはお伝えできると考えています。

■ なぜこのトピックについて話したいのか（モチベーション）
「設定した冗長化、本当に機能するの？」この疑問を抱えながら運用を続けるのは、とてもストレスフルなことだと私は思っています。だったら実際に試してみようとFISを使った検証に挑戦しました。
試しに検証を行うことによって、仕様の理解が深まり、それが不安を払拭することにつながりました。そしてそれが結果的に信頼性の向上になったと感じています。この体験を通じて、同じような不安を持つ方の一助になればと思っています。

■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）
SREのプラクティスを用いてアプリケーションを信頼性高く運用していくことと同様に、データに関連する分野でも実践することができます。データ分野へのSREプラクティスの適用はDRE（Data Reliability Engneering）と呼ばれ、データの活用においては不可欠です。

千株式会社では複数プロダクトの横断分析のためデータ分析基盤を構築していますが、「データの件数があわない」「データが取り込まれていない」という問い合わせからパイプラインの障害に気づくようなカオスな状態でした。そこから信頼性のあるデータ分析基盤を目指して、SREのプラクティスを取り入れながら発生していた課題について段階的に対応していったこととその歩みについてお話します。

■ 発表の詳細（1000字程度）
SREのプラクティスを用いてアプリケーションを信頼性高く運用していくことと同様に、データに関する分野でもこれらのプラクティスを実践することができます。

このセッションではデータ分析基盤の構築の背景から構築の経緯、カオスな状況に陥っていた状態、そこからそれぞれの課題に対して行ったことを中心にお話させていただきます。
具体的には以下のような内容を予定しています。

1. 千株式会社のデータ分析基盤について
   千のデータ分析基盤の構築の背景とどう構築されてきたかについてご説明します。

2. 構築する中で発生していたデータ分析基盤の課題
   背景と構築状況を踏まえて、データ分析基盤に関わる方々の目線で発生していた課題について紹介します。

3. 発生していた課題についての対応
   データ利用者やデータエンジニアのそれぞれの視点で見えていた課題について深堀し、それぞれの課題についてどう対応したか・対応した結果どういった成果が得られたかについてご紹介します。

具体的には以下の内容を想定しています。

• データパイプラインの監視と計測
• データ分析基盤に関連するトイル削減とAIを活用した一部作業の自動化
• 個人ではなくチームとして対応していくための仕組みづくり

4. 今後の展望
   多くの課題に向き合っていったとしても我々のデータ分析基盤の改善はいまだ道半ばです。新たな要求が次々と生まれ、その都度新しい課題に直面しています。
   ですが、信頼性向上の取り組みで確実に何もない状態からの変化は起きており、「エラーが起きても気づけない」状態から脱却できたことは何よりも大きな一歩だと考えています。この経験を通じて得られたデータ分析基盤の信頼性についての考え方の変化と今後の展望についてお話させていただきます。

■ 対象聴衆とその人たちが得られるもの
プロダクトの開発者やSREの方々、データエンジニアの方々全般が対象です。データ分析基盤で起きうる実際の課題や課題に対する取り組みについて、私たちの例を通してヒントを得られます。

■ なぜこのトピックについて話したいのか（モチベーション）
ビジネスを考える上でデータ分析基盤の信頼性はアプリケーションの信頼性と同様に重要なものであると考えています。千のデータ分析基盤へのゼロからの信頼性向上の実践を紹介することで、これから取り組もうとしている方々の一助になれればと考えています。

■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓
・Culture: SRE文化の醸成と組織変革
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
本セッションでは、クラウド ETL サービス「TROCCO®」の1人目の専任 SRE として、 primeNumber の SRE チーム立ち上げからの取り組み、特にスタートアップ環境特有の課題にどう対応してきたかを共有します。

これまで、CTO や業務委託の方々、SRE として入社してくれた2人のメンバーと協力して様々な改善を行ってきました。
紹介する内容は、決して自分一人でやってきたことではなく、チームとして取り組んできた内容です。
また、スマートラウンドの山原さんの記事、「スタートアップの1人目SREが入社後にやってきたこと」と同様に、取り扱う内容は SRE の理論や原理原則に沿って各種プラクティスを実践したこと、というよりは、セキュリティ、モニタリング、IaC、コスト、パフォーマンス、運用、開発効率などなど、「いまこの組織で取り組むことでプロダクトと事業に貢献できるのではないか？」と自分たちなりに判断してきたこととなります。

このセッションを通じて、SRE チーム立ち上げ期における具体的な課題設定、運用プロセスの構築・改善、そして組織的な文化醸成に関する実践的な知見を提供します。
また、Corporate SRE というポジションをオープンし、SRE のプラクティスを「プロダクト以外」に広げていくという可能性を模索していくことにも言及します。

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

クラウド ETL サービス「TROCCO®」における1人目専任SREとして、3年間でチームと組織の信頼性を段階的に向上させてきた取り組みを紹介します。

◯ 入社〜6ヶ月：荒野の開拓期
システム構成図もなく、IaCも一部のみという状態から、まずは現状把握・可視化のために構成図の作成を実施。FTR（Foundational Technical Review）取得のためのセキュリティ強化を行い無事取得。また、ポストモーテム文化の醸成とインシデント対応の型化に取り組みました。

◯ 6〜12ヶ月：信頼性と開発文化の向上
DB 起因のインシデント頻発に対し、課題の深堀りからAurora 3系（MySQL 8系）へのアップグレード、DB メンテナンス体制を整備。開発文化面では、ドキュメントの Confluence 移行、作業スレ（Working Out Loud）推進によるリモートワーク下の情報共有を改善。CTO の1人 Always On-Call 状態を、ローテーション体制とドキュメント文化、通知の仕組み化により解消しました。

◯ 1〜2年：チーム強化と役割の拡大
2人目SREが JOIN 、自分はセキュリティチーム兼務を開始。ビジネスへのより直接的な関わりが増え、海外リージョン構築では法務・グローバルチームと要件をすり合わせながら別環境を構築（このタイミングで Terraform Module 化も実現）。SLA策定と集計運用、SOC2 準備など、ビジネスに直結した取り組みを実施。SLO とエラーバジェットポリシーを定め、ジョブ実行基盤のスケーリング改善に取り組みました。

◯ 2〜3年：成熟と発信
1人目セキュリティエンジニアが JOIN、SRE 人数は変わらず。ログデータのDB分離と削除、EKSカナリアリリースの仕組み作り、AWS Organization導入、NATインスタンス信頼性向上など、中長期の運用に響く施策を実施。採用への関与を深め、情報発信（ブログ、登壇、イベント出展）にも積極的に取り組みました。

◯ 3年〜：そしてCorporate SRE へ
3人目の SRE が JOIN。SOC2 取得のための対応を再開。組織課題への対策として全社横断で様々な「信頼性」を高める取り組みが必要と判断し、「Corporate SRE」を立ち上げました。プロダクト開発"以外"への SRE のプラクティス適用を目指します。

全期間を通じて、Terraform 運用改善、コスト削減、監視・アラート改善など、継続的な改善活動も並行して実施しています。時間の許す限りこれらの取り組みについても紹介します。

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

◯ 対象聴衆

• SRE、インフラエンジニア
• スタートアップのエンジニア、マネージャー
• SRE チームの立ち上げや改善に関心のある方

◯ その人たちが得られるもの

• スタートアップにおける SRE チーム立ち上げ初期のリアルな課題と取り組みの共有
• 技術的な改善だけでなく、組織的な改善や文化醸成の重要性
• 自身の現場で活かせる学びや気づきを提供する

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

スタートアップで SRE ロールを担う方、インフラ基盤の改善に取り組むエンジニア、SRE チームの立ち上げや運営に関心のある方々に、現場で役立つ情報やヒントをお届けできればと考えています。

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

■ 発表概要（400字程度）
SRE チーム（リライアビリティ&セキュリティチーム）の組成から2年、エンジニアリングマネージャ（以下 EM）として人・チーム・技術の間の矛盾（成果で評価したいが測りにくい／スクラムで個のブレイクスルーが発生しにくい／横断課題を見つけたいがプロダクト理解が浅い）に直面しました。矛盾と共存しつつ、成果に結びつけるための SRE チームの運営の実践を共有します。

■ 発表の詳細（1000字程度）
【背景】
横断的な技術課題を解決するために SRE チーム（現在4名）を立ち上げました。立ち上げ当初、弊社では IaC の分散管理、監視基盤の一貫性の欠如、デプロイとバッチジョブの安定性問題といった課題が山積でした。これらを解決するプラットフォームチームとしてSREチームを組成しました。

【直面した矛盾】
EM として、単なる課題解決ではなく、持続可能なチーム運営と明確な成果の両立が求められました。
その過程で次の3つの矛盾に直面しました：

• （人） 高いスキルを持っているが、成果に結び付かず評価が難しい
• （チーム） スクラム導入で属人性を排除できた反面、個人のブレイクスルーが発生しにくい
• （技術） 横断課題を見つけたいが、各プロダクトの理解が浅い

【解決アプローチ】

1. 人への対応：
   チームミッション → KPI ツリー → 個人ミッションに分解し、各メンバーのグレードに対する期待値を明文化。定量化しづらい成果もどのような影響をもたらしたかという観点で評価
2. チームへの対応：
   バックログを全員が起票しオーナーを設定。担当者は柔軟に変更可能で、成果責任はオーナーが持つ体制。ゴール（期待される成果）の認識を合わせ、実現方法はメンバーの裁量に任せる。
3. 技術への対応：
   プロダクト開発チームとの協働を強化し、クリティカルユーザジャーニー（CUJ）からSLI、SLOを共同で設計。プロダクトへの理解を深めながら、適切な優先度で横断的課題に取り組める土台を形成。

【まとめ】
SRE のプラクティスをチーム運営に適用することで、矛盾を受容して成果に結びつける取り組みをしています。このアプローチは、 SRE チームに限らず、様々なエンジニアリングチームの運営に使えると考えています。

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

• SREチームのEM/マネージャー → 矛盾に対処しながらチームを成長させる実践的フレームワーク
• SREチームメンバー → 個人の成果とチーム貢献を両立させるためのマインドセット

■ なぜこのトピックについて話したいのか（モチベーション）
SRE の話というよりはマネージメントの話に近いですが、人とチームの運営という視点を共有することで SRE 文化に貢献できればと思います。