最新記事公開時にプッシュ通知します

【スゴ本】重大インシデントは報告されなかったミスから始まる。致命傷を負う前に読むべき5冊

2025年10月20日

【スゴ本】小さなミスの「ごまかし」が致命傷になる前に読むべき5冊[レバテックLAB]

Dain

古今東西のスゴ本(すごい本)を探しまくり、読みまくる書評ブログ「わたしが知らないスゴ本は、きっとあなたが読んでいる」の中の人。自分のアンテナだけを頼りにした閉鎖的な読書から、本を介して人とつながるスタイルへの変化と発見を、ブログに書き続けて10年以上。書評家の傍ら、エンジニア・PMとしても活動している。
わたしが知らないスゴ本は、きっとあなたが読んでいる

はじめに

私の周りには、真面目で几帳面で責任感が強く、自分の仕事を完璧にこなそうとするITエンジニアが多い。上層部や顧客の要求から生まれる「失敗は許されない」という文化は、現場への圧力となり、エンジニア自身の自己検閲を強めることになる。

その結果、保守的で融通が利かなかったり、新しい技術や改善への挑戦が減ったりする。ミスが多発しそうなタスクを忌避し、リスクの押し付け合いが起きやすい。大きなプレッシャーは小さな失敗を隠す動機となる。

小さな失敗は積み重なり、やがて大きな失敗へとつながる。1つの重大事故の背後には、29の軽微な事故があり、さらにその背景には300のヒヤリ・ハットがあるというハインリッヒの法則は、ITエンジニアを長く続けるほど身に覚えがある。

問題は失敗ではなく、失敗を極度に恐れ、萎縮してしまうことにある。失敗が明るみに出ると、「なぜ起きたのか?」「再発防止は?」と責任追及が始まり、さらなる萎縮を呼ぶ。

負のループを脱出するために、どうすればよいか?

書籍リスト
  1. 1. 『「正しく」失敗できるチームを作る』石垣雅人 著
  2. 2. 『失敗の科学』マシュー・サイド 著、有枝春 訳
  3. 3. 『なぜエラーが医療事故を減らすのか』ローラン・ドゴース 著、入江芙美、林昌宏 訳
  4. 4. 『失敗の本質』戸部良一、寺本義也、鎌田伸一、杉之尾孝生、村井友秀、野中郁次郎 著
  5. 5. 『「何回説明しても伝わらない」はなぜ起こるのか?』今井むつみ 著

失敗をリフレーミングして再発防止につなげる

そこで1冊目、『「正しく」失敗できるチームを作る』だ。

▲『「正しく」失敗できるチームを作る』石垣雅人 著、技術評論社

「失敗」すればいい。それも、できるだけ早い段階で小さな失敗をして、そこから得たノウハウをフィードバックしていけばいい。

そもそも、失敗が全く無いプロジェクトなんて、存在しない。人間がやることだから、大なり小なりミスがある。個人で収まらない手戻りやリテイク・リスケジュールは普通にある。ましてや、ITエンジニアが任されるのは、たいてい新しい技術であり新しい要件だ。

もちろん、失敗しないに越したことはないが、それは不可能というもの。だから、学習につなげ、改善を積み重ねられる失敗をしていく。アジャイルやDevOpsが強調する「実験文化」「改善文化」はそのための仕組みになる。

失敗とは何か?本書では、マーチン・ファウラーの「失敗とは何か」を用いて、失敗の本質を言い当てる。

プロジェクトの失敗はスケジュールの遅れや予算の超過による失敗ではなく、見積りの失敗です。プロジェクトが遅れた、またはコスト超過したために失敗したと言うのではなく、失敗したのは見積りなのです。
(「失敗とは何か(What Is Failure)」、訳は筆者による)

プロジェクトの失敗とは、良く言われる「納期遅れ」や「予算超過」そのものではないのだ。それらは結果にすぎず、真の失敗は「見積りの誤り」にある。つまり、失敗とは「予測(見積り)と現実の乖離が、重大な影響を及ぼした現象」である。

この視点に立つと、失敗から学ぶ問いは変わる。

「なぜ納期に遅れたのか」で思考を止めるのではなく、「どの見積りが誤っていたのか」「その見積りはなぜ甘かったのか」と掘り下げることができる。

例えば仕様変更が原因で遅延した場合も、「仕様変更を受け入れて間に合うと判断した根拠は妥当だったか?」と問い直すことで、初めて再発防止につながる学びが得られる。

