什么是系统开发订单方即用户端应承担的合作义务
![什么是系统开发订单方即用户端应承担的合作义务](https://monolith.law/zh-cn/wp-content/uploads/sites/44/2024/05/shutterstock_1059777902-1024x684-1.jpg)
系统开发的工作,随着被开发的系统规模的增大,需要投入的人力和工时也会相应增加。因此,在这里,不仅是承担开发的供应商方,对于发出系统开发订单的用户方也会有一定的合作义务。
这与通常的订单接收关系是不同的。例如,如果你向裁缝店订购定制西装,而不是IT系统,作为客户(用户)的订单方并没有特别的“义务”。承担“义务”的主要是接受订单的裁缝店(供应商)。正因为需要大量的人力和工时的IT系统,用户也需要与供应商“合作”,这就是其结构。
本文将解释关于系统开发这样的事情,不能仅仅依赖供应商,订单方有哪些法律义务。
既然是自家的系统,不能仅仅“全权委托”
即使是一个系统开发项目,也常常涉及到许多人和组织。不仅需要精通编码技术的工程师和程序员,为了将这些人员的成果整合成一个成果,项目经理的角色也变得非常重要。
然而,即使供应商拥有高技术能力和组织能力,也不可能仅凭供应商的力量完成系统开发。例如,只在公司内部使用的公司专用术语,以及公司特有的业务知识等,供应商只能通过单方面的努力来了解。大规模系统开发越是如此,一般趋势是,使用该系统的公司本身也是拥有许多员工和业务的大公司。为了使系统开发项目成功,实际上,在计算机工作之前,整理这些业务逻辑往往占据了大部分的权重。
因此,用户方不应该因为“我不是IT技术专家”而采取被动态度,反而应该积极提供信息,以使项目进展顺利。在这个意义上,用户在系统开发项目中的角色实际上并不小。
基于判例的用户方的合作义务是什么
![](https://monolith-law.jp/wp-content/uploads/2019/07/shutterstock_1013853733-1024x683.jpg)
那么具体来说,在系统开发项目中,用户方承担的合作义务是什么呢?关于这一点,过去的判例留下了许多线索。
在审判中,供应商方(被告)的交货期延迟,用户(原告)的决策延迟等因素,使得用户对开发的合作义务是否存在成为了争议点。对此,法院认定了用户方的合作义务违反,并否定了供应商方的债务不履行责任。(虽然合同的解除被承认,但也被认定了六成的过失抵偿。)
本案的电算系统开发合同是所谓的定制系统开发合同,这种定制系统开发合同,承包商(供应商)单独无法完成系统,委托人(用户)在开发过程中,需要准确地进行内部意见协调,统一观点,明确向承包商传达需要什么样的功能,与承包商一起,研究需要的功能,最终确定功能,进一步,确定屏幕和账单,验收成果物等角色分担是必要的。
东京地方法院平成16年(2004年)3月10日判决
本判决不仅表明系统开发本身是与用户方的共同工作,而且明确了“应在哪些具体点上合作”的问题,这似乎非常富有启示。
试着将上述判决文的文字翻译成系统开发的IT术语。
最终确定功能・・・ →需求定义:明确化想要制作的具有哪些功能的系统 |
确定屏幕和账单・・・ →基本设计:从系统操作者的角度设计系统的外观,如屏幕和账单等 |
验收成果物・・・ →测试:验证是否按照规格完成,与数据库转储等证据资料一起确认,接受交付。 |
可以这样整理。这些都是无论IT系统的专业性有多高,都不能单独完成的事情,需要用户的合作。需要的功能和屏幕布局应由用户明确,而且只有用户才能确认是否实现了所需的功能。
另外,就像供应商被赋予项目管理义务一样,用户也被赋予合作义务,如果用户在上述过程中违反合作义务,反过来,供应商可能会基于债务不履行或不法行为向用户提出损害赔偿请求。
对于事后规格变更的请求应如何理解
![](https://monolith-law.jp/wp-content/uploads/2019/07/shutterstock_357730949-1024x614.jpg)
再者,如果我们以系统开发项目是用户和供应商的共同工作为前提,那么我们可以进一步展开讨论。这就涉及到,“如果用户在事后要求添加或修改功能,从而导致无法按期交付,那么这究竟是谁的责任?”这样的问题。
系统开发通常是从需求定义开始,然后按照基本设计、详细设计、制造(程序实现)和测试的顺序进行,目标是尽可能避免回溯(通常被称为瀑布模型)。然而,由于某种原因,前期工作出现疏漏,导致工作回溯的情况在现实中经常发生。
在这种情况下,如果不能按期交付,我们应该如何看待呢?通过解读过去的判例,我们可以看出,根据额外工作发生的时间,结论可能会有所不同。
如果额外工作发生在外部设计等规格明确化之前
前述的判例指出,在基本设计阶段(程序实现阶段之前),用户提出的额外开发请求,并没有违反合作义务。
用户向供应商提出在基本设计工作中对要构建的系统的各种要求,这在系统开发的过程中是很正常的,而且,对于没有专业知识的原告用户来说,判断这些要求是否需要额外的委托费用或延长交货期限等,或者是否会对工作进程造成困扰,是很困难的。因此,不能说原告用户应该自我约束,不应提出可能导致额外委托费用或延长交货期限等的要求。相反,如果原告用户提出了需要额外委托费用或延长交货期限等的要求,那么负有项目管理义务的被告应该告知原告用户这一点,并寻求撤回要求或延长交货期限等的协商,以避免开发工作受到影响。
东京地方法院2004年(平成16年)3月10日判决
在这个判决中,法院同时指出,用户有一定的合作义务,但用户并不是系统开发的专家。也就是说,作为订单的用户,如果他们不是系统开发的专家,那么在系统内容明确之前,他们可能会提出各种各样的要求,甚至可能会要求修改交货期限等,这是可以理解的。
然而,这里对供应商的义务,实际上是指他们应该努力进行沟通,例如请求延期或者(如果不能改变交货期的话,建议撤回额外的要求)。因此,这并不意味着供应商有义务接受所有用户的要求,并按原定的日期交货,所以在这一点上需要注意。
如果额外工作发生在制造或测试工程的规格确定之后
如果我们反过来看看上述判决的内容,我们可以在一定程度上预测,如果是在规格已经确定之后的额外开发,结果会是什么。在这种情况下,这样的要求可能会被拒绝。确实,无论规格确定之前还是之后,用户和供应商对开发工作的理解程度都有很大的差距。
然而,如果在规格确定之后改变或增加订单内容,可能会强迫进行工作的重做。在这种情况下,对于由此产生的交货延迟,“因为是客户,所以提出各种要求是理所当然的”这种辩护往往很难站得住脚。更何况,如果有很多规格变更或功能添加在事后发生,那么这可能会引发疑问,即在事前已经完成的基本设计等上游工程中,用户是否违反了合作义务。
从这些考虑来看,对于一旦确定后进行的规格变更,如果这是导致交货延迟的原因,那么将其视为供应商的责任是不现实的。从前述的判决文中,我们可以合理地推断出这样的含义。
此外,这种判断往往不仅基于合同,还基于与系统开发进度相符的会议记录等证据。关于会议记录的详细解释,请参阅下面的文章。
相关文章:从法律角度看系统开发中的会议记录的记录方式[ja]
总结:重要的是不要忘记需求定义是用户端的过程
虽然需求定义是供应商端展示技术的地方,但首先,我们应该意识到这其实是用户端的业务。即使是由外部专家帮助建立的系统,只要它是公司自己使用的系统,那么在法律上,我们认为这应该是公司治理应该覆盖的领域。
如果用户端在开发过程中不合作,即使项目出现严重问题,法院也可能对用户端持严格的观点。这一点,我们首先应该认识到。
Category: IT
Tag: ITSystem Development