如果系統開發業務因用戶方便而中斷,應如何應對?

系統開發這項業務，通常往往會以長期項目的形式進行。然而，如果在進行中的系統開發項目中，用戶方面單方面表示「該系統已經不需要了，不用再開發」，那麼，作為接受工作的供應商方面能做些什麼呢？

本文將整理系統開發合約的特點，並解釋在這種情況下的應對策略。

思考用戶因故中斷的意義

系統開發這種契約有幾個應該被稱為特色的點。一個是，其工期通常較長，作為管理項目的義務，供應商方面也承擔著大量的義務和大量的裁量權。關於供應商方面承擔的項目管理義務的整體內容，本所在以下的文章中詳細解釋。

https://monolith-law.jp/corporate/project-management-duties[ja]

另一個是，即使用戶是客戶，他們也有廣泛的義務協助供應商的業務。由於這是在自家內部使用的系統，所以不能只是「全權交給」供應商。從公司內部，也有義務適時協助供應商發揮專業性並進行業務。關於這一點，本所在以下的文章中進行了詳細的解釋。

https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]

簡單地將以上內容總結在這裡，供應商和用戶之間，既有開發系統的「外部供應商」和支付報酬的「客戶」這種對價關係，同時也有朝著實現項目的共同目標協同工作的「夥伴」這種面向。這種關係的複雜性，通常不會出現在訂製西裝的裁縫等地方，也是與系統開發相關的契約的一個重要特點。由於這種關係的複雜性，與系統開發相關的爭議一旦發生，就會在如何法律整理雙方關係的問題上變得複雜並容易產生糾紛。

如果用戶方面改變主意，突然說「最終本所不再需要那個系統，所以不需要再推進項目」，那麼本所應該如何理解雙方的權利和義務關係呢？在某種意義上，思考這個問題意味著在面對這種複雜的契約關係時，提供了一個運用法律思維的實例。以下，本所將在假設這種情況的基礎上，整理出應該考慮的事項。

首先，整理提出解約的原因

從供應商的角度來看，即使在「用戶單方面希望中斷項目」的情況下，也不一定能與用戶共享這種認識。例如，假設有一個項目正在開發一個管理海外駐點員工人事的系統，後來海外擴張計劃本身被撤銷，因此開發該系統變得不再需要。確實，僅從這個解釋來看，可能會被認為是用戶單方面的改變主意。

但是，如果在達到這樣的決定的過程中，供應商也存在著各種工程延遲等項目管理義務違反的實際情況，並且開發本身的進展困難，也成為公司政策變更的一個原因，那又該如何呢？

如前所述，系統開發是供應商和用戶共同承擔大量義務，並密切協作推進的。因此，即使是用戶提出希望中斷，並且供應商認為這是用戶自行解約的情況，也應該認識到可能會被指出供應商的責任問題，並可能會被反駁為基於債務不履行的解除或協議解約等。

是自行解約，還是基於債務不履行的解除，還是協議解約，這些區別往往會根據項目的進展狀況和至今為止的談判過程等，根據個別案例進行判斷。因此，如果供應商在認為是用戶自行解約的情況下進行後續處理，則應在會議記錄等中明確記錄此事，以防止後來在此問題上產生爭議。

接著確認報酬請求與損害賠償的依據條款

在考慮上述因素後，如果可以將話題推進為用戶自行取消的情況，接下來，本所將考慮供應商是否可以根據完成比例向用戶請求報酬，或者是否可以請求損害賠償。

在這種情況下，應參考的條款會因合約類型而異。系統開發合約大致上可以區分為承包合約和準委託合約。

https://monolith-law.jp/corporate/contract-and-timeandmaterialcontract[ja]

然後，對於準委託合約和承包合約，日本民法（Japanese Civil Code）有以下規定：

a.)準委託合約的情況
報酬請求：日本民法第648條第3項
當委託因無法歸咎於受託者的原因在履行過程中終止時，受託者可以根據已完成的比例請求報酬。
損害賠償請求：日本民法第651條
1.委託可以隨時由各方當事人解除。
2.當一方當事人在對方不利的時期解除委託時，該當事人必須賠償對方的損害。但是，如果有不可避免的原因，則不在此限。

b.)承包合約的情況
損害賠償請求：日本民法第641條
在承包人未完成工作期間，訂單者可以隨時賠償損害並解除合約。

另外，根據日本民法第641條的損害賠償範圍，不僅包括已經支付的費用，還被認為廣泛包括「如果合約未被解除，則可以獲得的利潤」。這是因為，從訂單者的角度來看，即使工作變得不必要，法律也強制完成工作是無意義的，因此，在這種情況下，反而通過支付相同的對價來保護接單者的利益是合理的。

然而，關於根據日本民法第641條的損害賠償，供應商和用戶之間的個別合約中，損害賠償的對象可能被排除在外的情況並不少見。在這種情況下，當事人之間的個別約定（即合約）將優先，因此，這些日本民法的規定可能不會適用，需要注意。

進一步證明成交量和損害

在用戶自行解約的情況下，常見的合約規定是可以要求支付已完成部分（即成交量）的委託費用，並可以要求賠償損害。因此，供應商通常需要證明成交量和損害以提出損害賠償請求。

然而，這種證明成交量，也就是完成比例的工作，實際進行起來可能會非常困難。因為，要確認哪些工作項目完成了多少，特別是當有多個分包商的情況下，進行進度確認的訪談等，實際進行起來可能會非常多。此外，製作支持訪談結果的資料，以及將訪談內容本身文檔化等工作，如果全部進行，工作量將會非常大。即使這樣，最終還是有可能被認為證據不足，那麼為證明準備的工作就可能會白費，這也是一個大問題。

考慮到這些問題，可以考慮的對策包括，在合約階段就明確規定，如果中途解約，則按照解約時的天數進行按日計算等，使計算更為簡單。此外，考慮到證明成交量需要花費大量時間，可以考慮放棄對成交量本身的請求，而選擇對”已完成部分的開發所需費用”提出請求。如果是公司內部的開發費用，則可以使用”工時×單價”這種簡單的計算公式來輕鬆計算。特別是在利潤率較低的項目中，通過優先考慮基於費用的請求，可以在重視債權回收的易行性的同時進行損失補償，這在許多情況下都可能成為更實際的救濟措施。

反過來，使用者應該考慮什麼？

順帶一提，對於打算自行終止合約的使用者，也有一些事項需要事先考慮。那就是，與供應商之間，應支付的損害賠償金額大約會是多少，等等，需要確認的概算金額。這裡所說的「概算」，是為了在後續的談判過程中有一個大致的參考，即使不是準確的金額，也足夠了（如果因為終止合約的意向表示遲延而導致本末倒置，那就太遲了）。

如果確認的概算金額被認為過高，應該要求對方解釋原因，但如果為了壓低支付金額而進行過度的談判，可能會引發無意義的訴訟等，使情況更加混亂。如果雙方之間的談判困難，諮詢律師也是一種選擇。

另外，本文的解釋是基於已經達成系統開發合約的前提下進行的，但在實際的系統開發場景中，「合約是否有效達成」也常常成為爭議點。關於這一點，本所在下面的文章中進行了詳細的解釋。

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

總結

本文中，本所解釋了如何處理因用戶方便而中斷項目的情況。然而，本文的重點是，本所需要考慮「是否真的可以說是用戶方便」和「供應商方是否真的沒有過錯」。

系統開發這種項目的特點是供應商和用戶都承擔著重大的義務。因此，如果不事先考慮好是否真的可以單方面歸咎於對方，可能會導致更加火上加油的情況，這是本所應該意識到的。