「なぜなぜ分析」は人に責任を帰さないのが大原則
この記事自体に文句があるわけではないのだが，
なぜなぜ分析とは、「なぜそれが起きたのか？」「その原因の原因は？」と、原因を幾重にも掘り下げる手法のこと。5段階も遡及すると、たいてい「私の不注意でした」となり、対策は「意識を入れ替える」という小学校の学級目標になる。反面、もっと深刻な「仕様変更が電話口で伝えられていた」とか「アジャイルの名のもとにテストが省略されていた」などは放置される（なぜなら、「人」を原因にしたいから）。
こんな冗談みたいな施策を続けていくと、スケープゴートになった人はどんどん心をすり減らし、不具合の初期症状は「知りません」の壁に囲われ、詳しい人から順番にプロジェクトからいなくなる。かくしてバグは報告されなくなる、システムが崩壊するまで。
『なぜエラーが医療事故を減らすのか』はスゴ本より
の部分は（書かれた方も分かった上でわざと書いてるのかもしれないが）いただけないので補足しておく。
人に責任を帰さないこと
「なぜなぜ分析」はもともとトヨタの未然防止手法「GD3（ジー・ディ・キューブ）」の中で使われる分析手法である。 トラブルが起きた際にその「真因」を探るためにトラブルの要因を「何故」をキーワードに深堀りしていく手法である。 だいたい5段階くらいまで下っていくと「真因」が見えてくると言われている。
この際に絶対にやってはいけないことがある。 それは「責任を人を帰す」こと。 つまり「なぜなぜ分析」の際に「私の不注意でした」となるのはやり方が間違っているか掘り方が足りないかのどちらかである。 リンク元の記事にも書かれているが，人は間違いを犯す生き物である。 だれだって間違えたくて間違うわけじゃない。 「間違うこと」をトラブルの原因にしても意味がない。 今回間違えたらなら次回も間違うに決まってるし，間違いを犯した人を裁いても別の人が間違うに決まってるからだ。 トラブルの「責任を人を帰す」ことは何もしないのと同じで，今後トラブルが起きるかどうかは完全に運任せということでもある。
もしトラブルの原因が「私の不注意」なら不注意を誘発する要因が必ずあるはずである。 それは不適切なルール設定かもしれないし，日頃の業務フローの中に見落としがあるのかもしれない。
たとえば，先日の日本年金機構の情報漏えい事故だが，要因としては以下の2点が挙げられるだろう（他にもあるかも知れないが私は当事者ではないので分からない）。
- 業務フローがルールを迂回する形で構築されている
- 「まぁ大丈夫だろう」という，いわゆる正常性バイアス
前者は不適切なルール設定の問題（守られないルールはルール自体に問題がある）。後者は業務フローを見なおすことで改善が可能である（たとえば定期的に「避難訓練」を行うことは有効である。実際に大きな企業ではやっている）。 こういった「真因」を紐解いていくのが「未然防止」の真髄である。
よくテレビとかで企業や官僚が「再発防止に努めます」とか言っているが，全然甘いと言わざるをえない。 「再発防止」という言葉には「真因」を突き止めることもなく場当たり的に対処して済ませようとする魂胆が丸見えである。 そんなことを言う企業や組織を信用してはいけない。
ピンチはチャンス
「トラブルは絶好のビジネスチャンス」と言っていたのは，私が会社勤めをしていた時のボスである。 トラブルはだれだって嫌なものだが，それをチャンスに変える図太さがないと今の世の中はやっていけない。 「カイゼン」はコストではなく投資なのだ。 「未然防止」はピンチをチャンスに変えるよい道具である。
「なぜなぜ分析」には批判も多いが，かんなはのこぎりの代わりにはならない。 道具は適切な場面とタイミングで使うものである。 また「なぜなぜ分析」は「未然防止」の手法のひとつにすぎないことをお忘れなく。 「なぜなぜ分析」を批判するなら，せめて GD3 の本を熟読してからにしろ，と言いたい。
（ちなみに私が「なぜなぜ分析」を含む未然防止手法を知ったのは車載制御の開発を行う某外資系企業に通ってた時。 GD3 の本を勧められ熟読するように言われた（それ以外では MISRA-C の解説本が必読書だった）。 実際，この時の経験は後の私の開発スタイルに大きく影響を与えている。 「カンバン方式」や「リーン開発」などトヨタが起源と言われている手法は色々あるが，ある日突然出てきたものではなく，不断の（未然防止の）取り組みの成果だと言っておこう）