もちろん納期遅延は「失敗」として顧客や上層部に説明する必要はある。だが、ただの「失敗」を「正しい失敗」にするためには、「どの見積りが誤っていたのか?」というリフレーミングが求められる。起きていること(納期遅延)は変わらないが、その意味付けや評価を変えることで、学べる失敗にする。

「ソフトウェア開発はゼロリスクであるべき」という前提を否定し、下記のような「正しい失敗」を導く組織文化を育む手法を紹介する。

・「隠された失敗」から「透明性のある失敗」へ
・「繰り返される失敗」から「学べる失敗」へ
・「低リスクなムダな失敗」から「リスクを取った学べる失敗」へ

マネージャーの役割は重要だ。失敗に関する考え方をリフレーミングし、失敗から組織が学ぶ重要性を説いたり、失敗事例が集まりやすい雰囲気をつくれという。

直視できなかった失敗を「歓迎」してみる

失敗は隠すものでなく、むしろ歓迎するべきもの。「歓迎する」とまで言わなければならないのは、人は失敗から学べないからだ。

人は失敗から学べない。いわゆる、一般的に「過去の過ちから学ぶ or 学ばない」という話ではない。そもそも、失敗を「失敗」と認知できないのだ。

▲『失敗の科学』マシュー・サイド 著、有枝春 訳、ディスカヴァー・トゥエンティワン

そんなバカな!?という人は、『失敗の科学』をお薦めする。「失敗を予習するために読む4冊」でも紹介したが、本書は、人はなぜ失敗から学べないのか、どうすれば学びに変えられるのかを解き明かした名著だ。

航空事故や医療事故などの豊富な事例に基づいて、人間に基本的に備わっている「認知的不協和」「確証バイアス」を解説する。

認知的不協和とは、自分の信念と矛盾する出来事に直面したとき、自尊心が脅かされ強い不快感を覚えることだ。旅客機のパイロットや医療現場で働くプロフェッショナルは、「自分は有能であり正しい判断ができる」と信じている。そのため、その信念を覆す事実を受け入れるのは難しい。

「判断を誤った」と認めることは自己評価の低下につながると感じ、無意識に抵抗が働いた結果、事実を歪めてでも自己正当化し、誤った判断を繰り返すことになる。さらに、多大な労力やコストを投じた場合、「それが無駄だった」と認めるのは、サンクコスト効果により、一層困難になる。

これに確証バイアスが加わる。これは、自分の信念や仮説を支持する情報ばかりを集め、反証となる情報を無意識に無視してしまう傾向のことだ。人は「自分は正しい」と信じたいがために、都合のよいデータだけを選び取り、誤った解釈を補強してしまう。

こうして認知的不協和と確証バイアスが組み合わさると、失敗を直視することができず、同じ過ちを繰り返す構造ができあがる。医療事故での「判断ミスを認めない医師」や、航空事故での「誤った操作を正当化するパイロット」の姿は、この心理メカニズムを如実に示している。

失敗は、隠されるというより、そもそも認知すらされないのである―――それが大事故や重大なトラブルにならない限り。

だから、どんな些細な失敗であれ、まず認知することから始める必要がある。そのために、失敗を歓迎しなければならないのだ。

スイス・チーズの増やしかた

失敗を認知するために失敗を「歓迎」する。このオープンな姿勢が肝要だと主張するのは、『なぜエラーが医療事故を減らすのか』になる。

▲『なぜエラーが医療事故を減らすのか』ローラン・ドゴース 著、NTT出版

どれほど医療技術が進んでも、人の手を経て、人による判断がなされる以上、必ずミスは紛れ込む。それをゼロに近づける試みをレポートしたのが本書になる。

認知すらされていないミスを、重大事故につなげないためには、どうすればよいか?ここでは、「失敗を予習するために読む4冊」で紹介したスイス・チーズモデル」を用いて解説する。

▲スイス・チーズ・モデル図解。Wikipedia「Swiss cheese model」より引用

現場で生じるミスや失敗は、赤い矢印だと考えて欲しい。穴の開いたスイス・チーズは、そうしたミスを炙り出すチェックだったりレビュー、あるいはプロセスに組み込まれた安全対策だと見立ててほしい。

一つ一つのチーズは穴だらけで、ともすると失敗の矢印が通り抜けてしまいそうに見える。だが、チーズを複数並べることで、あるチーズの穴をすり抜けても、別のチーズに矢は刺さり、右側の重大事故へ通り抜けないようになっている。

つまり、一つ一つのレビューや安全対策が不十分であっても、これを冗長化することで、重大事故にさせないようにする。

このチーズを増やすためには、どうすればよいか?

