在系統開發中,承包合約的工作完成是什麼

系統開發通常是一個長期的過程，並且可能會多次被要求更改規格或實現額外的功能。對於接受這項工作的供應商來說，有時可能會陷入看不到出路的困境。對於這些供應商來說，「到底需要做到什麼程度才算是完成了本所的工作」這個問題，有時可能成為一個切身的困擾。

然後，系統開發往往是通過承包合約來進行的，而承包合約是以「工作的完成」為目標的合約。

本文將從法律的角度解釋，「在什麼時機，做到什麼程度的系統開發，才算是完成了工作」這一點。

何謂系統開發的完成

對技術人員來說，系統開發的完成意味著什麼

在系統開發的現場，如果問「系統開發何時完成」，一般的回答可能是「當測試階段結束並交付成果物時」。確實，一般的系統開發流程從需求定義開始，進行功能內容的確認等工作，然後創建各種設計文件，實現程序，最後確認是否正確運行並完成測試階段，並以用戶端的驗收為結束。

因此，從具體業務參與的技術人員的角度來看，「系統開發的完成＝驗收合格」可能是一種常見的理解。

從法律角度看系統開發的完成

另一方面，從法律角度來看，如果問系統開發何時完成，那麼當然，討論的焦點將是供應商在何時何種情況下可以說已完成其在契約上承擔的法律義務。首先，系統開發的契約基本上可以分為承包契約和準委託契約。

https://monolith-law.jp/corporate/contract-and-timeandmaterialcontract[ja]

關於這兩種契約類型的差異的解釋，請參見上面的文章。但是，如果談到系統開發的完成，也就是供應商方面的債務履行，那麼其判斷標準的條款分別如下：

承包契約：日本民法第632條
第632條
承包是當事人一方約定完成某項工作，另一方約定支付該工作結果的報酬，從而產生效力。
準委託契約：日本民法第648條
第648條
1.如果沒有特別約定，受託者不能向委託者請求報酬。
2.受託者在履行委託事務後，才能請求報酬，除非報酬是按期間定的。
3.如果委託因受託者無法負責的原因在履行過程中終止，受託者可以按已履行的比例請求報酬。

系統開發的完成問題主要出現在承包契約

然而，不僅限於系統開發的情況，「工作完成的時間點是何時」這一點基本上是承包契約的問題。在準委託契約的情況下，比起以產生特定結果或成果為債務履行，更多的是專業人才在擁有一定裁量權的情況下，（無論結果如何）適時做應該做的事情。即使在條文上，即使沒有產生預期的成果物，只要事務處理本身進行得適當，也可以請求報酬（第648條第2項），如果因受託者無法負責的原因在履行過程中終止，也可以按比例請求報酬（第648條第3項）。承包契約重視「結果」，準委託契約重視「過程」。

因此，在準委託契約中，更容易出現的法律問題是在進行委託業務的過程中的「注意義務」。也就是說，當被寄予高度信任的前提下，可以追究何時違反了基於委託契約的注意義務。

另一方面，承包契約中重要的是「工作的完成」。如果沒有完成應完成的事情，供應商方面就無法履行其債務，也無法請求報酬。但是，如果已經完成，那麼沒有必要特別問題其過程中的部分。因此，「系統開發項目何時完成」這個問題基本上可以說是承包契約中「工作的完成」這個詞語的法律解釋問題。

何時可以認為系統開發的工作已完成

那麼，本所應該在何時認為「工作已完成」呢？讓本所來看看過去的法院判例。

關於工作完成的法院判例

以下引述的判例中，供應商交付的系統後來在處理速度和通信費用等方面出現了問題。儘管發現了這些問題，但開發過程本身已全部完成，因此爭議的是是否可以說「工作已完成」。結果，法院認定工作已完成。

日本民法第632條和第633條規定，承包人對訂單者的報酬支付時間為承包人完成工作並將工作目標物交付給訂單者的時間，另一方面，該法第634條規定，如果工作目標物有瑕疵，承包人對訂單者承擔保證責任（第一項），在承包人履行其對工作目標物瑕疵的保證責任之前，訂單者有權拒絕支付報酬（第二項）。根據這些民法的規定，法律區分了工作結果不完全的情況，即工作目標物有瑕疵和工作未完成的情況，即使工作目標物存在瑕疵，無論是隱藏的還是明顯的，都不應認為工作未完成。
因此，關於承包人是否完成工作，應以工作是否完成了最初承包契約預定的最後一個工程為判斷標準，訂單者在承包人完成最後一個工程並交付目標物時，不能僅因工作目標物有瑕疵就拒絕支付承包費用。

上述判決認為「工作已完成」是指完成了系統開發的最後一個工程。對於供應商製作的系統存在缺陷（在法律上通常稱為「瑕疵」）的情況，有另一套瑕疵保證責任制度作為救濟措施。

因此，即使將「工作已完成」的概念解釋得稍微寬泛一些，最終也不會對用戶方造成不公平。總結如下：

【承包契約中的債務＝工作的完成＝所有工程的完成】
＝＝＝＝＝＝＝＝＝＝＝
如果工作未完成……
↓
【承擔未履行債務的責任】
＝＝＝＝＝＝＝＝＝＝＝
即使工作完成但存在缺陷……
↓
【在認定債務履行的同時，問題在於瑕疵保證責任】

上述判例顯示了如何區分這些問題。

然而，關於「工作已完成」的問題，本所也可以從「用戶方的驗收合格」的角度來考察。關於用戶驗收進度緩慢的法律問題，本所在另一篇文章中進行了解釋。

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

法律工作完成的意義

在系統開發中，如果「工作完成」被認可，則意味著債務已經履行，因此不會再被追究「債務不履行」的責任。如果是承包合約，除非工作被認定為完成，否則無法請求報酬，即使有特別約定預付款等，這些基本上也必須退還。另一方面，如果工作的完成被認定，供應商就需要承擔瑕疵擔保責任和合約上的品質保證問題。

供應商從債務不履行責任中獲得解放，意味著用戶方面解除合約的餘地將大幅度縮小。因為基於瑕疵擔保責任的合約解除，僅限於無法達成合約目的的情況。如果合約被解除，供應商也會失去請求報酬的權利（簡單來說，就是不再有報酬進來），因此在實務上，經常會出現圍繞「工作完成」的爭議。

關於系統開發合約的「解除」，本所在以下的文章中進行了詳細的解釋。

https://monolith-law.jp/corporate/cancellation-of-contracts-in-system-development[ja]

關於工作完成的各項注意事項

如何看待規格變更與額外開發

對於供應商來說，可能會遇到「雖然已經能夠完成最初提出的規格，但卻被要求改變規格或增加功能，即使想要結束工作，也無法劃下句點」這樣的情況。在這種情況下，「何時結束系統開發」這樣的問題就會浮現。關於這個問題的詳細解釋，請參見以下的文章。

https://monolith-law.jp/corporate/increase-of-estimate[ja]

也要注意民法的修訂

此外，基於承攬合約的瑕疵擔保責任規定，由於傳統條文之間的關聯複雜且難以理解，因此這是一個受到民法修訂影響較大的領域。在民法進行修訂的過程中，關於如何理解「瑕疵」這一概念，請參見以下的文章進行詳細解釋。

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

總結

本文中，本所針對可能會陷入「看不見出口」的情況的系統開發項目，解釋了如何將其與「工作完成」這一日本法律概念相連接的途徑。每個項目的出口可能會因開發要求而異，但是，一旦發生爭議，法律上的「工作完成」概念往往能成為指引的線索。本所認為這種情況並不少見。