📊

Observability Conference Tokyo 2025 に行ってきました

に公開

はじめに

Observability Conference Tokyo 2025に参加してきました。
本記事では、特に印象に残った3つのセッションについてまとめます。

反省から紐解くオブザーバビリティとして本当に必要だったテレメトリ

セッション概要

このセッションは、タイトル通り「反省」から始まります。実際に経験した失敗事例を交えながら、本当に必要なテレメトリとは何かを紐解く内容でした。

陥りがちなアンチパターン

「たくさんのデータを元に多角的に分析すればいい」という落とし穴

良かれと思って様々なテレメトリを収集した結果、以下のような問題に直面したとのこと。

  • 膨大なデータと複雑化により、思っていたような分析ができない
  • 必要なデータが埋もれてしまう
  • システム運用が安定してくると誰も使わなくなる
  • コストだけがかかり、費用対効果が合わない

さらに、データを取得していても全ての事象を分析・原因究明できるわけではないとのこと。

失敗から学んだこと: ユーザー視点の欠落

実際にあった失敗事例として、CPU、メモリなどのインフラメトリクス監視のみに注力していたケースがありました。

何が起きたのか

  • インフラのメトリクスは問題なし
  • しかし、ユーザーからはクレームが続く
  • 問題に対処しているつもりでも、ユーザーの不満は高まるばかり
  • 結果として、オブザーバビリティツールが使ってもらえなくなった

この失敗から学んだのは、ユーザー体験に影響する指標に焦点を当てないと、利用者体験が捉えられず、サービスのイメージダウンに繋がるということでした。これがゴールデンシグナルが重要である理由です。

どこから始めるべきか?

4つのゴールデンシグナルから始める

  • Latency(レイテンシー)
  • Traffic(トラフィック)
  • Errors(エラー)
  • Saturation(飽和度)

「絶対的な回答は存在しない」。重要な判断基準は、「このテレメトリがないと、信頼性・ビジネスに影響が出るな」と思った場合に取得すること。この基準に照らして、まずは4つのゴールデンシグナルから始めることがおすすめしていました。

コストとのバランス: テレメトリを「育てる」

まず既存のリソースを活用する

  • カスタムメトリクスを作成する前に、標準メトリクスで確認できることは多い
  • 新しいデータを取得する前に、既存データを観点を変えて見てみる

段階的な追加

  • 短期間に一度に多くを追加しない
  • 不要なテレメトリを取得するリスクを避ける

テレメトリを「育てる」という考え方

  1. 追加する
  2. 分析する
  3. 必要性を再確認する

この繰り返しでテレメトリを育てていくことが重要です。一度設定して終わりではありません。

コスト調整の具体的手法

  • データの保存期間の調整
  • サンプリングレートの調整

「完璧なオブザーバビリティは存在しない。大切なのは段階的に改善すること」

他のセッションで学ぶ「小さな改善を継続する」という考え方と共通しています。失敗から学び、段階的に改善していく姿勢が、オブザーバビリティを実際に機能させるための鍵だと実感しました。


オブザーバビリティ成熟度モデルの企画から社内導入まで:複数サービスで評価を通じた組織変革の軌跡

※ 発表資料は見つかりませんでした...
関連記事
https://developersblog.dmm.com/entry/2025/06/30/110000

セッション概要

SREの横断組織としての立場を活かし、複数サービスのオブザーバビリティ成熟度を評価・改善した取り組みについてのセッションでした。

横断組織のメリット

SREが様々なサービスチームと協業していたことで、俯瞰的な視点から組織全体を見ることができた点が、この取り組みの強みでした。

オブザーバビリティの目指す姿

  • AIが異常を検知し、スケールアウト等を自動実行
  • 人的介入なしで自己回復できること
  • ユーザー行動の理解と最適化
  • 継続的な改善と最適化

評価の実施方法

Google Formを利用したアンケート調査
アンケートの結果、以下のことが判明

  • 監視基盤:問題なし
  • 行動分析:問題なし
  • 開発プロセス:問題なし
  • 課題: アラート対応が属人化していることが浮き彫りに

実施したアクション

判明した課題に対して、以下の施策を実施

  1. アラートルールの棚卸し
  2. 深刻度分類による整理
  3. 対応優先度の明確化

レベル別改善アクションプランのメリット

  • 開発チーム - 誤検知をなくすことで開発に集中できる
  • 経営層向け - 開発投下時間の純増として示せる

継続的改善の課題と対策

課題

  • 日常業務が忙しく、改善が停滞
  • 評価を継続する仕組みの不在

対策

  • 成功体験を積み重ねてモチベーションを維持
  • 評価は出発点と捉える
  • 完璧を求めず、小さな改善を継続

組織へのメッセージ

「評価は出発点。完璧ではなく、小さな改善を継続することが重要」

