鱼骨图 (石川图)¶

当一个复杂的问题发生时，其背后的原因往往不是单一的，而是由多个不同领域的、相互关联的因素共同导致的。如果我们只凭直觉去思考，很容易遗漏掉一些关键的潜在原因。鱼骨图（Fishbone Diagram），也因其发明者石川馨（Kaoru Ishikawa）博士而被称为石川图（Ishikawa Diagram）或因果图（Cause-and-Effect Diagram），是一种强大的、可视化的根本原因分析（Root Cause Analysis）工具。它的核心目标在于，通过一个形似鱼骨的结构化框架，来帮助团队系统性地、全面地发散和组织导致一个特定问题（结果）的所有潜在原因。

鱼骨图的魅力在于其结构化的头脑风暴过程。它提供了一系列经典的原因类别（即鱼的“大骨”），引导团队从不同的、预设的角度去思考，从而避免了思维的盲点。通过将所有可能的“人、机、料、法、环、测”等因素都呈现在一张图上，团队可以对问题的复杂性有一个全局的、整体的认识，并在此基础上，进一步识别出那些最值得深入调查和验证的关键原因。

要点速览

用途：把一个问题的所有潜在原因，按类别系统地列出来，找到最值得验证的关键原因。
结构：鱼头 = 问题；大骨 = 原因类别（如 6M）；小骨 = 具体原因。
画法：定义问题 → 选分类 → 按类别头脑风暴 → 圈出关键原因 → 用数据验证。
最佳搭档：用五问法往深挖单个原因，用帕累托分析给原因排优先级。
注意：鱼骨图上的每一条都只是“假设”，没有数据验证之前不能当成结论。

鱼骨图的结构¶

一张鱼骨图，由几个形象的、固定的部分构成：

鱼头（Head）：位于图的最右侧，通常用一个方框框起来，里面写着我们要分析的问题或结果（Effect）。例如，“本月产品缺陷率上升20%”。
鱼脊（Spine）：一条从鱼头向左延伸的、水平的主干线。
大骨（Main Bones）：从鱼脊上斜向延伸出的几条主要分支，代表了产生问题的几大原因类别（Categories）。这些类别为思考提供了结构。
中骨/小骨（Sub-Branches）：从大骨上延伸出的、更细小的分支，代表了在每个主要类别下，团队成员通过头脑风暴想到的、更具体的潜在原因。

经典的原因分类模型（大骨）¶

根据分析对象所处的行业不同，鱼骨图的大骨分类可以灵活选用不同的经典模型：

制造业常用的“6M”模型（即“人、机、料、法、测、环”）：
- Manpower（人）：操作人员的技能、经验、责任心、疲劳度等。
- Machine（机器）：生产设备的老化、精度、维护保养状况等。
- Material（物料）：原材料的质量、规格、供应商稳定性等。
- Method（方法）：工作流程、操作规程、工艺参数设置等。
- Measurement（测量）：测量工具的精度、检验标准、数据记录的准确性等。
- Milieu / Mother Nature（环境）：工作场所的温度、湿度、光照、组织文化等。
服务业常用的“4S”或“8P”模型：
- 4S：Suppliers（供应商）、Systems（系统/流程）、Surroundings（环境）、Skills（技能）。
- 8P：Product（产品/服务）、Price（价格）、Place（渠道）、Promotion（促销）、People（人员）、Process（流程）、Physical Evidence（有形展示）、Productivity & Quality（生产力与质量）。
软件与互联网团队：没有统一标准，常用的大骨是 Code（代码）、Build（构建）、Test（测试）、Infrastructure（基础设施）、People（人员）、Process（流程）。

分类模型只是思考的脚手架，不是必须照搬的规定。选择的原则是：这几个类别加在一起，能覆盖问题所有可能的来源，而且彼此不太重叠。

如何绘制和使用鱼骨图¶

第一步：明确定义“鱼头”（问题）

与团队一起，就所要分析的问题，达成一个清晰、具体、无歧义的共识。好的问题陈述要可衡量、有时间范围、不预设原因：“本季度客户满意度下降15%”是好的；“因为客服态度差导致满意度下降”就不好，因为它在第一步就把原因写死了。将这个问题陈述写在白板右侧的“鱼头”位置。
第二步：画出“鱼脊”和“大骨”（原因类别）

画出主干线，并根据你的行业和问题特点，选择一个合适的分类模型（如6M），画出几条主要的大骨，并标上类别名称。一般 4~6 根大骨最合适。
第三步：进行头脑风暴，填充“中/小骨”（具体原因）
- 这是鱼骨图的核心环节。主持人引导团队，围绕每一个大骨类别，进行头脑风暴，提出所有可能的具体原因。
- 关键技巧：在每个具体原因下，可以结合五问法进行连续追问，从而找到更深层次的原因。例如，在“人”的大骨下，一个原因是“员工操作失误”，继续追问“为什么会失误？”，得到“因为培训不足”；再问“为什么培训不足？”，得到“因为没有标准化的培训教材”。把这条因果链作为中骨、小骨画上去。
- 将所有想到的原因，都以中骨或小骨的形式，连接到相应的大骨上。这一阶段只记录、不评判，避免过早否定某个想法。
第四步：分析鱼骨图，识别关键原因

