5 Whys：每一個「為什麼」都往下挖一層

大野耐一在 1950 年代為豐田生產系統設計了一個簡單到近乎粗暴的工具：遇到問題，連問五個「為什麼」。

不是因為五是神奇數字，而是因為大多數人在第二個「為什麼」就停下來了——停在症狀，而不是原因。

一個真實的例子

問題：網站今天崩潰了。

• 為什麼崩潰？ 因為伺服器過載。
• 為什麼過載？ 因為有一個程式跑了不該跑的迴圈。
• 為什麼有這個迴圈？ 因為程式碼部署時沒有跑測試。
• 為什麼沒跑測試？ 因為 CI/CD 流程沒有強制要求。
• 為什麼沒有強制要求？ 因為當初上線趕時間，這個步驟被跳過了。

如果只問一個「為什麼」，你的解法是「擴充伺服器容量」。如果問到第五個，你的解法是「重新設計部署流程，強制測試」。第一個治標，第五個治本。

為什麼停在第一個「為什麼」是陷阱

大多數問題的直接原因很顯眼，也很容易解決。這讓人傾向於把「症狀消失」當作「問題解決」——但如果根本原因沒有改變，問題只是換個面孔再出現。

大野耐一把這稱為「表面修復」的陷阱：你解決了問題的倒數第一層，卻讓組織習慣了在症狀層作業，而不是在系統層思考。

什麼時候用 5 Whys

5 Whys 最適合用在已經發生的問題——事後分析（post-mortem）或回顧（retrospective）——而不是預測性決策。

• 生產事故、客訴、重工 → 適合
• 客戶流失率上升 → 適合
• 「為什麼我們長期做不到 X」的反省 → 適合
• 規劃一個全新的產品 → 不適合（這時候用 Pre-mortem）

五個「為什麼」只是建議，不是規定

有些問題在第三個「為什麼」就到根本，有些問題需要七個。重要的不是數字，而是**「問到你問不下去，或問到你能採取行動的那一層」**。

當你的回答從「因為某人做了某件事」變成「因為我們的系統沒有設計成…」，通常代表你到了值得介入的層級。

一個常見的 5 Whys 失敗模式

指向人的失敗：如果你的第五個「為什麼」的答案是「因為某個人不夠盡責」，你很可能問錯了方向。5 Whys 的目的是找到系統性原因，而不是把問題歸咎給個人。當答案開始指向「某人的錯誤」，試著追問：這個人為什麼做出這個選擇？是訓練不足、資訊不夠、流程不清楚？

完整的 5 Whys 引導問題在 Apexhone 的框架介紹頁裡。