【「スゴ本」中の人が薦める】失敗を予習するために読む4冊

全てにおいてパーフェクトな仕事は存在しない。何かしら問題があったり、小さからず失敗があるもの。失敗をクヨクヨするよりも、予め失敗するものとして、なったらどうするかを準備しておこう。

 

• keyboard_arrow_down はじめに
• keyboard_arrow_down 失敗を科学する
• keyboard_arrow_down 失敗が再発するメカニズム
• keyboard_arrow_down ミスを厳罰化するとミスが報告されなくなる
• keyboard_arrow_down ミスから学ぶチームのつくり方
• keyboard_arrow_down スイス・チーズの喩え
• keyboard_arrow_down IT失敗学の研究
• keyboard_arrow_down おわりに

明確なゴールと計画が敷かれ、充分な準備や引継ぎがなされ、潤沢な予算とメンバーの下、納期も品質も想定通り――断言する、そんな仕事は、存在しない。

むしろ、プロジェクトは既に始まっているにもかかわらず、人もカネも揃っておらず、そもそも何をするのか曖昧なのに、納期だけはキッチリ切ってある。そんな中で走りながら考え、検討しながらつくり上げ、なだめてすかして穴を塞いで、なんとか動くモノに間に合わせねばならぬ――これが定常運転だ。

仕事とは常にやっつけだ。

だから失敗するのは当然だ。

失敗が大きいか小さいかだけの話であり、パーフェクトな仕事なんてものは無い。もちろんこれは本音ベースの話であり、外に吹聴するときは別であることは言わずもがなだが、念のため蛇足しておく。

というか、大なり小なり失敗するものとして扱わないと、心が保たぬ。何かしらの失敗が「ある」ものとして、むしろどんな失敗にどう対処するかを予め想定しておいて、準備をしたほうが気が楽だ。

もちろん、あらゆる失敗を予測することは不可能だから、想定外がでたらその時に考えよう。それでも、見える失敗は準備しておいたほうがいい。

そうした、失敗を準備するために役立つ書籍を紹介する。

とてつもない大失敗であれ、些細なミスであれ、それに直面した人たちがどんな風に対応したかを知っておいた方がいい。上手く言い逃れたり他人のせいにしたりするケースを目の当たりにすれば、自分はどう向き合えば良いかの標になるし、真摯に向き合う背中を見れば、そうありたい姿のロールモデルにもなる。

起きてしまったことにどう向き合うかを考える上で、まずお薦めしたい一冊目はこれ。『失敗の科学』だ。

「ありえない」失敗が起きたとき、人はどう反応し、何を考え（あるいは考えず）、対応していくのか。そして、どのようなメカニズムで失敗が繰り返されるのかが、豊富な事例と共に解説されている。

例えば、米国における医療ミスによる死亡者数は、年間40万人以上と推計されている(※1)。イギリスでは年間3万4千人もの患者がヒューマンエラーによって死亡している(※2)。
※1 A new, evidence-based estimate of patient harms associated with hospital care – PubMed (nih.gov)
※2 A safer place for patients: learning to improve patient safety – White Rose Research Online

回避できたにもかかわらず死亡させた原因として、誤診や投薬ミス、手術中の外傷、手術部位の取り違え、輸血ミス、術後合併症など多岐にわたる。数字だけで見るならば、米国の三大死因は、「心疾患」「がん」そして「医療ミス」になる。

うっかり見落としたり、忘れてしまうといったミスは、人間だからあたりまえだ。だが、あまりにも多すぎるこの数字は何を物語っているのか。

『失敗の科学』の著者マシュー・サイドは、ミスそのものよりも、ミスに対する「姿勢」に着目する。

無謬主義である医療業界には、「完璧でないことは無能に等しい」という考え方が是とされる。失敗は脅威であり不名誉なこととされているため、スタッフはエラーマネジメント（ミスの防止・発見）のトレーニングをほぼ受けていないという。

ミスが起きたとき、人は失敗を隠そうとする。自分を守るために、失敗を認めようとはしない。ちょうど映画のシーンを編集でカットするように、失敗の記憶を消し去ってしまう。自分の過ちを認めるよりも、事実の解釈を変えてしまうこともある。

個人レベルのみならず、ひとたび組織的な立場からの表明となると、事実とは異なることを言い出す。

