“５ Whys(5つのなぜ)”というテクニックは，根本的な原因を解析するための一般的なテクニックであり，アジャイルのレトロスペクティブでも多く使われている。このテクニックはアジャイルチームに適しているのだろうか？あるいは，もっと適切なテクニックが他にあるのだろうか？
Etsyの技術運用担当副社長であるJohn Allspaw氏は，自身のブログ記事 “The Infinite Hows”の中で，5 Whysは捨てるべきだ，と主張している。5 Whysは，根本原因を解析するための第一歩としてならばよいが，原因の過剰な質問は不評を買う結果になる，と氏は指摘する。
(すべてのレトロスペクティブ，あるいはポストホックな調査が目標とすべき)学習をするためには，複数の，さまざまな視点が必要です。それには多くの人たちから，それぞれ言い分を聞く必要があります。つまり，“how?”を聞くのです。
“why?”と安易に問えば，“who?”(ほとんどの場合，これは無関係です)という質問に対する答が返ってくるか，あるいは“人々が職場で持つ‘神秘的な’インセンティブないしモチベーション”について聞くことになります。
“how?“を問うことで，その事象が起きるに至った条件の(すくなくとも一部の)説明を受けて，意味のある運用情報が入手できるのです。
ARMS Reliabilityのブログにあるように，5 Whysメソッドへの批判は，次のようなことを根拠にしている。
- より深い根本原因に踏み込まず，現象のレベルに留まる傾向がある。
- 調査者の現在の知識を越えることができない，つまり，既知のもの以外の原因を発見できない。
- 正しい"why"を問うことへの支援が欠如している。
- 結論に再現性がない。同じ問題に対して違う人が5 Whysを実施すれば，到達する原因も異なる。
- 各質問には複数の根本原因が存在し得るにも関わらず，ただひとつの根本原因を特定する傾向がある。
- 非線形であることの多い事象に対して，線形のコミュニケーション方法を想定している。
氏はニューヨークのVelocity Conferenceで，自身のチュートリアルから一例を公開している。
- 新規リリースによって，ユーザのある機能が無効になった。なぜ？ サーバの１台がフェールしたから。
- なぜサーバがフェールしたのか？ よく分からないサブシステムが，間違った方法で使われたから。
- なぜ間違った方法で使われたのか？ エンジニアが正しい使い方を知らなかったようだ。
- なぜ知らなかったのか？ トレーニングを受けていなかったから。
- なぜトレーニングを受けなかったのか？ マネージャも彼のチームも“忙し過ぎる”ため，マネージャが新人エンジニアのトレーニングを当てにしていなかったから。
この因果連鎖は事実として，個人の属性を結論にしています。このような事象が発生することになった複数の条件については，説明できていません。
“how”を問う時，我々は物語やストーリを求めているのだ，と氏は言う。このストーリの中で，人々の行動の様子を理解することができる。以下に示すのは，“Behind Human Error”という書籍からの引用で，ヒューマンエラーの“ファースト”および“セカンド”ストーリの違いについて説明したものだ。
|
ファーストストーリ |
セカンドストーリ |
|
ヒューマンエラーが失敗の原因と見なされる |
ヒューマンエラーは組織のより深い部分にある，システム的な脆弱性の影響によるものと解釈される |
|
失敗を説明するには，何を行うべきだったかを語れば満足できる |
何を行うべきだったかを語るだけでは，その行動に至った理由を説明することはできない |
|
もっと注意するように指示すれば，問題は解決する |
絶えず脆弱性を探す事によって，初めて，組織の安全性を高めることができる |
前述した5 Whysの例での質問が作り出すのは，ファーストストーリの方法で得られるような回答だ，と氏は言う。もっと適切な，“how”のような質問をすることによって，我々はセカンドストーリに到達するチャンスを獲得できるのだ。
なぜ“5 Whysのアプローチ”は次善の策に過ぎないのか，なぜ“5 How”がそれに代わるものなのか。それを説明するために氏は，一組のチュートリアルを提供している。４つのパートで構成され，それぞれが45分の長さだ。
Part I – ポストホックなレトロスペクティブの罠と学習に関する導入および科学的基礎
Part II – 用語定義: 報告，因果関係，ケーススタディ，複雑性に取り組むチーム