從法律的角度看,系統開發中的變更管理該如何進行

在系統開發項目中，使用者在事前說明的內容，往往在工作進行過程中會有所變更。因此，作為接受工作的供應商，即使已經簽訂了合約，也可能需要對後來的合約內容變更作出應對。

本文將從法律角度對於這種難以按照預期進行的系統開發項目中，後續出現的「變更」現象該如何處理進行解說。

為何系統開發項目會在事後「變更」

系統開發是供應商和用戶的共同工作

系統開發通常經過規劃和提案階段，開發需求被定義，並簽訂合約。然後，合約簽訂後，經過各種設計，按照設計實施，完成工程，最後進行測試，這是一般的流程。在整個過程中，接受工作的供應商作為系統開發專家，當然要承擔廣泛的義務，但用戶方也有一定的合作義務。在確定應建立的系統應具有的功能（＝需求定義）、屏幕外觀和操作感（＝基本設計），以及確認是否按需求完成（＝測試或驗收）等階段，用戶的合作尤為重要。關於系統開發中用戶承擔的義務的一般解釋，請參見以下文章。

https://monolith-law.jp/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]

總結

在頻繁進行規格變更的現場，確實容易與各種問題和爭議的風險並存。然而，在這種需要靈活應變的現場，僅僅強調「管理的重要性」，往往難以實施有效的措施。

如何在追求商業速度感和萬一發生意外情況的準備之間取得平衡，這個問題的最佳解決方案往往會因公司的狀況和項目的內容而異。本所認為，即使考慮到本文的內容，每個公司和項目也需要尋找適合自己的方法，這種態度也是非常重要的。