失敗はなぜ起きるのか？ 失敗事例を構造で読む完全ガイド
失敗を本当に理解したいなら、「誰が悪かったか」より先にどういう条件が重なって、その判断が起きたのかを見なければいけません。
うまくいかなかった案件、事故、障害の多くは、1人のミスだけで起きたわけではありません。現場の見落とし、伝達の抜け、無理な日程、弱い安全確認、曖昧な責任分担。こうした小さな穴が同じ方向に並んだとき、表面に見える失敗が起きます。
この記事では、失敗事例を感情論ではなく構造で読むために、基礎知識から実際の事例、分析の手順、ありがちな誤解までをまとめて整理します。
- 失敗を「個人の能力不足」だけで片づけるとなぜ学びが浅くなるのか
- 失敗を構造で読むときに押さえるべき基本用語と見方
- 実際の事例で、何が連鎖し、どこに防げる余地があったのか
- 次の失敗を減らすために、何を直せばよいのか
全体像と結論
結論から言うと、大きな失敗は「単発のミス」ではなく「条件の連鎖」で起きると考えるのが出発点です。
たとえば、担当者が誤った判断をしたとしても、その前にはたいてい次のような背景があります。
- 十分な情報が届いていなかった
- 危険信号が以前から見えていたのに慣れてしまっていた
- 納期や運用都合が安全側の判断を押し返していた
- チェックの仕組みが人の注意力に依存していた
- 失敗後に記録と共有が不十分で、同じ弱点が残っていた
つまり、失敗を理解する軸は「原因探し」より少し広いです。見るべきなのは次の5点です。
- 何が起きたか
- その直前に誰が何を見て何を判断したか
- その判断を生んだ条件は何か
- 途中で止めるはずの仕組みはなぜ効かなかったか
- 再発防止は人への注意喚起で終わっていないか
ここがポイント: 失敗分析の目的は犯人探しではなく、同じ失敗が再び起きる条件を減らすことです。
基礎知識: 失敗を構造で見るとはどういうことか
まず、失敗を見る2つの考え方を分けておくと理解しやすくなります。
「人の問題」として見る見方
これは「誰かがミスしたから起きた」という見方です。わかりやすい半面、そこで止まると再発防止が弱くなります。
注意力や気合いを求めても、情報不足や無理な運用が残ったままなら、別の人が同じ場所でまたつまずくからです。
「仕組みの問題」として見る見方
心理学者ジェームズ・リーズンは、失敗を個人だけでなくシステム全体の防御の弱さとして捉える考え方を広めました。いわゆる「スイスチーズモデル」は、複数の防御にそれぞれ穴があり、その穴が重なると事故や障害が表に出る、という説明です。
ここで重要なのは、現場の行動だけでなく、その前段にある条件まで見ることです。
- 教育や訓練は十分だったか
- 危険情報は意思決定者まで届いていたか
- 例外運用が常態化していなかったか
- 異論を言いやすい場だったか
- チェックは手順だけでなく実際に機能していたか
先に覚えたい4つの用語
- 直接要因: 直前に起きた操作ミスや判断ミスなど、表面に見える引き金
- 潜在条件: 以前から積み上がっていた弱点。人員不足、曖昧な権限、古い手順、無理な計画など
- 防御策: レビュー、承認、監視、テスト、自動化、第三者確認のような事故を止める壁
- ポストモーテム: 障害や失敗の後に、何が起き、なぜ起き、どう防ぐかを記録して学ぶ振り返り
仕組み: 失敗事例はどう分解すれば見えてくるのか
失敗を構造で読むときは、時系列だけで追うより、層に分けて見るほうが整理しやすいです。
1. 表面の出来事を確定する
最初にやることは、評価ではなく事実の確定です。
- いつ起きたか
- 何が壊れたか、止まったか、遅れたか
- 誰に影響が出たか
- どこで最初に異常が見えたか
ここが曖昧だと、後の議論が印象論になります。
2. 直前の判断を洗い出す
次に、「最後に失敗へ近づけた判断」を見ます。ただし、ここで終わらせません。
見るべきなのは、判断の善悪より、その時点で見えていた情報です。
- 何を根拠に進めたのか
- 何が見えていなかったのか
- 反対意見はあったのか
- その反対意見は誰に届いたのか
3. 背後の条件を探る
ここが構造分析の中心です。直前の判断を生んだ背景を掘ります。
- 日程や売上などの圧力
- 慣れによる危険信号の軽視
- 部門間の伝達不全
- 文書や手順の不備
- 監視やテストの弱さ
同じ失敗が繰り返される組織では、この層が放置されています。
4. 防御策がなぜ機能しなかったかを見る
失敗の本質は「ミスが起きたこと」だけではありません。ミスを止める仕組みが止められなかったことも同じくらい重要です。
たとえば、次のような状態です。
- レビューが形だけで、実際は流れ作業だった
- 警告が出ても、止める権限が弱かった
- 監視はあったが、異常の意味が共有されていなかった
- 手作業が多く、再現性が低かった
5. 再発防止策の質を見極める
対策は強さに差があります。
| 対策の種類 | 内容 | 再発防止の強さ |
|---|---|---|
| 注意喚起 | 気をつける、周知する | 弱い |
| 手順修正 | 確認項目を増やす、承認を追加する | 中程度 |
| 構造修正 | 自動チェック、権限制御、設計変更でミスしにくくする | 強い |
人の注意力にだけ頼る対策は、忙しくなると崩れやすいです。構造を変える対策ほど、再発防止としては強くなります。
重要ポイント: 失敗を深く理解するための観点
ここからは、実際の分析で特に見落とされやすい論点を絞って整理します。
圧力は失敗の「背景」ではなく「一部」
納期、打ち上げ日程、障害復旧の急ぎ、顧客対応。こうした圧力は言い訳ではなく、意思決定を変える実際の要因です。
「急いでいた」は感想で終わらせず、何が削られたのかまで見る必要があります。
- 確認時間が減ったのか
- 異論の検討が省かれたのか
- 既知のリスクを飲み込む判断になったのか
異常の常態化が起きていないか
小さな異常が続いても大事故にならないと、人はだんだん慣れます。すると、本来は止まるべき場面でも「いつもの範囲」と見なしてしまいます。
これは単なる油断ではなく、組織が危険信号を学習できていない状態です。
「責任」と「非難」は分ける
構造で考えると言っても、責任が消えるわけではありません。決裁者、設計者、運用責任者にはそれぞれ責任があります。
ただし、責任の確認と、個人を攻撃して終わることは別です。再発防止に必要なのは、責任の所在だけでなく、その責任を支える仕組みが十分だったかです。
具体例: 失敗を構造で読むと何が見えるのか
抽象論だけでは掴みにくいので、性質の違う2つの事例を見ます。
チャレンジャー号事故: 技術不良だけでは説明できない失敗
1986年1月28日、NASAのスペースシャトル「チャレンジャー」は打ち上げ73秒後に空中分解しました。NASAの資料では、技術的には右側固体ロケットブースター接合部のOリング破損が直接原因とされています。
ただし、ここで止めると理解が浅いです。NASAが公開している事故調査の要約では、打ち上げ前から低温がOリングに与える影響への技術者の懸念があり、さらに意思決定や安全体制にも重大な問題があったとされています。
構造で分けるとこう見えます。
- 直接要因: Oリングが高温ガスの漏れを防げなかった
- 背景条件: 異常な低温、以前からあった接合部への懸念
- 組織要因: 技術者の懸念が十分に扱われない意思決定、安全部門の関与の弱さ
- 圧力: 過密な打ち上げ計画とスケジュール圧力
- 学べる点: 技術問題が見えていても、意思決定の仕組みが弱ければ止められない
この事故が示したのは、壊れた部品だけ直しても不十分だということです。実際、NASAはその後、設計変更だけでなく、安全・品質保証の体制も見直しました。
ソフトウェア障害の振り返り: 人を責めるより、再発しにくい設計に変える
技術運用の世界では、GoogleのSRE資料が失敗学習の実務をかなり明確に言語化しています。ポストモーテムは、障害の影響、原因、対処、再発防止策を記録し、次の障害確率や影響を下げるためのものだと整理されています。
そのうえでGoogleは、「人を直す」のではなく、システムとプロセスを直すという立場を取ります。これは、複雑な環境では個人の完璧さに依存しても限界があるからです。
Atlassianが紹介している事例もわかりやすいです。重要機器の設定ファイルの記述ミスで全社障害が起きたあと、担当者を処罰するのではなく、設定投入前に自動で起動可否を確認する仕組みを入れ、さらに人手で設定を触る余地自体を減らしました。
この事例を構造で見ると、学ぶべき点は明確です。
- 直接要因: 設定ミス
- 弱かった防御: 読み込み前の自動検証がなかった
- 再発防止: 人の注意ではなく、自動チェックを追加
- 学べる点: 同じ人を責めても再発確率は大きく下がらないが、仕組みを変えると下がる
業界が違っても、読み方は同じです。事故でも障害でも、見るべきなのは「最後のミス」ではなく「そこまで通してしまった構造」です。
よくある誤解
「根本原因は1つに決まる」
実際には、失敗は複数要因の組み合わせで起きることが多いです。1つだけ選ぶと、都合のいい単純化になりやすく、対策も弱くなります。
「責めない分析は甘い」
責めないことと、曖昧にすることは違います。事実確認、責任確認、対策実行は必要です。ただ、恐怖で黙らせると、次の危険信号が上がってこなくなります。
「チェックを増やせば十分」
チェックを増やしても、忙しい現場では形骸化します。重要なのは、止める権限、見落としにくい設計、自動化など、守りが実際に機能する形にすることです。
「失敗事例は特殊で、自分たちには関係ない」
分野は違っても、構造は似ます。
- 警告が軽視された
- 時間圧力が強かった
- 手順が現実に合っていなかった
- 責任はあるのに権限が弱かった
- 学びが文書で終わり、設計に反映されなかった
ここが共通するなら、その事例は十分に自分ごとです。
理解を深める整理: 失敗分析で見るべき質問
失敗事例を読むとき、次の質問を当てると表面的な感想で終わりにくくなります。
事実確認の質問
- 何が起きたのか
- 影響は誰に及んだのか
- どの時点で止める余地があったのか
判断の質問
- 当事者は何を知っていて、何を知らなかったのか
- 反対意見や警告は上がっていたのか
- なぜその判断がその場では合理的に見えたのか
構造の質問
- どの防御策が機能しなかったのか
- 圧力や慣れは判断をどう変えたのか
- その失敗は別の人でも起こしうる設計だったのか
改善の質問
- 対策は「気をつける」で終わっていないか
- 自動化、設計変更、権限変更まで踏み込めているか
- 学びは共有され、次の現場で使える形になっているか
最低限ここだけ覚えるポイント
- 失敗は1人のミスではなく、複数の条件が重なって起きることが多い
- 分析では、直接要因だけでなく潜在条件と防御の弱さまで見る
- 納期や運用圧力は、失敗の外側ではなく失敗の構成要素である
- 「責任を問うこと」と「個人攻撃で終わること」は別物
- 再発防止は注意喚起より、設計変更や自動化のほうが強い
- 良い振り返りは、事実を記録し、共有し、次の仕組みに反映させる
まとめ
失敗事例から本当に学ぶには、「誰が失敗したか」から「なぜその失敗が通ってしまったか」へ視点を移す必要があります。
表面のミスだけを見ると、注意力や気合いの話で終わります。ですが、構造まで見ると、情報の流れ、権限の設計、日程圧力、防御策の弱さ、学習の不足が見えてきます。そこまで見えてはじめて、次の失敗を減らせる対策に届きます。
次に失敗事例を読むときは、最後の判断だけを追わず、その判断を生んだ条件と、止めるはずだった壁の弱さを必ず見てください。そこに再発防止の本体があります。