ITエンジニアなら思い当たらないだろうか。まともな仕様が提示されないままスタートした結果、品質が安定せず、不具合を抱えたリリースが見えている場合だ。組織「内」の進捗報告の場で淡々と述べたはずの問題が、なぜか外向けには「問題なし」「オンスケ」と伝えられる。

あるいは、依頼された見積もりに、重要な前提条件が抜けていることに気づいた場合だ。抜けている前提を見積もり回答に追加し、その前提が守られないことで生じるリスクを説明するのだが、なぜか正式回答では省略され、数字だけが一人歩きし始める（そしてウヤムヤになった前提はトラブルの温床になる）。

組織の内側と外側が、あたかもホンネとタテマエのような建付けになっているのだ。

そして、ひとたび重大事故が起きて、予期せぬ結果について説明が必要なとき、どう答えるのか？

医療事故の調査によると、「ミス」ではなく「複雑な事態が起こった」と表現されるという。「技術的な問題が生じた」「不測の事態によって」といった婉曲法によって明らかにしない。情報開示に対する抵抗は強く、「患者が知る必要がない」「言っても理解できない」という言葉を盾に取り、事実を語ろうとしない。

疫学的調査によると、受診1万件につき、医療ミスを原因とする深刻な損傷が44～66件発生しているという。しかし、実際にヒアリングをしたところ、この結果通りの申告をしている病院は1％に過ぎなかったという。また、50％の病院は、受診1万件につき5件未満と報告していた。つまり、大半の病院が組織的に言い逃れをしていることになる。

ミスを認めない体質により、インシデントが共有されず、再発が繰り返され、重大事故につながる――この負のスパイラルは、医療業界に限ったことではない。あり得ない証拠をでっち上げる検察官や、自己保身のあまり事実を捻じ曲げる経済学者も登場する。もちろんITプロジェクトの場合も同じである。

では、こうしたミスを無くすにはどうすれば良いか？

「失敗は悪」として罰則を設ければよいという考えがある。ミスを厳罰化することで規律を正そうとする発想である。

この仮説を検証するためにリサーチが行われた。投薬ミスが慢性化している複数の病院が選ばれ、一つのグループは懲罰志向で、ミスを厳しく問い詰めさせた。もう一つのグループは非難をしない方針で運営した。

もうお分かりかと思うが、懲罰志向のグループにおいては、ミスの報告は激減した。一方、非難しないグループでは、報告件数は変わらなかった。そして、実際にミスが起きた件数は、懲罰志向のグループが遥かに多かったという。

私には、これと似た経験がある。かつて「品質を向上させるため、バグをゼロにする」というトチ狂った信条の上司が着任し、エラーを見つけ次第、厳しく叱責するようになった。

バグは激減したのだが、それは品質が良くなったわけではなく、報告されなくなったに過ぎない（その上司が離任するまで、報告用とは別の管理簿をつくって不具合の解析や改修調整をするようしのいだ）。

その上司が馬鹿なのは、なぜバグを管理するかを理解していないからだ。

なぜバグを管理するかというと、テストが想定通り進んでいて、品質を担保されているか測るためだ。沢山テストされてるならバグは出やすいし、熟知しているプログラマならバグは出にくい（反対に、テスト項目は消化しているのに、バグが出ないと、テストそのものの品質を疑ってみる）。つまり、バグの出具合によって、テストの進捗と妥当性が判断できる。

ミスを厳罰化するとどうなるか？

悲惨な事例は、『ヒューマンエラーは裁けるか』に詳しい。

個人的なミスが、ただ一つの「原因→結果」として重大な事故に直結していたなら、分かりやすい。だが、現実としてありえないだろう。ミスを事故に至らしめた連鎖や、それを生み出した土壌があるはずだ。

そうした背景や複雑な状況を無視して、ミスを起こした「個人」を糾弾することは、果たして公正なのか？「重大な過失」という判断は、誰が、何を基準になされるべきか？医療や航空業界における事故現場で実際に起きた事例を用い、こうした疑問に応えることで、議論の場をつくりだしている。

例えば、業務上過失致死罪を受けたスウェーデンの看護師の事例がある。

1. 　1. PCによる処方箋の作成の手間を厭って読みにくい手書きのメモを書いた医師
2. 　2. メモを「見せる」だけで口頭で引継ぎ指示した夜勤の担当（後にメモは消失）
3. 　3. シリンジの薬剤とバイアルの薬剤の箱を取り違えた看護師
4. 　4. ダブルチェックした同僚と小児科のスタッフ
5. 　5. 調剤の現場をサポートをした医師
6. 　6. 容態が急変した患者の対応をした医師

