各種系統開發模型在法律上的優點與缺點是什麼

在推進系統開發項目的方式中，存在著一定的方法論。通常，當本所在書籍等資源中學習與系統開發相關的法律問題時，往往以最為古典的方法——被稱為瀑布模型的方法為前提。然而，用於推進系統開發的方法論和模型並不僅僅是瀑布模型。例如，近年來，敏捷開發模型的選擇也變得越來越多。

本文將從法律風險和糾紛預防等角度，對瀑布模型和敏捷開發模型進行比較並進行解說。

何謂開發模型

什麼是瀑布模型

在系統開發的進行方式中，最常見且最經典的方式如下：

• 需求定義：釐清即將開發的系統應具備的功能，以及所需的規格
• 基本設計：從使用者的角度出發，設計系統的全貌，包括畫面設計、畫面轉換等
• 詳細設計：從開發商的角度出發，設計系統的全貌，包括程式檔案之間的連接等
• 程式實現：根據設計書進行程式碼編寫
• 測試：驗證產品是否符合規格，並請求使用者確認

這種像沿著河流從上游到下游的開發方式，盡可能避免步驟的前後混亂或回溯，被稱為「瀑布模型」。這種流程並非創建運行系統的必要條件。然而，在系統開發這種往往需要大量人力和長期投入的項目中，計劃性變得非常重要。因此，劃分各個工程、整理角色、明確各負責人的責任範圍等事項也往往被重視。

什麼是敏捷開發模型

另一方面，開發工作的進行方式並不一定適合「上游→下游」的一氣呵成的方式。確實，由於業務的性質，計劃性和預見技術是重要的，這點無庸置疑。然而，首先，創新的製造和創作工作往往在一開始就無法完全計劃，這種情況很常見。如果重視這一點，不僅要按照一次性的計劃進行工作，還應該容易靈活地對後續的修正和規格的變更進行應對，並增加嘗試和錯誤的次數。這種思考方式反映在開發方法上，就被稱為「敏捷開發模型」。在敏捷開發模型中，一般不會花太多時間準備詳細的計劃或設計書，而是反覆實現和測試非常小的程式，逐漸將其轉變為大型的程式或系統。

學習法律問題較易的是瀑布模型

在比較兩種開發模型之前，本所首先需要了解，每種開發模型所伴隨的法律問題，以及蒐集資訊和學習法律的容易程度。

大部分的參考書籍都是以瀑布模型為基礎撰寫的

在學習與系統開發相關的法律問題或法律知識時，瀑布模型在資訊蒐集的容易程度上佔有優勢。討論系統開發的法律書籍在大多數情況下，都是以瀑布模型為前提撰寫的。由於傳統的、一般的系統開發都是依照瀑布模型進行，因此在這裡，敏捷開發只是補充的位置，大多只是簡單介紹。因此，如果你想從書籍中獲取與系統開發相關的法律問題的資訊，瀑布模型會讓你更容易進行學習。

裁判例的積累也多在瀑布模型

此外，由於瀑布模型是傳統的、一般的系統開發方法，因此過去實際發生的爭議案例的積累也相當豐富。在法律討論中，除了條文之外，過去的裁判例的知識也具有重要的意義。對於只讀條文文字無法判定為「白」或「黑」的案件，也可以從過去的裁判例中獲得見解，有時可以補充條文的內容。

即使不是明文化的法律，法院所做出的判決的積累也可能像條文一樣成為確立的判斷標準。這種情況被稱為「判例法理」。即使在系統開發等話題之外，如果已經有判例法理的積累的領域，即使是未知的爭議，也可能相對容易預測最終的爭議走向。在這方面，基於瀑布模型的系統開發有許多可預見的優點。

各種開發方法的優點

基於上述內容，以下本所將比較各種方法的優點和缺點。前半部分主要整理了瀑布模型的優點，而下半部分則更清楚地說明了敏捷開發的優點。

計劃性和預見性的比較

在計劃性和預見性方面，瀑布模型可能是更好的選擇。無論系統的規模有多大，都會被細分為「上游→下游」的各個階段。如果為每個階段設定截止日期，則進度管理相對容易。

另一方面，敏捷開發是一種不需要在預先計劃或整體構想上投入太多成本和努力的方法，因此可能容易變成一種臨時應變的方法。

個別角色和責任範圍明確化的比較

在瀑布模型中，由於每個階段都被細分，因此有一個優點，即可以明確每個項目成員的角色。

另一方面，敏捷開發的工作階段劃分可能會變得模糊，因此對於突發問題等，誰應該負責等問題也可能變得模糊。

大規模開發的易行性比較

在計劃性和角色劃分方面，瀑布模型的優點在於大規模開發。即使需要組織大量人員，只要將工作階段細分並促進分工，就可以降低人際關係調整的成本。

另一方面，敏捷開發模型並不適合大規模開發。這種方法重視的是開始工作的速度，而不是計劃性或角色劃分，因此在擔心最終交付日期可能延遲的情況下，可能難以應用。

速度感和效率的比較

敏捷開發的開始更快

從用戶提出功能需求到實際實現的速度上，敏捷開發模型更具優勢。因為在瀑布模型中，上游和下游階段的負責人通常是明確分開的，這使得供應商內部的溝通變得更為繁瑣。這種溝通的繁瑣可能會使其更難應對後期的規格變更請求。

另一方面，敏捷開發模型可以期待在不設立中介的情況下，以速度感開始和執行。這與敏捷開發模型最大的優點——容易應對後期規格變更——密切相關。然而，即使是敏捷開發模型，如果對規格變更和額外開發的請求持續應對，也可能帶來項目「燃燒」的風險。因此，如何進行「變更管理」是敏捷開發模型系統開發成功的關鍵。關於變更管理的詳細說明，請參見以下文章。

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]

選擇哪種開發模型最適合，不僅要從法律的角度考慮，還需要綜合考慮項目的規模、預算、目的等因素。