5个为什么

TL;DR

5个为什么：连续问"为什么会发生这种情况？"五次，从症状深入到根本原因。第一个答案通常是症状；第五个通常是你能实际修复的可操作原因。用于制造、软件事后分析和管理回顾，以防止复发而非仅仅对症状做出反应。

什么是5个为什么？

5个为什么由丰田工业创始人丰田佐吉开发，在1970年代成为丰田生产系统（TPS）的基石。TPS的架构师大野耐一将其描述为丰田科学方法的基础："通过重复五次为什么，问题的本质及其解决方案变得清晰。"

该技术看似简单：当问题发生时，问"为什么？"并记录答案。然后对那个答案再问"为什么？"。重复直到找到一个可以实际修复的原因——通常在第五次迭代左右。目标不一定是正好五个问题（有时三个就够，有时需要七个），而是持续追问直到达到可操作的根本原因，而非停留在症状性答案上。

该方法的力量在于抵抗显而易见之事的拉力。我们的认知系统天生会对近因采取行动——问题的直接触发因素。机器停止工作；我们重启它。客户投诉；我们道歉。截止日期错过；我们增加更多时间。这些反应解决症状。5个为什么强迫越过症状，到达如果解决就能防止问题复发的结构性或系统性原因。

工作原理

步骤1：精确定义问题
  ——写一个清晰、具体的问题陈述
  ——"生产线停止了"而非"出了问题"
步骤2：问"为什么会发生这种情况？"
  ——记录第一个因果答案
  ——保持事实性，而非解释性
步骤3：对前一个答案再问"为什么？"
  ——深入原因，而非症状
步骤4：重复直到达到根本原因
  ——根本原因：可解决的系统性故障
  ——你已深入到足够程度的迹象：答案是流程/系统故障
步骤5：验证因果链
  ——向上阅读："因为X→导致Y→导致Z→"
  ——因果链应该逻辑清晰
步骤6：在根本原因层面设计对策
  ——不要只修复症状；解决根本原因

三个现实案例

丰田生产线停止：经典丰田案例：生产机器人意外停止。为什么机器停止了？——超负荷；保险丝烧断了。为什么超负荷？——轴承润滑不足。为什么润滑不足？——润滑泵没有正常循环油。为什么泵没有正常工作？——泵入口被金属屑堵塞了。为什么入口被堵塞？——没有安装过滤器；维护程序中没有指定。修复不是"更换保险丝"。而是"安装过滤器并更新维护程序"。更换保险丝解决症状；对策解决根本原因。没有5个为什么，同样的故障会在几周内再次发生。

软件部署失败：关键API服务在凌晨2点宕机。为什么服务宕机了？——主服务器内存不足错误。为什么内存不足？——当天发布的新功能有内存泄漏。为什么内存泄漏到达生产环境？——代码审查或测试中没有发现。为什么测试中没有发现？——预发布环境不模拟持续的生产负载。为什么预发布环境不模拟生产负载？——我们从未定义部署前进行负载测试的政策。修复：为所有内存密集型功能在生产部署前实施负载测试政策。不是：责怪工程师。

创业公司错过销售目标：B2B SaaS公司Q3收入目标错过40%。为什么错过了收入目标？——管道转化率从22%降到11%。为什么转化率下降？——竞争对手在7月推出了更便宜的替代品。为什么我们输给更便宜的替代品？——我们在销售电话中无法清晰表达差异化。为什么销售无法表达差异化？——我们没有竞争战斗卡；销售代表在即兴发挥。为什么没有战斗卡？——产品营销被分配到一个重要会议，而不是竞争情报。修复：创建竞争战斗卡流程和资源分配政策。不是：解雇销售团队。

何时使用

✅ 5个为什么很适合

• 运营故障事后分析（停机、缺陷、交付失败）

• 重复出现的问题——"为什么这种情况一直发生？"

• 敏捷开发中的团队回顾

• 任何"修复显而易见的事情"没有效果的问题

❌ 需要谨慎的情况

• 问题有多个原因（使用鱼骨图代替）

• 需要在诊断前恢复服务（先修复，后分析）

• 原因确实是随机的或外部的

鱼骨图根因分析事前验尸科学方法

常见误用和局限

停在第一个"足够好"的答案。最常见的失败：识别出一个合理的原因就停止。"服务器内存不足"是原因；它不是根本原因。越过舒适区，到达系统性故障。

把人当作根本原因。"因为约翰没有检查服务器日志"不是根本原因。约翰是系统中的一个节点——问系统为什么没有支持约翰。是缺少政策？没有警报？他超负荷了？人通常是近因；系统通常是根本原因。

为多原因问题创建单一因果链。5个为什么产生线性因果链；许多问题有分支原因。如果多个第二层原因看起来同样相关，使用鱼骨图代替。

因果链中的确认偏差。两个不同的分析师可以为同一个问题构建非常不同的因果链。因果链反映了带入调查的假设。通过反向阅读因果链并检查每个因果链接来验证。

相关模型

根因分析鱼骨图问题树黑匣子思维

常见问题

是否必须正好是五个"为什么"？
不是。"5"是启发式，不是规则。有些问题三个就解决了；复杂的可能需要七个。停止标准是达到一个原因，该原因：(a)可以通过特定对策解决，(b)如果解决，将防止问题再次发生。当你达到那个层面时，就停止——无论三个还是八个。

近因和根本原因有什么区别？
近因是直接触发因素："服务器崩溃是因为内存溢出"。根本原因是深层可解决的系统性原因："服务器崩溃是因为我们没有负载测试政策"。近因描述发生了什么；根本原因解释系统为什么允许它发生。根本原因通常是流程、政策或设计故障——可以改变以防止再次发生的事情。

如何防止5个为什么变成指责游戏？
将调查框架为系统审计，而非绩效评估。使用"我们的流程中什么允许X发生？"而非"为什么人Y做了X？"当人出现在因果链中时，问系统应该提供什么来防止一个合理的人犯那个错误。丰田的做法是在个人失败之前假设系统失败。

延伸阅读

• Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production — 原始来源

• Liker, J.K. (2004). The Toyota Way — TPS的全面介绍，包括5个为什么

• Dekker, S. (2006). The Field Guide to Understanding 'Human Error' — 故障分析的系统思维方法

用AI应用

🚀 用话老师对你的问题运行5个为什么分析 →

本页面是话老师思维模型知识库的一部分。