如果在验收后发现系统故障,应该如何应对?

从一般意义上讲，系统开发是按照在需求定义阶段确定的内容进行程序实现，最终由用户和供应商共同确认是否达到了规定的要求，通过验收后才算完成。

然而，在现实中，测试阶段和验收阶段可能无法发现的错误和故障，很可能在后续的运营阶段中暴露出来。一旦接受了交付，那么在法律上我们能要求什么呢？

验收合格后或测试过程后仍可能存在漏洞并不奇怪

从技术角度来看，供应商完成各种测试过程和用户验收合格后，发现各种漏洞和故障并不罕见。用户在验收过程中通常会主要检查屏幕上可见的输入和输出。然而，IT系统通常在用户可见的屏幕外观之外，如背后的数据库和各种计算、控制程序部分，具有复杂细致的结构。因此，从用户角度对屏幕上的输入和输出进行检查本身就有其局限性。因此，全面验证所有可能出现的故障并不现实。

从承担开发工作的供应商角度来看，情况也是如此。例如，确认实施的程序内容是否存在漏洞或故障是“测试过程”。但是，在测试过程中，是否真的能够验证所有可能的漏洞和故障，并不一定能做到。在系统开始在业务中全面应用之后，供应商可能没有预见到的操作可能会发生，或者可能会开始注册大量的数据，或者可能会有多个用户同时访问，即使在这种情况下，创建一个可以继续运行的系统本身就需要优秀的技术能力。

在验收和测试等阶段，发现所有可能的漏洞和故障并不现实，实际开始使用后可能会发现各种问题，这就是IT系统的特点，首先应该理解这一点。

债务履行完毕通常被视为已完成

那么，当这样的问题真正出现时，我们应该如何应对呢？我们将按照法律程序进行整理。

首先，如果在事后发现了各种错误和问题，用户可能会想要追究向他们提供服务的供应商的责任。然而，通常情况下，如果产品已经交付并通过验收，那么基于债务未履行的责任追究往往会变得困难。

首先，除非有特殊的约定，系统开发合同通常会涵盖民法中的承包合同规定。关于承包合同的具体内容，我们在以下文章中进行了详细的解释。

https://monolith-law.jp/corporate/system-development-contact-agreement[ja]

在承包合同中，“工作的完成”是债务履行的要求。关于“工作的完成”具体意味着什么，我们在以下文章中进行了详细的解释。

https://monolith-law.jp/corporate/completion-of-work-in-system-development[ja]

在这里，我们解释了在过去的判例中，承包合同中的“工作的完成”在系统开发的背景下，意味着开发过程的全部结束。并且，我们解释了在开发过程全部结束后出现的错误和问题，将成为承包合同中的瑕疵担保责任问题。

总的来说，一旦接受了交付并通过了验收，那么债务本身就被视为已经履行。在这个前提下，后续的质量保证问题，也就是瑕疵担保责任的追究问题，通常会成为主要问题。

基于瑕疵担保责任追究责任的路径

那么，如果我们基于瑕疵担保责任要求供应商采取行动，我们应该按照什么顺序来考虑呢？让我们一起来确认一下。

首先确认bug或故障的严重性和严重程度

当bug或故障在事后被发现，并被法律定义为“瑕疵”时，我们需要寻求某种保障，这时候bug或故障的严重性就成为了问题。法律上的瑕疵问题主要有以下三种情况：

1. 即使是可以称为bug或故障的情况，但只是轻微的，不能被法律定义为“瑕疵”
2. 虽然符合法律上的“瑕疵”的定义，但仍然可以实现合同的目的
3. 符合法律上的“瑕疵”的定义，并且无法实现合同的目的

这三种情况决定了是否可以基于瑕疵担保责任追究责任，第一和第二种情况的界限决定了是否可以基于瑕疵担保责任解除合同，第二和第三种情况的界限决定了是否可以基于瑕疵担保责任解除合同。

第634条

1.当工作目标物存在瑕疵时，订购者可以向承包人要求在合理的期限内修复瑕疵。但是，如果瑕疵不重要，并且修复需要过多的费用，那么这个规定就不适用。

2.订购者可以代替修复瑕疵，或者与修复瑕疵一起，要求赔偿损失。在这种情况下，第533条的规定适用。

第635条

当工作目标物存在瑕疵，并且因此无法实现合同的目的时，订购者可以解除合同。但是，对于建筑物和其他土地工程物，这个规定不适用。

关于这种“瑕疵”的阶段性区分，我们在以下的文章中进行了详细的解释。

https://monolith-law.jp/corporate/defect-warranty-liability[ja]

接下来明确应向供应商提出的要求

接下来，我们需要明确应向对方提出什么要求。如果你想解除合同，仅仅证明它是瑕疵是不够的，你还需要证明它是“无法实现合同目的”的程度。在这里，“目的”的判断通常会参考系统开发项目启动初期的会议记录和规格书的记录等。即使在验收合格后，也可能出现bug或故障在事后被发现的情况，因此在开发项目结束后，应该严格保存各种文档。

https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]

除了解除合同外，你还可以要求赔偿损失或修复瑕疵等，这些都是瑕疵担保责任的内容。

其他注意事项

在进行法律行为，如解除合同时，也要注意操作方式

如果作为瑕疵担保责任的内容，进行合同的解除，那么也应该掌握进行解除所需的法律手续的操作方式。关于合同解除的效果、有效的意思表示的方式、以及如何进行不会引起后续问题的通知等，我们在以下的文章中进行了详细的解释。

https://monolith-law.jp/corporate/cancellation-of-contracts-in-system-development[ja]

希望通过谈判而不是争议来解决问题

此外，这一系列的法律论述并不仅仅在发生诉讼的情况下才有意义。通过诉讼解决争议对双方当事人来说负担都非常大。相反，这些法律知识应该在诉讼前的谈判阶段大力运用。关于这些法律知识在诉讼以外的谈判中有多大的意义，我们在以下的文章中进行了解释。

https://monolith-law.jp/corporate/disputes-related-to-system-development[ja]

应区分错误和缺陷，以及功能的缺失

如果实施的功能或规格存在错误或缺陷，或者根本就没有必要的功能，那么讨论的内容将会有所不同。如果必要的功能并未全部配备，那么在承包合同中可能无法认定为“工作完成”，也可能无法认定为债务履行。

另外，即使没有提供必要的功能或规格，如果用户在需求定义阶段没有提供适当的信息，那么可能应该评估将其视为合同内容的一部分是否不适当。

总结

在项目进程中出现的问题，有时会在项目进行中被发现，有时则会在运营阶段等事后阶段被发现。即使顺利完成了所有的工程，也并不一定能放心。这种特性似乎正是被象征在”瑕疵担保责任”（日本瑕疵担保责任制度）这一制度中的系统开发项目。我们认为，不仅要做好看到项目结束后的文件管理，也要理解这一系列的流程是非常重要的。