系统开发结束后,供应商需要承担的支持义务是什么

在系统开发中，众所周知，专业的系统开发供应商（Vendor）需要承担”项目管理责任”，但在法律上，还有一个类似但不同的概念，即”支持责任”。在本文中，我们将结合过去的判例等，对这个”支持责任”进行解释。

什么是支持义务

支持义务概述

在谈到供应商对用户的义务时，典型的义务包括项目管理义务。这是在过去的判例中反复提及并得到确立的，是作为系统开发专家的供应商对一系列项目所承担的义务的总体概念。

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

项目管理义务是非常著名的系统开发法律术语，毫无疑问，它是供应商承担的主要义务。然而，在一些判例中，存在着与项目管理义务不同的义务，即“支持义务”。

支持义务是针对用户的运营支持问题

那么，什么是支持义务呢？为什么它需要被特别地以不同于项目管理义务的名称来称呼呢？支持义务通常在系统开发结束后的场景中成为问题。系统开发项目，由于其项目性质为“开发”，因此，基本的思路是，一旦应开发的系统完成，项目就结束了。也就是说，明确应开发的系统是什么（即需求定义），并确认它是否已经完成（即测试或验收），这就是系统开发项目。关于验收这个过程，考虑到它作为“系统开发项目的结束”具有重要的意义，关于在这个阶段容易出现的法律问题，我们在下面的文章中进行了详细的讨论。

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

然而，即使我们理解系统开发项目是新系统的开发过程本身，开发的系统在之后的业务中被利用也是一个自然的前提。也就是说，如果我们完全忽视了系统开发后如何利用该系统的问题，并且只要我们在开发工作中，只要我们做出了产品，就可能产生大的不合理性。考虑到这些因素，在过去的判例中，也对供应商是否应承担一定的运营支持义务提出了问题。也就是说，是否应该认为供应商在系统开发合同中承担的义务中，也包含了开发后的运营支持义务。由于运营支持不是开发过程本身，因此为了与项目管理义务区分，我们认为这就是“支持义务”这个词被使用的原因。

关于支持义务问题的判例

在系统测试阶段，用户业务实施受阻的案例

在以下引述的判决中，用户在系统运行前进行的系统测试中，无法像最初预期的那样利用系统，结果导致用户放弃了系统的运行。这是用户在开始运营时遇到的问题，从之前签订的系统开发合同中，如何确定供应商的责任成为了问题。最后的结论是，承认了用户方的损害赔偿请求，其依据是指出了“违反支持义务”。

一、违反支持义务
（1）原告代表在平成九年（1997年）七月十四日向被告表示，“不仅要制作系统，还希望你们能一直负责到系统能正常运行。”、“我们是外行，既然付了高价，就希望你们能让系统一直能用。”对此，被告解释说，可以构建能实现原告引入目标的系统，并承诺会一直支持到系统能正常使用。因此，原告和被告之间达成了一致，即被告会一直支持到原告能正常使用本系统。
被告对原告承担支持义务，从本案承包合同的代金中，“包装引入支持”这一项中计入了一千七百二十六万的费用，以及在报价单中，关于月度维护费，“引入后六个月免费维护”被记载，以及在标题为“关于未来SE支持（内部讨论资料）”的文件中，关于生鲜订单，“制定引入步骤（计划）”和“数据/运营验证工作”可以接受SE支持，这一点已经得到确认。

（2）然后，被告对原告承担的支持义务具体包括，至少在原告本系统正式运行之前，被告对原告，①提供关于本系统运营方法的适当建议，②参与运营测试并处理在运营测试中出现的系统问题，③根据运营测试结果改进系统，④对操作员进行引入教育。
然而，被告在运营测试中出现大量问题时，只是将其归咎于操作员的熟练度问题，并没有认真对待，只是要求支付操作员的引入教育费用，没有对原告提供任何适当的支持以便向正式运行过渡。

东京地方法院八王子支部平成15年（2003年）11月5日判决

在这个判决中，包括目录在内的整个判决书中，“支持”这个词出现了大约30次。用户要求适当支持的声音直接记录在判决书中，可以看出在详细考虑案件经过的同时，也在寻求公平的解决。此外，对于本案的理解，特别值得注意的是：

• 违反支持义务被视为“债务不履行”的一部分，因此被命令赔偿由此产生的损害
• 在整个判决书中，没有一次使用“项目管理义务”这个词

尽管它是与项目管理不同的概念，但是可以看出，他们试图将其视为系统开发合同所包含的合同义务。

我们应如何理解支持义务的性质

支持义务的概念尚不明确

前述的判例基本上表明，进行系统开发的供应商应同时提供用户开始运营所需的支持。然而，与项目管理义务相比，关于支持义务的判例积累等并不丰富，了解其实质的线索也不多，这是当前的现状。特别是，“支持”这个术语本身也包含一个问题，即具体应做什么并不明确。

支持义务并非无限制地被认可

此外，承认供应商违反支持义务的上述判决，也同时揭示了一个非常重要的点。

被告根据本案承包合同，对原告构建和交付的系统，被认为有义务提供原告运营所需的一定支持。然而，其内容并不被认为是原告主张的那样，无期限地，直到原告实际能够运营本案系统为止，免费提供所有支持。

东京地方法院八王子支部2003年（平成15年）11月5日判决

如果接受的业务主要是系统“开发”，那么应该进行的“运营”支持也自然有限制。这可能是指出了这一点。在本判决中，也引用了寻求支持的用户的声音，提到了预先估计的内容，提到了是否有特约进行支持等问题，可以看到一些特色。也就是说，考虑到如果支持义务的概念无限制地扩大，将给供应商方带来重大负担，因此对义务违反的认定本身也应该谨慎进行。

支持义务的实质应与用户的合作义务一起考虑

到目前为止的讨论基本上是关于“在系统开发的运营初期阶段，用户和供应商应如何共同承担业务负担”的问题。其中确实包含了从“开发”合同到供应商在运营开始时承担多大的法律义务这一稍微复杂的问题。同时，也必须强调需要根据具体情况进行判断的趋势。

然而，供应商承担的支持义务的实质是什么，通过理解用户承担的合作义务，可以认为会变得更加确定。

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

首先，通过新系统改进业务的努力，有技术专家的供应商和拥有公司业务知识的用户的共同工作的一面。因此，对于所谓的支持义务，通过明确用户作为“履行合作义务”的一部分应通过自助努力解决的问题，其范围在很多情况下也会自然确定。

总结

在本文中，我们在基础的项目管理知识的基础上，对“支持义务”这一衍生概念进行了整理。虽然“支持义务”的概念仍有许多模糊的地方，但我们认为，理解这一概念的关键仍然在于基础的事项，如“项目管理义务”和“合作义务”等。