关于敏捷开发的法律和合同问题

系统开发的推进方式有其方法论。最古典且最普遍的是瀑布模型，许多处理系统开发的法律书籍也是以此模型为前提进行论述的。本文将解释基于敏捷开发模型的系统开发中可能存在的法律问题，这是从书籍等资料中难以获取的信息。

敏捷开发模型与法务

系统开发中的模型是什么

在系统开发项目中，为了全面掌握进度，我们有一个叫做开发模型的框架。这个框架的代表就是所谓的“瀑布模型”。就像水从河流的“上游”一直流到“下游”一样，需求定义、设计、实现、测试等各个阶段都是一气呵成的。这种方法旨在尽可能减少工作步骤的回溯和重复，适合于有计划地推进工作。

另一方面，敏捷开发模型是反复实现小程序并进行测试。通过反复实现小程序并进行测试的迭代工作，逐渐构建出大型系统。关于这些系统开发模型的更详细的解释，以及两种开发模型的优点和缺点的比较，可以在以下的文章中找到更详细的信息。

https://monolith-law.jp/corporate/legal-merits-and-demerits-of-development-model[ja]

敏捷开发模型的特点

敏捷开发模型的一个重要优点是，它可以快速地进入实际工作。由于需求定义和设计文档的“上游工作”与程序实现工作并未分开，因此，包括对功能的添加和修改，以及规格的变更等在内的应对措施，都可以灵活地进行。从法律角度看，为了使敏捷开发模型成功，特别重要的是如何进行文档管理和变更管理。在敏捷开发模型中，角色和职责并没有像瀑布模型那样明确地划分。此外，由于这种方法强调的是执行和开始的“速度”，而不是“管理”，因此很容易导致各种设计文档、规格书、会议记录的不完整。

再者，关于变更管理，由于敏捷开发模型对变更的应对较为顺畅，因此，有可能在跳过决策者的批准过程，直接在现场层面应对规格变更请求的过程中，项目出现问题。一旦出现这种情况，“对后期变更的应对较为顺畅”这一开发模型的优点，就可能成为项目问题的风险。

敏捷开发中的文档管理和变更管理方法

文件管理的重要性

在基于敏捷开发模型的开发项目中，法律上的担忧是口头交流的积累可能导致文件的缺乏。关于为什么在系统开发项目中文件管理变得如此重要，我们在以下文章中进行了详细的解释。

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

在该文章中，我们从预防争端（即“预防法务”）和争端发生时的证据保全（即“危机管理”）两个角度，解释了在系统开发项目中文件管理的重要性。

设立联络协议会对文档管理有效

在采用敏捷开发模型的情况下，与瀑布模型不同，事先并没有准备明确的计划。因此，仅仅管理计划和实际结果的差距是不够的，如果任由现场自行处理，可能会导致金钱和时间成本的增加。

因此，负责人定期举行联络协议会以促进项目的顺利进行是一种有效的策略。在开发规模较小的情况下，确实，比起定期举行联络协议会，负责人之间在可以聚集的时候聚集的方式更受欢迎。然而，在敏捷开发模型的情况下，会议中未能处理及时问题的风险也可能增大。因此，定期举行联络协议会并将其纳入合同等文件中是安全的。规定的方式如下，经济产业省模型合同书中有以下的示例。

（设立联络协议会）

第12条 甲和乙，直到本业务结束，为了讨论进度情况、风险管理和报告、甲乙双方的共同工作和各自的分工工作的实施情况、应包含在系统规格书中的内容的确认、问题的讨论和解决以及其他为了使本业务顺利进行所需的事项，应设立联络协议会。但是，（中略）。

2. 联络协议会，原则上，应按照个别合同规定的频率定期举行，并且，甲或乙认为必要的时候随时举行。

3. 联络协议会，甲乙双方的负责人、主任负责人以及负责人认为适当的人员应出席。此外，甲和乙可以要求对方让需要参加联络协议会讨论的人员出席，除非有合理的理由，对方应答应。

4. 乙应在联络协议会上，按照甲乙双方另行约定的格式制作进度管理报告并提交，并根据该进度管理报告确认进度情况，必要时讨论并决定是否有延迟事项，如果有延迟事项，其原因和对策，是否需要改变本章规定的推进体制（人员的更换、增减、再委托方的更换等），安全措施的执行情况，是否有需要改变个别合同的事由，如果有需要改变个别合同的事由，其内容等事项，并确认决定的事项、继续考虑的事项以及如果有继续考虑的事项，其考虑的时间表和进行考虑的当事人等。

（以下，第5条、第6条、第7条省略。）

联络协议会的存在，通过合同条款赋予其一定的合法性，赋予其与其他临时会议不同的意义，这是最重要的一点。

利用联络协议会改善变更管理的路径

在敏捷开发中，双方最初达成的事项在事后被更改是前提条件。因此，如何管理事后的规格更改的情况也非常重要。

在这种情况下，如果定期举行联络协议会，变更管理和操作方式将变得非常顺畅。例如，将变更讨论设定为在联络协议会上进行，并在合同中规定，如果一方提出变更讨论的要求，对方有义务应对该讨论。（以下摘录了日本经济产业省模型合同的规定。）

（变更管理程序）

第37条 甲或乙，如果收到对方基于（中略）的变更提案书，应在收到之日起○天内，向对方提交记载了以下事项的书面（以下称为“变更管理书”）。甲和乙应在第12条规定的联络协议会上讨论该变更的可行性。（以下，关于记载事项的内容省略）

上述规定的要点可以整理如下：

• 接受变更申请的方法是统一为“变更提案书”格式
  
• 从接收提案书到讨论它的日期设定了期限 → 即使没有“◯天内”这样的表述，也可以考虑用“尽快”等词替换。
  
• 讨论变更的可行性的场所统一为“联络协议会”
  

也就是说，为了避免口头基础上的“是否提出变更申请”、“是否对变更的可行性做出回应”等认识的差异，明确了程序的方法。

对诚信义务和信义原则的理解受到质疑

到目前为止，我们已经介绍了关于“联络协商会”、“变更协商”等合同条款的模型。然而，为了理解这些本质，重要的是理解“诚信义务”和“信义原则”等事项。首先，敏捷开发模型往往难以进行，除非有订购方和接单方的信任关系。因为它重视实际工作的开始速度，通常情况下，开始前的程序被最小化。因此，在实际操作中，也经常会包含对对方施加“诚信义务”的条款。

第4条第3款 在变更协商中，应考虑变更的对象、变更的可能性、变更对代金和交货期的影响等，并诚实地协商是否进行变更。

这是为了防止在最初基于信任关系进行的谈判中，突然以“是否应对合同变更表示同意，完全取决于接受申请方的自由，没有义务应对强制”等形式主义的法律论点背叛对方。这不仅限于系统开发，也反映了涉及私人交易的法律原则。

民法第一条第二款

权利的行使和义务的履行必须按照信义和诚实进行。

法律并不总是重视形式主义的“合同书的记载内容”或“条文的措辞”。特别是在有对方的交易中，应该灵活地使用实质的“信义”和“诚实”。另外，关于法律上规定的“义务”并不一定基于“合同”这一程序，我们在以下的文章中也进行了详细的解释。

https://monolith-law.jp/corporate/system-development-unlawful-responsibility[ja]

总结

在基于敏捷开发模型的系统开发项目中，理解行政程序和管理体制可能会逐渐变得松散的风险当然是重要的。然而，不仅如此，理解法律本身基于”诚信原则”等的灵活特性，并将其应用于实际工作中的态度，也被认为是重要的。