受托开发与运维合同该如何签订——从IPA《标准交易与合同范本》学习准委托与承揽的区分使用

「明明签的是整体承揽合同，需求还没定下来开发就开始了，最后因为”什么算完成”吵得不可开交」

「虽然签了按月付费的运维合同，但双方对运维范围的理解并不一致」

「拿到报价后被告知”需求定义阶段要签准委托合同”，但不明白为什么要按阶段拆分合同」

在系统开发外包中，很多纠纷的根源并非技术问题，而是合同的形式。

其实，针对这个问题，官方已经准备好了一份”范本”，那就是IPA（独立行政法人信息处理推进机构）发布的《信息系统标准交易与合同范本》。

本文将以这份标准合同为基础，用发包方也能看懂的语言，梳理委托或承接受托开发、运维业务时，合同应当如何搭建。

需要说明的是，本文是基于IPA公开资料的一般性解读，并非法律意见。具体合同问题，请咨询律师等专业人士。

1．先说结论

关于系统开发与运维合同，先来总结一下IPA的标准交易与合同范本所展示的思路。

• 不把开发的全部阶段汇总成一份合同，而是按阶段拆分签订（多阶段合同）
• 尚未确定”要做什么”的规划与需求定义阶段，采用准委托合同
• “要做什么”确定之后，从内部设计到开发・测试的阶段，原则上采用承揽合同（外部设计阶段则视项目情况，两种合同都有可能）
• 运维这类持续性工作，原则上采用准委托合同
• 发包方也负有确定需求、提供信息等协助义务
• 规格变更不通过口头沟通处理，而要走书面的变更管理流程

简单来说，其原则是”对尚未确定的事项不承诺完成责任，对已经确定的事项承诺完成责任”，按阶段区分使用不同的合同形式。

2．IPA《信息系统标准交易与合同范本》是什么

《信息系统标准交易与合同范本》是一份官方文件，汇总了系统开发委托合同的范本及其解读说明。

它最初由日本经济产业省于2007年发布，即以受托开发（含部分规划）与维护运维为对象的第一版。其背景是用户企业（发包方）与IT供应商（受托方）之间，对合同内容的理解经常出现偏差，纠纷频发。

之后，修订工作由IPA接手，对应2020年4月施行的修订版民法的第二版于2020年12月22日发布。第二版整理了后文将提到的合同不符责任，以及成果完成型准委托合同的定位等内容。

需要注意的是适用范围。第一版和第二版最初是针对企业核心系统等相对大规模的定制开发（瀑布式），面向拥有系统部门与法务体系的企业之间的交易而设计的。针对中小规模交易，或使用套装软件・SaaS的场景，另外还准备了以”套装软件、SaaS/ASP的使用、维护运维”为对象的补充版标准合同。建议先确认自身的交易更接近哪一种，把条文当作思路的基础来使用，而不是原样套用条款，这才是恰当的距离感。本文所介绍的，也是不论规模大小都用得上的”思路”部分。

这份标准合同具有以下特点。

• 由用户企业、IT供应商、行业团体、法律专家共同讨论制定，设计上力求中立，不偏向任何一方
• 合同范本以Word格式公开发布，可以根据自身交易情况修改后使用
• 不仅有条文本身，还附有”为什么这样规定”的解读说明
• 还公开了用于确定开发合同安全规范的指南等附属文件

也就是说，这份资料既可以作为拟定合同时的初稿基础，也可以作为审查对方提出的合同时的比较基准。

3．核心在于”多阶段合同”──为什么要按阶段拆分合同

标准交易与合同范本思路的核心，就是多阶段合同。

系统开发大致按以下阶段推进。

规划与需求定义（决定要做什么）
        ↓
设计・开发・测试（制作已确定的内容）
        ↓
验收与部署支持（把做好的系统投入实际业务）
        ↓
运维（持续运行）

多阶段合同，是指不把这些阶段汇总成一份合同，而是按阶段（或阶段的组合）分别签订合同的方式。

为什么要拆分呢？理由很简单，因为不同阶段”能够承诺的内容”是不一样的。

在需求定义结束之前，要做的东西无论是内容还是工作量都尚未确定。如果在这个时间点就把开发整体的金额和交期定下来，会出现以下两种情况之一。

• 受托方为应对不确定的风险，报出偏高的金额
• 以低价接下项目的受托方，后来又主张”那超出范围了”，与发包方产生纠纷

反过来，如果需求定义已经完成，要做的东西已经确定，受托方就能以现实的精度给出报价，并承诺完成。

多阶段合同，是以”需求定义结束后，再对开发部分重新估价”为前提的方式。从发包方的角度看，一开始总金额无法确定，这会带来不安。但标准合同的立场是，与其用没有依据的金额把整体定死，不如采用这种方式，结果上纠纷和无谓的成本反而会更少。

4．准委托与承揽──两种合同类型的区别

在多阶段合同中，会按阶段区分使用准委托合同与承揽合同。这两者的区别，是本文中最重要的一点。

