如果系统开发的报酬未支付,相关的法律是什么?

对于承接系统开发业务的供应商来说，可能最大的风险就是“尽管已经交付，但用户不支付报酬”的情况。由于系统开发的成本大部分是由具备技能的程序员等人才构成的，因此往往会产生大量的人力成本。如果销售收入的回收出现滞后，有时可能会成为生死攸关的问题。本文将从法律的角度，针对用户不支付报酬的情况，讨论供应商应考虑的事项。

首先，需要确认是否可以申请报酬

• 尽管供应商已向用户交付了成果物，但用户不接受交付，导致申请报酬的工作也停滞不前
• 尽管认为验收已经完成，但用户的认识存在某种差异，不愿意支付报酬

这种情况在现实中是完全可能发生的。

此外，用户检查完成的系统规格并接受交付，在系统开发的术语中，被称为”验收”。关于验收的意义，以及当其进展不顺时应考虑的问题，我们在下面的文章中进行了详细解释。

相关文章：系统开发的验收和假定验收条款的适用场景[ja]

虽然关于验收本身的全面解释将在上述文章中进行，但从法律上来说，是否可以说用户的验收已经完成，需要考虑”假定验收条款”的规定。

考虑到这一点，如果用户不支付报酬，首先应考虑的问题可能是以下几点：

1. 工作是否已经完成，或者还未完成
2. 是否可能适用瑕疵担保责任（日本民法第635条）

之所以首先要确认上述两点，是因为如果工作已经完成，并且预先确认了瑕疵担保责任（日本民法第635条）不适用，即使提起诉讼，也不能期待得到报酬的支付。

那么，具体来说，供应商方的负责人应该查看哪些内容来考虑上述两点呢？下面，我们来看看需要确认的文件有哪些。

为了查明是否可以请求报酬，应确认的文件是什么

关于如何管理应开发的系统的规格变更，以及变更管理文档的编制方法等，我们在另一篇文章中进行了详细的解释。

相关文章：从法律角度看，系统开发中的变更管理应如何进行[ja]

接下来，确认可以申请多少报酬

关于可以申请多少报酬，原则上应在合同中有所记载。然而，如果在事后进行了规格更改等操作，也可能会出现没有留下完整合同（或类似文件）的情况。关于基于规格更改、功能添加等后发原因的估算重新计算方法，我们在以下文章中进行了详细解释。

相关文章：系统开发的估算金额是否可以在事后增加[ja]

虽然估算的重新计算方法如本文所述，但特别是从考虑是否可以增加申请金额的角度来看，

1. 是否有关于附加开发、功能修正部分的估算书及其内容
2. 用户对估算书的反应内容
3. 是否有关于在任务管理列表中记录的附加开发、功能修正产生的情况以及其金额的协议

将会以这些点为中心进行考察。关键是要调查是否可以说在“以该金额下达业务订单”的点上，与用户方的意愿是否一致（也就是说，是否可以说合同已经成立）。

最后，我们来探讨实际进行诉讼时的关键问题

注意可能会遭到反诉的风险

在系统开发中，无论是用户还是供应商，一方向另一方提起诉讼，往往会遭到对方的反诉。也就是说，如果用户拒绝支付报酬，那么用户方也可能有一些理由。

首先，系统开发中，用户方也有各种合作义务，但首先，我们不能忘记供应商作为系统开发专家，具有广泛的自由裁量权和重大责任。关于供应商在系统开发中承担的项目管理义务，我们在以下文章中进行了详细解释。

相关文章：系统开发中的项目管理义务是什么[ja]

因此，关于是否可以归咎于单方面拒绝支付报酬的用户方，这是需要事先仔细考虑的问题。从过去的判例来看，最初由供应商提出报酬请求并提起诉讼，但用户反过来提出恢复原状的义务和赔偿请求的案例是很常见的。

也需要考虑是否真的有商业利益

即使供应商的主张被接受，并且在诉讼中确认实际上可以请求报酬，但如果事态升级到诉讼，那么预计未来的交易将实际上变得困难。此外，即使在诉讼中自己的主张被接受，但实际收到报酬可能需要相当长的时间，这也是需要做好准备的。考虑到进行诉讼所需的时间和成本并不小，可能更多的情况下，努力寻找妥协的点会更为稳妥和合适。

总结

当用户不按照约定支付报酬时，我们需要法律上的审查，这就需要确认多种类型的文件。此外，不仅仅是需要做好文件管理，还需要考虑如果最终决定进行诉讼，组织会面临哪些风险和劣势。

日常的文件管理确实通常属于现场级别的工作。然而，一旦决定根据存储的文件和资料进行诉讼，这可能成为重大的管理决策。在这种非常规情况下，现场和管理层的团结和组织力将受到考验。因此，我们应该理解这一系列的流程。