系统开发的估价金额能否在事后增加

系统开发这项工作，无论是下订单的用户方，还是接单的供应商方，都会涉及大量的人力，因此，要让所有人步调一致地推进项目并不容易。虽然不用说，计划性是极其重要的业务，但是，用户作为订单方能否将适当的信息整理好并简洁地传达给供应商，实际上并非如此。当开发过程进展到一定程度时，如果被要求更改规格或增加功能，能否在预先估计的金额上增加费用，对于接受工作的一方来说，这是非常关心的问题。

那么，这些权利在法律上在什么情况下会被承认呢？又或者，这些额外开发和功能修正的报酬金额应该如何确定呢？本文将对这些各种疑问进行整理。

首先，何时可以称之为附加开发和功能修正？

在系统开发项目中，接受工作的合同类型通常是承包合同或类似的委托合同。无论哪种合同类型，接受工作方应该做的事情（=义务）和随之而来的报酬（=权利）都会成对出现在合同中。因此，如果后来添加了不包含在报酬金额假设的工作中的工作，那么可以说这是附加开发和功能修正。相反，如果包含了这样的工作，那么将被视为按照最初的规格（=原有合同的范围）处理。

关于承包合同和类似委托合同的区别等，我们在另一篇文章中进行了详细解释。

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

然而，如果连屏幕上显示的字体的微调等都必须预先在规格中确定，那么所有这些都可以说是附加开发，这可能会严重阻碍顺畅的商业交易。因此，考虑到这些规格的详细讨论，实际上一刀切的划界并不容易。但是，如果要给出一般的指导原则，那么：

• 规格一旦确定，就被命令添加更多的功能
• 程序的实现已经完成，然后被命令进行修正

在这种情况下，这种主张在法律上有一定的合理性的可能性较高。

是否可以称为追加开发和功能修正成为了争议焦点的裁判例

肯定例：基本设计规格在事后被修改的案例

以下的案例是在事后对规格进行了修改。

软件开发过程包括①需求定义、②外部设计、③内部设计、④源程序的创建（程序设计、编码）、⑤各种测试（单元测试、组合测试、系统测试）等步骤（中略）初始规格（中略）是通过内部设计以后的工作来实现的，这是基于本次开发委托合同的报酬请求权和对价关系的业务范围。规格变更的申请在法律上被视为委托人超出初始合同业务范围的新的业务委托合同的申请，如果承接人没有提出额外工程费用，并在没有达成额外费用协议的情况下完成了额外委托的工作，那么就应理解为委托人和承接人之间达成了没有确定费用的新的承包合同，并产生了相当的额外开发费用支付义务。

大阪地方法院平成14年（2002年）8月29日判决

理解这个判决的关键是把握”对价关系”和”新的合同”这两个关键词。

另外，上述判决还提出了另一个非常有趣的观点。那就是，按钮的布局和文字的字体等非常详细的部分的微调并不属于这里所说的规格变更。相关内容如下：

然而，在软件开发中，由于其性质，外部设计阶段并不会决定到显示在屏幕上的文字的字体和按钮的布局等细节，对于这些细节，在规格确定后，通过当事人之间的讨论，通常会进行一定程度的修正，考虑到这一点，将这种对规格进行详细化的要求也视为规格变更是不合理的。

大阪地方法院平成14年（2002年）8月29日判决

判决文中使用了”规格的详细化”这个有趣的词汇。

• 已经确定的事项在后来被改变的情况
• 在进行过程中可以决定的事项，却没有明确决定而继续进行的情况

这可能也表明了，这两种情况在法律上的处理应该是不同的。

其他肯定的例子

此外，在被认定为附加开发和功能修正的案例中，包括：

• 交付的程序数量比最初的计划增加了约一倍的案例（东京地方法院2017年（公历）4月22日判决）
• 工作期间延长了约三倍的案例（东京地方法院平成22年（2010年公历）1月22日判决）

等等。从这样的整理中可以看出，工作期间的延长也被采纳为广义的附加开发，并且可以接受一定的法律保护。

「关于额外开发的协议和报酬增加」与「最初的合同成立」是两个不同的问题

关于这些问题的重要点是，

1. 「首先，两家公司之间是否正式达成了关于系统开发的合同（最初的合同）」的情况
2. 「一旦正式达成了关于系统开发的合同，是否又额外达成了关于额外开发的合同」的情况

在这些情况下，法院的判断标准是不同的。简单来说，法院：

• 对于1的情况，倾向于严格（在没有合同书的情况下，不容易承认合同的成立）
• 对于2的情况，倾向于相对宽松（即使没有关于额外开发的合同书，也会灵活地承认报酬增加等）

可以这么说。关于1的情况，我们在另一篇文章中详细解释了。

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

否定例：被视为包含在相同委托内容中的法律案例

然而，另一方面，也有一些法院判决并未承认报酬增加的案例。在以下引述的判决中，关于系统开发的合同，业务内容在签订业务委托合同后发生了变化，因此，是否应承认报酬的增加成为了争议焦点。

本案的争议点在于，（1）原告在本案合同中承接的业务内容是什么，（2）关于右承接业务，原告和被告之间是否达成了扩大规模并增加代金的协议，（省略）等问题。（省略）