完璧な状態を目指すとかえって動けなくなり、改善が停滞してしまいます。まずは現状を評価し、そこから小さな改善を積み重ねていく。この継続的な姿勢こそが、組織のオブザーバビリティを実際に機能させるための鍵だと学びました。


SRE ✖️ マネジメントレイヤーが挑戦した組織・会社のオブザーバビリティ改革ービジネス価値と信頼性を両立するリアルな挑戦

セッション概要

組織レベルでのオブザーバビリティ改革において、技術的な側面だけでなく、マネジメント・ビジネスの観点からどのようにアプローチしたかを共有するセッションでした。

組織におけるオブザーバビリティの課題

定量化の難しさ

  • 組織レベルになると定量的指標が減り、定性的になりがち
  • 定量的な指標が取れても活用ができていない

コミュニケーションの壁

  • システムを理解している経営層は少ない
  • エンジニアリングの内容が直感的に伝わりにくい
  • エンジニアが翻訳しながら話す必要があり疲弊しがち

成果の不透明性

  • モニタリングはしていても成果に繋がっているのか不明
  • オブザーバビリティに昇華させていく必要がある

成功のための重要なポイント

1. 職種を超えた共通認識

  • 観測・観察するにせよ、職種を超えて共通認識を持つ必要がある

2. 仲間作り

  • 自分一人でやり切ろうと思わない。共感してくれる仲間が必要

3. バランスの取れたアプローチ

  • データ至上主義だと失敗する
  • 設定するSLO(目標)がきつすぎると疲弊する
  • 現実的な目標とバッファが必要

共通言語化の重要性

課題
SLO、エラーバジェット、オブザーバビリティなどのエンジニア用語は、エンジニア以外に伝えるのが難しい

解決策

  • なんとなくをやめ、データ・ドリブンな意思決定をする
  • SLO/SLIの指標を使い、技術的な投資/優先度変更の意思決定に活用
  • SLOを共通言語化する

オブザーバビリティの定義
「事実に基づく可視化と学習」

このようにシンプルに定義することで、職種を問わず理解できる形で説明できることを学びました。

オブザーバビリティ改革の具体的アプローチ

可視化戦略

  • 職種を超えた共通認識の確保
  • 開発チームのパフォーマンス可視化
  • 組織間のコミュニケーションボトルネックの特定

データ分析手法

  • 従業員サーベイを多角的に分析
  • 施策の進捗、採用・離職状況との突き合わせ
  • SLO(サービスレベル目標)の設定

改善プラクティス

  • 複雑な状況をシンプルに翻訳
  • エラーバジェットの概念を経営指標に適用
  • ポストモーテム文化の醸成

成果

  • 従業員サーベイスコアが10%上昇
  • エンジニアリングと経営の橋渡しが実現
  • キャリアパスの拡大

SLOやエラーバジェットといった技術的な概念を経営指標に翻訳することで、エンジニアリングの価値を可視化できることを学びました。従来は定性的にしか語られなかった組織の課題を、データに基づいて定量的に把握し改善する。その結果が従業員サーベイスコア10%上昇という具体的な成果として表れています。オブザーバビリティは、システムだけでなく組織全体に適用できる強力な考え方だと実感しました。


懇親会

こういったイベントの懇親会に参加するのは初めてで、しかも一人での参加だったため最初は緊張していましたが、会場をうろうろしていると気さくに声をかけてくださる方がいて、自然と会話が始まりました。

また、セッションで気になったスピーカーの方々に直接話しかける機会もあり、発表では聞けなかった裏話やより詳しい実装の話など、オフレコならではの深い話を聞くことができました。

懇親会は、単なる交流の場というだけでなく、セッションの理解を深めたり、現場の生の声を聞ける貴重な機会だと実感しました。次回以降も積極的に参加したいと思います。


まとめ

3つのセッションに共通していたのは、完璧を目指さず、段階的に改善していくという考え方でした。

  • 本当に必要なテレメトリから始める
  • 成熟度モデルによる段階的改善
  • データに基づく定量的な意思決定

それぞれ異なる切り口でしたが、いずれも「使われるオブザーバビリティ」を実現するための具体的なアプローチが学べました。

特に印象的だったのは

  • 完璧なオブザーバビリティは存在せず、段階的な改善が重要
  • まずは4つのゴールデンシグナルから始め、必要に応じて追加する
  • 技術概念を経営指標に翻訳し、共通言語化することでコミュニケーションを促進できる
  • データに基づいた定量的な意思決定が組織の改善につながる

自チームでも、まずは4つのゴールデンシグナルが適切に取得できているか確認することから始めたいと思います。また、オブザーバビリティ成熟度を評価し、小さな改善を積み重ねていきます。懇親会での直接的な交流を通じて、発表資料だけでは得られない深い学びや実践的なヒントを得ることができました。今回学んだ「完璧を目指さず、段階的に改善していく」という考え方を、実際の業務で実践していきたいと思います。

Discussion