关于系统开发中合同解除的方法

由于系统开发项目通常会持续很长一段时间，因此在项目进行过程中出现“燃烧”等情况也是完全可以预见的。虽然如果用户和供应商能始终保持步调一致那自然最好，但我们也应该预见到可能需要考虑中途解除合同的情况。

本文将解释与系统开发相关的重要问题，即合同的“解除”这一法律选项。

系统开发与解约的关系

民法中的解约是什么

在修订后的《日本民法》中，关于合同的“解约”一般规定在第540条到第548条。解约合同意味着将一份已经签订的合同的效力在后期消除。

如果从用户和供应商的关系来看，通常一旦合同签订，供应商就有义务开发系统，用户也有支付报酬的义务。这些义务的反面就是双方的“权利”。如果合同被解除，双方承担的义务和拥有的权利将恢复到合同签订前的状态。因此，即使还有未履行的债务，也不再有履行的义务，而且根据合同签订前的状态，双方都有恢复原状的义务。这就是所谓的“恢复原状义务”。

另外，如果同时存在损害，可以另行进行赔偿。

系统开发实务与解约的关系

对于熟悉系统开发等业务法律实务的人来说，提到合同的“解约”，首先联想到的可能是解约通知书。但是，即使在系统开发的法律背景下，解约的依据可以大致分为两种情况。

以债务不履行（履行迟滞）为理由的情况

（例）供应商超过了最初承诺的交货期，但仍未交货

《日本民法》第五百四十一条当事人一方不履行其债务时，对方可以设定合理的期限进行催告，如果在该期限内未履行，对方可以解除合同。

在承包合同型的系统开发中，“当事人一方”即供应商承担的“债务”是完成并交付符合需求定义的系统。因此，如果供应商在超过交货期后仍未交货，换句话说，就是供应商在交货期内未完成工作。那么，“工作的完成”在系统开发中具体是什么呢？关于这一点，我们在下面的文章中进行了详细解释。

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

以瑕疵担保责任为理由的情况

（例）供应商交付的系统存在许多错误和数据不一致，后来发现不适用于实际使用

《日本民法》第六百三十五条如果工作的目标物存在瑕疵，因此无法达到合同的目的，订购者可以解除合同。但是，对于建筑物和其他土地工程物，不适用此条。

另外，从系统开发项目的角度来看，供应商方面表示解除合同的情况并不常见。通常，我们可以假设用户会向供应商表示解除合同。

关于瑕疵担保责任，我们在下面的文章中进行了详细解释。

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

解除通知书及其相关法律问题

解除通知书是一种文件，通常由用户向供应商传达解除合同的意愿。在法律条款中，可以参考以下内容：

日本民法 第五百四十一条：当事人一方未履行其债务时，另一方可以设定合理期限，催告其履行，如果在该期限内未履行，另一方可以解除合同。

从系统开发相关文档的角度看，解除通知书的特点不在于促进项目的顺利进行，而在于结束项目。此外，它也是一种期望直接产生一定法律效果的文件，这也是其重要特点。

然而，正如前述条款所述，与合同等文件不同，只要满足一定条件，单方面的意愿表示就足够了。当用户向供应商提供解除通知书时，接收到该通知书的供应商负责人可能会遇到“即使阅读了解除通知书，也不明白为什么合同被解除”的问题。那么，用户在编写解除通知书时，应该在多大程度上具体指出解除的原因呢？

是否应在解除通知书中写明解除原因

关于这一点，从过去的判例等来看，我们认为在解除通知书中明确写明解除原因并不是进行解除的必要条件。以下引述的判例是一个因为交付的系统存在问题而引发法律问题的案例。在用户方进行解除意向表示时，需要具体了解到什么程度的问题内容，并需要具体指出这些问题，这些问题成为了问题的点，法院做出了以下的判断。

解除的意向表示并不一定需要显示解除原因，可以通过单一的意向表示进行多个解除原因的解除，即使在进行解除的意向表示时提出某个理由，除非特别明确表示不会因其他原因进行解除等特殊情况，否则该意向表示应被认为是基于当时存在的所有原因，意图完全终止合同的意向表示。

东京地方裁判所2004年（平成16年）12月22日

法院的观点是”可以通过单一的意向表示进行多个解除原因的解除”。也就是说，重要的是合同当事人是否有解除的意愿，而不需要详细指出具体的原因。

也就是说，即使已经交付，但是否应该被视为未完成，或者是否因为存在重大缺陷而应该被视为瑕疵担保责任的问题，这些问题在解除意向表示的阶段并不需要提出。即使暂时不考虑这些微妙的问题，但如果先进行解除的意向表示，即使后来发生诉讼，也可以争论是履行迟延还是瑕疵担保责任作为解除的依据。

• 交付的是未完成的产品……→债务不履行
• 交付的是有重大缺陷的产品……→瑕疵担保责任

即使没有详细指定原因，解除的意向表示也是有效的。

然而，具体指出解除原因并提交解除通知书的做法，即使在与供应商之间出现沟通误会或认识不一致的情况下，也有明确这些问题的优点。对于接收解除通知书的对方来说，如果他们能想到原因，那么后来纠纷的可能性也会减小。因此，尽可能明确写明解除原因是更好的做法。

设定了“相当的期间”的催告是多长时间？

另一个可能考虑的问题是在日本民法（Japanese Civil Code）第541条中，“相当的期间”是多长时间。然而，对于这一点，我们认为没有必要过于纠结。因为，即使在发出催告的期间内没有设定“相当的期间”，只要从催告开始已经过了相当的期间，就可以解除合同。即使催告的期间不是“相当的期间”，只要实际上已经过了相当的期间，也可以解除合同，这在判例法上也已明确。

在系统开发项目中，一旦出现履行延迟或瑕疵担保责任等“燃烧”问题，即使设定了“相当的期间”进行催告，完成交付或瑕疵修复的情况可能并不多。考虑到这些因素，在实际操作中，围绕“相当的期间”发生严重争议的可能性不大。

关于系统开发中履行延迟的定义，我们在另一篇文章中进行了解释。

https://monolith-law.jp/corporate/performance-delay-in-system-development[ja]

解除通知书的通知方法是什么？

关于解除通知书应该通过何种方式通知，只要最终能确保通知能够到达（更进一步来说，如果能够通过某种方式证明通知已经确实到达）那么任何方式都没有问题。

因此，没有必要过于在意手续问题。确实，在实际操作中，为了避免后续出现“说了没说”的问题，人们往往更倾向于使用内容证明邮件等方式。然而，只要能确认对方已经收到，即使是使用FAX或电子邮件等简便的方式也没有问题。但是，最终如果事情发展到需要进行诉讼，那么就需要证明“通知已经到达对方”，从这个角度来看，内容证明的方式确实更为安全。

总结

在本文中，我们根据系统开发的背景，对合同解除进行了整理。除了实际操作如何解除的技巧，如果能理解包括法律有效的意愿表示方法在内的各个方面，这些知识应该会变得容易应用。