什么是系统开发订单方即用户端应承担的合作义务

系统开发的工作，随着被开发的系统规模的增大，需要投入的人力和工时也会相应增加。因此，在这里，不仅是承担开发的供应商方，对于发出系统开发订单的用户方也会有一定的合作义务。

这与通常的订单接收关系是不同的。例如，如果你向裁缝店订购定制西装，而不是IT系统，作为客户（用户）的订单方并没有特别的“义务”。承担“义务”的主要是接受订单的裁缝店（供应商）。正因为需要大量的人力和工时的IT系统，用户也需要与供应商“合作”，这就是其结构。

本文将解释关于系统开发这样的事情，不能仅仅依赖供应商，订单方有哪些法律义务。

既然是自家的系统，不能仅仅“全权委托”

即使是一个系统开发项目，也常常涉及到许多人和组织。不仅需要精通编码技术的工程师和程序员，为了将这些人员的成果整合成一个成果，项目经理的角色也变得非常重要。

然而，即使供应商拥有高技术能力和组织能力，也不可能仅凭供应商的力量完成系统开发。例如，只在公司内部使用的公司专用术语，以及公司特有的业务知识等，供应商只能通过单方面的努力来了解。大规模系统开发越是如此，一般趋势是，使用该系统的公司本身也是拥有许多员工和业务的大公司。为了使系统开发项目成功，实际上，在计算机工作之前，整理这些业务逻辑往往占据了大部分的权重。

因此，用户方不应该因为“我不是IT技术专家”而采取被动态度，反而应该积极提供信息，以使项目进展顺利。在这个意义上，用户在系统开发项目中的角色实际上并不小。

基于判例的用户方的合作义务是什么

那么具体来说，在系统开发项目中，用户方承担的合作义务是什么呢？关于这一点，过去的判例留下了许多线索。

在审判中，供应商方（被告）的交货期延迟，用户（原告）的决策延迟等因素，使得用户对开发的合作义务是否存在成为了争议点。对此，法院认定了用户方的合作义务违反，并否定了供应商方的债务不履行责任。（虽然合同的解除被承认，但也被认定了六成的过失抵偿。）

本案的电算系统开发合同是所谓的定制系统开发合同，这种定制系统开发合同，承包商（供应商）单独无法完成系统，委托人（用户）在开发过程中，需要准确地进行内部意见协调，统一观点，明确向承包商传达需要什么样的功能，与承包商一起，研究需要的功能，最终确定功能，进一步，确定屏幕和账单，验收成果物等角色分担是必要的。

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

本判决不仅表明系统开发本身是与用户方的共同工作，而且明确了“应在哪些具体点上合作”的问题，这似乎非常富有启示。

试着将上述判决文的文字翻译成系统开发的IT术语。

可以这样整理。这些都是无论IT系统的专业性有多高，都不能单独完成的事情，需要用户的合作。需要的功能和屏幕布局应由用户明确，而且只有用户才能确认是否实现了所需的功能。

另外，就像供应商被赋予项目管理义务一样，用户也被赋予合作义务，如果用户在上述过程中违反合作义务，反过来，供应商可能会基于债务不履行或不法行为向用户提出损害赔偿请求。

对于事后规格变更的请求应如何理解

再者，如果我们以系统开发项目是用户和供应商的共同工作为前提，那么我们可以进一步展开讨论。这就涉及到，“如果用户在事后要求添加或修改功能，从而导致无法按期交付，那么这究竟是谁的责任？”这样的问题。

系统开发通常是从需求定义开始，然后按照基本设计、详细设计、制造（程序实现）和测试的顺序进行，目标是尽可能避免回溯（通常被称为瀑布模型）。然而，由于某种原因，前期工作出现疏漏，导致工作回溯的情况在现实中经常发生。

在这种情况下，如果不能按期交付，我们应该如何看待呢？通过解读过去的判例，我们可以看出，根据额外工作发生的时间，结论可能会有所不同。

如果额外工作发生在外部设计等规格明确化之前

前述的判例指出，在基本设计阶段（程序实现阶段之前），用户提出的额外开发请求，并没有违反合作义务。

用户向供应商提出在基本设计工作中对要构建的系统的各种要求，这在系统开发的过程中是很正常的，而且，对于没有专业知识的原告用户来说，判断这些要求是否需要额外的委托费用或延长交货期限等，或者是否会对工作进程造成困扰，是很困难的。因此，不能说原告用户应该自我约束，不应提出可能导致额外委托费用或延长交货期限等的要求。相反，如果原告用户提出了需要额外委托费用或延长交货期限等的要求，那么负有项目管理义务的被告应该告知原告用户这一点，并寻求撤回要求或延长交货期限等的协商，以避免开发工作受到影响。

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

在这个判决中，法院同时指出，用户有一定的合作义务，但用户并不是系统开发的专家。也就是说，作为订单的用户，如果他们不是系统开发的专家，那么在系统内容明确之前，他们可能会提出各种各样的要求，甚至可能会要求修改交货期限等，这是可以理解的。

然而，这里对供应商的义务，实际上是指他们应该努力进行沟通，例如请求延期或者（如果不能改变交货期的话，建议撤回额外的要求）。因此，这并不意味着供应商有义务接受所有用户的要求，并按原定的日期交货，所以在这一点上需要注意。

如果额外工作发生在制造或测试工程的规格确定之后

如果我们反过来看看上述判决的内容，我们可以在一定程度上预测，如果是在规格已经确定之后的额外开发，结果会是什么。在这种情况下，这样的要求可能会被拒绝。确实，无论规格确定之前还是之后，用户和供应商对开发工作的理解程度都有很大的差距。

然而，如果在规格确定之后改变或增加订单内容，可能会强迫进行工作的重做。在这种情况下，对于由此产生的交货延迟，“因为是客户，所以提出各种要求是理所当然的”这种辩护往往很难站得住脚。更何况，如果有很多规格变更或功能添加在事后发生，那么这可能会引发疑问，即在事前已经完成的基本设计等上游工程中，用户是否违反了合作义务。

从这些考虑来看，对于一旦确定后进行的规格变更，如果这是导致交货延迟的原因，那么将其视为供应商的责任是不现实的。从前述的判决文中，我们可以合理地推断出这样的含义。

此外，这种判断往往不仅基于合同，还基于与系统开发进度相符的会议记录等证据。关于会议记录的详细解释，请参阅下面的文章。

相关文章：从法律角度看系统开发中的会议记录的记录方式[ja]

总结：重要的是不要忘记需求定义是用户端的过程

虽然需求定义是供应商端展示技术的地方，但首先，我们应该意识到这其实是用户端的业务。即使是由外部专家帮助建立的系统，只要它是公司自己使用的系统，那么在法律上，我们认为这应该是公司治理应该覆盖的领域。

如果用户端在开发过程中不合作，即使项目出现严重问题，法院也可能对用户端持严格的观点。这一点，我们首先应该认识到。