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

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

為何專案會「失控」

一個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″的輸出，這種邏輯錯誤通常不會在隨意操作螢幕時被發現。在這個意義上，測試過程也需要一定的”技術力”。）

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

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

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

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

可以這樣整理。

總結

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

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