語言: 繁體中文
免費試用 14 天

官方技能 · 商業思想家的原則

大野耐一式 5 個為什麼根本原因分析

v1.0.1 · 更新

用大野耐一舉例說明的 5 個為什麼找出問題的根本原因：可衡量的落差、每一步都有證據的為什麼鏈，以及針對原因而不是症狀的對策。

Not affiliated with or endorsed by Taiichi Ohno or their companies. About these principles: Taiichi Ohno's ideas, explained.

加入我團隊的 Pod 下載 SKILL.md

可在 Claude、ChatGPT 和程式設計代理中使用。使用 Team 和 Business 方案時，我們改進官方技能後，你 Pod 裡的這個技能會自動更新。

適用情境

你要提供的內容

你會得到的內容

一張每步附證據的為什麼鏈表格、倒讀檢查、根本原因、附負責人的應急處置和根本對策，以及怎麼確認有效。

運作方式

  1. 把問題寫成落差 「出貨延遲：上週 140 筆訂單中有 12 筆，標準是 15:00 前下單當天出貨。」具體、有數字，並寫出標準（原則 4）。
  2. 問第一個為什麼 落差為什麼會發生？寫出直接、看得到的原因，並附上證據。
  3. 繼續追問（原則 1） 拿每個答案再問它為什麼會發生。每一步一列，各附證據。如果一個答案有兩個原因，就分岔，兩條都追下去。
  4. 檢查每一環 用「所以」把鏈條倒過來讀一遍：「沒有濾網，所以金屬屑跑進去，所以泵軸磨損……」。哪個「所以」說不通，鏈條就在那一步出錯。
  5. 在根本原因停下（原則 2） 下一個為什麼已經超出你能控制的範圍（天氣、法律）時停下；或是找到的原因是你能消除、而且消除後故障就不會再發生時停下。可能問三次就到了，也可能要問七次。
  6. 訂出對策（原則 3） 一項針對根本原因（裝濾網）；需要的話，再加一項眼前的應急處置（換保險絲）。分別標明；只有應急處置不算解決。
  7. 寫明負責人、日期和驗證方式 兩週後要怎麼知道問題沒有再發生？

SKILL.md 檔案

完整檔案，就是你的 AI 讀到的內容。 下載檔案

---
name: ohno-style-five-whys
description: 依照大野耐一為豐田生產方式舉例說明的做法，對一個問題做 5 個為什麼（5 Whys）根本原因分析：把問題寫成和標準之間的落差，對每個答案再問為什麼，直到找到能消除的原因（五次只是參考，不是規定），用事實檢查每一環，並針對根本原因、而不是表面症狀採取對策。適用於事故、瑕疵、延遲、客訴或反覆發生的故障需要找出根本原因，團隊一直在替同一個症狀補破洞，或有人要做 5 Why、根本原因分析（RCA）、想知道「為什麼老是發生這種事」的時候。
---

# 大野耐一式 5 個為什麼根本原因分析

以下是大野耐一在他談豐田生產方式的著作中公開說明過的原則，依據精實企業研究院（Lean Enterprise Institute）用語辭典的整理，以及豐田對他所扮演角色的介紹。本技能與大野耐一及其公司沒有任何關聯，也未獲其認可或背書。這個技能處理一個問題：沿著為什麼的鏈條一步步追問，每一步都附上證據，最後提出針對根本原因的對策。

## 基本規則

- 不要把所列來源以外的引言或觀點歸給大野耐一。
- 不要扮演、模仿大野耐一，也不要用他的口吻寫作；只用下面的原則檢視使用者的資料。
- 鏈條裡每個答案都要有事實佐證（日誌、紀錄、觀察、親眼看到的人）。沒有的就標成「[待確認：……]」，鏈條停在這裡，確認後再往下。
- 追問的是流程，不是人。「因為小陳忘了」絕不是根本原因；要問流程為什麼讓人有機會忘記。
- 不編造這次事件的任何事實。

## 原則

1. **反覆問為什麼。** 問題一出現，就一再問為什麼，越過表面症狀，追到根本原因。來源：精實企業研究院用語辭典，"5 Whys"。
2. **五這個數字不是重點。** 一直問到找出並消除根本原因為止。來源：同一詞條。
3. **消除原因，而不是症狀。** 大野耐一自己舉的例子是一台停下來的機器：過載燒斷了保險絲，因為軸承沒有潤滑，因為油泵打油不夠，因為泵軸磨損了，因為沒有濾網擋住金屬屑。只換保險絲或只換油泵，故障還是會再發生。來源：同一詞條，引用大野耐一 1988 年著作第 17 頁。
4. **從和標準之間的落差出發。** 辭典把這個方法放在解決問題的流程裡：具體定義問題、設定目標、分析根本原因、訂出對策。來源：同一詞條。
5. **背景。** 豐田認為大野耐一協助建立了豐田生產方式，這套方式的目的是徹底消除浪費、縮短前置時間。來源：豐田，"Toyota Production System"。

## 適用情境

- 事故、系統中斷、瑕疵或延遲交貨需要找出根本原因。
- 同一個問題「修好」之後又回來了。
- 客訴指向的是流程，不是一次性的意外。
- 不適用於團隊對整個專案的回顧（用 retrospective），也不適用於把客服工單整理成 bug 回報（用 bug-report-from-ticket）。

## 需要準備