これらのプロセスを経て、規定量の10倍のキシロカインを含む薬剤が作成され、投与された生後三ヶ月の女児が死亡した。たしかに、濃度の異なる容器を間違えたことは事実だが、ミスを誘発するような環境や、ミスを検出できなかったことはとがめられなかった。また、6. でキシロカインを繰り返し投与したことについてとがめられることもなかった。ただ、3. の看護師の「過失」として扱われる。看護師は裁判を通じて、真実が明らかになることを求めるが、弁護士はこう言う。

それはできません。裁判所で求められているのは真実ではありません。求められているのは司法手続きと法的解釈であり、その手続きが正当であることと法的解釈が正しく行われ適用されるかどうかで、真実は二の次です。

この事故が明るみにでたのは、3. の取り違えを看護師が自発的に報告したからだ。2. のメモが誤読（誤記？）された可能性も考えられるが、メモは残っていない。看護師の記憶のみ拠っているため、信憑性は低く評価される。結局、看護師は病院を守るためのスケープゴートとして扱われ、似たようなインシデントを起こしていた同僚たちは「私でなくてよかった」と胸をなでおろす。再発防止策は「その場ではない」としてスルーされ、インシデントの共有という絶好の機会は失われる。

司直やマスコミの糾弾により、エラーは「犯罪」として扱われる。そこでは、アクシデントはもはや accidental （偶発的）といった意味合いをなくし、一罰百戒のための厳罰化が横行する。

著者はこうした状況に異を唱える。ヒューマンエラーを「犯罪化」し、事故の責任者を探し出して罰することでは、問題は解決しないと考える。民事訴訟も刑事訴訟もヒューマンエラーの抑止力として機能しない。

そこから生まれる不安は、例えば「防衛医療」といった後ろ向きの対策に向かうというのだ。防衛医療とは、医療訴訟の増加に伴い、医療者側が可能な限り訴訟リスクを回避するための医療行為になる。患者にとってプラスでも、後で訴えられる可能性があるなら、あえて行わないといったことが起こる。

「真実」よりも「もっともらしさ」を求め、後知恵バイアスで歪められたストーリーの下では、関係者は「オメルタ（Omertà）」を守るようになる。「オメルタ」とは沈黙の掟のことで、和風に言うなら「キジも鳴かずば撃たれまい」だろう。

ヒューマンエラーの厳罰化は、現場の萎縮を招くことになる。ミスが報告されなくなり、失敗が再発するメカニズムそのものである。

では、どうすればよいか？

失敗を認め、そこから学習することで、再発させない。どうすればこれが実現可能になるのか？

『失敗の科学』では、ミシガン州立大学での実験が紹介されている。被験者に単純なテストを受けてもらい、ミスをした時にどのように反応するかを、脳波測定する実験だ(※3)。
※3 Mind your errors: evidence for a neural mechanism linking growth mind-set to adaptive posterror adjustments – PubMed (nih.gov)

着目するべき脳信号は2つあるという。1つ目は、自分のミスに気づいた後50ミリ秒で自動的に現れる信号だ。これは「エラー関連陰性電位（ERN）」と呼ばれ、エラーを検出する機能に関連する前帯状皮質に生じる反応になる。

2つ目は、これはミスの200～500ミリ秒後に生じる信号になる。「エラー陽性電位（Pe）」と呼ばれ、自分が犯したミスに意識的に着目するときに現れる。

自分のミスに気づくERNの信号と、そのミスを意識的に着目するPeの信号、この2つの信号が強いほど、失敗から素早く学ぼうとする傾向があることが分かった。さらに、Peの信号が強い人ほど、「知性や才能は努力によって伸びる」と考える傾向があったという。

ミスから学ぼうとするマインドセットは、個人のみならず組織でも育成できる。

本書では、究極の失敗型アプローチとして「事前検死」が紹介されている。

人の死の原因や状況を明らかにする「検死」は、あたりまえなのだが、人が死んだ「後」に行われるものだ。だが、「事前」とはどういう意味だろうか？

これはpost-mortem（検死）をもじった造語で、pre-mortem（事前検死）になる。プロジェクトが終わった後に振り返るのではなく、実施前に検証するのだ。

