認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名のSREが200名のプロダクトエンジニアを支援 by 樋口貴志

■ 発表カテゴリ

• Tech: SREを支える具体的な技術や手法
• Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）
皆さんの組織では、全体におけるSREの割合はどのくらいでしょうか？SmartHRでは現在4名のSREエンジニアがいます（2025/10現在）。一方で、プロダクト開発エンジニアは約200人、比率は1:50にもなり、チーム数は40以上にも及びます。さらに2025年5月にARR200億円に達し、5年後には売上1000億円を目指して急成長中です。

このような急成長環境の中で、SREチームのミッションは「日々増え続ける膨大なプロダクトチームが、信頼性に関する知識や経験を通して、適切な機能開発と信頼性への投資ができるようになること」であり、これが売上1000億円到達の鍵だと考えています。

しかしながら、SREはわずか4名です。個々のチームを丁寧に支援していくには時間が足りません。かといって、全体に薄く広く関わっても本質的な成果は得られないでしょう。

本発表では、このような課題を抱えながらもミッション達成に向けて行った「オブザーバビリティの導入」と「SLI/SLOの導入」のChallenge！と成果をご紹介します。

■ 発表の詳細（1000字程度）
概要でもお伝えした通り、SREチームは少人数のため、200名・38プロダクト規模のチームにJoinする形では時間も人も足りません。そのため、基本的にはEnabling（※1）として活動することになりますが、オブザーバビリティ基盤やSLI/SLOの導入・運用を各チームに任せきりにすると、プロダクトエンジニアの認知負荷が拡大し、本来事業を前に進めるための機能開発にリソースを割けなくなります。

また、SREチームはPlatformチーム（※2）としての役割も兼務しており、開発者がセルフサービスで高品質な開発・運用を行える環境（Paved Road / 舗装された道）を提供する必要があります。

このような状況の中で、Enabling/Platformチームとして活動しながら、50倍規模のチーム群の認知負荷を上げずにどのようにミッション達成をしていくのか。SREチームの立ち位置を前提に、オブザーバビリティとSLO導入の観点からお話します。

※1 チームトポロジーにおける「Enablingチーム」を指す。ここではSREの知見を複数のプロダクトチームに横断的に共有・支援する形態を「Enabling」と呼ぶ。
※2 チームトポロジーにおける「Platformチーム」を指す。具体的には開発・運用のための共通基盤（CI/CD、モニタリング、IaCなど）の設計、構築、提供などを指す。

1. 前提：組織体制とSREチームの立ち位置
   • SREチームはまだ始まったばかり！Enabling/Platformチームとしての役割
   • 急成長する"スケールアップ企業"におけるSREチームのミッションと課題
2. 高品質かつ効率的なオブザーバビリティ実現へのChallenge！
   • 本末転倒！？モニタリングが引き起こす認知/運用負荷の問題とその解決法
     • 自前でオブザーバビリティプラットフォームを構築する際の認知/運用負荷の問題
       • 独自実装によるプラットフォーム構築は専任チームによる運用が必須
       • 「OSS + マネージドサービス」でも保守作業が残り、トイルが発生する
     • 「オブザーバビリティプラットフォームSaaS」の活用という選択肢と決断
       • 「何でも作る」思考から「あえて作らない」選択へ — 事業の業務ドメインに集中する重要性
       • SaaS費用と認知/運用負荷軽減効果の比較、開発スピード維持のためのSaaS活用決断
   • SaaSを活用したオブザーバビリティ環境の構築
     • プロダクト開発チームが「すぐに」「わかりやすく」使えるダッシュボードの設計
       • SLO違反時に原因をすぐ特定できる「レスポンス劣化率」「パーセンタイル比較」「スローレスポンス履歴」の表示
       • 「SLOダッシュボードの歩き方」の策定と活用
     • 認知/運用負荷を最小化するプロダクトチームへの展開
       • レバレッジを効かせるダッシュボード構築のIaC化
       • 共通部分の部品化による構築工数の短縮
3. 少人数のSREチームによる全プロダクトチームへのSLO導入へのChallenge！
   • Enablingを開始する前の準備
     • SREチームとプロダクト開発チームの責任分界点の明確化
       • SRE：SLO計測の仕組みや運用環境の提供
       • プロダクト開発チーム：アプリケーション固有のSLO目標値の設定と達成
     • 自社文化に適したコミュニケーション方法の確立
       • 横断的な活動を促進するチャットツールの効果的な活用
       • SRE活動の可視化と定期的なロードマップ振り返り/共有の仕組み
   • 効果的なEnablingプラクティス
     • 「社内向けSLO導入ガイド」の策定と活用
       • CUJ（クリティカルユーザージャーニー）を軸としたSLI/SLO設計方法
       • 適切なSLOしきい値設定のために蓄積されたQ&A
     • 共通言語：「SLO星取表」による方向性の統一と進捗の可視化
       • Step毎に定義されたSLO運用の成熟レベルの可視化と事業目線でのメリット
       • 各プロダクトのSLO運用会議で星取表を見直し方向性を統一、SREチームのマネジメント負荷を軽減

■ 対象聴衆とその人たちが得られるもの
対象：拡大する組織で新しくSREチームを立ち上げたい方、少人数のSREチームでレバレッジの効かせ方に悩んでいる方、SREをまだ導入していないが開発チームに小規模に取り入れてみたい方
得られるもの：SREを小規模に始める際の実践的なアプローチ、機能開発のスピードを維持しながら（＝認知負荷を増やさずに）オブザーバビリティとSLOを導入する方法、そしてこれらの取り組みを支えるコミュニケーション方法の例

■ なぜこのトピックについて話したいのか（モチベーション）
現代の多くの組織がDevOpsを採用していますが、ほぼ確実に直面するのが認知負荷と運用負荷の増大です。また、IT人材不足によりSREに割けるリソースは限られており、「SREチームを立ち上げたものの、効果的な施策を実行できず失敗した」という事例もよく耳にします。こうした状況から、潤沢な人材リソースや高度な専門知識がなければSREは始められないという印象を持つ方も少なくありません。

しかし、SREはまだ発展途上の分野です。認知負荷と運用負荷を上げない形でSREのプラクティスを導入した実践例を共有することで、少人数でもSREのプラクティスを組織に効果的に取り入れることができます。これが信頼性を維持しながら事業成長を促進する第一歩となるため、本会議に参加する皆様と共に試行錯誤しながら前進していけることを願っています。