首先，本案合同是一份承包合同，双方同意以合同金额作为原告承接业务（承包）的确定对价，关于承接业务的步骤数、单价等，只是原告在计算承包金额时的内部资料，步骤数的增加等情况与承包金额完全无关。（省略）

如前所述，原告的承接业务在昭和62年（1987年）2月25日被修改，只限于系统管理、承包工程费用计算和部分工具，其余部分由被告负责，右修改后的原告的业务仍在最初合同的开发业务范围内，并未发生变化，关于右业务的对价，本案合同最初确定的金额已经包含了所有的委托金额。

东京地方法院平成7年（1995年）6月12日判决

在该判决中，即使更改了由供应商承接的业务内容，但其开发内容仍在最初合同内容的范围内，因此，应由最初承诺的报酬来覆盖，这是法院的判断。

总的来说，报酬金额是基于预期要完成哪些工作而确定的，对于不包含在其中的工作，应采取承认额外报酬请求的立场。

而且，报酬金额是对完成哪些工作的对价，这并不仅仅是合同书，会议记录等也会作为证据进行判断。关于会议记录的重要性，我们在下面的文章中进行了详细的解释。

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

如何确定追加开发和功能修正的报酬金额

在系统开发的现场，一旦确定的规格后来发生变化的情况并不罕见。每次这样的事情发生时，都要准备新的书面合同，并进行合同事务，这在现实中可能并不现实。对于需要追加和修改的事项，再次确定其规格内容，如果可以总结并签订备忘录等，那就另当别论，但如果在这样的程序也无法进行的情况下项目突然停止，那么应该如何计算报酬金额呢？

在这种情况下，应参考的条款是以下引用的《日本商法》第512条（下划线部分是作者画的）。

《日本商法》第512条：商人在其业务范围内为他人行为时，可以请求适当的报酬。

在这个条款中，“适当的报酬”在具体场景中最终会变成多少，这是一个问题。从过去的判例来看，似乎采用了根据工作的工时、数量或期间比例，应承担其成本的观点。这可能是因为系统开发业务本质上是一种服务业，其基本成本是人力成本。

因此，尽管《日本商法》中“适当的报酬”这个词的抽象度相反，但在这种情况下估计追加报酬的金额并不需要太复杂的计算。以下，让我们来看几个判例。

案例1：承认了与工时增加成比例的额外报酬的实例

基于本案的规格更改，开发工时应视为上述工时的总和，即257.5人/天，这是合理的。如果将每人/天的开发成本按照本案的开发委托合同的相同金额，即32,500日元（在甲3中，单价为650,000日元[每人/月]，如果将一个月的工作日数定为20天，那么每人/天的开发成本就是32,500日元）进行换算，那么基于本案的规格更改请求的额外开发成本应为8,368,750日元，这是合理的。

大阪地方法院，平成14年（2002年）8月29日判决

“每人/天”是关键词。这表明了使用工时作为额外报酬计算的依据。

案例2：承认与程序数量成比例的额外报酬

在考虑本案中包含的额外部分的相应报酬金额时，计算机系统开发的主要成本是技术人员的人力成本，而这些人力成本大致与编写的程序数量成比例。因此，我们将初始合同金额2325万元除以完成的206个程序数量，得到每个程序的单价，然后将通过三次检查的414个程序数量乘以这个单价，得出4672.5728万元（23,250,000÷206×414=46,725,728）的金额，我们认为这是合理的。

东京地方法院平成17年（2005年）4月22日判决

虽然出现了很多数字，但如果你冷静地阅读，你会发现并没有进行复杂的计算。基于最初的合同内容，我们确认了”每个程序的单价是多少”，然后只是进行了简单的”单价×数量”的乘法运算。

案例3：承认与期间长度成比例的额外报酬的实例

在甲3合同中，原告自平成17年（2005年）1月至3月的3个月的工作作为准委托的对价，规定了6000万日元。然而，从同年4月开始的工作中包含了无偿的工作，与前一年相同，预计同年4月开始的新学期由于课程注册等系统的运行，工作量将增加。从这些情况来看，基于上述3个月的工作对价设定的6000万日元，原告自平成17年（2005年）4月至9月的6个月的工作报酬，设定为1亿2000万日元是合理的。

东京地方法院平成22年（2010年）1月22日判决

上述判决表明，对于延长的期间，也应使用简单的比例计算来计算额外的报酬。

总结

如上所述，通过列举一些判例，我们可以看到程序员和工程师的额外报酬在法律上的处理似乎有一定的规律和共性。也就是说，原则上，我们应该根据较为客观的指标，如投入的工时、（交付的程序等的）形式化的工作量、工作时间或期间等，尽可能简单地进行计算。

从严格意义上的程序化或完美的工时估计实际上失败，因此产生了这种额外的开发或功能修复，考虑到这一点，只要投入了人力，或者完成了形式化的工作量，或者投入了时间，就会产生额外的报酬，这可能听起来很无趣。然而，从承包方的角度来看，即使我们的目标是优先考虑客户的利益，这种权利在法律上被认可的可能性也是有意义的，这可能是一种危机管理的观点。