ストーリー
田
田中VPoE
プラットフォーム、SLI/SLO、インシデント検知 — 技術的な設計は一通り完了した。だが、ここからが最も難しいパートだ
あなた
技術的な設計は終わったのに、まだ難しいことがあるんですか？
あ
田
田中VPoE
ツールを導入しただけでは組織は変わらない。可観測性を「文化」として根付かせる必要がある。最高のプラットフォームがあっても、チームが使わなければ意味がない。ダッシュボードを作っても誰も見なければ無駄だ
あなた
文化の醸成は具体的にどうすればいいのでしょうか
あ
田
田中VPoE
「文化」は抽象的に語られがちだが、実際には具体的な要素に分解できる。「オーナーシップ」「データ駆動の意思決定」「非難なき振り返り」「継続的学習」 — これらの要素を組織プロセスに組み込むことで、文化は自然に醸成される
可観測性文化とは何か
文化の定義
| 観点 | 説明 |
|---|---|
| 文化とは | 「誰も見ていないときにチームがどう行動するか」 |
| 可観測性文化 | システムの状態を常に理解し、データに基づいて意思決定する組織の習慣 |
| 目指す状態 | 可観測性が「特別なこと」ではなく「当たり前のこと」になっている |
文化が成熟している組織の特徴
成熟した可観測性文化:
開発者が新機能を実装するとき:
✓ 計装（メトリクス、ログ、トレース）を自然にコードに含める
✓ SLIを定義してから機能をリリースする
✓ ダッシュボードをPRと一緒にレビューする
インシデントが発生したとき:
✓ データに基づいて冷静に原因を分析する
✓ 「誰のせいか」ではなく「何が壊れたか」に焦点を当てる
✓ ポストモーテムで可観測性の改善点を必ず議論する
日常業務で:
✓ チーム定例でSLOダッシュボードを確認する
✓ エラーバジェットに基づいてスプリント優先度を調整する
✓ 新しいチームメンバーにオンコールと可観測性の研修を行う可観測性文化の4つの柱
柱1: オーナーシップ
| 原則 | 説明 |
|---|---|
| You Build It, You Run It | サービスを開発したチームが運用にも責任を持つ |
| SLOオーナーシップ | 各サービスのSLOは、そのサービスを開発するチームが所有する |
| 計装の責任 | 計装はインフラチームの仕事ではなく、開発チームの責任 |
オーナーシップの具体的な仕組み
| 仕組み | 内容 | 効果 |
|---|---|---|
| サービスカタログ | 各サービスのオーナーチーム、オンコールローテーション、SLOを一覧化 | 「誰に聞けばいいか」が明確 |
| オンコールローテーション | 開発チーム自身がオンコールを担当 | 運用の痛みが設計にフィードバックされる |
| SLOレビューへの参加 | サービスオーナーが週次SLOレビューに参加 | SLOへの当事者意識が生まれる |
柱2: データ駆動の意思決定
| 原則 | 説明 |
|---|---|
| 推測するな、計測せよ | 「たぶんこれが原因だと思う」ではなく、データで確認する |
| SLOに基づく優先度判断 | エラーバジェットの状態に基づいてスプリントの優先度を決める |
| 変更の影響を測定 | デプロイ前後のメトリクスを比較し、変更の影響を定量的に評価 |
データ駆動の意思決定プロセス
従来の意思決定:
「最近パフォーマンスが悪い気がする」
→ 「たぶんDBが遅い」
→ 「DBのスペックを上げよう」（推測ベース）
データ駆動の意思決定:
「P99レイテンシが先週比で30%上昇」（定量データ）
→ トレース分析: 「特定のAPIエンドポイントが原因」（絞り込み）
→ ログ分析: 「N+1クエリが発生している」（根本原因特定）
→ 「N+1クエリを修正する」（データに基づく判断）
→ デプロイ後: 「P99レイテンシが元の水準に回復」（効果測定）柱3: 非難なきポストモーテム（Blameless Postmortem）
| 原則 | 説明 |
|---|---|
| 人ではなくシステムに焦点 | 「誰がミスをしたか」ではなく「なぜシステムがミスを許したか」を問う |
| 心理的安全性 | 失敗を報告・共有しやすい環境を作る |
| 学習の文化 | インシデントを「失敗」ではなく「学習機会」と捉える |
非難なきポストモーテムの実践
| 実践 | やるべきこと | やってはいけないこと |
|---|---|---|
| 言葉遣い | 「システムがこの変更を安全にデプロイする仕組みがなかった」 | 「Aさんがデプロイミスをした」 |
| 焦点 | 寄与要因の分析（プロセス、ツール、設計） | 個人の責任追及 |
| 改善策 | システム的な再発防止策（自動テスト、ガードレール） | 「次から気をつける」 |
| 共有 | 全社に公開し、組織の学びとする | 関係者のみでクローズ |
柱4: 継続的学習
| 原則 | 説明 |
|---|---|
| 知識の共有 | 可観測性のベストプラクティスを組織内で共有する |
| スキル向上 | 全開発者が可観測性の基本スキルを持つ |
| 実験の奨励 | 新しい計装手法や分析手法を試すことを奨励する |
学習プログラムの構成
| プログラム | 頻度 | 内容 | 対象 |
|---|---|---|---|
| Observability 101 | 入社時 | 可観測性の基本概念、ツールの使い方 | 全新入社員 |
| SLO Workshop | 四半期 | SLI/SLO設計、エラーバジェットの実践 | サービスオーナー |
| Incident Response Drill | 月次 | 模擬インシデント対応訓練 | オンコール担当者 |
| Observability Show & Tell | 隔週 | チーム間のベストプラクティス共有会 | 全開発者（任意参加） |
| Failure Friday | 月次 | カオスエンジニアリング実践 | SRE + 有志 |
文化醸成のアンチパターン
よくある失敗パターン
| アンチパターン | 症状 | 対策 |
|---|---|---|
| ツール信仰 | 「ツールを導入すれば解決する」と思い込む | ツールは手段。プロセスと文化の変革が本質 |
| SREチームに丸投げ | 「可観測性はSREの仕事」と他チームが無関心 | オーナーシップの分散とオンコール参加の義務化 |
| トップダウン強制 | 経営層が一方的にツール導入を命令 | ボトムアップの課題認識とチャンピオンの育成 |
| 完璧主義 | 最初から完璧な可観測性を目指し、何も進まない | 小さく始めて段階的に拡大（MVP思考） |
| メトリクスの暴走 | 測定できるものを全て測定し、データの海に溺れる | SLIに基づく「意味のある計測」に集中 |
可観測性チャンピオンプログラム
チャンピオンとは
| 項目 | 説明 |
|---|---|
| 定義 | 各チーム内で可観測性の推進役を担うメンバー |
| 役割 | チーム内でのベストプラクティス普及、ツール活用の支援、SLOレビューの推進 |
| 選出基準 | 可観測性に関心が高く、チーム内で影響力がある人材 |
| 支援体制 | SREチームが定期的な勉強会とオフィスアワーで支援 |
チャンピオンの具体的な活動
| 活動 | 頻度 | 内容 |
|---|---|---|
| チーム内の可観測性レビュー | 毎スプリント | PRに計装が含まれているかの確認 |
| SLOダッシュボード更新 | 月次 | サービスの変更に合わせたダッシュボード更新 |
| チャンピオン定例 | 隔週 | 全チームのチャンピオンが集まり情報交換 |
| ナレッジ共有 | 随時 | Wikiやドキュメントへのベストプラクティス記録 |
「文化は”制度”と”習慣”の積み重ねだ。オンコールローテーション、SLOレビュー、ポストモーテム — これらのプロセスを定着させることで、文化は自然に醸成される。“文化を変えよう”と叫ぶだけでは何も変わらない」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 文化の4柱 | オーナーシップ、データ駆動、非難なきポストモーテム、継続的学習 |
| オーナーシップ | You Build It, You Run It。開発チームが運用にも責任を持つ |
| アンチパターン | ツール信仰、SREへの丸投げ、完璧主義を避ける |
| チャンピオン | 各チームに可観測性チャンピオンを配置して推進力を確保 |
チェックリスト
- 可観測性文化の4つの柱を理解した
- オーナーシップの具体的な仕組み（サービスカタログ、オンコール）を理解した
- 非難なきポストモーテムの原則と実践方法を理解した
- 文化醸成のアンチパターンと対策を理解した
次のステップへ
次は「チームオンボーディング」を学びます。新しいチームメンバーや、これまで可観測性に馴染みがなかったチームをどのようにオンボーディングするかの具体的な手法を身につけましょう。
推定読了時間: 30分