TL

非難なきポストモーテムとSafety-II

障害から本当に学べる組織になる。後知恵バイアスと帰属の誤りをどう排除するか、ローカル合理性の考え方、そしてSafety-IからSafety-IIへの視点転換と学習文化の原理を解説します。

応用DevOpsポストモーテムSRESafety-II学習文化信頼性最終更新: 2026-06-21
TL;DR要点だけ先に
  • 1.非難なきの本質は優しさではなく精度。人を責める文化は失敗を隠させ、隠れた原因が学習を止めて再発を招く。
  • 2.後知恵バイアスと基本的帰属の誤りが分析を歪める。ローカル合理性を前提に「その時の情報でなぜ妥当に見えたか」を問う。
  • 3.Safety-Iは失敗を減らす視点、Safety-IIはうまくいく理由を増やす視点。両者を併せて回復力(レジリエンス)を設計する。

「非難なき」は道徳ではなく精度の問題

非難なきポストモーテム(blameless postmortem)はしばしば「人に優しい振り返り」と誤解されますが、本質は 分析の精度 にあります。人を責める文化では、当事者は処罰を避けるために情報を隠すか、自己弁護に有利なように経緯を語ります。すると分析の入力データそのものが汚染され、真の原因に到達できません。隠れた原因は修正されず、同じ障害が形を変えて再発します。

つまり非難の有無は、学習システムへの入力品質 を決める変数です。正直に話しても罰されないと全員が確信して初めて、本当の意思決定の連鎖が机上に並びます。基本(/devops/incident-postmortem/)を踏まえた上で、本稿はその裏側にある認知科学と安全工学の原理を扱います。

Just Culture(公正な文化)

非難なきは「誰も決して咎められない」ではありません。Just Culture は、正直な過誤(human error)・リスク行動(at-risk behavior)・無謀(reckless)を区別します。前二者は仕組みで支える対象、最後だけが説明責任の対象です。重要なのは線引きを 行為の結果ではなく、行為時点の意図と認識 で行う点です。結果の重大さで遡って裁くと、後述の後知恵バイアスに直結します。

後知恵バイアスと基本的帰属の誤り

ポストモーテムを歪める二大認知バイアスがあります。

後知恵バイアス(hindsight bias) は、結果を知った後では「予見可能だった」と感じてしまう傾向です。障害が起きた後にログを並べれば、危険の兆候は一直線に見えます。しかし当事者は、その兆候が無数の正常なノイズに埋もれた状態で、リアルタイムに判断していました。結果から逆算して「なぜ気づかなかったのか」と問うのは、見えなかったものが見えていたと仮定する誤りです。

基本的帰属の誤り(fundamental attribution error) は、他者の失敗を状況要因ではなく性格・能力に帰属させる傾向です。「彼が不注意だった」で止まると、同じ状況に置かれた別の人も同じ操作をしてしまう構造的欠陥が見えなくなります。

この二つが結合すると、「予見できたはずのことを、不注意な個人が見逃した」という物語が自動生成されます。心地よく完結しますが、修正可能な原因を何も与えません。

反実仮想(counterfactual)を根本原因と取り違えない

「もし手順書を確認していれば防げた」式の反実仮想は、後知恵で構成した架空の分岐にすぎません。実際には起きなかった行動を根拠に責めるのは、分析ではなく断罪です。問うべきは「なぜ確認しないことが、その時は自然だったのか」です。手順書が古い・長い・参照しづらい、といった実在の制約こそが対策対象になります。

ローカル合理性(local rationality)

これらのバイアスを排除する基盤が ローカル合理性原理 です。これは「人は、その時点で自分が持っていた情報・目標・注意資源の範囲内では、合理的に行動していた」と仮定する立場です。当事者は事故を起こそうとしたのではなく、限られた認知資源で その局面では妥当に見える選択 をしました。

したがって分析の問いは「なぜ間違えたのか」ではなく、「その判断が、その時点でなぜ妥当に見えたのか」 に変わります。この問いは、当事者が見ていた画面・受け取っていたアラート・抱えていた時間圧力・矛盾する目標(速度と安定の板挟みなど)を再構築させ、システム側の改善点を浮かび上がらせます。

# 非難ありの問い(結果から逆算、修正不能)
なぜ本番に危険な設定を入れたのか? → 「不注意」で停止

# ローカル合理性の問い(行為時点に立つ、修正可能)
その変更は、その時どんな情報のもとで妥当に見えたか?
  - ステージングと本番の差分が画面に出ていなかった
  - 確認ダイアログが常に出るので無意味化していた(警報疲労)
  - リリース期限の圧力で時間が逼迫していた
→ 差分表示の追加・段階反映・自動チェックという仕組みの対策へ

