在系統開發中如何解除合約

由於「系統開發」這樣的項目通常是長期的，因此在進行過程中出現「燃燒」等情況也是可以預見的。然而，如果用戶和供應商能夠始終保持步調一致，那當然是最好不過，但本所也應該預見到可能需要考慮中途解除合約的情況。

本文將針對合約「解除」這一法律選項，以及與系統開發相關的重要問題進行解釋。

系統開發與解約的關係

何謂民法上的解約

在修訂後的日本民法中，關於契約「解約」的一般規定，是在第540條至第548條的條文中規定的。解約契約，意味著將已經締結的契約的效力在後來消除。

如果從用戶和供應商的關係來看，通常一旦契約締結，供應商就有開發系統的義務，用戶也有支付報酬的義務。這些也成為了雙方的「權利」。如果這些被解約，雙方所承擔的義務和所擁有的權利將恢復到締結契約前的狀態。因此，即使還有未履行的債務，也不再有履行的義務，並且根據締結契約前的狀態，有義務恢復到原狀。這就是所謂的「恢復原狀義務」。

另外，如果同時有損害發生，也可以另行賠償損害。

系統開發實務與解約的關係

對於熟悉系統開發等商業法律實務的人來說，當提到契約的「解約」，首先想到的可能是解約通知書。然而，即使在系統開發的法律背景下，解約的依據也可以大致分為兩種情況。

以債務不履行（履行遲滯）為理由的情況

（例）供應商超過了原定的交貨期限，但仍未交貨

日本民法第五百四十一條當事人的一方不履行其債務時，對方可以設定合理的期限，要求履行，如果在該期限內未履行，對方可以解除契約。

在承包型的系統開發中，「當事人的一方」即供應商所承擔的「債務」是完成並交付符合需求定義的系統。因此，即使超過了交貨期限，供應商仍未交貨，換句話說，就是供應商在交貨期限內未完成工作。那麼，「工作的完成」在系統開發中具體是什麼意思呢？關於這一點，本所在下面的文章中詳細解釋。

https://monolith-law.jp/corporate/completion-of-work-in-system-development[ja]

以瑕疵擔保責任為理由的情況

（例）供應商交付的系統存在許多錯誤和數據不一致，後來發現不適用於實際使用

日本民法第六百三十五條如果工作的目的物存在瑕疵，因此無法達到契約的目的，訂單者可以解除契約。但是，對於建築物和其他土地工程物，不在此限。

另外，從系統開發項目的角度來看，供應商方面表示解除契約的情況並不常見。通常，本所可以假設是用戶向供應商表示解除契約。

關於瑕疵擔保責任，本所在下面的文章中詳細解釋。

https://monolith-law.jp/corporate/defect-warranty-liability[ja]

解約通知書及其相關法律問題

解約通知書，通常是用戶向供應商傳達解除合約的文件。在法條上，可以參考以下的內容。

日本民法 第五百四十一條（明治時代，1907年）：當事人一方未履行其債務時，另一方可以設定合理期限，催告對方履行，若在該期限內未履行，另一方可以解除合約。

從系統開發相關文件的角度來看，解約通知書的特點並非為了順利推進項目，而是為了結束項目。此外，這是一份期望直接產生一定法律效果的文件，這也是其主要特點。

然而，如前述條文所述，與合約等文件不同，只要滿足一定條件，單方的意向表示就足夠了。當用戶向供應商提出解約通知書時，供應商方面的負責人可能會遇到「即使讀了解約通知書，也不明白為什麼合約被解除」的問題。那麼，用戶在撰寫解約通知書時，應該具體指出解約原因到何種程度呢？

是否應在解約通知書中寫明解約原因

對於這一點，從過去的判例等來看，本所認為在解約通知書中明確寫明解約原因並非進行解約的必要條件。以下引述的判例是一個因為交付的系統存在問題而引發法律問題的案例。在用戶方面進行解約意向表示時，需要具體了解到何種程度的問題內容，並需要具體指出這些問題，這些問題成為了問題點，法院對此做出了以下的判示。

解約的意向表示並不一定需要顯示解約原因，可以通過單一的意向表示來進行多個解約原因的解約，即使在進行解約意向表示時提出某種理由，除非特別明確表示不會因其他原因進行解約等特殊情況，否則該意向表示應被認為是基於當時存在的所有原因，並終止所有合約的意向表示。

東京地判平成16年12月22日 (2004年12月22日)

法院的觀點是”可以通過單一的意向表示來進行多個解約原因的解約”。也就是說，重要的是合約當事人是否有解約的意願，而不需要詳細指出該原因。

因此，即使是已經交付的，但是否應該被視為未完成，或者是否存在重大缺陷，因此應該被視為瑕疵擔保責任的問題，這些問題在進行解約意向表示的階段並不需要問題化。即使對這些微妙的問題暫時不問，如果先進行解約意向表示，即使後來變成訴訟，也可以爭辯履行遲滯或瑕疵擔保責任作為解約的依據。

• 交付的是未完成的物品…→債務不履行
• 交付的物品存在重大缺陷…→瑕疵擔保責任

即使不詳細指定原因，解約的意向表示也是有效的解約意向表示。

然而，具體指出解約原因並提出解約通知書的做法，即使在與供應商之間出現溝通錯誤或認識不一致的情況下，也有可能明確表示這一點的優點。此外，對於接收解約通知書的對方來說，如果他們對原因有所了解，則後來發生爭議的擔憂也會減少。因此，實際上，盡可能明確地寫明解約原因是更好的。

何謂「相當期間」的催告期限？

另一個需要考慮的問題是在日本民法（Japanese Civil Code）第541條中，「相當期間」的長度是多少。然而，對於這一點，本所認為沒有必要過於擔心。因為，即使在進行催告的期間內沒有設定「相當期間」，只要從催告開始經過了相當期間，就可以解除契約。即使催告的期間不是「相當期間」，只要在經過相當期間後，也可以解除契約，這一點在判例法上也已明確。

在系統開發項目中，一旦出現履行遲延或瑕疵擔保責任等「火災」問題，即使設定了「相當期間」進行催告，完成交付或瑕疵修復的情況可能並不多。考慮到這些因素，實際上，關於「相當期間」的嚴重爭議的可能性不大。

關於系統開發中履行遲延的定義，本所在另一篇文章中進行了解釋。

https://monolith-law.jp/corporate/performance-delay-in-system-development[ja]

解除通知書的通知方法是什麼？

對於解除通知書的通知方法，只要能確保通知能夠到達（更進一步來說，如果能夠證明通知確實已經到達），則任何方法都沒有問題。

因此，沒有必要過於神經質地擔心程序問題。確實，在實務上，為了避免後續的「說了沒說」的問題，通常傾向於使用內容證明郵件等方法。然而，只要能確認通知已經到達對方，即使是使用FAX或電子郵件等簡便的方法也沒有問題。但是，如果最終進入訴訟等程序，則需要證明「通知已經到達對方」，從這個角度來看，內容證明確實是安全的。

總結

本文中，本所根據系統開發的情境，對於合約解除的相關事項進行了整理。除了實際操作解除的方法之外，如果能理解包括法律上有效的意願表示方式在內的相關知識，這將成為一種容易應用的知識。