如果系統開發業務因用戶方便而中斷,應如何應對?
系統開發這項業務,通常往往會以長期項目的形式進行。然而,如果在進行中的系統開發項目中,用戶方面單方面表示「該系統已經不需要了,不用再開發」,那麼,作為接受工作的供應商方面能做些什麼呢?
本文將整理系統開發合約的特點,並解釋在這種情況下的應對策略。
思考用戶因故中斷的意義
系統開發這種契約有幾個應該被稱為特色的點。一個是,其工期通常較長,作為管理項目的義務,供應商方面也承擔著大量的義務和大量的裁量權。關於供應商方面承擔的項目管理義務的整體內容,本所在以下的文章中詳細解釋。
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]
總結
本文中,本所解釋了如何處理因用戶方便而中斷項目的情況。然而,本文的重點是,本所需要考慮「是否真的可以說是用戶方便」和「供應商方是否真的沒有過錯」。
系統開發這種項目的特點是供應商和用戶都承擔著重大的義務。因此,如果不事先考慮好是否真的可以單方面歸咎於對方,可能會導致更加火上加油的情況,這是本所應該意識到的。
Category: IT
Tag: ITSystem Development