对日离岸开发，基本定位在以Cost-Down为目的的一种软件开发外包。在这种背景下的受注方会有以下现象：
1）人员过于年轻，缺乏经验，品质意识低
2）人员流动大(离职，晋升，换岗)
这种情况下如何保证软件的品质是最大的课题。其中一大有效手段便是我今天想要阐述的根本原因分析。对于软件过程中引起品质问题的错误，日方的见解是：“只要是人为的事就不可能不犯错，但是需要对每次出错的地方进行根本原因分析，找出根本原因所在，并提供对策，以图今后不再重犯。”
个人从根本原因分析中获益良多，自己的case，他人的case都可以借鉴
■ 什么是根本原因分析
软件开发中的根本原因分析是指将为什么会混入BUG，为什么没有能够防患于未然这两个问题追究到底。
对于BUG的产生原因开发担当者和检查担当者会说：“由于误解导致错误”、“这是判断错误”。一般的追究也就到此为止了，然而真正的根本原因分析是例如：“那么，为什么会产生误解呢”——这样的对于事物的根本原因进行逆向分析的方法。
■ 根本原因分析的必要性
根本原因分析是对于遭受的失败，以不再两次遭受同样的失败为目的，而确立并实施的一种机制。人们对于失败往往会有不堪回首的想法，然而回溯到失败的根本原因进行分析，确立不再反复遭受失败的机制，不但可以避免相同的过失，对于组织整体，也起到可以提高技术技能和生产效能的效果。
软件的障害从发生到修正为止的流程如所示。
①导致障害的错误
②程序上的缺陷
③程序的缺陷产生的现象
④现象的通知
⑤原因分析
⑥程序修正
⑦根本原因分析
⑧技术・管理的改善
①～④是从障害发生到通知障害为止的流程。之后，如果只进行⑤,⑥就结束的话，不知道什么时候，还会发生基于①的其他缺陷，而不得不反复进行②～⑥。因此，不应该仅仅以⑤,⑥结束，而是应该实施至⑦,⑧为止的流程，预先解决根本性的问题。
失败如果停止在⑥的话，就只能停留在把失败进行治标的水平上，如果进行到⑧的技术・管理的改善的话，就可能实现开发组织全体的技能以及生产效能的提高。失败决不是应该被忌讳、嫌弃的事物，而应该被当作技能提升的重要的一个步骤。
将失败保持一个谁都可以理解的形态，通过共享使得不仅失败的当事者，而且与之相关的所有人都能够预防该失败的发生，采用这样的机制也是十分必要的。
■ 根本原因分析的思想准备
进行原因分析时，需要以下的思想准备。
・ 舍弃先入为主的观念
为了进行深层次的根本原因分析，必须舍弃先入为主的观念，采取以事实说话的态度。如上所述，遭受失败的人往往希望掩饰失败，或是有不愿承认失败的种种心理活动。但是，考虑到将该失败限于最小限度，并制定失败的预防对策，就不应该满足于表面的事实，通过人物采访等方法，努力挖掘出隐藏的事实也很关键。
・ 带着假说去对应
发现不同的事实显而易见相互矛盾时，不应该忘记带着某种假说(构想)进行分析。只是单纯的观察事实的话，本来应该只有少数的根本原因，就会发散成繁多的表面原因。而且，如果一开始没有带着假说去对应的话，即使想去通过人物采访的方法挖掘隐藏的事实，询问的方式也会让人不知所云。
・ 分析至找到诀窍为止
“如果这样做，不仅可以避免失败，而且无需特别的努力就可以很容易的实现，不能实现的话才会让人觉得可疑”，象这样考虑，分析直至找到诀窍为止。如果不能找到这样的诀窍时，可以进行方向转换后继续进行分析，例如如果觉得人不应该犯这样的错误，可以尝试考虑一下物理结构。
重大障害的根本原因，往往不仅是开发者个人层次的问题，还会发现很多根植于组织和规则的问题。简单的在自己能够处理的范围内进行分析，想找到对策的话，就会使得这些深层次的问题原样残留，有可能导致别的重大障害的产生。下一页中记载了根本原因的分析示例。不仅是从一个开发者的层次可以处理的范围，而是包含了开发流程・管理・人材养成等，从一个宽广的视点实施根本原因分析，具有这样的心理准备是十分必要的。
■ 根本原因分析的手法
根本原因分析中，逼近根本原因的最一般的方法是类似“为什么，混入了问题？”、“为什么，没能够事先发现问题？”这样反复的问为什么，为什么。
据说这里将“为什么”反复进行７次以上可以有效逼近根本原因。
另外，如果能够将原因分类为失败学中提及的以下10种情况，也可以认为已经充分进行了根本原因分析。
- 无知
- 疏忽
- 不遵守手顺
- 误判断
- 调查 ・讨论不足
- 制约条件的变化
- 企划不良
- 价值观不良
- 组织运营不良
- 未知
・ 根本原因分析中反复进行“为什么”的Point
1) 对于“为什么”，尽可能简单的回答——使用“XXX 是YYY ”这种程度的简单的文章。
“何时”“何地”“多少”这样的信息也可以使用，请不要使用“由于ZZZ ，XXX 是YYY ”这样带有条件的写法。一旦带有条件，往往意味着漏过其他的要因。 如果写成“由于是新人，没有开放已经获得的空间”，就会特别关注新人这个要因，对于新人以外的其他人也有可能产生同样的miss，很有可能就不能采取合适的对策。
2) “为什么”之后的文章中，不要把前文看作“因此”
对于内存溢出，举出要因：没有开放已经获得的空间。这时，“为什么”之后的文章中，不应该把前文看作“因此”，即“没有开放已经获得的空间，因此，内存溢出”。虽然这个例子中意思还是通顺的。
3) “为什么”之后的文章中，加入“只有这个原因吗?”，检讨是否有其他的要因
对于内存溢出，举出要因：没有开放已经获得的空间。追问“只有没有开放已经获得的空间这个原因吗?”。如此检讨是否有其他的要因就效果会比较好。有可能还会发现同时打开多个文件或是机器内存过少等其他的要因。
4) 其他 不要使用“不好”“有问题”等有歧义的写法。
应该具体写清楚，为什么不好? 为什么有问题? 人总是想回避心理方面的追究。即使举出“疲劳”、“误解”等作为要因，作为其对策“不要过于疲劳”、“注意不要误解”——也只不过是个口号。应该对于管理/工具等制度和机制，进行追究/对策的分析。`
附：失败学
I. 关于失败学 对失败做出正确分析，基于分析结果对失败进行分类，并利用得到的失败知识，开发不会重蹈覆辙的系统。所谓失败学，就是对这一系列流程进行学习、研究。 失败的分析 失败由“要因”、“内情”、“结果”构成。我们所看到的大多只是“结果”部分。为了对失败进行分类，除了结果，我们还必须知道要因和内情等背景，而它们都是隐藏起来的。为了了解它们，可以通过反复假定和验证，从而进行近似处理。 首先，假定1个导出“结果”的“内情”。如果给“内情”一个可以假想的“假定要因”并得到“结果”，那么这个组合就可以称为导出“结果”的构造的候选。同样创建其他候选（内情、要因），与之前的候选进行比较，提取出共通部分。以共通部分为基础，反复假定“要因”和“内情”的组合。如果看到聚合现象，就可以说得到了真正的“要因”和“内情”。对于假定，推测、分析是不可欠缺的。
II. 失败时人的心理 失败时，当事人的心理会如所述： 刚刚失败后，思路会是“回想经过”—>“simulation”－>……。随着时间的推移，渐渐感到反省、后悔，最后想要隐藏、忘掉或置之不理。如果此人的失败信息隐藏起来，那么同一组织的其他人就会重复同样的失败。失败信息的隐藏通常伴有极高的代价。 面对失败，重要的是千万不要胆怯，要冷静地弄清要因和内情，考虑对策，以保证之后不会重复同样的失败。失败学就是帮助构建一个系统（职场环境），是应用到软件开发中的、用于避免严重失败的手段。
III. 失败的分类 要活用一个失败并从中得到学习，就必须对失败进行分析并理解。下表将失败的原因分为了10个大种类。
除了第10项的“未知”，编号数越大，就是越高级的判断错误，也可以认为是社长等组织领导者失败的原因。
IV. 信息共享的必要性 通常，在生产组织中是按照企划－>设计－>制作－>贩卖－>维护的顺序传达命令、指示的，报告路线则与此相反。然而，失败信息主要以投诉（claim）的形式，从市场向贩卖、再从贩卖向设计传达，因此经常会因每个部门的认识不一致，导致报告的失败信息产生偏差。 设计者必须听取来自外部的对自己产品的评价，不这样就无法进步。没有失败信息的反馈，这对设计来说是致命的。 企划的失败是所有部门中影响最大的，并且通常是无法挽回的。 然而，在实际中，组织的失败信息拥有一种特性，那就是每个部门都怕承认失败会对自己的部门不利，只要没有强制力量，就都把失败信息控制在暗处，而不向其他部门传达。 理想的失败信息的传达是，首先当然要将每个部门的失败信息在各自的部门内处理，所有的失败信息作为信息的积累，汇总到一个网络中。需要做的不只是简单地以数据库的形式积累，还要进行失败信息的记录化、一般化、共享化，从任何部门都能够访问其他部门的失败信息，然后通过活用开展活动。 失败信息应该作为所有部门的共有财产来处理，当可以这样做的时候，生产组织就能够获得新生，并在很大程度上变得更新更强。
