从法律的角度看,系统开发中的变更管理应如何进行

在系统开发项目中，用户在项目进行过程中经常会更改他们事先解释过的内容。因此，作为接受工作的供应商，即使是已经签订的合同，也可能需要应对后续的合同内容变更。

本文将从法律角度解析在系统开发项目中，如何处理那些并未按照预期进行，而在事后进行的“变更”现象。

为什么系统开发项目在完成后会被“修改”

系统开发是供应商和用户的共同工作

一般来说，系统开发会经过规划和提案阶段，确定开发需求，然后签订合同。合同签订后，会经过各种设计，按照设计实施，完成工程，最后进行测试，这是一般的流程。在整个过程中，接受工作的供应商作为系统开发专家，当然要承担广泛的责任，但用户方也有一定的合作义务。在确定应该创建的系统应具有的功能（=需求定义）、屏幕外观和操作感（=基本设计）以及是否按照需求完成（=测试或验收）等阶段，用户的合作尤为重要。关于用户在系统开发中承担的义务的一般解释，可以在以下文章中详细了解。

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

尽管有合作义务，但用户总是会提出各种修改要求

然而，即使不是系统开发专家的用户，也不能总是计划性地，全面地向供应商传达系统开发所需的信息。实际上，由于这是一项细致且精密的工作，用户往往无法预测哪些事实在后续工程中可能具有决定性意义。因此，讽刺的是，重要的事实往往会在后期逐渐浮出水面。由于这种情况，实际的项目中，虽然“从上游工程到下游工程一气呵成”是理想的，但在预计到可能会有各种修改的情况下，“如何进行变更管理”成为了重要的问题。

何为变更管理书

何时需要使用变更管理书

变更管理书是用户向供应商提出，从之前的说明内容中，更改规格或添加功能的请求时使用的文件。如前所述，在需求定义和基本设计等阶段，用户也有义务协助供应商的工作，但在后续的工作过程中，实际上可能会提出不同的要求。

举例来说，需要变更管理书的场合可能包括：

• 在需求定义和基本设计阶段，如果有遗漏的地方，需要在事后请求添加功能
• 在开发过程中，如果业务方针等进行了重新审查，需要更改规格

等等。

另外，关于添加功能、更改规格等话题，对于接受工作的一方来说，最关心的问题可能是，法律上是否允许更改估算金额。关于这一点，我们在另一篇文章中进行了详细的说明。

https://monolith-law.jp/corporate/increase-of-estimate[ja]

在进行这种事后的估算增加时，变更管理书将成为推测估算内容合理性的依据。为了在根据增加的估算进行索赔时，不引发与对方的争执（也为了在争执发生时，使自己的观点具有说服力），编制变更管理书就显得非常重要。

变更管理书的记载事项

那么，法律上，变更管理书应该记载哪些事项呢？利用变更管理书，根据规格变更和功能的添加来应对的合同机制已经被广泛认知。因此，通过查看经济产业省模型合同等官方提供的合同条款模板，大致可以了解应该记录哪些事项。

（变更管理程序）
第37条 甲或乙在收到对方根据第34条（系统规格书等的变更）、第35条（中间资料的用户批准）、第36条（未确定事项的处理）的变更提案书时，应在收到之日起○日内，提交记载以下事项的书面（以下称为“变更管理书”）给对方，并且甲和乙应在第12条规定的联络协商会议上讨论该变更的可行性。
① 变更的名称
② 提案的负责人
③ 年月日
④ 变更的原因
⑤ 包含变更规格的变更详细事项
⑥ 如果变更需要费用，其金额
⑦ 包含考虑期间的变更工作计划
⑧ 其他变更对本合同及个别合同的条件（工作期间或交货期，委托费，合同条款等）的影响

直接阅读条文，确认推荐记载的项目，就不需要再多的解释了。为了避免后来的“说了没说”的问题，应该详细并具体地记录变更的经过。

在明确记载这些事项后，加上供应商和用户双方的负责人和决策者的签名或盖章等，即使万一发生诉讼，也具有与合同书同等的证据意义。

你需要知道的关于变更管理的事项

变更管理通常应与任务管理一起进行

创建变更管理书的原因在于，通过管理变更历史，可以引导项目的完成（或者，如果无法完成，可以避免不公正的责任追究）。为了实现这些目标，在实际操作中，创建变更管理书通常与创建和更新任务管理清单一起进行。也就是说，如果在变更管理表中管理了变更历史，那么这些已经达成一致的变更项目将被纳入到任务管理清单的项目中，作为未来需要处理的任务。

最好同时规定变更讨论的方式

不仅要规定变更管理的方式，还应同时规定关于变更讨论的方式，这样可以期待变更的处理更加顺利。这一点在特别是在采用敏捷开发等开发方法的情况下尤其重要，因为这些开发方法预设了后期会有各种各样的变更。在实际操作中，也经常可以看到规定了当有关于变更管理的讨论请求时，对方应在何时回应等规定的例子。

变更讨论与诚实义务

对于双方一度达成一致的合同，如果事后要进行变更，那么这实际上也可以看作是签订新的合同。从合同是基于当事人自由意愿的角度来看，原则上，供应商没有义务应对变更合同。然而，如果过分强调这种权利，可能会担心实际上的系统开发项目无法顺利进行。

因此，在实际操作中，合同书中经常明确写有“诚实应对变更讨论的义务”，如果供应商不诚实应对变更，可能会有损害赔偿请求等情况。例如，以下是一种表述方式（以下是条款的示例，引用自独立行政法人信息处理推进机构官方制定的“ff基本/个别契约模型的基本契约书案”）。

第4条3项 在变更讨论中，应考虑变更的对象、变更的可否、变更对代金和交货期的影响等，并且双方当事人都应诚实讨论是否进行变更。

关于变更方法的规定

如前所述，进行变更时，从法律角度来看，每次都应开展关于变更的讨论是“安全”的。然而，如果是小规模的项目，可能不需要特别规定变更讨论的方式。在这种情况下，可以考虑不设定关于讨论的规定，而是通过用户和供应商各自的负责人在变更管理书上签名和盖章等方式，才能进行变更。如果只通过口头协议就轻易地进行变更，是否进行了变更往往会变得模糊，这可能会导致后期出现大问题，因此，应当彻底进行文档管理。

然而，每次都为了变更管理而准备单独的文件可能会觉得负担重，可能更重视灵活应对。在这种情况下，可以考虑将变更相关事项在会议记录中进行文档化。关于系统开发中会议记录的保存方式，我们在以下的文章中进行了详细解释。

https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]

总结

在经常进行规格更改的现场，的确容易出现各种问题和纠纷的风险。然而，在这种需要灵活应变的现场，仅仅强调“管理的重要性”往往难以采取实际的措施。

如何平衡商业所需的速度感和对万一的情况的准备，这个问题的最佳解决方案往往因公司的状况和项目的内容而异。考虑到本文的内容，我们认为，每个公司和每个项目都需要寻找适合自己的方法，这种态度也是非常重要的。