当鱼骨图被填满后，它就提供了一幅关于问题成因的全景图。此时，团队需要一起审阅整个图表，并通过讨论、投票或简单的数据验证，来识别出那些最有可能导致问题的、或者影响最大的“关键少数”原因。可以用不同颜色的笔，将这些关键原因圈出来。
第五步：制定后续的验证和改进计划

鱼骨图本身是一个发散和分析工具，它不能直接解决问题。下一步，团队需要针对圈出的那几个关键原因，制定具体的验证计划（例如，去现场收集数据，验证某个假设是否成立），并在此基础上，制定出最终的改进措施。

鱼骨图模板¶

开会前把下面这张“原因登记表”准备好，边画图边填写，会议结束时就能直接得到一份可执行的验证清单。

问题陈述（鱼头）：＿＿＿＿＿＿（可衡量、有时间范围、不预设原因）

原因类别（大骨）	具体原因（中骨）	深层原因（五问法追问）	现有证据 / 需要的数据	是否关键	负责人
人	新员工操作失误	缺少标准化培训教材	近一个月新员工返工记录	✓	张三
机器	设备精度下降	保养周期被拉长	设备保养日志		李四
方法	……	……	……
物料	……	……	……
测量	……	……	……
环境	……	……	……

会前检查清单

问题陈述里没有出现“因为……”
参会者覆盖了问题涉及的各个环节（一线执行、管理、质量/测试）
准备好了与问题相关的基础数据（发生时间、频率、影响范围）
选定了大骨分类，并提前写在白板上

应用案例¶

案例一：分析“软件App闪退率高”的问题

鱼头：App在最新版本上线后，用户闪退率上升了50%。
大骨：采用软件开发的变种模型：Code（代码）、Build（构建）、Test（测试）、Environment（环境）、People（人员）。
分析：通过团队的头脑风暴，可能在“代码”大骨下，发现了“新的第三方库存在内存泄漏”；在“测试”大骨下，发现了“自动化测试用例没有覆盖到低端安卓机型”。经过进一步的数据验证，团队最终定位，“内存泄漏”是导致闪退的最主要原因。

案例二：分析“软件编译时间过长”

鱼头：主干分支的完整编译时间从 8 分钟增加到 25 分钟，开发者每天因等待编译损失约 1 小时。
大骨与主要原因：
- 构建环境：构建服务器配置低、多个流水线共享同一台机器。
- 构建方式：未启用增量编译、每次都清空缓存重新构建。
- 代码结构：模块之间存在循环依赖，改一个文件会触发大面积重新编译。
- 依赖管理：第三方依赖每次都从远端重新下载。
- 人员与流程：缺少对构建时长的监控，问题持续了几个月才被注意到。
结论：团队统计各环节耗时后发现，“构建服务器配置低”“未使用增量编译”和“模块间循环依赖”是影响最大的三个关键原因，并据此制定了硬件升级和技术重构计划。“缺少监控”虽然不是直接原因，却是问题被拖延的原因，于是同时加上了构建时长告警。

案例三：分析“一场市场营销活动效果不佳”

鱼头：本次“双十一”促销活动，销售额未达到预期目标。
大骨：采用市场营销的4P模型：Product（产品）、Price（价格）、Place（渠道）、Promotion（促销）。
分析：团队可能发现，在“价格”大骨下，有“优惠券规则过于复杂，用户看不懂”；在“渠道”大骨下，有“社交媒体的广告投放，没有精准地触达目标人群”。通过这个分析，团队可以为下一次的活动，提供清晰的、可供规避的“避坑指南”。

案例四：分析“病人术后感染率上升”

鱼头：本季度骨科病房的术后感染率，比上一季度上升了5%。
大骨：采用医疗领域的6M模型。
分析：一个由医生、护士、院感科专家组成的跨职能团队，共同绘制鱼骨图。他们可能最终发现，在“方法”大骨下的“术前皮肤消毒流程执行不到位”，和“环境”大骨下的“病房通风系统滤网更换不及时”，是两个最可疑的关键原因。接下来，他们将对这两个点，进行重点的数据收集和现场观察。

常见误区¶