まだ始まってもいないのに、「プロジェクトは大失敗でした。なぜですか？」という問いを立て、失敗していないうちから失敗を想定して学ぼうとする手法である。メンバーは、プロジェクトに対し否定的だと受け止められることを恐れず、懸念していることをオープンに話し合うことができる。

これはわたしも行っている。

ディスカッションで「もし上手くいかないことがあるとしたら、それはどんな理由？ヤバい順に考えてみよう」と問いかけて、反応を見るやり方だ。荒唐無稽なやつから割と現実的なものまで出てくる。

コツは、できるだけ極端でおかしな例を最初に挙げることだ。いきなり訊かれても、皆は簡単に答えられない（だいたい、そんな質問をしてくるPMはあんまりいない）。だから、最初に自分から、おかしな例えを示してあげる。

例えば、顧客が提示してきた要件定義の期間が短すぎると感じたなら、「ちょうどその期間に、担当全員が同時にインフルエンザになったらどうする？」と振ってみる。すると、要件定義のドラフト版を前倒しでもらっておこうとか、質問表だけ先行して作ってお客に渡してしまおうといったアイデアが出てくる。

そうしたアイデアの有効性はともかく、失敗を先に見えるようにしておこうという姿勢が重要なのだ。

人だから、ミスが起きるのは当然のこと。そのミスを再発させず、トラブルにまでつなげない仕組みが必要となる。ミスから学ぶためには、まずエラーを受け入れるオープンな姿勢が肝要となる。

この姿勢を受けた試みは、『なぜエラーが医療事故を減らすのか』で紹介されている。

著者はフランス人。医療安全の第一人者にして現役の臨床医でもある。原書のタイトルはもっとシンプルに、「エラー称賛」となっている。

どんなに研究が進み、医療技術が高度になったとしても、相手は人の身体だ。人が設計図を引いたエンジンや原子炉と異なり、人体は機械ではない。絶え間なく代謝し続ける複雑な生体だ。

そして医師は、7,200種類の医療行為、5,000種類の医薬品、50,000種類の医療機器および器具を扱う必要がある。生体組織検査やX線撮影を依頼し、患者を入院させ、看護師、理学療法士、歯科医師などの協力を求める。数百の疾患に対し、選択の組み合わせは無数にあるといっていい。

そして、人は誰しも間違える。

米国の無謬主義とは一線を画し、「人は間違いを犯す」という前提に立っている。重要なのは、そのヒューマンエラーを連鎖させず、重大な事故にさせないための仕組みなのだ。

ハインリッヒの法則によると、1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常（ヒヤリ・ハット）が存在するという。言い換えるなら、いきなり重大な事故が突如として起こるのではなく、そこに至るまでの様々なインシデントが連なっているのである。

そうしたインシデントの連鎖を止めるため、さまざまなマニュアルやチェックリストが整備されている。これらを充実させるためには、エラーが前提であることを受け入れ、ミスを報告し皆で学習する文化を広げることが肝要だという。「エラー称賛」というタイトルの意味はここにある。

本書では、ヒヤリ・ハットから事故への連鎖を止めるための、様々な事例が紹介されている。

例えば、成人向けと小児向けの薬剤を同じ棚に置かないというルール。同じ薬剤を異なる分量で処方してしまったエラーがあったからこそ、このルールができたと言える。

あるいは、会話のプロトコルをルール化し、「入力の”打つ”」と「注射の”打つ”」と分けて復唱させ、単に「打つ」だけで伝えないようにする。「この薬剤を打っておいて」と言われたら、「その薬剤データを入力しておくのですよね」と復唱させる。

過去に申告されたエラーを元に、有形無形のさまざまな関所を設けるのだ。

こうした関所のことを、並べたスイス・チーズで視覚的にモデル化する。一つ一つのチーズは穴だらけだが、並べることにより、エラーという矢の通り道を塞ぐ。幾つもの穴をすり抜け、刺さったチーズが「ヒヤリ・ハット」になる。

それぞれのチェックは完璧ではないが、エラーの原因は一つとは限らない。刺さった最後のチーズは確かに目立つかもしれないが、そこへ至る一連の流れを見なおし、各ステップでの不具合を見つけ出し、システム全体としての改善を図ることが必要になる。

スイス・チーズ・モデルに基づけば、不幸にして最後のチーズとなった医療者を責めるのは意味がない。事故の当事者は、たくさんあったはずの防御装置の欠陥を明るみに出した者にすぎないのだから。