単純にチェックを増やすといった発想では、同じ箇所に穴が空いたチーズを並べることになりがちだ。この場合、チェックが冗長化されて手間が増えるだけで、穴を塞ぐことにはつながりにくい。

ここは発想を変えて、矢印が一番右側に到達し、重大事故につながる場合を先回りして考える。チェックや対策をすり抜けて、もし、重大事故が生じるなら、それはどんな事故になるか?と、方向性を逆転させて考える。

この手法は「事前検死」と呼ばれる。失敗するリスクを見つけ出すことで、その対策を早く学べる。プロジェクトが開始した段階でメンバーを集め、「このプロジェクトは大失敗しました。なぜでしょう?」と問う。

あえて未来の失敗を前提とし、そこから想像力を働かせる。すると、普通なら思いつかない要因も、「失敗した未来」から逆算して可視化されやすくなる。事前検死は「失敗を予習するために読む4冊」でも紹介したが、ここではITプロジェクトならではの例を追加してみよう。

例えば、「試験機と本番機を間違えて、本番機をDROPした」なんてホラーな話が出てくるかもしれぬ。そこから考えられる対策として、「それぞれの環境に接続する端末を物理的に分ける」や、そこにコストが掛けられない場合「プロンプトの文字色や壁紙を変える」「手順書の文字色を変える」といったアイデアが浮かぶかもしれない。

事前検死は、プロジェクト開始直後だけでなく、レビューの時にも使える。一通り終わった後、「もしこのレビューをすり抜けている不具合があるとしたら、それは何だろう?」という質問を投げかけてみる。レビュー時は、その対象機能の実装なりテストケース(すなわち、スイスチーズの「チーズ」の部分)が関心の焦点となっている。だが、チーズの穴となる部分を想像してもらうのだ。

レビューで見落とされがちなのは、非機能要件と対象機能のスキマにある問題だ。レビュー対象の機能が呼び出した先で処理時間がかかる場合、いつからタイムアウトとして扱うかが検討されておらず、デフォルトのタイムアウトになっていた。しかし別契機でデフォルトのタイムアウト時間が設定変更となった場合、元の機能で不具合が生じるやつ。

旧日本軍の教訓を開発現場に活かす

ここまで「正しい失敗」をする方法や、「正しい失敗」ができるチームづくりについて紹介してきた。最後は反対に、正しい失敗ができない組織はどのようなものになるかを、日本軍をベースに考えてみよう。

▲『失敗の本質』戸部良一 ほか著、中公文庫

太平洋戦争において日本軍がおかしてきた失敗の事例研究としては、『失敗の本質』がある。経営層向け研修のサブテキストとして用いられることが多いので、予習のつもりで読むのもいいかも。

これは歴史書ではなく、歴史書からピックアップした事例をベースに、特定の観点から解説したケーススタディ集と見たほうがいい。本書の結論は、「負け戦の究極の原因は、日本軍の組織文化である」になる。

そして、この結論に持っていくために、歴史にIFを持ち込んで「もし〜ならば戦局は変わっていた」という後知恵で議論を組み立てる。

では、後知恵バイアスまみれだからダメかというと、そうでもない。想定通りの戦局とならなかった場合(=見積もりと現実にギャップが生じた場合)、日本軍が取った対応を逆転させることで、今の教訓として学べるから。

本書が主張する「過去の成功体験の過剰適応(過学習)が、時代の変化に対応できなくさせた」という教訓は、現代にもつながっている。

つまりこうだ。陸軍は、日露戦争で成功した銃剣突撃白兵戦を信奉し続け、火力中心・機動戦を重視する近代戦の流れに取り残された。いっぽう海軍は、日露戦争で成功した艦隊決戦思想に固執し、航空機・潜水艦・レーダーの台頭による統合システム戦に遅れた。

組織からすると「過去の成功体験=正しいやり方」という前提から抜け出せなかったと言える。日本軍の失敗は「組織文化」というよりも変化に対する鈍感さに置き換えるとしっくりくる。

「過去の成功が選択を見誤らせる」例なら、KodakのフィルムとかNokiaの携帯電話が有名だろう。最近だと、NikeのBoC戦略だろうか。コロナ禍の外出制限で成功した直販モデルが、ポストコロナの消費者や小売チャネルの離反を招いている。

日本軍の失敗の逆張りを目指すなら、どうすればよいか?つまり、失敗から教訓を探し、人ではなくやり方を変え、異議を歓迎し、そして変化に対して敏感になるにはどうすればよいか?本書からは、以下の対応が引き出せるだろう。

