系统开发的交付延迟与法律上的履行迟延的关系

所谓的系统开发项目，在某种意义上总是与交货期限的战斗。从法律的角度来看，我们可以考虑一下如果万一不能按时交货，那么可能会出现的风险。

本文将解释这种“交货延迟”在何种情况下会被视为履行迟滞，并可能导致债务不履行等法律责任。

系统开发中的交货期限是什么

一般来说的交货期限

一般来说，“交货期限”是指为了交付客户要求的产品所设定的期限。即使在开发现场，也可能会遭遇意外的问题，但交货期限往往需要严格遵守。在接单方和发单方之间存在力量差距的情况下，严格遵守交货期限的趋势可能会更加明显。或者，如果交货期限延迟，可能会根据超出的部分进行折扣，或者将超出的工作部分免费。无论如何，交货期限通常被视为维护与交易伙伴的信任关系的重要因素。

关于法律上的“工作完成”概念和交货期限，我们在另一篇文章中也有解释。

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

从法律角度看交货期限

从法律角度看，首先，当供应商和用户签订合同时，供应商就有义务（=债务）交付系统。然后，设定了对这个债务履行的时间限制，就可以说是交货期限。也就是说，交货期限的延迟可以说是债务不履行的一种类型，也就是履行迟延。因此，对于由供应商的故意或过失导致的交货期限延迟，将承担由履行迟延导致的债务不履行责任（日本民法第412条）。

1.当债务的履行有确定期限时，债务人从该期限到来时开始承担迟延责任。
2.当债务的履行有不确定期限时，债务人从知道该期限到来时开始承担迟延责任。
3.当债务的履行没有设定期限时，债务人从接到履行请求时开始承担迟延责任。

日本民法第412条

这条法文中所说的“承担责任”，简单来说，就是赔偿损失的责任。

当债务人不按照债务的本旨履行时，债权人可以要求赔偿由此造成的损失。当债务人因应归责于自己的原因而不能履行时，也同样适用。

日本民法第415条

此外，如果用户向供应商设定了“相当的期间”，并催告其在该日之前交付，但供应商未能交付，用户可以解除合同。

当一方当事人不履行其债务时，对方可以设定相当的期间并催告其履行，如果在该期间内没有履行，对方可以解除合同。

日本民法第541条

关于这种情况下的“解除”选项的一般解释，我们在下面的文章中进行了详细的解释。

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

并非所有的交付延迟都构成法律上的违约

然而，“未能按期交付”的表面事实，并不一定意味着违约的履行延迟。为了使单纯的交付延迟成为法律上的履行延迟，需要满足以下一些条件。

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

另外，由于系统开发通常是用户和供应商双方承担义务的项目，可能会有供应商和用户都被认定为违反义务，损害赔偿被抵消的情况。

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

再者，通常在交付期限临近时进行的是成果物的“验收”。关于验收，我们在以下的文章中进行了详细的讨论。在这里，我们将解释用户不接受验收导致交付未完成的情况。

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

话题的要点是，“未能按期交付＝违约”并不是那么简单。虽然我们说交付延迟，但可能是供应商的原因，也可能是用户的原因，原因可能有各种各样。形式上的“截止日期延迟”和实质上构成违反义务的“履行延迟”在概念上有很大的差距。

关于履行迟滞的判例

以下，我们将探讨一些因交货期延迟而产生的，关于是否可以追究基于履行迟滞的债务不履行责任的判例。尽管这是关于交货期的争议，但其本质是”用户的合作义务”和”项目管理义务”，基于系统开发基础的案件整理的重要性，并无不同于其他争议。

用户违反合作义务与过失抵消的履行迟滞案例

在以下引述的判决书中，由于供应商的交货期延迟，用户作为原告提起了诉讼。这个诉讼在一定程度上得到了法院的接受，但同时，也指出用户方没有提供适当的合作是其中的一个原因，因此，由于交货期延迟造成的损害的40%应由用户负责。

