ストーリー
田
田中VPoE
成熟度モデルのフレームワークは理解できた。次は実際に組織の現状を分析する方法だ
あなた
各チームにヒアリングすればいいですか？
あ
田
田中VPoE
ヒアリングだけでは不十分だ。人は自分の環境を過大評価する傾向がある。「うちはちゃんとやっている」と言うチームのログが非構造化テキストだったりする。定量的なデータ収集と定性的なヒアリングの両方が必要だ
あなた
ギャップ分析のようなものですね
あ
田
田中VPoE
その通り。あるべき姿と現状のギャップを正確に把握し、優先的に解決すべき課題を特定する。これが可観測性戦略の出発点だ
現状分析の3つのアプローチ
1. 定量的データ収集
実際のシステムから客観的なデータを収集します。
| 収集対象 | 確認項目 | 収集方法 |
|---|---|---|
| テレメトリカバレッジ | メトリクス、ログ、トレースの導入率 | リポジトリスキャン、設定ファイル確認 |
| データ品質 | 構造化率、フォーマット統一率、欠損率 | ログサンプリング分析 |
| ツールインベントリ | 使用ツール一覧、契約状況、利用率 | ツール管理台帳、請求データ |
| インシデントデータ | MTTR、MTTD、インシデント件数推移 | インシデント管理システム |
| コストデータ | ツール費用、運用工数、ストレージコスト | 請求データ、工数管理 |
2. 定性的ヒアリング
チームメンバーの実体験と認識を収集します。
| 対象者 | ヒアリング項目 |
|---|---|
| SRE/インフラチーム | 現在の運用プロセス、ペインポイント、改善要望 |
| 開発チーム | 計装（インストルメンテーション）の状況、デバッグ体験 |
| マネージャー | 可観測性に対する投資意欲、優先度認識 |
| オンコール担当者 | インシデント対応時の情報アクセス、困りごと |
| 経営層 | ビジネス観点での可視性要求 |
3. インシデント振り返り分析
過去のインシデントから可観測性の課題を抽出します。
| 分析項目 | 目的 |
|---|---|
| 検知までの時間（MTTD） | 検知能力のギャップを特定 |
| 原因特定までの時間 | 分析能力のギャップを特定 |
| 必要だったが不足していた情報 | データ収集のギャップを特定 |
| 複数チームをまたいだ調査の有無 | 統合性のギャップを特定 |
| 再発した問題 | プロアクティブ検知のギャップを特定 |
よく見つかる課題パターン
ツールスプロール（ツールの乱立）
組織でよく見る状態:
メトリクス:
チームA: Datadog
チームB: New Relic
チームC: Prometheus + Grafana
チームD: CloudWatch
ログ:
チームA: Datadog Logs
チームB: Splunk
チームC: ELK Stack
チームD: CloudWatch Logs
トレース:
チームA: Datadog APM
チームB: なし
チームC: Jaeger
チームD: X-Ray| 影響 | 詳細 |
|---|---|
| コスト非効率 | 類似ツールの重複契約、ボリュームディスカウントの機会損失 |
| 知見の断絶 | チーム間でツール知識が共有されない |
| 統合困難 | サービス間の相関分析ができない |
| 運用負荷 | 複数ツールの管理・アップデート・トラブルシューティング |
データサイロ
| 問題 | 具体例 |
|---|---|
| フォーマット不統一 | チームAはJSON構造化ログ、チームBはプレーンテキスト |
| 相関IDの欠如 | リクエストをサービス間で追跡できない |
| メトリクス命名規則の不統一 | http_requests_total vs request_count vs api.requests |
| 保持期間の不統一 | チームAは90日、チームBは7日 |
| アクセス権の分断 | 他チームのデータを参照できない |
可観測性格差
組織内の成熟度分布（よくある状態）:
Level 4 ┤
Level 3 ┤ ██ SRE
Level 2 ┤ ████ フロントエンド、API
Level 1 ┤ ██████ 決済、通知
Level 0 ┤ ████ バッチ、データPF
└───────────────────
チーム数
問題: 最も成熟度が低いサービスが障害のボトルネックになるギャップ分析の実施方法
ターゲット状態の定義
まず組織として目指すべき成熟度レベルを定義します。
| 判断基準 | Level 2を目標にすべき組織 | Level 3を目標にすべき組織 |
|---|---|---|
| 組織規模 | 100名以下の開発組織 | 100名以上の開発組織 |
| サービス数 | 10以下 | 10以上 |
| SLA要件 | 99.9%未満 | 99.9%以上 |
| インシデント頻度 | 月1回未満 | 月1回以上 |
| マイクロサービス化 | 初期段階 | 進行中・成熟 |
ギャップマトリクス
| 評価軸 | 現状レベル | 目標レベル | ギャップ | 優先度 | 必要なアクション |
|---|---|---|---|---|---|
| データ収集 | 1 | 3 | 2 | 高 | 統合収集パイプライン構築 |
| データ品質 | 0 | 2 | 2 | 高 | ログフォーマット標準化 |
| 分析能力 | 1 | 3 | 2 | 中 | 相関分析基盤導入 |
| プロセス | 0 | 2 | 2 | 高 | SLI/SLO定義と運用 |
| 文化 | 1 | 2 | 1 | 中 | 教育・オンボーディング |
| コスト管理 | 0 | 2 | 2 | 低 | コスト可視化と予算管理 |
優先順位の判断基準
| 優先度 | 条件 |
|---|---|
| 最優先 | インシデント対応に直結する課題（MTTR短縮に寄与） |
| 高 | サービス間の統合に関わる課題（データ断絶の解消） |
| 中 | 効率化・標準化に関わる課題（コスト削減、知見共有） |
| 低 | 将来的な改善に関わる課題（高度な分析、自動化） |
「“全部やる”は”何もやらない”と同じだ。最もインパクトが大きい課題を3つに絞り、まずそこに集中する。それが戦略だ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 3つのアプローチ | 定量的データ収集、定性的ヒアリング、インシデント振り返り |
| よくある課題 | ツールスプロール、データサイロ、可観測性格差 |
| ギャップ分析 | 現状と目標の差を6軸で可視化し、優先順位を付ける |
| 優先順位付け | インシデント対応への直結度を最重要基準とする |
チェックリスト
- 現状分析の3つのアプローチを理解した
- ツールスプロールとデータサイロの問題を理解した
- ギャップ分析の実施方法を理解した
- 優先順位付けの判断基準を理解した
次のステップへ
次は「可観測性戦略の設計」を学びます。ギャップ分析の結果をもとに、組織の可観測性を改善するための戦略を設計する方法を身につけましょう。
推定読了時間: 30分