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

MONOLITH LAW MAGAZINE

IT

關於系統開發項目的「燃燒」相關法律

IT

關於系統開發項目的「燃燒」相關法律

系統開發這樣的項目並非一蹴可幾的事情,而是需要投入大量的人力、組織、龐大的資金,以及長期的開發時間等眾多資源才能實現。本文將解釋在法律框架下,系統開發項目中「燃燒」這種現象如何被整理,並總結出解決方案的指導原則。

為何專案會「失控」

一個IT系統,即使不是特別大規模的專案,也需要大量的程式檔案和源代碼的堆疊才能正確運作。從螢幕端看到的操作感覺遠遠無法想像(或者反過來說,從螢幕端看到的操作感覺越簡單明瞭的IT系統),往往需要更細緻和精密的設計。

  • 只有交付日期確定,但規格和需求仍然模糊,時間就這樣過去了
  • 團隊成員過於關注公司內部政治問題,由於人際關係壓力,有許多成員中途退出
  • 包括PM在內的管理層缺乏談判能力,並未要求成員適當的報告、溝通和諮詢

等等,具體的失控原因可能因專案而異。然而,從法律角度來看,專案失控的原因可以通過幾種類型相對簡單地整理。

炎上類型1:項目在進行中突然停滯的情況

在系統開發的過程中,項目在進行中突然停滯的典型原因,往往是用戶端和供應商端的溝通不良。首先,系統開發這樣的項目,不僅需要供應商端的專業技術力和組織力,最終使用該系統的用戶端的協助也是必不可少的。

因此,如果對於一個項目,雙方各自的角色並未明確,項目的進行可能會受到阻礙,甚至可能出現某種「業務推託」的情況。關於用戶端的義務和供應商端的義務的法律考量,請參考以下的文章。

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

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

關於各自應承擔的責任的詳細內容,請參考上述文章。但在這裡要強調的是,在一個系統開發項目中,用戶和供應商都有一定的責任。大致上,需求定義、設計(包括基本設計)和驗收等,都需要用戶端的協助才能完成,過去的判例和裁判例都承認了這一點。

另一方面,供應商端在接受用戶端的協助(並且在此同時,也需要進行相應的溝通努力)後,也有責任確保項目的順利進行,並發現和消除阻礙項目進行的因素。

在這種思考方式的基礎上,用戶端有義務從內部實施治理,而供應商端則有義務以外部專家的身份發揮其專業性和技術力。法院已經表明了對雙方義務的認識,並將公平地處理所有的爭議。

此外,「停滯」的情況往往容易在驗收的場景中出現。關於驗收的詳細解釋,請參考以下文章。

https://monolith-law.jp/corporate/estimated-inspection-of-system-development[ja]

在這種情況下,一旦發生爭議,過去的項目進展、會議的討論內容等可以客觀確認的證據將被重視。因此,事先記錄的文件往往具有重要的意義。為了不讓自己的立場處於不利的情況,徹底的文件管理是非常重要的。關於系統開發中文件管理的重要性,請參考以下文章。

https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]

炎上類型2:用戶自行決定解約的情況

在項目進行中途解約的情況是什麼?

另外,本所也需要考慮到項目進行中途,由於用戶的需求,可能會被要求停止的情況。例如,一家公司開始建立一個包括海外據點在內的一體化人事管理IT系統,但公司的海外擴張策略被撤銷。在這種情況下,已經開始的系統開發可能對用戶來說已經不再需要。

首先,企業應如何建立IT系統的問題,其前提是「該企業內部有哪些業務」,這兩者是密不可分的。因此,由於組織結構和業務部門的重大變更,戰略的根本性審查等影響,可能會在事後改變系統的需求(或者變得不需要)。

由於這些情況,項目在進行中途可能會被中斷,這也可能引發各種法律問題。在這種情況下,通常由於是用戶的自身原因,因此根據完成的比例要求報酬等,供應商也會被認可一定的法律權利。根據採用的契約類型,依據的條款可能會有所不同,但其內容可以整理如下:

・如果是承包契約:日本民法第641條
日本民法第641條
→在承包人未完成工作期間,訂單者可以隨時賠償損害並解除契約。
・如果是準委託契約:日本民法第648條第3項(根據情況,也可能根據日本民法第651條要求賠償損害)
日本民法第648條
→如果委託在履行中途因無法歸咎於受託者的原因而結束,受託者可以根據已經履行的比例要求報酬。
日本民法第651條
→1.委託可以由任何一方隨時解除。
→2.如果一方在對方不利的時期解除委託,該方必須賠償對方的損害。但是,如果有不可避免的原因,則不在此限。

燃燒類型3:後來發現交付的系統存在缺陷

如何應對交付後發現的系統問題?

用戶端通常從螢幕操作感來理解系統的完成度,但從接受工作的一方來看,更難解的是數據庫的設計,或者在預想所有操作方法的基礎上,找出測試項目。

也就是說,即使是一開始使用時看似沒有問題的系統,也可能出現以下情況:

  • 隨著註冊數據量的增加,處理速度變慢
  • 即使是在日常基本業務中看似沒有問題的系統,也可能在幾個月或幾年一次的特殊操作中出現錯誤
  • 即使表面上看起來結果輸出正確,但實際邏輯可能是錯的(舉一個簡單的例子,對於用戶端的輸入1+1,即使正確地輸出了”2″,也不一定能正確地進行計算處理。無論輸入什麼計算式,都會返回”2″的輸出,這種邏輯錯誤通常不會在隨意操作螢幕時被發現。在這個意義上,測試過程也需要一定的”技術力”。)

這些情況實際上是可能發生的。如果敢於從法律角度分析這些案例,可能是供應商方面的項目管理義務違反,也就是可能涉及到民法上的不完全履行問題。

在這種情況下,如果合約上沒有特別的規定,通常會涉及到承包合約的規定。

在這種情況下,應該考慮的點可以整理如下。

・如果工作根本就沒有完成
→如果工作沒有完成,原則上就不會產生報酬。但是,如果這是由於用戶端違反合作義務造成的,供應商方面也可以採取法律措施,如索賠。
・如果工作已經完成,但合約目的無法實現
→ 它被視為存在法律缺陷(《民法典》第 635 條)。如果用戶取消服務,供應商不能要求賠償。相反,用戶將能夠向供應商索賠損失。 (有關此類案例的詳細說明,請參閱單獨的文章。)

https://monolith-law.jp/corporate/defect-warranty-liability[ja]

・工作完成了,並且交付了能達成合約目標的成果物,但仍然存在一些應該賠償損害或修補瑕疵的小瑕疵
→供應商可以要求支付報酬,但用戶端也可以要求損害賠償。因此,通常情況下,兩者會以相抵的金額進行抵銷。
・工作完成了,並且內容沒有瑕疵
→這根本不是本文中所說的「燃燒」案例,而是正常地要求支付報酬並完成項目。

可以這樣整理。

總結

每個系統開發的項目都會經歷各種不同且多樣的曲折過程。然而,當本所談到法律項目的「燃燒」問題時,本文所提出的框架將成為一種視覺圖表。與系統開發相關的法律問題確實包含了非常多樣化的主題。

然而,就像系統開發這項業務需要建構性的思考能力一樣,伴隨其而來的風險管理也需要通過不失去對整個領域的全局視野,才能更加建設性地進行。這樣的觀點,您認同嗎?

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:

返回頂部