LESSON 30分

ストーリー

田
田中VPoE
オンコール体制を設計した。次は障害が起きた「後」の話だ。ポストモーテム — 障害の振り返りだ
あなた
障害報告書のようなものですか？
あ
田
田中VPoE
従来の障害報告書とは根本的に違う。うちの会社では障害が起きると「犯人探し」が始まる。「誰がこのコードを書いた？」「誰がレビューを通した？」。この文化を変えないとSREは機能しない
あなた
個人を責めてしまうと、隠蔽が起きますよね
あ
田
田中VPoE
その通りだ。障害を隠す、報告を遅らせる、リスクを取らなくなる — すべて「責められる」恐怖から生まれる。ブレームレス（blame-less）文化は、SREの根幹だ

ブレームレス文化の本質

なぜブレームレスが必要か

「責める」文化の結果ブレームレス文化の結果
障害を隠す障害を素早く報告する
報告を最小限にする詳細な情報を共有する
リスクを避ける（イノベーション停滞）適切なリスクを取れる
個人の注意力に依存システムの改善に投資
「誰のせいか」を追求「なぜ起きたか」を追求

ブレームレスの誤解

誤解正しい理解
「誰も責任を取らなくてよい」個人を責めないが、組織的な改善責任は明確にする
「何をしても許される」意図的な過失や繰り返しの不注意は別途対処する
「原因を追及しない」原因は徹底的に追及する。ただし「人」ではなく「システム」に着目する
「甘い文化」むしろ厳しい。問題の根本原因を徹底的に掘り下げる

ブレームレスの実践

言い換えのフレームワーク

Blame（責める）Blameless（学ぶ）
「Aさんがテストを忘れた」「テストが実行されずにデプロイされる仕組みだった」
「Bさんの設定ミス」「設定ミスを検出できる仕組みがなかった」
「Cさんがレビューで見落とした」「レビュープロセスでこのタイプの問題を検出できない」
「なぜ確認しなかったのか」「確認が必要だと気づける仕組みがなかった」

システム思考

ブレームレスの思考プロセス:

「誰が間違えたか？」
  → 「なぜその人がそのアクションを取ったか？」
    → 「そのアクションが合理的に見える状況とは？」
      → 「システムがどう改善されればその状況を防げたか？」

例:
「山田さんが本番DBに直接クエリを実行して障害」
  → 「なぜ本番DBに直接アクセスしたか？」
    → 「テスト環境にデータがなく、本番で確認するしかなかった」
      → 「テスト環境のデータ同期を自動化する」
      → 「本番DBへの直接アクセスを技術的に制限する」

組織にブレームレスを根付かせる

リーダーシップの役割

プラクティス説明
リーダーが率先して示すVPoE/CTOがポストモーテムで「システムの問題」に焦点を当てる
自分の失敗を共有するリーダーが過去の自分の障害経験をオープンに語る
報告者を称賛する障害を早期報告した人を明確に称賛する
犯人探しを止める会議中に「誰が」という質問が出たら「何が」に言い換える

段階的な導入

フェーズ期間活動
啓蒙1-2ヶ月ブレームレスの概念を全社に説明、事例共有
実践開始3-4ヶ月SREチーム主導で最初のブレームレスポストモーテム実施
定着5-6ヶ月開発チームにも展開、ポストモーテムを定期実施
文化化7ヶ月以降全チームが自律的にブレームレスポストモーテムを実施

抵抗への対処

抵抗発言例対処
管理職「責任を取る人がいないと困る」個人責任と組織改善の違いを説明
ベテラン「昔からこうやってきた」データで従来手法の限界を示す
被害者意識「自分のチームばかり障害を起こす」システムの複雑さの問題として再フレーム

まとめ

ポイント内容
ブレームレスの本質個人を責めず、システムの改善に焦点を当てる
誤解の排除「責任放棄」ではなく「組織的学習」のための文化
導入の鍵リーダーシップが率先して示すことが不可欠

チェックリスト

  • ブレームレス文化の本質と誤解を理解した
  • 「責める」から「学ぶ」への言い換えができる
  • 組織へのブレームレス導入アプローチを理解した

次のステップへ

次は「ポストモーテムの書き方」です。ブレームレスの原則に基づいた、効果的なポストモーテムドキュメントの作成方法を学びましょう。

推定読了時間: 30分