根据以上的讨论，原告用户在被告要求解决悬而未决的问题时，没有在目标期限内解决，没有做出适时适当的决定，可以说没有提供适当的合作。然而，对于原告用户关于被告违反对功能添加或更改请求的合作义务的主张，虽然可以承认原告用户实际上在本案基本设计书中提出了开发内容的添加，更改等要求，但不能说这构成了原告用户违反合作义务，被告的主张没有理由。对于被告关于原告用户过度要求的合作义务违反的主张，也不能承认原告用户根据本案计算系统开发合同等的委托费提出过度的要求，没有理由。
相反，被告在平成11年（1999年）1月以后才了解到处理数量（在同年7月或8月的”处理”数量），在同年5月31日以后提出了不合理的额外委托费用负担和处理减少的要求，可以说被告的项目管理存在不适当的地方。

东京地方判决，平成16年（2004年）3月10日

上述判决认定了供应商的交货期延迟属于履行迟滞，但其原因部分在于用户没有解决供应商提出的关注问题等，因此，对用户主张的损害的60%进行了”削减”，承认了用户的请求。这是一种”过失抵消”的处理，与交通事故中双方都有过错的情况相同。

在这个判决书中，包括目录在内的全文中，“合作义务”一词出现了40多次。从法律上的论点来看，供应商的项目管理义务和用户的合作义务的划分才是本质问题。

完全确认履行迟滞的判例

以下引述的是一份判决书，其中，供应商方面的责任完全被证实，因交货延迟而被确认为履行迟滞的债务不履行责任。在本案中，由于用户在系统完成之前解除了合同，供应商方面提起了诉讼，但用户认为延迟交货是原因，因此引发了争议。

被告对设计系统进行了各种更改指示，因此，一定程度的完成延迟是无法否认的。特别是被告在平成17年（2005年）6月23日也给出了最终的更改指示，因此，根据该指示，”自动计算侧石明细项”功能尚未完成，这不能归咎于原告。
然而，除此之外，被告的更改指示是在同年4月初给出的，并且，如认定的那样，（省略）没有确认到设计系统完成计划的更改情况（除去被告在同年6月23日的更改指示部分）。
原告在平成17年（2005年）6月末，除去上述同月23日的更改指示部分，设计系统并未完成到可以实际运行的程度，如图片无法显示或搜索功能无法运行等系统的重要部分尚未完成。
（省略）可以看出，原告在系统开发过程中并未充分管理工作流程。
因此，不能认为原告无法遵守交货期的主要原因在于被告的指示，也不能认为原告没有应负的责任。

东京地方裁判所平成19年（2007年）2月16日

在本判决中，对于在交货期约一周前出现的规格更改指示等问题，判决指出，这个功能的未完成不能归咎于供应商。然而，

• 对于几个月前发出的更改指示尚未回应的问题
• 自上述指示发出后，供应商也发出了完成预定日的邮件
• 未完成部分是系统的重要部分，如图片显示和搜索功能的实现等，这些未能回应的问题是项目管理义务违反的证据

考虑到这些因素，确认了基于履行迟滞的债务不履行。

从两个判决中可以得出的结论

基于这两个判决，我们可以说，在系统开发中，“交付期限”的问题，归根结底是如何划定用户的合作义务和供应商的项目管理义务的边界的问题。也就是说，从法律上来看，履行迟延是债务不履行责任的一种，因此，是否存在供应商方面的任何义务违反自然成为了争议焦点。然后，为了考虑明显出现的损害事实（即用户方面因交付期限延迟而产生的损失）是否可以归咎于供应商，同时也需要考虑如何理解用户方面的合作义务。

总结

当我们听到”履行迟滞”这个词，从字面意思上看，确实可能会误以为这只是”交货期延迟”这一形式事实的另一种说法。然而，履行迟滞实际上是债务不履行的一种形式。因此，更适合将其理解为”违反项目管理义务”。

在系统开发项目中，”交货期”的问题不应仅仅局限于交货期的前后，而应将其转化为供应商的项目管理义务和用户的合作义务的问题进行整理。这被认为是非常重要的。