关于系统开发中各种开发模型的法律优点和缺点

在推进系统开发项目的过程中，有一定的方法论。通常，在通过书籍等进行关于系统开发相关法律问题的学习时，往往以被称为瀑布模型的最经典方法为前提。然而，作为推进系统开发的方法论和模型，并非只有瀑布模型。例如，近年来，敏捷开发模型的选择也越来越多。

本文将从法律风险和争议预防等角度，对瀑布模型和敏捷开发模型这两种方法进行比较和解释。

什么是开发模型

什么是瀑布模型

在系统开发的过程中，最常见且最经典的方法如下：

• 需求定义：梳理即将开发的系统应具备的功能和所需的规格
• 基本设计：主要从用户的角度出发，设计系统的全貌，包括界面设计和界面转换等
• 详细设计：主要从开发商的角度出发，设计系统的全貌，包括程序文件之间的连接等
• 编程实现：根据设计文档进行编程
• 测试：验证是否按照规格要求完成，并请求用户确认

这种开发方法，就像沿着下行的河流从上游→下游，尽可能避免步骤的前后和回退，被称为“瀑布模型”。这种流程本身并不是制作运行系统的必要条件。然而，在系统开发这样的项目中，往往需要投入大量的人力和长期的时间，因此计划性变得非常重要。因此，各个阶段的划分，角色的整理，各负责人的责任范围的明确等事项也被视为重要。

什么是敏捷开发模型

另一方面，开发工作的进行方式并不总是适合“上游→下游”的一气呵成的方法。确实，由于业务的性质，计划性和预见的技术是重要的，这是不言而喻的。然而，首先，这是一项涉及到新产品和作品制作的工作，很多时候，从一开始就不可能制定完美的计划。如果重视这一点，那么不仅要按照一次性的计划进行工作，还应该重视事后的修正和规格的变更，增加试错的次数等。这种思考方式反映在开发方法上，就被称为“敏捷开发模型”。在敏捷开发模型中，一般不会花费太多时间准备详细的计划和设计文档，而是反复实现和测试非常小的程序，逐渐将其转变为大型程序和系统。

学习法律问题更容易的是瀑布模型

在比较两种开发模型之前，我们首先需要了解每种开发模型所伴随的法律问题，以及收集信息和学习法律的便利性。

大多数参考书籍都是基于瀑布模型编写的

在研究与系统开发相关的法律问题或学习法律知识时，瀑布模型在信息收集的便利性上占有优势。大多数关于系统开发的法律书籍都是以瀑布模型为前提编写的。因为传统的、普遍的系统开发都是按照瀑布模型进行的，所以在这里，敏捷开发只是补充性的位置，通常只是简单介绍。因此，如果你想从书籍中获取与系统开发相关的法律问题的信息，瀑布模型会更容易学习。

瀑布模型的判例积累也较多

此外，由于瀑布模型是传统的、普遍的系统开发方法，因此过去实际发生的争议案例的积累也较丰富。在法律讨论中，除了法条本身，过去的判例知识也具有重要的意义。对于只读法条文字无法明确判断为“白”或“黑”的案件，通过从过去的判例中获取知识，可以补充法条的内容。

即使不是明文化的法律，法院所做的判断的积累也可能像法条一样成为判断标准。这些被称为“判例法理”。不仅限于系统开发等话题，如果在已有判例法理积累的领域，即使是未知的争议，也可能相对容易预测最终的争议走向。在这方面，基于瀑布模型的系统开发有很多优点。

各种开发方法的优点

基于上述内容，我们将在下文中比较各种方法的优点和缺点。前半部分主要整理了瀑布模型的优点，而下半部分则侧重于清晰地阐述敏捷开发的优点。

从计划性和预见性的比较

在计划性和预见性等方面，可以说瀑布模型更具优势。无论要创建的系统规模有多大，它都会被细分为从“上游→下游”的各个阶段。为每个阶段设定截止日期，其进度管理相对容易进行计划。

另一方面，敏捷开发是一种不需要在预先规划和整体构想上投入太多成本和努力的方法，因此可能容易变成临时性的方法。

根据各自角色和责任范围的明确性进行比较

在瀑布模型中，由于每个阶段都被详细地细分，因此有一个优点，即可以明确每个项目成员的角色。

另一方面，在敏捷开发中，由于阶段划分往往模糊，因此在面对突发的问题等情况时，谁应该负责这一点也容易变得模糊。

大规模开发的便利性比较

在计划性和角色分工方面表现优秀的瀑布模型，对于大规模开发来说，其优点越发明显。即使需要组织大量人员，只要将工程细分并促进分工，就能够降低人际关系调整所需的成本。

另一方面，敏捷开发模型并不太适合大规模开发。这种模型更重视开始工作的速度感，而非计划性或角色分工，因此在担心最终交付日期可能会有所偏差的情况下，使用这种模型就变得困难了。

速度感和效率的比较

敏捷开发的启动更快

从用户提出某个功能的需求到实际实现的速度感来看，敏捷开发模型更胜一筹。这是因为在瀑布模型中，上游和下游的负责人通常是明确分开的，这使得供应商内部的沟通成本较高。这种沟通成本高的问题，往往会导致对后期规格变更请求的处理能力较弱。

另一方面，敏捷开发模型可以期待在不设立中介的情况下，以速度感启动和执行。这与敏捷开发模型最大的优点——容易应对后期规格变更——密切相关。然而，即使是敏捷开发模型，如果对规格变更和附加开发的请求一味地应答，也可能带来项目“燃烧”的风险。因此，敏捷开发模型的系统开发，如何进行“变更管理”是成功的关键。关于变更管理的详细说明，请参阅以下文章。

https://monolith-law.jp/corporate/howto-manage-change-in-system-development[ja]

瀑布模型在中途更不容易停滞

另一方面，在速度感和效率的比较中，从长期时间轴来考虑也很重要。如果考虑到项目在中途“燃烧”，进展停滞的风险，那么瀑布模型更胜一筹。引发项目中途停滞的最大风险是用户和供应商之间的沟通不良。在这一点上，瀑布模型的优点在于能够明确双方的角色分工。

在验收阶段更容易推进的是敏捷开发

然而，从验收阶段的谈话推进容易性来看，敏捷开发模型稍占优势。这是因为用户和供应商在系统开发的中途也会进行详细的信息共享。这可以期待减小最终成果物出现后，双方认识的差异一下子显现出来的风险。关于系统开发的验收步骤的解释，以及相关的法律问题，请参阅以下的文章。

https://monolith-law.jp/corporate/estimated-inspection-of-system-development[ja]

总结

通过这样的比较，我们可以总结出，从全面管理的角度来看，瀑布模型是更有利的；而如果重视项目启动和执行的速度，那么敏捷开发模型将是更好的选择。另外，关于基于敏捷开发模型的系统开发所涉及的法律问题，我们在下面的文章中进行了详细的讨论。

https://monolith-law.jp/corporate/legal-and-contract-issues-of-agile-development[ja]

选择哪种开发模型，不仅要考虑法律的角度，还需要综合考虑项目的规模、预算、目标等因素。我们认为，这是一个需要综合判断的问题。