承揽合同──承诺完成的合同

承揽，是承诺”完成这项成果物”的合同。受托方承担完成责任，如果没有完成，原则上不能请求支付报酬（不过，即使项目中途终止，如果已完成的部分可以切分出来并对发包方有益，有时也会认可按相应比例支付报酬）。

如果交付物不符合合同内容，受托方要承担合同不符责任。这是2020年施行的修订民法在原有”瑕疵担保责任”基础上重新构建而成的制度，发包方除了可以要求修补（请对方修正）之外，在设定期限要求修补而未被履行等特定条件下，还可以要求减少报酬。不过，如果不符情形是由发包方所提出的规格或指示本身造成的，除非受托方明知问题却未告知，原则上发包方不能提出上述请求。标准合同第二版反映了这一修订内容。

由于是以完成为交换条件、承担较重责任的合同，因此适合用在能够明确界定”何为完成”的阶段。

准委托合同──承诺以专业身份工作的合同

准委托，是承诺”以专业人士的身份履行业务”的合同。受托方不承担完成责任，取而代之的是承担善良管理人的注意义务，即以专业人士通常应有的谨慎程度来履行业务的义务。

听到”没有完成责任”，发包方或许会感到不安。但这并不意味着”可以偷工减料”。如果作为专业人士的工作不到位，仍然会因违反善良管理人的注意义务而被追责。

此外，修订后的民法还明文规定了成果完成型准委托这一报酬支付方式。与按照已完成业务的比例支付报酬的履行比例型（以时薪结算的方式是其典型代表，也可以是按月固定金额履行定型业务的形式）不同，成果完成型是针对约定好的成果支付报酬。对于像需求定义文档这样有明确成果物的准委托业务，采用这种方式，就可以做成”虽是准委托，但成果物的交付与报酬相挂钩”的形式。

按阶段区分使用

标准交易与合同范本大致设想了如下的区分使用方式。

这里需要注意的是，这并不是”承揽对发包方有利”“准委托对受托方有利”这种简单的对立关系。

如果硬把尚未确定的工作签成承揽合同，就会在完成标准依然模糊的状态下，只单方面承诺了完成责任，最终演变成”到底完成没完成”的各说各话。选择与阶段性质相符的合同类型，最终才能保护双方的利益。

5．运维合同中应当事先约定的内容

开发结束后的运维，潜藏着与开发不同的纠纷隐患。最常见的就是”按月支付的维护费究竟包含到什么范围”这一认识上的偏差。

虽然统称为运维，但其中其实汇集了性质各不相同的多项工作。

• 运行监控、备份、定期维护
• 操作方法等的咨询应对
• 故障发生时的初步调查与恢复处理
• 缺陷修复
• 跟进操作系统与中间件的更新
• 功能追加、界面变更等改造

其中，监控、咨询应对、初步调查这类持续性工作，原则上采用准委托型。而内容可以明确界定的功能追加或改造，比起模糊地包含在维护合同里，更安全的做法是单独报价，以承揽的形式独立出来。

建议在签约时，至少以书面形式约定以下几点。

• 划清月费（固定金额）范围内包含的工作与不包含的工作
• 咨询与故障应对的受理时段，以及开始应对所需的大致时间
• 故障重要程度的分级，以及各级别对应的应对方针
• 发生超出固定金额范围的工作时，报价与下单的流程
• 开发阶段的合同不符责任（免费修正的对象范围）与维护合同（有偿应对）之间的关系

特别是最后一点，很容易被忽视。交付后不久发现的缺陷，究竟属于开发合同的合同不符责任范围，还是应由维护合同来应对，如果不在合同中明确期限和条件，就很容易引发纠纷。

6．发包方也有义务──协助义务与项目管理义务

稍微跳出合同条文本身来说，标准交易与合同范本的解读，以及以往的判例，都反复揭示了一个重要观点：系统开发是发包方与供应商的共同作业，双方都负有各自应尽的义务。

• 供应商一方，负有以专业人士的身份妥善管理项目、如存在风险须加以说明的义务（项目管理义务）
• 发包方一方，负有确定需求、提供业务内容相关信息、在期限内做出必要决策等协助义务

也就是说，如果发包方以”专业的事我们不懂”为由把一切都交给供应商处理，也就是所谓的”甩手掌柜”式外包，那么需求就无法确定下来，一旦项目失败，发包方自身的协助义务也可能被追究。

标准交易与合同范本中，内置了将双方角色分工文档化、并通过联络协调会（例会）共享进度与问题的机制。与其把它当作合同范本来看，不如把它当作共同运营项目的规则手册来阅读，这样对发包方而言也能收获良多。

7．规格变更要通过”变更管理流程”来处理

在开发过程中出现”这个界面还是想这样改一下”之类的需求，是难以避免的。问题不在于出现变更本身，而在于仅凭口头或邮件往来就把变更推进下去。

• 发包方觉得”以为只是个小改动”
• 受托方则认为”虽然处理了，但工时膨胀了，想要求追加费用”