『失敗の本質』は、日本軍の行動をアンチパターンとする場合、どのような姿勢で向き合えばよいか?という視点で読むといい。「いまのやり方」が正解だったのは過去だったかもしれない――組織として、そういうスタンスで向き合うのだ。

失敗を報告してもらえることに「ありがとう」

失敗を歓迎する組織は、どうやってつくられるか?犯人を探すのではなく教訓を探し、人を責めるのではなくやり方を変えるには、どうすればよいか?

1つの具体的な方法は、まず「ありがとう」を伝えることだと考える。私の場合だが、ミスが申告されたとき、トラブルの第一報を受け取った時、何よりもまず「ありがとう」から返事をするよう、心がけている。

・教えてくれてありがとう。 いま知ったおかげで、リスケ調整ができるかもしれない
・今でよかった、ありがとう。リリース後だったらもっと大変だったに違いないから
・ありがとう、まずは業務影響を優先して調べよう

「失敗したら非難される」という恐怖や、「私のせいにされるかもしれない」という不安が、報告をためらわせる。その恐怖や不安を取り除くために、失敗を報告してきた勇気を称える。

▲『「何回説明しても伝わらない」はなぜ起こるのか?』今井むつみ 著、日経BP

同じようなことは、『「何回説明しても伝わらない」はなぜ起こるのか?』でも語られている。本書は、コミュニケーションの失敗がどのように起きているかについて、認知科学の観点から解き明かす。

人はバイアスや記憶の曖昧さ、感情による影響など、認知の「ショートカット」や誤りを通じて情報を処理しており、これが「伝わらない」原因となっていると説く。

そして、相手のスキーマ(バックグラウンド・知識・経験)を想像し、ただ結論(主張)だけでなく、その理由や背景もセットで伝えることで、相手の納得感を高めることができるという。相手のスキーマに結びつけやすくするため、例え話や比喩・ストーリーを用いることも有効だという。

さらに、相手の感情面に配慮することで、伝わり方に影響するという。感情は認知の「フィルター」として働き、同じ言葉であっても受け取り方や解釈を左右するという。

「イヤな報告を受けた時こそ、相手を褒める・感謝する」くらいの心づもりが必要です。部下のホウレンソウ(特にネガティブなもの)に対して褒める」というフィードバックを続けていくうちに、「失敗を報告したら褒めてくれた」という話が広まるようになります。そうすると、ポジティブサイクルが回り始めます。
『「何回説明しても伝わらない」はなぜ起こるのか?』 p.281)

ミスの報告へのハードルが下がり、ミスの取り返しがつかなくなる前に、報告してくれるようになる。

おわりに

注意してほしいのは「失敗してもいい」というわけではないこと。もちろん失敗はできればしたくないもの。だが、失敗を忌むべきもの、隠すものとして扱うと、負のループが始まる。責任感が強く真面目なITエンジニアほど、追い込まれるようになる。

このループを断ち切るため、失敗とは学びと成長のための機会だと捉えよう。

『「正しく」失敗できるチームを作る』では、「正しい失敗」とは何かを定義した。ITプロジェクトにおいて「失敗ゼロ」は幻想であり、「正しい失敗」をすることで失敗を知見に変えるヒントを紹介した。

『失敗の科学』では、人に備わっている2つのバイアス――認知的不協和と確証バイアス――を紹介した。失敗は、隠されるというよりも、トラブルになったり炎上しない限り、そもそも認知すらされないのが普通だと考えよう。

『なぜエラーが医療事故を減らすのか』では、どうやって失敗を致命的なトラブルに連鎖させないかを、スイス・チーズのモデルを用いて、ITプロジェクトの実例と共に解説した。スイス・チーズを増やすために、チームで失敗を共有することが肝要だと説明した。

『失敗の本質』を用いて、日本軍の失敗への向き合い方を反面教師として活用した。変化を恐れず、失敗から教訓を抽出し、組織のシステムを更新し続けることこそが、ITプロジェクト成功のカギだとも言える。

最後に、『「何回説明しても伝わらない」はなぜ起こるのか?』を通じて、失敗への初手の対応として「感謝」の有効性を説明した。「ミスに感謝する」なんて奇異に受け取るかもしれないが、心理的安全性を確保し、ミスを小さい段階で早く受け取るには、「ありがとう」が有効だ。

ITエンジニアを追い込む負のループを断ち切るのは、「ありがとう」が返ってくるチームから始まる。失敗を歓迎する文化をあえて演出するために、リーダーは率先して使っていきたい。

関連記事

人気記事

  • コピーしました

RSS
RSS