在系统开发中,承包合同的工作完成是什么

系统开发通常是一个长期的过程，而且经常会有多次的规格更改和额外功能的实施要求，这可能会让接受工作的供应商陷入看不到出路的困境。对于这样的供应商来说，“到底需要做到什么程度才算完成了我们的工作”这个问题，有时可能会成为他们切实的困扰。

而且，系统开发往往是通过承包合同进行的，承包合同是以“工作的完成”为目标的合同。

本文将从法律的角度解释，“在什么时机，做到什么程度的系统开发，才算是完成了工作”这一问题。

什么是系统开发的完成

对于技术人员来说，系统开发的完成意味着什么

在系统开发的现场，如果有人问“系统开发何时完成”，一般的回答可能是“当测试阶段结束并交付成果物时”。确实，一般的系统开发流程从需求定义开始，包括梳理应实现的功能内容等，然后创建各种设计文档，进行程序实现，最后确认系统是否正常运行的测试阶段结束，以用户方的验收为结束，这是基本的流程。

因此，从具体业务参与的技术人员的角度来看，“系统开发的完成=验收合格”这样的理解应该是普遍的。

从法律角度看系统开发的完成

另一方面，从法律角度来看，如果问系统开发何时完成，那么讨论的核心自然是供应商在合同上承担的法律义务在何时何种情况下可以说是完成。首先，系统开发的合同基本上可以分为承包合同和准委托合同。

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

关于这两种合同类型的区别的解释，我将在上面的文章中进行，但如果从系统开发完成，即供应商方承担的债务履行的角度来说，其判断标准的条款分别如下：

承包合同：日本民法第632条
第632条
承包是当事人一方约定完成某项工作，另一方约定支付该工作结果的报酬，从而产生效力。
准委托合同：日本民法第648条
第648条
1.如果没有特别约定，受托者不能向委托者请求报酬。
2.受托者在应得报酬的情况下，除非履行了委托事务，否则不能请求报酬。但是，如果按期间确定报酬，则适用第624条第2款的规定。
3.如果委托因受托者无法归责的原因在履行过程中终止，受托者可以按已履行的比例请求报酬。

系统开发的完成问题主要出现在承包合同

然而，不仅限于系统开发的情境，“工作完成的时间点是什么时候”这个问题基本上出现在承包合同中。在准委托合同的情况下，与其说是以带来特定结果或成果为债务履行，不如说是作为具有专业性的人才，在具有一定的自由裁量权的基础上，（无论结果如何）做应该做的事情，这是一种强调意义的合同类型。在准委托合同的条文中，即使预期的成果物没有完成，只要事务处理本身进行得适当，也可以请求报酬（第648条第2款），如果由于受托者无法归责的原因在履行过程中终止，也可以按比例请求报酬（第648条第3款）。承包合同重视“结果”，准委托合同重视“过程”，也可以这样说。

因此，在准委托合同中，更可能出现的法律问题是在执行委托业务过程中的“注意义务”。也就是说，当被寄予高度信任的前提下，基于委托合同的注意义务违反可以追究的是什么情况。

另一方面，承包合同中重要的是“工作的完成”。如果应完成的工作没有完成，供应商方的债务履行就无法实现，原则上也无法请求报酬。但是，如果已经完成，那么没有必要特别关注过程中的问题。因此，“系统开发项目何时完成”这个问题基本上可以说是承包合同中“工作的完成”这个词的法律解释问题。

何时可以称为系统开发工作的完成

那么，我们应该在何时具体考虑到所谓的“工作完成”的时机呢？让我们来看一下过去的判例。

关于工作完成的判例

以下引述的判例中，供应商交付的系统后来在处理速度和通信费用等方面出现了问题。尽管发现了这些问题，但由于开发过程本身已经全部完成，因此争论的是是否可以称之为“工作完成”。结果显示，工作的完成本身是被接受的。

《日本民法》第632条和第633条规定，对于承包人向订购者支付报酬的时间，应当是承包人完成工作，并向订购者交付工作目标物的时候。另一方面，该法第634条规定，如果工作目标物有瑕疵，承包人对订购者承担保证责任（第1款），并且在承包人履行其对工作目标物瑕疵的保证责任之前，订购者有权拒绝支付报酬（第2款）。根据这些《日本民法》的规定，法律区分了工作结果不完全的情况，即工作目标物有瑕疵的情况和工作未完成的情况，即使工作目标物存在瑕疵，无论这些瑕疵是隐藏的还是显现的，都不应认为工作未完成。
因此，关于承包人是否完成工作，应以工作是否完成了最初承包合同预定的最后工序为标准，订购者在承包人完成工作的最后工序并交付目标物时，不能仅仅因为工作目标物有瑕疵就拒绝支付承包费用。

上述判决认为，“工作完成”是满足了系统开发的最后工序的要求。对于供应商制作的系统存在的不足（在法律上通常称为“瑕疵”），作为救济措施，已经另外准备了瑕疵保证责任制度。

因此，即使将“工作完成”的概念稍微宽泛地解释，最终也不会对用户方造成不公平。总结如下：

【承包合同中的债务=工作完成=所有工序的完成】
＝＝＝＝＝＝＝＝＝＝＝
如果工作没有完成……
↓
【承担不履行责任】
＝＝＝＝＝＝＝＝＝＝＝
即使工作完成但存在不足……
↓
【在承认债务履行的同时，存在瑕疵保证责任问题】

上述判例显示了如何划分这些问题。

然而，关于“工作完成”的问题，我们可以从“用户方的验收合格”的角度改变视角进行考察。关于用户方验收不顺利的法律问题，我们在另一篇文章中进行了解释。

https://monolith-law.jp/corporate/estimated-inspection-of-system-development[ja]

法律工作完成的含义

在系统开发中，如果“工作完成”得到认可，那么就意味着债务已经履行，因此不会再被追究“债务不履行”的责任。如果是承包合同，除非工作完成，否则无法请求报酬，即使在特别约定中约定了预付款等，这些基本上也必须退还。另一方面，如果工作完成的事实得到认可，那么供应商只需要承担瑕疵担保责任和合同上的质量保证问题。

供应商从债务不履行责任中解脱，意味着用户方解除合同的余地将大大减小。这是因为基于瑕疵担保责任的合同解除，仅限于无法实现合同目标的情况。如果合同被解除，供应商也会失去请求报酬的权利（简单来说，就是不再有报酬），因此在实际操作中，围绕“工作完成”容易引发争议。

关于系统开发合同的“解除”，我们在以下文章中进行了详细的解释。

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

关于工作完成的注意事项

如何看待规格更改和附加开发

对于供应商来说，可能会遇到这样的情况，即“虽然已经能够满足最初提出的规格，但是却被要求更改规格或增加功能，即使想要结束工作，也无法找到一个合适的结束点”。在这种情况下，也会出现“何时结束系统开发”的问题。关于这个问题的详细解释，请参阅以下文章。

https://monolith-law.jp/corporate/increase-of-estimate[ja]

也要注意民法的修订

此外，基于承包合同的瑕疵担保责任规定，由于传统条款之间的联系复杂且难以理解，因此这是一个受到民法修订影响较大的领域。在民法被修订的过程中，关于如何理解“瑕疵”的问题，我们在以下的文章中进行了详细的解释。

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

总结

在本文中，我们对于那些可能会陷入“看不到出路”的系统开发项目，阐述了如何将其与“工作完成”的法律理论相联系的路径。每个项目的出路可能会因开发要求而异，但是，一旦围绕这些问题发生争议，法律上的“工作完成”概念往往能成为指导的线索。我们认为这种情况并不少见。