5 Why 分析 5 Whys Analysis

什麼時候該用它？

當你發現團隊一直在「修症狀」而不是「解決問題」的時候。同一個 bug 修了三次還是會出現？客訴量降了又升？5 Why 幫你挖到根因。

• 事故 Postmortem：服務掛了、資料遺失、上線出包之後
• 反覆出現的問題：同一類 bug、同一種客訴、同一個流程卡關
• 轉換率異常：數字突然掉了，需要快速找出原因
• 團隊回顧：Sprint Retrospective 中找到需要改善的根因
• 跨部門協作問題：溝通不良、交接遺漏的深層原因

框架結構

核心邏輯

從一個可觀察的問題出發，連續問「為什麼？」，每一次答案成為下一次提問的起點，直到找到可以被改變的根本原因。

範例：電商訂單出貨延遲

1. 為什麼訂單出貨延遲了？→ 因為倉庫沒有即時收到訂單資訊
2. 為什麼倉庫沒收到？→ 因為 ERP 系統的訂單同步延遲了 2 小時
3. 為什麼同步延遲？→ 因為 API 排程設定為每 2 小時跑一次
4. 為什麼設定 2 小時？→ 因為當初系統建置時訂單量很少，沒有改過
5. 為什麼沒有人改過？→ 因為沒有監控機制提醒同步頻率已經不符合現在的訂單量

根因：缺少訂單同步頻率的監控和自動調整機制。修 API 排程只是短期解法，建立監控才是長期解。

五次不是硬性規定

有時候 3 次就找到根因，有時候需要 7 次。「5」是經驗法則，提醒你不要在第一層就停下來。

來源與歷史

• 1930s：豐田佐吉在豐田自動織布機製造所發展出反覆追問的品質管理方法
• 1950s：兒子豐田喜一郎將方法系統化，融入豐田生產系統（TPS）
• 1970s：大野耐一在《豐田生產方式》中正式介紹 5 Why 方法
• 2000s：精益創業運動將 5 Why 從製造業帶入軟體業，Eric Ries 在《精益創業》中大力推薦
• 至今：幾乎所有科技公司的 Postmortem 模板都包含 5 Why 分析

真實案例：Jefferson Memorial 的牆面腐蝕

美國國家公園管理局發現 Jefferson Memorial 的牆面腐蝕速度異常快：

1. 為什麼牆面腐蝕？→ 因為清潔劑太強
2. 為什麼用這麼強的清潔劑？→ 因為鳥糞太多
3. 為什麼鳥糞多？→ 因為蜘蛛多（鳥來吃蜘蛛）
4. 為什麼蜘蛛多？→ 因為飛蛾多（蜘蛛來吃飛蛾）
5. 為什麼飛蛾多？→ 因為傍晚開燈太早，吸引飛蛾

解法：把開燈時間延後 1 小時。飛蛾減少 → 蜘蛛減少 → 鳥減少 → 不需要強力清潔劑 → 牆面腐蝕問題解決。

如果停在第一層，他們會一直換清潔劑品牌。

使用步驟

Step 1：明確定義問題

用一句客觀的描述寫下問題。「轉換率很差」不夠具體，「結帳頁的轉換率從上週的 3.2% 降到 2.1%」才行。

Step 2：召集相關人員

找到跟問題相關的人一起做 5 Why。一個人做容易陷入自己的假設。

Step 3：逐層追問

每一層的答案必須是事實，不是猜測。如果答不出來，就去查數據或 log。「我覺得可能是因為…」不是有效的答案。

Step 4：驗證根因

找到根因後，問自己：「如果解決這個根因，原始問題還會發生嗎？」如果答案是「還是會」，代表你找的不是真正的根因。

Step 5：制定行動方案

針對根因（不是症狀）制定改善措施，並設定追蹤指標。一週後回來看問題是否真的解決了。

這樣做 vs 避免這些

這樣做

• 每一層都要有事實佐證 — 不要用猜測取代查證
• 寫下來 — 口頭問答容易跳層或遺漏
• 允許多條因果鏈 — 一個問題可能有多個根因，畫成魚骨圖（石川圖）更清楚
• 聚焦在「系統」而非「人」— 根因應該是流程或機制的問題，不是「小明犯錯了」

避免這些

• 不要在第一層就停下來 — 「因為 API 壞了」不是根因
• 不要變成「獵巫大會」— 5 Why 是找系統問題，不是找人開除
• 不要問「為什麼我們不夠好」這種無法回答的問題
• 不要跳過驗證 — 找到根因後一定要確認「修了這個，問題真的會消失嗎」