關於敏捷開發的法律和合約問題

系統開發的進行方式有其方法論。最古典且最普遍的是瀑布模型，許多處理系統開發的法律書籍也以此模型為前提進行討論。本文將針對基於敏捷開發模型的系統開發，解說可能存在的法律問題，這是從書籍等資源中較難獲得的信息。

敏捷開發模型與法務

系統開發中的模型是什麼

在系統開發項目中，為了全面掌握進度，本所有一種稱為開發模型的框架。其代表就是所謂的「瀑布模型」。也就是說，就像水從河流的「上游」一路「下流」，本所將需求定義、設計、實現、測試等各個階段一氣呵成地完成。這種方法旨在盡可能減少步驟的回溯和重複工作，適合計劃性地推進業務。

另一方面，敏捷開發模型則是反覆實現小型程序並進行測試。通過反覆實現小型程序並進行測試，本所逐漸構建出大型系統。關於這種系統開發模型的更詳細說明，以及兩種開發模型的優點和缺點的比較，請參見以下文章。

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. 乙方應在聯絡協議會上，根據甲方乙方雙方另行決定的格式製作進度管理報告並提交，並根據該進度管理報告確認進度狀況，並在必要時討論和確認已決定的事項、需要繼續研究的事項以及需要繼續研究的事項的研究時間表和研究參與者等。

（以下，第五項、第六項、第七項省略。）

聯絡協議會的存在，即使在契約條款中也有一定的正當性，與其他臨時召開的會議有不同的意義，這是最重要的一點。

利用聯絡協議會進行變更管理的途徑

此外，在敏捷開發中，雙方最初達成的協議在事後被更改是前提。因此，如何管理事後的規格變更情況也非常重要。

在這種情況下，如果定期舉行聯絡協議會，變更管理的方法也會變得非常順暢。例如，將變更討論定為在聯絡協議會上進行，並在契約中納入一方提出變更討論時，對方有義務應對該討論。（以下摘錄經濟產業省模型契約的規定。）

（變更管理程序）

第 37 條 甲方或乙方在收到對方的（中略）變更提議書後，應在○日內，將下列事項記載在書面中（以下稱為「變更管理書」），並將其交給對方，甲方和乙方應在第 12 條規定的聯絡協議會上討論該變更的可行性。（以下，記載事項省略）

上述規定的要點可以整理如下：

• 將接受變更申請的方法統一為「變更提議書」的格式
  
• 設定了從接收提議書到討論的日期限制 → 即使不是「◯日內」這樣的表述，也可以考慮用「儘快」等詞代替。
  
• 將討論變更的可否的場所統一為「聯絡協議會」
  

換句話說，為了避免引起「是否提出變更申請」、「是否對變更的可否給予回應」等認識的不一致，明確化了程序的方法。

對誠信義務和信義原則的理解受到質疑

到目前為止，本所已經介紹了關於「聯絡協商會議」、「變更協商」等契約條款的模型。然而，為了理解這些本質，重要的是理解「誠信義務」和「信義原則」等事項。畢竟，敏捷開發模型往往難以在沒有訂單方和接單方的信任關係的情況下進行。因為，通常情況下，本所會重視實際工作的開始速度，並將開始前的程序最小化。因此，在實務上，本所也會將「誠信義務」的條款納入對方的契約中。

第4條第3項 在變更協商中，應考慮變更的對象、變更的可否、變更對價金和交貨期的影響等，並誠實地討論是否進行變更。

這是為了防止在最初基於信任關係進行的談判中，突然以「是否應對契約變更，完全取決於接受提議方的自由，無需強制應對」等形式主義的法律論來背叛對方。這不僅限於系統開發，也反映了涉及私人交易的法律原則。

日本民法第一條第二項

權利的行使和義務的履行必須信守並誠實地進行。

法律並不一定重視形式主義的「契約書的記載內容」或「條文的文字」。特別是在有對方的交易中，應該靈活地使用實質的「信義」和「誠實」。另外，關於「義務」這種法律上的要求並不一定基於「契約」這種程序，本所在以下的文章中也進行了詳細的解釋。

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

總結

在基於敏捷開發模型的系統開發項目中，理解事務程序和管理體制可能會逐漸變得馬虎的風險當然是重要的。然而，不僅如此，理解「誠信原則」等法律本身具有的靈活特性，並將其應用於實務的態度，也被認為是重要的。