おいて根本原因を洗い出す基本テクニックであり、いまだ重要な役割がある。Whysの誤解と真実。whysは責任追及の文化を生む問題の特定は、その問題に関与した人を責めることとは違う。whysの基本ルールの1つは、根本的な原因を人に求めないことだ。何がヒューマンエラーを引き起こしたのか?失敗の原因は何か?どのようなプロセス、変更可能な行動、文化的な要因があるのか?に着目する。このとき後知恵を捨てるのも重要だ。Errorより)失敗という結果と、悪いプロセスはセットではない。人々がすべきだったこと、やるべきでなかったこと、という仮定の話に深入りしない。行動の是非でなく、その行動の理由を当事者になったつもりで理解する。)時間的、空間的に事故にもっとも近いところにいた人、あるいは事故を防げる可能性のあった人だけにフォーカスするのをやめる。Whysという名前だからといって、文字通り5回なぜを繰り返せということではない。根本原因が1つだけってのは滅多に無い別に1つだけにしろ、という話はどこにもない。因果関係の連鎖が、複数の要因からなるツリー状になっていても大丈夫。Whysは技術的な原因と結果を特定するだけではない。あなたのチームがそれらの要因を無視していない限り、プロセス、文化、大局的な事業状況を原因に求めれば良い。Whysをやっても十分な根本原因に行き当たることができないかもしれない。Whysはチームワークであり、インシデントに関わった全員が、その事後処理に関わるべきだ。https://leaddev.com/reporting-metrics/how-run-great-software-incident-post-mortemヒューマンエラーは出発点で、そこから掘り下げる。人間ではなく、システムを指し示す答えを探す。その結果、1段目のWhyは「ディスクが一杯で書き込みできなかった」という事実に到達する。問題はここからで、次のWhyとして以下のようなものを考えがちだが...管理者が過去のビルド結果をパージしていなかったディスクの状態をモニタリングしていなかったこれは「しなかった」ことであり、実際に起きたことではない。実際には発生しなかったことは無限に考えられるので、いくらでもWhyを紡いでいけて「地球が居住可能じゃなければ、だれもビルド失敗を気にする人はいないだろう」などに行き着くことも可能だ。「しなかった」ことは、人の過失と捉えることができてしまうので、責任追及に話が行きがちで「非難の嵐」をうむことになる。Whysの掘り下げに使うのではなく、辿り着いた根本原因からアクションアイテムを構築するときには有用なものとして使える。Whysの途中で誰かが「しなかったこと」を言ったら、棄却するけれどもそれをどこかに記録しておいて、その後アクションアイテムを考えるときに使おう。