關於系統開發的驗收與視為驗收條款的適用情形
在系統開發的過程中,「驗收」階段往往容易出現法律問題。
「驗收」是指當承包商交付成果物時,發包商需要進行的檢查和點檢義務。假設,交付後發包商長時間未進行「驗收」,則承包商(供應商)將處於法律上的不穩定地位。
為了解決這種問題,契約中通常會包含「視為已驗收」的條款。
本文將根據實際的判例來解釋在何種情況下會發生「視為已驗收」之情形。
什麼是系統開發中的驗收
首先,在系統開發項目中的「驗收」,是指訂單的接收者,也就是供應商,對其交付的成果物(在這裡指的是IT系統)進行檢查和審核,以確認是否符合訂單發出者,也就是用戶,所訂購的目的和規格。
從開發者的角度來看,這可以被視為「確認是否真的完成了」的過程,也可以將其定位為測試工程。
由於開發IT系統的工作性質,訂單接收者即供應商的裁量權往往較大,因此實際製作的產品與用戶所需的產品之間可能會出現差異。
一般來說,驗收合格意味著用戶自己確認實際交付的成果物符合他們所需的產品(或者是他們要求開發系統的目的)。
在實際的合約操作中,即使可以預見到系統可能存在瑕疵,但仍有許多合約將驗收合格作為支付報酬的條件。
注意「視為已驗收條款」
一旦在驗收階段出現問題,用戶和供應商都會陷入困境。
例如,即使供應商已經完成了成果物並已經展示出來,但由於用戶端負責人的情況,不進行驗收,那會怎麼樣呢?
為了應對這種情況,系統開發的契約中通常會包含所謂的「視為已驗收條款」。
什麼是視為已驗收條款
第 28 條 (本軟體的驗收)
甲方應在個別契約約定的期間(以下稱「檢查期間」)內,根據前條的檢查規範書進行檢查,並檢查系統規範書和本軟體是否一致。
2. 如果本軟體符合前項的檢查,甲方應在檢查合格書上簽名蓋章,並交付給乙方。此外,如果本軟體不符合前項的檢查,甲方應立即向乙方交付明確說明不合格原因的書面,並要求修正或補充,如果不合格原因被接受,乙方應在協議的期限內免費修正並交付給甲方,甲方應在必要的範圍內,再次進行前項規定的檢查。https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf [日語]
3. 即使檢查合格書未交付,但如果甲方在檢查期間內未以書面形式明確說明具體原因提出異議,則本軟體將被視為通過了本條規定的檢查。
4. 本條規定的檢查合格將被視為本軟體的驗收完成。
在法律上,第3項的「視為」這種說法是一個值得注意的點。從法律術語的角度來看,「視為」和「推定」實際上有完全不同的含義。
視為・・・
→即使實際上不是〇〇,但在法律上被視為與〇〇相同
(例)如果在考試中操作智能手機,將被「視為」作弊
→無論實際上操作智能手機的行為是否為作弊,都將被視為作弊並採取相同的措施。
推定・・・
→除非有特殊的證據否定〇〇這個事實,否則將〇〇視為事實。
(例)如果在考試中看智能手機,將被「推定」為作弊
→原則上將被判定為作弊,但如果能夠反證說明是作弊以外的用途,那麼這個判定可以在後來被推翻。(然而,通常在考試場地不會聽到這樣的公告。)
換句話說,「推定」和「視為」在推翻它們的門檻上有著巨大的差異。「無論驗收是否合格,都將被視為合格」的含義就包含在其中。
與視為已驗收條款規定相關的判例
過去也有視為已驗收條款規定在審判中發揮決定性作用的例子。例如,以下引用的判決文是用戶在規定期間內未進行驗收,並在事後提出所需功能未實現的訴訟,並進行審判。然而,法院根據視為條款規定,判定已經完成了交付。
在本契約中,Y公司在本系統交付後,應立即進行檢查,並在10天內進行驗收並以書面形式通知,如果在上述期限內未通知,則視為已驗收合格,在本案中,不能認定有不符合檢查的地方的通知,因此,可以確認交付和驗收的事實。
東京地判平成24年2月29日判決
然而,即使存在這種視為已驗收條款,也存在否定其適用,認定供應商違反義務的判例。
以下引用的判決文的案件是,儘管需要供應商的協助進行驗收,但供應商卻未提供協助,這一點與前述的判例不同。
原告(供應商)主張,被告(用戶)在成果物交付日起10天內未通知檢查結果,因此根據本軟體開發契約書第9條第4項,被視為成果物已驗收。然而,要達到這樣的結果,需要原告的協助,而原告並未對被告提供這樣的檢查協助,因此,在本案中,即使被告在成果物交付日起10天內未通知檢查結果,也不能根據本軟體開發契約書第9條第4項視為被告驗收了本軟體。
東京地判平成16年6月23日
視為已驗收條款本身的制度目的可以認為是「儘管想要儘快進行驗收,但由於用戶方的單方面原因,無法進行,工作停滯」,從這種不穩定的立場中儘快釋放供應商,並保持雙方關係的公平。
因此,遠離這種目的,「以視為已驗收條款為盾,盡可能地拖延驗收,並將不良品等強加給他人」是不可能的。
一旦被「視為」驗收合格,用戶必須支付系統開發的對價。考慮到這種重要性,法院也將供應商的協助情況納入考慮,並努力做出公平的判斷。
作為支持這種判斷的證據,除了契約書外,隨著系統開發的進展,議事錄也可能成為重要的證據。
另外,供應商作為系統開發的專家,對於項目應該承擔什麼樣的全面義務,請參考以下的文章。
即使驗收業務原則上應由用戶方進行,但作為系統開發的專家,供應商也應該對驗收提供各種協助,這一點可以從以下文章的內容中自然理解。
驗收時發現瑕疵的情況
然而,在驗收階段,可能會發現系統的不足(在法律上,我們通常使用「瑕疵」這個詞)。關於這種情況的法律問題,請參考以下的文章。
總結
在系統開發中,「驗收」原則上代表供應商方面的義務履行的完成,因此,對於使用者和供應商來說,都可以說是非常重要的。為了避免在此處產生嚴重的問題,無論是訂單方還是接單方,都應對「視同驗收條款」有充分的理解。
然後,考慮到萬一驗收進行不順利的情況,從事前的合約階段開始,雙方都應該對與驗收相關的規定特別進行細緻的意識協調,這被認為是非常重要的。
Category: IT
Tag: ITSystem Development