如果系统开发业务因用户方便而中断,应如何应对?

系统开发这项业务，通常往往会以长期项目的形式进行。那么，如果在开始进行系统开发后，用户方单方面表示“不再需要该系统，不必再开发”，那么承接工作的供应商方能做些什么呢？

本文将整理系统开发合同的特点，并解释在这种情况下的应对策略。

思考用户因自身原因中断的意义

在系统开发的合同中，从合同的角度来看，有一些应该称之为特色的点。其中之一是，其工期通常较长，作为项目管理的义务，供应商方面也承担着大量的义务和大量的自由裁量权。关于供应商承担的项目管理义务的整体内容，我们在下面的文章中进行了详细的解释。

https://monolith-law.jp/corporate/project-management-duties[ja]

另外，另一个特点是，用户，即使是客户，也广泛地承担着协助供应商工作的义务。由于这是在自己公司内部使用的系统，所以不能仅仅依赖供应商来完成。从公司内部，也有义务适当地协助供应商，使其能够发挥专业性并进行工作。关于这一点，我们在下面的文章中进行了详细的解释。

https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]

如果在这里简单地总结以上内容，供应商和用户之间，既有开发系统的”外部供应商”和支付报酬的”客户”这种对价关系，同时也有朝着实现项目目标这一共同目标协作的”伙伴”的面貌。这种复杂的关系通常不会出现在定制西装的裁缝等地方，也是系统开发合同的一个重要特点。由于这种关系的复杂性，系统开发相关的争议一旦发生，就会在如何法律整理双方关系的问题上变得复杂和纠结。

如果用户方面改变主意，突然说”最终不需要那个系统了，所以不需要再推进项目了”，那么应该如何理解双方的权利和义务关系的问题，思考这个问题在某种意义上，也具有在面对这种复杂的合同关系时，运用法律思维的实例的意义。以下，我们将在设想这种情况的基础上，整理出应该考虑的事项。

首先，整理提出解约的原因

从供应商的角度看，“用户单方面想要中断项目”这样的认识，不一定能够与用户之间共享。举个例子，假设有一个项目正在开发管理海外驻地员工人事的系统，后来海外扩展计划被撤销，因此开发这样的系统变得不再需要。确实，只看这个解释，可能会被理解为用户方的单方面改变主意。

然而，如果这样的决定是由于供应商方面存在项目管理的义务违反，如各个阶段的延迟等，以及开发本身的进展困难，也成为公司政策变更的一个原因，那又该如何呢？

如前所述，系统开发是供应商和用户共同承担大量义务，紧密协作推进的。因此，即使是用户方提出想要中断，即使供应商认为这是用户的自行解约，也可能被指出供应商方的责任原因，可能会被反驳为基于债务不履行的解除或协议解约。

是自行解约，还是基于债务不履行的解除，还是协议解约，这些区别往往根据项目的进展情况和至今为止的谈判经过等，每个案例都需要单独判断。因此，如果供应商在认为是用户的自行解约的情况下进行后续处理，那么在会议记录等中，应明确记录这一点，以防止后来在这一点上产生争议。

接下来，确认索赔和赔偿的依据条款

在考虑了上述因素后，如果可以将问题视为用户自行决定解约的情况，那么接下来，我们需要考虑供应商是否可以根据完成的比例向用户索取报酬，或者是否可以要求赔偿损失。

在这种情况下，应参考的条款会因合同类型的不同而不同。大体上，系统开发合同可以分为承包合同和准委托合同。

https://monolith-law.jp/corporate/contract-and-timeandmaterialcontract[ja]

然后，对于准委托合同和承包合同，民法设定了以下规定：

a.)准委托合同的情况
索赔：民法第648条第3款（日本《民法》第648条第3款）
当委托因无法归责于受托人的原因在履行过程中终止时，受托人可以根据已经履行的比例索取报酬。
赔偿损失：民法第651条（日本《民法》第651条）
1.委托可以由任何一方随时解除。
2.当一方在对方不利的时期解除委托时，该方必须赔偿对方的损失。但是，如果有不可避免的原因，这不适用。

b.)承包合同的情况
赔偿损失：民法第641条（日本《民法》第641条）
在承包人未完成工作期间，订购人可以随时赔偿损失并解除合同。

另外，根据民法第641条（日本《民法》第641条）的赔偿损失范围，不仅包括已经支出的费用，还广泛包括”如果没有被解除合同，本来可以获得的利润”。这是因为，从订购人的角度看，即使工作变得不必要，法律也强制要求完成工作是没有意义的。因此，在这种情况下，反而通过支付相同的对价来保障接单方的利润是合理的。

然而，关于根据民法第641条（日本《民法》第641条）的赔偿损失，供应商和用户之间的个别合同中，往往有不少情况被排除在赔偿损失的范围之外。在这种情况下，双方单独达成的约定（=合同）将优先，因此，这些民法规定可能不适用，需要注意。

进一步推进成交量和损害的证明

在用户方因自身原因解约的情况下，通常会看到的合同规定是，可以要求支付成交量（即完成部分）的委托费用和赔偿损失。因此，通常来说，供应商方需要进行成交量和损害的证明，以便进行损害赔偿的要求。

然而，这种成交量，也就是完成比例的证明，如果真的要进行，可能会变得非常困难。因为，要确认哪些工作项目完成了多少，特别是当有多个分包商的情况下，进行进度确认的听证等，如果真的要进行，可能会变得相当大。此外，如果要制作支持听证结果的资料，或者将听证内容本身文档化，那么所需的工作量可能会变得非常大。即使这样，如果最后被告知证据不足，那么为证据准备所花费的努力可能会变得徒劳，这也是一个大问题。

考虑到这些因素，可以考虑的对策包括，在合同阶段就明确指出，如果中途解约，将按照解约时的天数进行按日计算，以便进行简单的计算。此外，考虑到对成交量的要求会花费大量的证明工作，可以考虑放弃对成交量本身的要求，而是对”已经完成部分的开发所需的费用”进行要求。如果是公司内部的开发费用，那么可以通过”工时×单价”这样简单的计算公式轻松计算出来。特别是在利润率较低的项目中，通过优先考虑基于费用的要求而不是成交量，可以期待在重视债权回收的便利性的同时进行损失补偿，这在许多情况下都可能成为更现实的救济措施。

从用户角度来看，我们应该考虑什么？

顺便说一下，作为用户，如果你打算因个人原因解除合同，也有一些事情你需要提前考虑。那就是，你应该提前确认一下与供应商之间可能需要支付的赔偿金额大概是多少。这里所说的“大概”，是为了在后续的谈判中有一个大致的参考，即使金额不准确，也足够了（如果因为等待确认具体金额而延迟表达解约意愿，那就本末倒置了）。

如果你确认的大概金额过高，你应该要求对方解释原因。但是，如果你为了降低支付金额而进行过度的谈判，可能会引发无意义的诉讼等，使情况进一步复杂化。如果双方谈判困难，你也可以考虑咨询律师。

另外，本文的讨论是基于已经达成系统开发合同的前提下进行的。但在实际的系统开发场景中，”合同是否有效成立”的问题也经常成为争议。关于这一点，我们在下面的文章中进行了详细的解释。

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

总结

本文主要解释了如何处理因用户原因中断项目的情况。然而，本文的重点是，我们需要考虑的是，“是否真的可以说是用户方的自身原因”，“供应商方是否真的没有过错”。

系统开发这样的项目特点是供应商和用户都承担着重大的责任。因此，如果不事先仔细考虑是否真的可以单方面归咎于对方，可能会导致更加火上浇油的情况，这是我们应该意识到的。