■ 発表カテゴリ
Architecture: SREの視点からのシステム設計
■ 発表概要(400字程度)
SREの役割は「信頼性」と「変更速度」のバランスを取ることですが、この実現にはアーキテクチャレベルでの戦略的思考が不可欠です。本セッションでは、SREが持つべきアーキテクチャモダナイゼーションの知識体系と実践的アプローチを提案します。
技術的負債の蓄積、運用負荷の増大、イノベーションの停滞—これらの問題は個別の技術選択ではなく、システム全体の構造と組織の不整合から生まれます。SREとして、どのようにビジネス戦略と技術戦略を結びつけ、持続可能な信頼性を実現するか。戦略的な可視化手法、ドメイン境界の設計原則、チーム構造との整合性、そして段階的な改善アプローチについて解説します。
特に、「運用の観点から見た良いアーキテクチャとは何か」「変更に強く障害に強いシステムの本質」「組織とシステムの相互作用」といった、SREが理解すべき本質的な概念を、実践的な文脈で紐解いていきます。単なる運用改善ではなく、システム全体の進化を主導するSREの新しい役割を提示します。
■ 発表の詳細(1000字程度)
SREは単なる「運用の専門家」ではありません。システムの信頼性を根本から改善するには、アーキテクチャレベルでの理解と介入が必要です。しかし、多くのSREチームは日々の運用対応に追われ、構造的な問題に取り組む余裕がありません。このセッションでは、SREがアーキテクチャの観点から価値を生み出すための思考法を共有します。
システムの各コンポーネントが持つ「戦略的価値」と「進化段階」を理解することで、どこに投資すべきか、何を標準化すべきかが見えてきます。差別化要素とコモディティの見極め、ビルドvsバイの判断基準、技術的投資の優先順位付けなど、SREが経営層と対話するための共通言語を提供します。
「なぜこのサービスは頻繁に障害を起こすのか」「なぜ小さな変更が大きな影響を及ぼすのか」—これらの問題の多くは、不適切な境界設計に起因します。ビジネスドメインの理解、データの整合性、トランザクション境界、非同期通信パターンなど、SREが知るべき設計原則を体系的に整理します。
コンウェイの法則は避けられない現実です。しかし、これを理解し活用することで、より良いシステムを構築できます。認知負荷の管理、チーム間のインタラクションパターン、プラットフォーム思考など、組織設計とシステム設計を同時に考えるアプローチを紹介します。
完璧なアーキテクチャを最初から作ることは不可能です。重要なのは、継続的に進化できる構造を作ることです。観測可能性の設計、実験のしやすさ、段階的な移行戦略、リスクの管理方法など、SREが主導すべき継続的改善のメカニズムを解説します。
開発チームの自律性を高めながら、全体の信頼性を担保する—これがプラットフォームアプローチの本質です。適切な抽象化のレベル、ゴールデンパスの設計、ガードレールの設置など、SREがプラットフォームエンジニアとして価値を提供する方法を探ります。
これらの概念を通じて、SREが「受動的な運用者」から「能動的なアーキテクト」へと進化するための知識体系を提示します。技術的な詳細よりも、思考のフレームワークと実践的なアプローチに焦点を当て、明日から使える知見を共有します。
■ 対象聴衆とその人たちが得られるもの
対象聴衆:
得られるもの:
■ なぜこのトピックについて話したいのか(モチベーション)
多くのSREチームが「消火活動」に終始し、本質的な改善に取り組めていない現状を目にしてきました。問題の根本原因の多くは、アーキテクチャレベルの構造的な課題にあります。しかし、SREとアーキテクチャを結びつけて考える機会は少なく、両者の間にはギャップが存在します。
SREこそが、運用の現実を知り、ビジネスへの影響を理解し、継続的な改善を推進できる立場にいます。このセッションを通じて、SREがアーキテクチャレベルで価値を創出し、組織全体の技術的進化を主導するための視座を提供したいと考えています。
「信頼性」は単なる運用の問題ではなく、設計の問題であり、組織の問題でもあります。この多面的な課題に対して、SREがどのようにアプローチすべきか、実践的な知見を共有することで、日本のSREコミュニティの発展に貢献したいと思います。
■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓
■ 発表概要(400字程度)
SREの現場では、障害を防ぐだけではなく、避けられないエラーや過負荷にどう向き合うかが重要です。多数のクライアントが多様なサービスとリアルタイムに通信するLINEでは、停止か稼働かの二択ではなく、段階的に劣化しながら体験を守る「グレースフル」な設計を重視しています。
これらを通じて「なめらかに劣化しても信頼性を維持する」LINEの実践を共有します。
■ 発表の詳細(1000字程度)
本発表では、LINEにおけるSRE実践を「なぜその仕様に至ったか」という議論の経緯も交えながら紹介します。
まずは、 障害の連鎖を防ぐサーキットブレイカー 。複数サービスと連携する際、上流が応答せずタイムアウトすると、アプリ全体の表示が遅延する課題がありました。異常を検知すると一定時間リクエストを遮断する仕組みを導入し、障害の連鎖を防いでいます。
次に、 上流サービスを守るアダプティブレイトリミッター 。リトライや瞬間的なアクセス集中で想定外の負荷が生じ、上流をダウンさせる恐れがあります。単純なRPS上限設定では柔軟性に欠けるため、上流から返されるエラー率や種類に応じて制御を動的に調整する仕組みを導入しました。
続いて、 過負荷時の体験を守るロードシェディング 。LINEアプリは多くをキャッシュするため、過負荷時には全リクエストを処理する必要はありません。リフレッシュ要求を後回しにし、新規コンテンツ取得を優先する「コンテキストアウェア」な仕組みによって、限られたリソースでもユーザー体験を守ります。
一方で古い情報が表示されるリスクも生じます。そこで、 応答不能時のエラーハンドリング として、鮮度が重要な情報に対してはクライアント側で追加の仕組みを実装。サーバー側に依存しないアプローチで、ユーザーが古い情報から誤った判断をしにくくしました。
さらに、 カナリーリリースとトラフィック制御 。一般的な10%先行リリースでは、単純なラウンドロビンだと不具合が全ユーザーに影響する恐れがあります。そこで影響範囲を明確に制御できる仕組みを取り入れ、安全にリリースできるようにしました。
最後に、 開発段階から健全性を確認するカジュアルな負荷試験 。従来のQAは機能検証が中心で、高負荷時の問題を事前に見つけにくい課題がありました。そのため、開発段階から簡易に負荷試験を実施できる環境を整備し、非機能要件の健全性を自然にチェックできる文化を育てています。
これらの取り組みを通じて、どのように「想定外を前提とする」設計を実現し、議論を経て現場に落とし込んできたかをお話しします。実例と背景を交えて紹介することで、皆さんの現場でも応用できるヒントを持ち帰っていただけるはずです。
■ 対象聴衆とその人たちが得られるもの
本発表は、ユーザー視点での信頼性向上を目指すSWEやSREを対象としています。クライアントサイドとサーバーサイドといった境界を越え、どのようにしてエンドツーエンドの信頼性を確保できるのか。その具体的な事例を持ち帰り、自らの現場に活かしていただけます。
■ なぜこのトピックについて話したいのか(モチベーション)
開発の現場では、エラー発生時の挙動に十分な配慮がなされないことが少なくありません。特にスケジュールに余裕がない場合や、再現の難しい障害への備えは後回しになりがちです。私自身も日々、優先度の判断に悩みながら、今取り組むべきことと後に回すことを天秤にかけつつ、チームと共にさまざまなプラクティスを導入してきました。
同じような課題に直面しているSREの方も多いと考えています。本発表を通じて、そうした悩みを共有し、実践のヒントを提供できれば幸いです。
■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談
■ 発表概要(400字程度)
多くのSRE組織が、サービス信頼性の向上に注力する一方で、「社内情報システム」や「セキュリティ」という隣接領域との連携不足に課題を感じていませんか?
私は「重複したタスクを対応する」などの課題を実感しています。
SRE・社内情報システム・セキュリティ3領域を同時にマネジメントする中でSREの考え方やプラクティスを活用することでシナジーを創出しました。
・SLO/SLIの設定と計測 → ヘルプデスク対応の期待値設定とコントロール
・サービスの信頼性向上 → プロアクティブなセキュリティ対策
・エラーバジェットの運用 → 経営イシューとなるセキュリティリスク管理と意思決定
本セッションでは、SREからキャリアを広げたい方、社内情報システムやセキュリティを主務としていてSREに興味がある方に「次のキャリアに向けたTips」「SREのプラクティスがいかに汎用的かという学び」を提供します。
■ 発表の詳細(1000字程度)
以下のアジェンダでお話します。
SRE / 社内情報システム / セキュリティの課題(6分)
・現代の多くの組織で、SRE・情報システム・セキュリティが分断されて運営されていることによる課題がある。
・重複する作業領域や兼務による非効率
・「サービスの信頼性を高める」という目的は一緒だが、手段が異なるので重複する
・インシデント対応時の責任範囲の曖昧さ
・組織的に縦割りになってしまう or どちらもボールを取りに行ってしまい、効率的に動きにくい
・技術選定における最適化の困難さ
・ナレッジの相互共有やスキルトランスファーがされにくい
SRE / 社内情報システム / セキュリティで統合型マネジメントをやってみた(8分)
・最初は責任範囲の対立やコミュニケーションコストの多さでうまく行かなかったので、以下を推進した。
・各領域の責任範囲定義 / 相互依存関係の設計
・コミュニケーション手法、意思決定プロセス
・KPI設計
・限られた時間とリソースの中で「何をやり、何をやらないか」を判断し、リソースをどう配分するか?の組織戦略。
・「攻めのSRE」を体現するためのTips。
SREのプラクティスをどう適用したか?(8分)
・「事業成長を支える部門」という切り口で共通しているので、以下を対応した。
・SLO/SLIの設定と計測 → ヘルプデスク対応の期待値設定とコントロール
・サービスの信頼性向上 → プロアクティブなセキュリティ対策
・エラーバジェットの運用 → 経営イシューとなるセキュリティリスク管理と意思決定
・これらの推進がシナジー創出に繋がり、結果としてエンジニアリングマネージャーが取り組むべき「組織の成果の最大化」に寄与した。
適材適所を実現する人材マネジメント(5分)
・SREが「組織成果の最大化」を実現するために工夫したこと。
・人のReliabilityの見極め方
・キャリアパス設計
・モチベーション管理
・SREの次のキャリアとしてエンジニアリングマネージャーを目指すことの優位性。
持ち帰ってほしいこと(3分)
・SREのプラクティスはさまざまな領域に活かすことができるし、次のキャリアに必ず役に立つ。
・SREはぜひ社内情報システムやセキュリティにもチャレンジしてほしい。
■ 対象聴衆とその人たちが得られるもの
■対象聴衆
■聴衆が得られるもの
■ なぜこのトピックについて話したいのか(モチベーション)
■個人的な体験と学び
私自身がSRE・社内情報システム・セキュリティの3領域を同時にマネジメントするという、そこまで同じロールの方が多くない珍しい経験をしている。
この経験を通じて、従来の縦割り組織では実現できない大きなシナジー効果と価値創造の可能性を実感し、また「SREのプラクティスの汎用性と可能性」について論じたいと考えた。
■SREコミュニティへの貢献意識
SRE NEXTで登壇者やコアスタッフを務める中で、SREコミュニティの発展に貢献したいという想いがあり、多くのSRE組織が組織運営や他部署との連携で課題を抱えている現状を見る中で、私の実践経験が同じような課題を持つ方々の参考になればと考えている。
特に、SREの枠を超えた統合的なアプローチは、まだ体系化されていない分野であり、実践例を共有することで業界全体の発展に寄与できると信じている。
また、この挑戦を通じてSREのキャリアの可能性を実感した。
■組織変革への情熱
「組織の成果の最大化」という目標に向けて、常に新しい組織運営手法にチャレンジしている。
3領域統合マネジメントも、その挑戦の一つです。このチャレンジが成功体験となったことで、他の組織でも同様の価値創造が可能であると考えおり、SRE Kaigi 2026のテーマである「Challenge SRE !」にまさに合致する、組織変革への挑戦を共有することで、釣行する方にきっかけや熱量を提供したい。
総じて理論的な話ではなく、実際に現場で使える知識とノウハウと明日からすぐに活用できる実践的な手法を届けたい。