口头或邮件往来虽然也能作为交涉的记录，但由于缺少一份双方就变更范围、费用、交期都正式达成一致的文书，到了这一步往往就容易变成各说各话。

标准交易与合同范本中，规定了变更管理流程。大致流程如下。

提出变更方案（双方均可提出）
        ↓
以书面形式（变更提案书）说明变更内容・影响范围・对费用与交期的影响
        ↓
双方协商
        ↓
达成一致后留存书面记录并实施变更／未能达成一致则维持原状

关键在于，不仅要就变更内容，还要把对费用与交期的影响一并达成一致之后，再着手推进。作为流程来说这是多了一道手续，但正是这道手续能够防止”说了没说”的纠纷。

8．敏捷开发有专用的标准合同

到目前为止说明的，都是以先确定需求再进行制作的瀑布式为前提的合同。

另一方面，针对边做边重新审视需求的敏捷开发，2020年3月31日发布了专门的标准合同──《信息系统标准交易与合同范本（敏捷开发版）》。

敏捷开发版具有以下特点。

• 合同类型以准委托合同为前提。因为这是一种以开发过程中不断追加、变更功能以及重新审视优先级为前提的方法，与一开始就确定成果物的承揽合同并不契合
• 开发方法采用Scrum，并把角色分工（产品负责人〔Product Owner〕等）纳入合同之中
• 附有签约前检查清单，其结构是让发包方与受托方先确认项目目的以及双方对敏捷开发的理解程度，再进入签约环节

其设计理念并非”因为是敏捷，所以合同可以模糊”，而是”正因为是应对变化的开发方式，才更要在合同中明确角色与推进方式”。

总结

整理一下可以从IPA的《信息系统标准交易与合同范本》中学到的受托开发・运维合同的思路。

• 不把整个开发汇总成一份合同，而是按阶段拆分签订（多阶段合同）
• 决定”要做什么”的规划与需求定义阶段采用准委托，制作已确定内容的内部设计之后的开发阶段原则上采用承揽（外部设计阶段两者皆有可能）
• 承揽承担完成责任与合同不符责任，准委托承担善良管理人的注意义务，受托方所负责任的性质并不相同
• 运维原则上采用准委托，并在签约时以书面形式划清固定金额范围与单独报价部分的界线
• 发包方也负有协助义务，”甩手掌柜”式外包会使项目走向失败
• 规格变更要纳入变更管理流程，并把对费用与交期的影响一并达成一致
• 敏捷开发有以准委托为前提的专用标准合同

标准合同范本及其解读，可以从IPA官网以Word格式免费下载。无论是即将委托开发的一方，还是被对方提出合同的一方，这都是一份值得先通读一遍、不会有损失的资料。

致正在考虑委托系统开发与维护的您

要恰当地选择合同形式，其前提是先梳理清楚”要做什么”“委托的范围到哪里”“发包方与受托方之间如何分工”这几点。

合同会社小村软件（合同会社小村ソフト）在承接Windows业务应用与Web系统的受托开发・维护咨询时，会遵循本文介绍的多阶段合同思路，把需求梳理阶段与开发阶段分开来提案。即使开发范围与成果物的梳理尚在起步阶段，也欢迎您先从确认当前业务内容开始咨询。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

承揽合同与准委托合同有什么区别？

承揽合同是针对「完成约定好的成果物」支付报酬的合同，受托方要承担完成责任与合同不符责任。准委托合同是针对「以专业人士的身份履行业务」支付报酬的合同（成果完成型的准委托，是针对约定好的成果支付报酬），受托方承担善良管理人的注意义务（以专业人士的身份认真履行业务的义务），但不承担完成责任。能够明确界定所做内容与完成标准的阶段适合采用承揽合同，以发包方为主导进行研讨的阶段，以及持续性的工作，则适合采用准委托合同。

为什么需求定义阶段推荐采用准委托合同？

因为需求定义是由发包方主导决定「要做什么」的阶段，供应商处于支持其研讨的立场。而且在开始阶段，成果物很难被具体确定下来，如果在这个阶段就承诺完成责任（承揽），完成的标准就会变得模糊，从而成为纠纷的原因。IPA的标准交易与合同范本中，规划与需求定义阶段同样设想采用准委托型。

运维合同应该采用承揽还是准委托？

运行监控、咨询应对、故障初步调查这类「持续性工作」，由于不符合「完成」这一概念，原则上采用准委托型。而内容与完成标准可以明确界定的功能追加或界面改造，则可以单独切分出来，以承揽的形式签约。重要的是，在签约时就以书面形式划清月度维护合同中包含哪些内容、哪些内容需要另行报价。

IPA的标准交易与合同范本可以直接使用吗？

标准合同范本以Word格式公开发布，前提是需要根据自身交易情况修改后再使用。由于它是以不偏向用户企业或IT供应商任何一方的中立立场制定的，因此可以作为拟定合同的初稿，也可以作为审查对方提出的合同时的比较基准。不过，具体的合同判断，建议咨询律师等专业人士。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。