在追究根本原因场景下，5Why分析法是一个很好用的工具。这种方法最初是由丰田佐吉提出，后面在丰田之外都广泛使用。
虽为5个为什么，但使用时不限定只做“5次为什么”的探讨，而是必须直到找到根本原因为止，有时可能只要3次，有时也许要10次，如古话所言：打破砂锅问到底。
5why法的关键所在：鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱，从结果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因。
一、关键点
- 5why的“5”并不是问题的数量；
- 5why的“5”指的是问题的深度，即不断地针对上一个问题的答案问问题，如果一直能问到第5层（依然可以继续），那往往才是问题真正的原因；
- 5why追求的是寻找问题的根本原因，即“问题的问题”
二、经典案例
丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因：
★ 问题一：为什么机器停了？
答案一：因为机器超载，保险丝烧断了。
★ 问题二：为什么机器会超载？（针对答案一提问题）
答案二：因为轴承的润滑不足。
★ 问题三：为什么轴承会润滑不足？（针对答案二提问题）
答案三：因为润滑泵失灵了。
★ 问题四：为什么润滑泵会失灵？（针对答案三提问题）
答案四：因为它的轮轴耗损了。
★ 问题五：为什么润滑泵的轮轴会耗损？（针对答案四问问题）
答案五：因为杂质跑到里面去了。
经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，在润滑泵上加装滤网。
如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。
三、SOP
3.1、从三个层面来挖掘原因
如果面对一个事故，不知道该如何入手，5why建议从三个层面来实施：
1、为什么会发生？从“制造”的角度。
答案要从主观意识转向具体行动，把“为什么会”句式，改成“做了什么”。
2、为什么没有发现？从“检验”的角度。
答案要从主观意识转向具体行动，把“为什么会”句式，改成“没做什么”。
3、为什么没有从系统上预防事故？从“体系”或“流程”的角度。
答案要把主语设定成“我们”，把“为什么xx会”，改成“为什么我们会让xx”。
每个层面连续5次或N次的询问，得出最终结论。
只有以上三个层面的问题都探寻出来，才能发现根本问题，并寻求解决。
这也是有些事故的复盘，没有一定级别的人参加，是不可能从流程、机制、体系上改进的原因。
3.2、询问时的基本原则
1、回答的理由是可控的，避免“借口”类答案；
2、询问和回答是在限定的一定的流程范围内；
3、从回答的结果中，我们能够找到行动的方向。
反面例子就是发散性的回答，比如下面例子：
这个工件为什么尺寸不合格？ 因为装夹松动;
为什么装夹松动？ 因为操作工没装好;
为什么操作工没装好? 因为操作工技能不足;
为什么技能不足？ 因为人事没有考评;
为什么人事没考评？ 人事人少，没精力；
为什么人事人少？ 公司没钱；
...
询问的目的是从根本上解决问题，而不是找借口和发散转移话题。
四、“刨根问底”是基本功
可能不少管理者在面对经营异常时会停在换保险丝这一层，没能力解决问题，只懂得一味的要结果，导致团队在浅层反复的左右横跳。
刨根问底除了意愿也需要能力。是否能带领团队拆解、发现、解决核心问题是管理者应该具备的一项基本功。
五、CaseStudy案例分析
2014年某月某日，某内部App ios版应用相关负责人小美接到大量用户投诉，ios的App启动时出现闪退现象，导致大量用户不能进入应用，虽说接到反馈后及时修复，但还是造成了一些不良的影响，针对此次事故，领导要求对事故进行总结，要求深入分析事故的原因。
小美基于5why分析法先对事故进行描述：
事故起止时间：2014年某月某日 10时30分-2014年某月某日 10时40分
责任人：小美
事故详情：小美对此次事故进行了详细描述，包含整个事故经过的时间、事件，在什么时间节点什么人做了什么事，谁发现的问题，谁解决的问题，怎样解决的问题。
影响范围：此次事故造成的影响和损失。
然后小美再结合5whys分析法中的原因分析实践深刻总结造成此次事故的所有原因：
1）为什么会发生此次事故？
事故的直接原因是由于某个服务端API的返回值新增加了一个字段导致此次事故的发生。
2）为什么服务端API的返回值变更会影响ios版app的崩溃而android版正常？
主要还是由于ios版代码兼容性问题，服务端api的变更导致了类似空指针异常的发生。
3）为什么事故发生前未能发现程序代码的兼容性问题而导致质量低的代码到线上？
一方面是由于小美是新人;另一方面组内缺少对代码进行质量控制的手段。
4）为什么组内没有对代码进行质量控制的手段呢？
一方面由于组内人手不足；另一方面缺少一个比较好的代码review流程去推动质量控制。
5）为什么不尽早推动这套代码review流程去预防类似事故的发生？
组内人员对代码质量的重视程度不够，存在侥幸心理。
结合5whys分析法的实践，从以下3个层面分析了此次事故的原因：
- 为什么会发生？
- 为什么没有提早发现？
- 为什么没有从系统或流程上预防事故？
表面上看因为服务端API的变动造成了此次事故，次级原因是由于IOS程序的兼容性导致，但其发生的根本原因还是在于开发人员对于代码质量存在侥幸心理并且上线流程上有漏洞，未能建立一套合理的代码Reivew和审核机制，只有制度或流程上的改进才能尽量避免类似问题的再次发生。
找到根本原因后，小美所在团队针对此次事故做了一个Casestudy总结，强调代码质量的重要性，并将代码Review的流程提上日程，利用公司Git平台提供的fork和pull request机制建立起一套合理的代码review流程，并要求组内人员遵守这套规则，使得代码质量大大提升，降低了事故的风险。
检查是否真的找到根本原因和解决方案有个简单方法：
Q: 当目前大家规划的Todo都完成后，如果事故再来一次，我们的表现会如何呢？
上面问题也是每次CaseStudy复盘最后要问的一个问题。
Casestudy作为美团工程师的必修课之一，如果不去结合5whys分析法去实践，只顾解决表面原因而不管根本原因，可能事故发生后采取临时措施改进后就忘了，问题免不了要复发；但通过5whys分析法这样一种分析过程，工程师们学会分析问题由表入里，直指问题要害，大大降低了解决问题的成本，从而间接提高了工作效率。
