MONOLITH 律師事務所+81-3-6262-3248平日 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

驗收後系統出現故障時應採取的對策

IT

驗收後系統出現故障時應採取的對策

從一般來說,系統開發是根據在需求定義階段確定的內容進行程式的實現,最終確認是否符合規格的完成,並由用戶和供應商共同確認,並以驗收合格為結束。

然而,在現實中,測試過程和驗收合格時可能無法發現的錯誤和問題,實際上在後續的運營階段等可能會被發現。一旦接受了交付,從法律上來說,我們可以要求什麼呢?

即使在驗收合格後或測試工程後,仍可能存在漏洞,這並不奇怪

從技術的角度來看,即使在供應商完成各種測試工程、用戶驗收合格後,仍可能出現各種漏洞或故障,這並不罕見。用戶在驗收工程中通常會主要進行從螢幕上可以確認的輸入輸出檢查。然而,IT系統除了用戶可以從螢幕上確認的外觀之外,往往在背後的資料庫或負責各種計算、控制的程式部分,具有複雜而細緻的結構。因此,從用戶的角度來看,從螢幕上的輸入輸出檢查中可以查詢的內容本來就有限。因此,透過檢查來全面驗證在後續運營階段可能出現的所有故障的可能性,實際上並不現實。

就像上述的情況,即使從負責開發業務的供應商的角度來看,也是同樣的情況。例如,確認實施的程式內容是否存在漏洞或故障,就是「測試工程」。但是,在測試工程中,是否真的可以驗證所有可能的漏洞或故障,並不一定。即使在開發的系統開始在業務中全面應用之後,也可能出現供應商未預期的操作,或者開始實際註冊大量的資料,或者多個用戶開始同時訪問等情況,要製作一個可以持續運行而不受影響的系統,本來就需要優秀的技術。

在驗收或測試等階段,發現所有可能的漏洞或故障並不現實,實際開始使用後可能會出現各種問題,這就是IT系統,首先應該理解這一點。

債務通常被視為已履行

在實際開始使用程式後出現的問題,通常很難追究供應商的責任。

那麼,當這種問題實際發生時,我們應該如何應對呢?我們將按照法律程序來整理。

首先,即使是事後,如果發現了各種錯誤或問題,用戶可能會想要追究至今為止一直委託業務的供應商的責任。然而,通常情況下,如果已經完成交付並且已經通過驗收,則很難追究基於債務不履行的責任。

首先,除非有特殊的協議,否則系統開發契約通常會涵蓋日本民法中的承攬契約規定。

在承攬契約中,「工作的完成」是債務履行的要求。

總的來說,一旦接受交付並完成驗收,則通常會假定債務已經履行,然後問題就變成了後續的品質保證問題,也就是是否可以追究瑕疵擔保責任。

基於瑕疵擔保責任追究責任的途徑

那麼,如果基於瑕疵擔保責任要求供應商對應,我們應該如何以何種順序來考慮呢?讓我們一起來確認以下內容。

首先確認錯誤或故障的嚴重性和深度

當錯誤或故障在事後被發現,並被視為法律上的「瑕疵」,要求某種保障時,錯誤或故障的嚴重性就成為問題。法律上的瑕疵問題,首先

  1. 即使可以稱為錯誤或故障,但只是輕微的,並不能被視為法律上的「瑕疵」
  2. 雖然符合法律上的「瑕疵」,但仍然可以實現契約的目的
  3. 符合法律上的「瑕疵」,並且無法實現契約的目的

這三種情形。區分第1和第2的基準是「可否基於瑕疵擔保責任追究責任」,而區分第2和第3的基準則是「可否基於瑕疵擔保責任解除契約」。

第634條

1.當工作目標物有瑕疵時,訂單者可以對承攬人設定適當的期間,要求其修補瑕疵。但是,如果瑕疵不重要,並且修補需要過多的費用,則不在此限。

2.訂單者可以代替瑕疵的修補,或者與其一起,提出損害賠償請求。在這種情況下,應適用第533條的規定

第635條

當工作目標物有瑕疵,並且因此無法實現契約的目的時,訂單者可以解除契約。但是,對於建築物和其他土地工程物,則不在此限。

關於這種「瑕疵」的階段性區分,本所在以下的文章中進行了詳細的解釋。

接著明確應向供應商提出的要求

接下來,我們需要明確應向對方提出什麼要求。如果你想解除契約,僅證明它是瑕疵是不夠的,還需要證明它是「無法實現契約目的」的程度。在這裡所說的「目的」的判斷,系統開發項目開始時的會議記錄和規格書的記載事項等是重要的線索。即使在驗收合格後,也可能出現錯誤或故障在事後被發現的情況,因此在開發項目結束後,應該徹底保存各種文件。

除了解除契約外,可行使的瑕疵擔保責任相關權利還包括損害賠償請求權和瑕疵修補請求權等。

其他注意事項

視野要放遠至專案完成,並掌握文件管理與法律程序的流程。

進行契約解除等法律行為時,應注意其方式

如果以瑕疵擔保責任的內容進行契約解除,則應同時掌握進行解除所需的相關規定,例如契約解除的效果、有效的意思表示方式、以及如何進行通知以避免日後的問題等。

希望以談判而非爭議的方式解決問題

此外,這些法律論述並不僅在訴訟發生時才有意義。訴訟解決爭議對雙方當事人來說都是一種重大負擔。相反,這些法律見解應該在訴訟前的談判階段就大力運用。

應區分軟體的錯誤和功能不足

如果實現的功能或規格存在錯誤,或者根本就缺乏必要的功能,那麼討論的內容將會有所不同。如果缺乏必要的功能,那麼在承攬合約中可能無法認定「工作的完成」,也可能無法認定債務已履行。

另外,即使缺乏這些必要的功能或規格,如果在需求定義階段用戶方未能提供適當的資訊,那麼可能應評價為將其視為合約內容的一部分本身就是不適當的。

總結

在項目進行的過程中出現的問題,有時會在項目進行中被發現,有時則在運營階段等事後被揭露。即使順利完成所有的工程,也不能完全放心,這似乎正是系統開發項目的特點,並在「瑕疵擔保責任」這一制度中得到體現。本所認為,不僅要徹底進行以項目結束後為前瞻的文件管理,也要理解這一系列的流程。

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

返回頂部