ミスを許してしまった仕組みの欠陥を直す発想は、ガードレールとして IaCCI/CD に落とし込めます。「次は気をつける」ではなく、そもそも事故れない構造を作るのが目的です。

Safety-I から Safety-II へ

伝統的な安全観 Safety-I は、安全を「失敗が無い状態」と定義し、うまくいかなかった事例(インシデント)だけを分析対象にします。前提は「システムは基本的に正しく動き、人間の逸脱が失敗を生む」という機械的な世界観です。対策は逸脱の除去、すなわち手順の標準化・制約・自動化です。

これに対し Safety-II(Erik Hollnagel が提唱)は、安全を 「うまくいく状態を増やす能力」 と定義します。着目点は反転します。

観点Safety-I(従来)Safety-II(回復力)
安全の定義失敗が無いことうまくいく事例が多いこと
分析対象少数の失敗事例日常の成功も含む大多数の事例
人間の見方失敗を生む不安定要因変動を吸収し成功を作る要因
目標逸脱・ばらつきの除去適応力(調整能力)の強化

決定的な洞察は、失敗と成功は同じ源から生まれる という点です。現実のシステムは設計通りには動かず、人間は曖昧な状況・矛盾する目標・不完全な情報の下で常に微調整して帳尻を合わせています。Hollnagel はこれを「効率と完全性のトレードオフ(ETTO)」と呼びました。その日常的な調整が大多数の場面で成功を生み、ごく稀に裏目に出たときだけ「失敗」と名付けられます。失敗だけを取り除こうとすると、成功を支えていた同じ適応力まで削ってしまう危険があります。

Work-as-Imagined と Work-as-Done のずれ

手順書が描く理想の作業(Work-as-Imagined)と、現場の実際の作業(Work-as-Done)には必ずずれがあります。このずれは怠慢ではなく、現実の制約に人間が適応した痕跡です。Safety-II は両者の差分を「埋めるべき逸脱」ではなく「学ぶべき知見」として扱い、現場がなぜそう動くかを理解してから仕組みを整えます。

実務への接続:成功からも学ぶ

Safety-II の実装は、Safety-I を捨てることではありません。失敗の分析(Safety-I)は依然必要で、その質を後知恵バイアス排除とローカル合理性で高めます。その上で、障害にならなかった事例からも学ぶ 活動を加えます。

  • ニアミス(あと一歩で障害だった事例)を、実害が無くても積極的に記録・共有する。
  • 「なぜ今日も大半のデプロイは無事だったのか」を問い、暗黙の防御策を可視化する。
  • カオスエンジニアリング(/devops/chaos-engineering/)で、平常時にシステムと組織の適応力そのものを試す。

これらは回復力(レジリエンス)を 計測可能な信頼性目標 へ橋渡しします。学習の成果は手順や暗黙知に留めず、SLO とエラーバジェット(/devops/error-budget-math/)の運用や、ガードレールの自動化に反映してこそ組織の資産になります。

試験・面接のポイント

「ポストモーテムを非難なきにする理由は」と問われたら、優しさではなく 学習精度(隠蔽の防止) と答えるのが核心です。後知恵バイアス・基本的帰属の誤り・ローカル合理性・Safety-I対Safety-IIの対比はセットで問われやすいので、「失敗の除去」対「成功の増強」「Work-as-Imagined」対「Work-as-Done」の語で整理しておきましょう。

まとめ

  • 非難なきの目的は 分析精度。責める文化は隠蔽を招き、隠れた原因が再発を生む。
  • 後知恵バイアス基本的帰属の誤り が分析を歪める。反実仮想を根本原因と取り違えない。
  • ローカル合理性 を前提に「その時なぜ妥当に見えたか」を問い、システムの欠陥を直す。
  • Safety-I(失敗を減らす)に Safety-II(うまくいく理由を増やす)を重ね、適応力=回復力を設計する。

DevOps/インフラ Article

非難なきポストモーテムとSafety-IIを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

DevOps

比較で見る軸

難易度: advanced / カテゴリ: DevOps/インフラ / タグ数: 6

導入後に効く点

後知恵バイアスと基本的帰属の誤りが分析を歪める。ローカル合理性を前提に「その時の情報でなぜ妥当に見えたか」を問う。

先に潰すリスク

用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。

数字・仕様の読み方
難易度
advanced
カテゴリ
DevOps/インフラ
タグ数
6

判断チェックリスト

  • 自社の用途が「DevOps / ポストモーテム」に近いか確認する。
  • 強みである「非難なきの本質は優しさではなく精度。人を責める文化は失敗を隠させ、隠れた原因が学習を止めて再発を招く。」が本当に評価軸になるか確認する。
  • 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

DevOpsポストモーテムSRESafety-II学習文化DevOpsポストモーテムSRE
参考: 公式情報