ヒューマンエラーは原因ではなく、むしろ結果なのだ。

日本では、この考え方に基づき、日本医療機能評価機構がつくられている。医療現場における医療事故やヒヤリ・ハット事例を収集し、分析することにより、安全対策の推進を図ることを目的としている。

人の命を預かる医療現場だからこその試みだが、他の産業、特にITエンジニアリングにおいてはどうだろうか？

「試験サーバと本番サーバの取り違え」とか「IDEのオートコンプリートを過信していた」など沢山ありそうだが、典型的な失敗事例なら、『IT失敗学の研究』が参考になる。

ヒューマンエラーの範疇よりも、プロジェクトレベルでの失敗になる。30ものプロジェクトの破綻例を分析し、「どこが問題だったのか」「本来どうすべきだったのか」を深掘りする。

本書は、プロジェクト破綻を以下の3つの観点から分析している。

1. 　1. 無責任なユーザー経営者
2. 　2. 頼りなき情報システム部
3. 　3. 実力不足のベンダー

例えば、ユーザーのマネジメント層が無責任だったケースとしては、選挙のスローガンで「ITによる行政の効率化」を掲げたが、いざ当選したら、単に職員へのPC配布にとどまった話。税金でベンダーが肥え太っただけで、「効率化」のKPIを予め決めておかなかった失敗と言えるだろう。

あるいは、レガシー更改プロジェクトで、テストまでトントン拍子に行ったけど、準正常系ルートが丸ごと抜けていたケース。要件定義あるあるで「正常系しか考えていませんでした」というやつ。当然、開発現場では「聞いてないよ！」と叫ぶ（しかも随意契約なのでケツまくれない）阿鼻叫喚の事例だ。

破綻したプロジェクトの屍の上に築かれたノウハウも貴重だ。

お役所を相手にするときは、「隠し仕様」があることを忘れるなと釘を刺す。役所に限らないが、いわゆるドキュメント化されておらず、「口伝」や「メモ」で残されている仕様のこと。

要件定義や仕様検討が充分で、後出しで詰められた仕様は、きちんとドキュメント化されないまま、誰かの引き出しにしまわれる。時が経ち、システム更改するとき、見積もりの段階ではオープンにされないで、プロジェクトが佳境に入り、だいたいテストフェーズで（仕様が曖昧な理由で）トラブルになったとき、誰かが思い出す――というケースだ。

こうした準正常系のルートや隠し仕様は、見積もりの段階では全く見えない。だから、過去のシステムを「そのまま」更改してくれという要求には充分に警戒すべし。これら全部洗い出す時間は、もちろんないため、コストに上乗せしておく必要があるのだ（役所プレミアムと呼ぶ）。

ITエンジニアなら胃が痛くなるような事例を集めたものだが、他山の石としては充分すぎる価値がある一冊だろう。

あらゆる人は、大なり小なり、失敗する。

問題は失敗そのものよりも、それをどう生かすかに尽きる。「失敗から学ぼう」というフレーズはよく耳にするが、どうすれば失敗から学べるかを準備しておかないと、誰も報告しなくなる未来が待っている。

医療事故や航空トラブル、司法の現場など、豊富な事例を通じて、ミスが再発するメカニズムと、失敗から学ぶための方法を紹介しているのが『失敗の科学』だ。失敗を準備するための最初の一冊として推したい。

重大な事故に関係したミスについて、どこまで踏み込むべきか解き明かしたのが、『ヒューマンエラーは裁けるか』になる。刑事責任を優先し、ミスをした人を犯罪者扱いするマスコミや司法が、失敗から学べない風潮を招くと警告している。

一方で、そうしたミスこそが失敗から学ぶための糧となると主張しているのが、『なぜエラーが医療事故を減らすのか』になる。ここで紹介されるスイス・チーズの喩えは、ソフトウェア開発の現場でも活かしていける考え方だ。

上記の事例は欧米のものが中心のため、日本のIT現場での失敗を考えるなら、『IT失敗学の研究』になる。不条理なプロジェクトのあるある集として、転ばぬ先の杖的に使いたい。特定非営利活動法人「失敗学会」が運営している失敗知識データベースか、あるいは日経クロステックのトラブル事例が非常に参考になる。他にも良さげなものがあったら、ぜひ教えてほしい。