- 問題：發生了什麼、在哪裡、什麼時候、多常發生，以及原本應該怎樣（標準）。
- 手上的事實：日誌、時間軸、紀錄、誰看到了什麼。
- 已經試過的做法。
- 誰能確認你還沒有的事實。

## 步驟

1. **把問題寫成落差。** 「出貨延遲：上週 140 筆訂單中有 12 筆，標準是 15:00 前下單當天出貨。」具體、有數字，並寫出標準（原則 4）。
2. **問第一個為什麼。** 落差為什麼會發生？寫出直接、看得到的原因，並附上證據。
3. **繼續追問（原則 1）。** 拿每個答案再問它為什麼會發生。每一步一列，各附證據。如果一個答案有兩個原因，就分岔，兩條都追下去。
4. **檢查每一環。** 用「所以」把鏈條倒過來讀一遍：「沒有濾網，所以金屬屑跑進去，所以泵軸磨損……」。哪個「所以」說不通，鏈條就在那一步出錯。
5. **在根本原因停下（原則 2）。** 下一個為什麼已經超出你能控制的範圍（天氣、法律）時停下；或是找到的原因是你能消除、而且消除後故障就不會再發生時停下。可能問三次就到了，也可能要問七次。
6. **訂出對策（原則 3）。** 一項針對根本原因（裝濾網）；需要的話，再加一項眼前的應急處置（換保險絲）。分別標明；只有應急處置不算解決。
7. **寫明負責人、日期和驗證方式。** 兩週後要怎麼知道問題沒有再發生？

## 輸出格式

```markdown
# 5 個為什麼：[一句話說明問題]
以下是大野耐一公開說明過的原則。本文件與大野耐一及其公司沒有任何關聯，也未獲其認可或背書。

## 問題
**發生了什麼：** [有數字的描述] · **標準：** [原本應該怎樣] · **開始於：** [日期]

## 鏈條
| # | 為什麼？ | 因為 | 證據 |
|---|---|---|---|
| 1 | | | |
| 2 | | | |
| 3 | | | |

## 倒讀檢查
[根本原因]，所以 [……]，所以 [問題]。是否成立：是／在第 [n] 步不成立。

## 根本原因
[一句話，關於流程]

## 對策
| 類型 | 行動 | 負責人 | 日期 |
|---|---|---|---|
| 應急處置（現在） | | | |
| 根本原因 | | | |

## 怎麼知道有效
[指標和日期]

## 使用的原則
[編號，附來源]
```

## 範例

**輸入：**「網路商店。上週 140 筆訂單裡有 12 筆晚一天出貨。我們承諾 15:00 前下單當天出貨。包貨的同事說，有好幾個下午出貨單印表機卡紙。出貨單是在 14:30 一次整批列印。印表機上次保養是 18 個月前；說明書寫每 6 個月一次。印表機沒有人負責。」

**輸出（節錄）：**

```markdown
以下是大野耐一公開說明過的原則。本文件與大野耐一及其公司沒有任何關聯，也未獲其認可或背書。

## 鏈條
| # | 為什麼？ | 因為 | 證據 |
|---|---|---|---|
| 1 | 為什麼 12 筆訂單晚出貨？ | 出貨單沒能及時印出來 | 包貨同事的說法 |
| 2 | 為什麼出貨單沒能及時印出來？ | 14:30 那一批列印時印表機卡紙 | 包貨同事的說法 [待確認：印表機錯誤紀錄] |
| 3 | 為什麼會卡紙？ | 已經超過保養週期 12 個月 | 保養紀錄；說明書寫每 6 個月一次 |
| 4 | 為什麼沒做保養？ | 印表機沒有人負責，所以沒人去安排保養 | 輸入：「印表機沒有人負責」 |

## 根本原因
出貨單印表機沒有負責人，所以保養從來沒排進行程；而只在 14:30 印一批，讓任何一次卡紙都會變成訂單延遲。

## 對策
| 類型 | 行動 | 負責人 | 日期 |
|---|---|---|---|
| 應急處置（現在） | 本週安排印表機保養 | [姓名] | [日期] |
| 根本原因 | 指定印表機負責人，並在行事曆排好每 6 個月一次的保養 | [姓名] | [日期] |
| 根本原因 | 出貨單分兩批列印：12:00 和 14:30 | [姓名] | [日期] |
```

## 寄出前檢查

- [ ] 輸出裡有出處說明和無關聯聲明。
- [ ] 問題寫成了和標準之間、有數字的落差。
- [ ] 每一步都有證據，或標成 [待確認]。
- [ ] 用「所以」倒讀鏈條時沒有斷掉。
- [ ] 根本原因關於流程，而不是某個人。
- [ ] 有針對根本原因的對策，不只是應急處置，並寫明負責人和日期。

## 常見錯誤

- 停在第一個看似合理的答案（「印表機卡紙了」）。
- 硬湊剛好五步。
- 以某個人的失誤收尾。
- 鏈條全憑意見寫成，沒有任何一步有證據。

分享給你的團隊

把它加入 AI Skill Pod，團隊每個人（外包人員也包括在內）都能從自己的 AI 使用同一個版本。 看看和團隊分享 AI 技能的最佳做法

加入我團隊的 Pod

更新紀錄

參考來源

  1. 5 Whys - Lean Enterprise Institute lexicon (2026-11-04 查閱)
  2. Toyota Production System - Toyota Motor Corporation (2026-11-04 查閱)