把鱼头写成了原因。“因为客服人手不足导致投诉增加”这样的鱼头，等于在分析开始前就给出了答案，团队会不自觉地只围绕这一个方向找证据。鱼头只写现象和结果。
把“想到的原因”当成“找到的原因”。鱼骨图是假设的清单，不是结论。没有数据或现场验证就直接采取行动，很可能花了力气却没解决问题。
原因停留在表面。“员工粗心”“设备不好”这类原因无法直接行动。对每个可疑原因至少追问两三次“为什么”，直到落到某个可以改变的流程、标准或资源上。
只有一个人在画。鱼骨图的价值来自不同岗位的视角。如果只有管理者或只有一线人员参与，图上会系统性地缺掉一整类原因。
追求“画满”。一张塞了上百个原因的鱼骨图很难再聚焦。原因太多时，先把问题拆小（例如按产品线、按时间段分别画），或者只保留团队认为可能性较高的原因。
大骨分类彼此重叠。比如同时设置“流程”和“方法”，会让同一个原因不知道该挂在哪里，讨论变成争论归类。分类之间要尽量互斥。

鱼骨图、五问法和帕累托分析的区别¶

这三个工具经常一起出现，但各自回答的问题不同：

	鱼骨图	五问法	帕累托分析
回答的问题	可能的原因有哪些？	这个原因背后的根源是什么？	哪几个原因影响最大？
思考方向	横向发散，求全面	纵向深挖，求深入	量化排序，求重点
需要数据吗	不一定，靠团队经验	不一定，最好有事实支撑	必须有，需要按原因统计频次或损失
适合的问题	原因来自多个方面的复杂问题	因果链条比较清晰的单一问题	原因已经明确、需要分配资源
典型用法	先用它列出全部可疑原因	对鱼骨图上的关键原因逐个深挖	收集数据后确定先解决哪几个

实践中最常见的组合是：鱼骨图列出原因 → 帕累托分析排出优先级 → 五问法深挖排名靠前的原因。

鱼骨图的优势与挑战¶

核心优势

结构化与全面性：提供了一个清晰的结构，引导团队从多个维度进行系统性思考，有效避免遗漏。
促进团队参与和共识：是一个极佳的团队协作工具，能够汇集所有人的智慧，并就问题的复杂性达成共识。
可视化：将复杂的原因关系，以一种非常直观、一目了然的方式呈现出来。

潜在挑战

可能变得过于复杂：对于一个极其复杂的问题，鱼骨图可能会变得非常庞大、杂乱，反而失去了清晰的焦点。
无法体现原因的权重：鱼骨图本身，并不能显示出哪个原因的影响更大。它需要与帕累托分析等其他工具结合，才能确定优先级。
只是一个“假设”的集合：鱼骨图上所有的“原因”，在经过数据验证之前，都还只是“潜在的、可疑的”原因，而非事实。
难以表达原因之间的相互作用：鱼骨图假设各类原因是并列的，但现实中原因之间常常互相强化。遇到这类问题，可以改用系统动力学或冰山模型。

常见问题¶

鱼骨图、石川图、因果图是同一个东西吗？

是的。三者指的是同一种工具：“鱼骨图”来自它的形状，“石川图”来自发明者石川馨，“因果图”来自它表达的内容。

大骨一定要用 6M 吗？

不一定。6M 适合制造业和质量问题；服务业常用 4S 或 8P；软件团队常按代码、构建、测试、基础设施、人员、流程来分。也可以根据问题自定义，只要各类别能覆盖所有可能来源、彼此不重叠即可。

一张鱼骨图写多少个原因比较合适？

没有硬性标准，常见是每根大骨 3~6 个具体原因，全图二三十个。如果原因远多于这个数，通常说明问题定义得太宽，可以拆成几个更具体的问题分别分析。

用什么工具画鱼骨图？

团队现场讨论用白板加便利贴最高效，便于随时移动和归类。需要存档或远程协作时，常见的选择有 Excel / WPS 表格模板、ProcessOn、亿图图示、Miro、draw.io 等。工具不重要，重要的是先把问题和分类想清楚。

画完鱼骨图之后下一步做什么？

针对圈出的关键原因收集数据进行验证，用帕累托分析确定先解决哪几个，再对确认的原因用五问法找到可以落地的根本原因，最后制定改进措施并跟踪效果。

延伸与关联¶

五问法（5 Whys）：鱼骨图的黄金搭档。在用鱼骨图进行横向的、广度的原因发散时，可以随时用五问法，对某一个具体的原因，进行纵向的、深度的根本原因挖掘。
头脑风暴：鱼骨图为头脑风暴提供了一个结构化的框架，使得创意生成更有序、更聚焦。
帕累托分析：在用鱼骨图识别出所有潜在原因后，可以通过收集数据，并用帕累托分析，来确定哪些是导致了80%问题的“关键少数”原因。
六西格玛 与 全面质量管理：鱼骨图是这两套质量管理体系中最常用的基础工具之一。

来源参考：石川馨（Kaoru Ishikawa）博士是日本战后质量管理运动的先驱之一。鱼骨图作为其发明的“质量管理七大工具”之一，被广泛应用于全球的质量管理和持续改进活动中，是全面质量管理（TQM）和六西格玛（Six Sigma）实践中不可或缺的基础工具。