ソフトウェア開発で「なぜなぜ分析」はアンチパターン

ソフトウェア開発に「なぜなぜ分析」を適用すべきではない理由

• ソフトウェアは（平均的には）複雑系
• 複雑系は、複雑な方法で故障する
• インシデント／問題に対する単一の因果関係を持つ単一の根本原因は、そもそも存在しない
• なぜなぜ分析は単一な根本原因に焦点を当てるために過度な、もしくは誤った抽象化を行いやすい

大まかに整理すると、ソフトウェア開発に「なぜなぜ分析」を適用すべきではない理由は上記のようなものになる。適用すべきではない、というのはかなり上品な言い方で、もっと言えば有害である。特に、なぜなぜ分析はその特性上、人的ミスに帰結しやすいという点も問題だ。

なぜ「なぜなぜ分析」はなくならないのか

• 会社のルールだから
  • 正確には、古い会社のルールを見直さず放置しているから
• 偉い人が言うから
  • 正確には、偉い人が学習を怠り、過去の自分の成功体験を繰り返しているから
• 他の方法を勉強していないから
• なぜなぜ分析の結果は、対外的に説明しやすいから

「なぜなぜ分析」はなくならない理由はこんなものだろう。なお「対外的に説明しやすい」点についてはある程度は理解できる。なぜなぜ分析が示すシンプルな因果関係、ストーリーはわかりやすいことは確かである。しかし、結果として選択したシンプルな因果関係、ストーリーはすぐに破綻する。また別の理由で次のインシデントが発生するからである。再発防止策がさらに増える。チェックリストが拡充される。そして無駄な作業ばかりが増え、生産性は落ちていく。

「なぜなぜ分析」がダメな例

先日読んだ「SREをはじめよう ―個人と組織による信頼性獲得への第一歩」にはこんな例が掲載されている。

• システムがダウンした
• （なぜ？）サーバーが停止したから
• （なぜ？）ディスクがいっぱいになったから
• （なぜ？）ログが肥大したから
• （なぜ？）ログローテしてなかったから
• （なぜ？）設定ファイルが漏れていたから →これが根本原因！
• すべての設定ファイルにログローテーションの設定があることを確認！

ツッコミどころが満載である*1。まあ作為的な例ではあるが。

観察した1つの事柄を深く掘り下げようとするのは構いませんが、その状況における他の要因を無視することを犠牲にしてはいけません。 ときには、なぜを繰り返す前に、何（つまり、何が起こったのか）の質問にすべて答えたことを確認する必要があります。

「なぜなぜ分析」は、単一の根本原因に焦点を当てることが、失敗から学ぶ上でいかに不利になるかを示す、特に明らかな例です。 この用語を使うと、明確な因果の連鎖を1つ特定できたと思った時点で、インシデントを深く観察することを（潜在的にでも）やめてしまうことになりますが、これはアンチパターンです。

---

SREをはじめよう ―個人と組織による信頼性獲得への第一歩 10章 失敗から学習する、より

「根本原因」という正解はそもそも存在しない

言うまでもなく、インシデントの原因は無数にある。もちろん、そういった複合要因をちゃんと分析すればいいのだが「根本原因」という用語はすべての背後に１つの真の原因があるように見えてしまう点で、ダメだと考えている。

そういえば過去にこんなことも調べていた
agnozingdays.hatenablog.com

自戒を込めて、特に（自分を含む）少し前の教育を受けていた世代は、優等生主義というか正解主義のきらいがある。注意したい。畑村先生がいいことを言っていた。

現代は、いままでの思考法ーー問題を分析し、その問題の正解を外から持ってくるという思考法ーーだけでは、多くの場面で通用しないことは、前章で述べてきた通りです。
前章でも触れましたが、私は今の時代を「正解がない時代」というより、唯一解のない「正解がいくつもある時代」と捉えています。

---

新　失敗学　正解をつくる技術、第２章　すべては仮説から始まる より

というわけで、言いたいことはこんなことです