什麼是系統和軟體開發的契約不適合責任?解釋修訂點
如果訂購的系統在交付後出現錯誤,本所應該如何從法律角度處理呢?
操作方法困難、處理速度慢、訂購的功能未能提供…。對於這些系統問題,作為訂購者,本所將對進行系統開發的供應商提出「契約不適合責任」的問題。
「契約不適合責任」是在2017年(西曆2017年)的日本民法修訂中,取代被廢止的「瑕疵擔保責任」而新設的。因此,本所需要注意這次修訂對系統和軟體開發的影響。
交付後常常出現的問題。為了避免這些問題,本所將解釋「契約不適合責任」的內容以及修訂帶來的影響。
民法中契約不適合責任的修訂點
「民法的部分修訂法」於2017年(平成29年,西曆2017年)6月2日公布,並於2020年4月1日開始實施。
在民法中,關於契約等的最基本規則部分被稱為「債權法」。
自1896年(明治29年,西曆1896年)制定的債權法以來,近120年來幾乎沒有進行過修訂。
因此,為了適應現代社會,這次進行了大幅度的修訂。
具體的修訂點涵蓋了許多方面,其中,新設的契約不適合責任概念是主要的修訂點之一。
因此,被稱為「瑕疵擔保責任」的部分已被更改為「契約不適合責任」。
何謂「契約不適合」
「契約不適合」是指根據當事人的協議或契約的意旨和性質,原本應具備的功能、品質、性能、狀態並未達成。
這個「契約不適合」的概念是在民法修正後,取代了原先「瑕疵」的概念。
在系統或軟體開發中,如果完成的系統與預先設定的規格不符,或者系統或軟體並未具備其性質應有的功能或性能等情況,都屬於「契約不適合」。
在判斷是否存在「契約不適合」時,會重視當事人的協議和契約的意旨、性質。
因此,將系統或軟體開發的目的和訂購經過等以書面形式記錄下來,以明示訂購者的需求和期望是非常重要的。
軟體的故障等符合「契約不適合」的情況
軟體出現問題,修復延遲的情況
首先,本所可以考慮軟體出現不能忽視的故障,並且需要回溯到設計階段進行審查等,無法立即處理的情況。
例如,導入的庫存查詢系統的搜索處理需要超過30分鐘等問題出現,必須另外手寫庫存台帳來應對客戶的問詢。對於這種情況,有判例認為符合現行「契約不適合」中的「瑕疵」(東京地方裁判所,平成14年(2002年)4月22日)。
故障逐步出現的情況
另外,本所也可以考慮即使每個故障都是輕微的,並且修復不需要花費太多時間,但是故障反覆出現,需要花費長時間才能修復所有的故障並使其正常運作的情況。
例如,導入的庫存查詢系統反覆出現故障,未來會出現多少故障,修復需要多少時間都不清楚,無法使用該系統進行正常的業務操作。在這種情況下,可以說是「契約不適合」。
軟體缺陷等不屬於「契約不適合」的情況
及時修復或採取替代措施的情況
在判例中,即使用戶指出了軟體的缺陷等問題,只要及時進行修復,或者與用戶協商後採取認為適當的替代措施,就不會被認定為「瑕疵」(東京地方裁判所,平成9年(1997年)2月18日)。
在系統或軟體的開發中,完全避免出現錯誤是不可能的,一定會出現一些問題,這是無法避免的。
因此,即使存在問題,只要及時進行修復等措施,就不應該被認定為「瑕疵」。
這種觀點在現行的「契約不適合」下也應該是一樣的。
此外,這裡所說的「及時」等判斷的依據是在系統開發過程中製作的會議記錄等證據。
特定個人無法輕易理解操作方法的情況
關於操作性和易用性,由於主觀因素的影響較大,因此,如果一般使用者無法使用,則會被認定為「契約不適合」。
僅僅因為特定個人無法輕易理解操作方法,並不能認定為「契約不適合」。
供應商的工作以外的原因導致問題的情況
如果系統或軟體開發的供應商的開發工作等與問題無關的原因導致問題,則不能說這個系統或軟體存在「契約不適合」。
例如,如果由於供應商不負責採購的硬體故障導致問題,則不會被認定為「契約不適合」。
【補充】用戶的指示導致問題的情況
如果由於用戶的錯誤指示,導致完成的系統或軟體出現問題,即使系統等被認定存在「契約不適合」,供應商原則上不需要承擔「契約不適合」的責任。
例如,在業務系統的開發中,如果用戶對只有他們才知道的情況給出了錯誤的說明,因此根據這些錯誤的信息開發的軟體出現問題,則供應商不需要承擔任何責任。
這種判斷背後的思考是,軟體開發的訂購方,也就是用戶,也有「合作義務」。詳細情況請參考以下文章。
根據契約不適合責任,業主・買主可以提出的請求
在這裡,本所將解釋與系統和軟體開發相關的契約不適合責任的內容,並考慮到修訂後的變更。
修復請求
如果故障被評估為契約不適合,則訂購者可能會提出修復請求。
在修訂前,如果問題的瑕疵不重要,且修復需要過多的費用,則無法提出修復請求。這種限制已被修訂刪除。
然而,即使在修訂後,如果「契約不適合不重要,且修復需要過多的費用」,修復請求仍可能無法被認可。
損害賠償請求
如果由於系統或軟體的故障,無法正常營業或需要支付額外費用,則訂購者可能會提出損害賠償請求。
在修訂前,除非有特殊約定,否則無論是否有過失,都可以提出損害賠償請求。
然而,修訂後,如果履行者有免責事由(不能歸咎於債務人的事由),則無法提出損害賠償請求。
因此,如果供應商能證明有免責事由,則不需要承擔損害賠償責任。
契約解除
以系統或軟體的契約不適合為理由,開發契約可能被解除。
在已經介紹的判例中,由於庫存查詢系統的搜索處理需要超過30分鐘,處理時間過長,甚至導致無法使用終端等問題,因此不得不放棄繼續使用該系統,因此認可了契約的解除(東京地方裁判所,平成14年(2002年)4月22日)。
在修訂前,只有在「無法達到契約目的」的情況下,才能解除契約。但是,這種限制已被修訂刪除。
然而,即使在修訂法下,如果契約不適合的程度「輕微」,則解除權仍可能不會被認可,這一點需要注意。
報酬減少請求
報酬減少請求權是由於修訂而新設的。
如果系統有故障,訂購者請求修復,但經過相當長的時間仍未進行修復,則訂購者可能會提出報酬減少請求。
負責期間
- 修復請求
- 損害賠償請求
- 契約解除
- 報酬減少請求
對於這些權利的行使,有一定的期間限制。
具體來說,只有在訂購者從知道系統或軟體存在契約不適合的情況「一年內」通知供應商的情況下,才能行使權利。
在修訂前,權利行使期間僅限於從「交付系統或軟體的時候起一年內」。因此,可以說修訂後可以行使權利的期間變長了。
另外,除了這種期間限制外,基於契約不適合責任認可的上述權利也適用消滅時效的規定。
因此,例如,如果在接收系統或軟體的交付11年後首次知道存在故障,則損害賠償請求權等權利已經過了「十年」的消滅時效期間,因此,無論是否在「知道契約不適合的一年內」通知,都無法行使權利。
拒絕支付報酬
訂購者可以在開發商進行修復或損害賠償之前,拒絕支付全部報酬。
考慮到契約不適合的契約條款要點
契約不適合責任的規定是可選擇的,可以通過雙方特約來限制責任內容或縮短權利行使期間。
因此,本所將在這裡解釋在系統和軟體開發中,需要注意與契約不適合責任相關的契約條款。
要點1:成為契約不適合對象的事件或範圍
如果對系統或軟體有不滿,訂購者可能會想要追求供應商的契約不適合責任。
然而,作為供應商,即使只是規格的問題,也不能接受因為不喜歡就被追求契約不適合責任。
此外,供應商可能會因為防止不公平的契約不適合責任追求而大幅提高報價,這對訂購者也是不利的。
因此,為了明確契約不適合的對象和範圍,重要的是要將訂購者希望引入什麼樣的系統,具有什麼樣的功能等目的寫入文件,並確實反映在規格書中。
此外,對於規格書中規定的事項,如果按照規定交付了系統或軟體,即使規格上有些不便,也可以考慮明確表示不屬於契約不適合。
通過這個規定,即使按照規格書開發,也可以防止因訂購者的喜好而被追求契約不適合責任。
要點2:保證期限的明確化
契約不適合責任的權利行使期間,並非從「交付時」開始,而是從「知道契約不適合的時候」開始計算。
此外,即使適用消滅時效,該期間最長也是「十年」,是一個長期的過程。
對供應商來說,根據情況,可能需要無償保證「十年」這樣長的時間,這是一個很大的負擔,因此在報價階段必須加價。
另一方面,作為訂購者,根據系統或軟體的使用期間等靈活設定保證期間,可能在費用等方面更有利。
因此,可以考慮根據系統等的內容靈活設定保證期間。
要點3:契約不適合發生時的對應
當契約不適合發生時,可以通過雙方的協議,限制可以行使的權利,例如民法所認可的損害賠償請求或解除等。
作為訂購者,需要確實理解契約中有哪些限制。
總結:建議向律師諮詢包含「契約不適合責任」的契約書的製作
由於日本民法(Japanese Civil Law)的修訂,對於系統和軟體開發的法律關係也產生了重大影響。
如果交付的系統出現問題,是否屬於「契約不適合」,以及可以追究的責任是什麼,並不能一概而論。
此外,為了預防爭議,開發契約階段需要訂購者和供應商之間進行充分的討論。
如果您對製作契約書有任何疑慮,請務必向專業的律師諮詢。
Category: IT
Tag: ITSystem Development