如果系統開發的報酬未支付,相關的法律是什麼?

對於承接系統開發業務的供應商來說，或許最大的風險就是「即使已經交付成果，用戶卻不支付報酬」的情況。由於系統開發的成本大部分來自於具有技能的人才，如程式設計師等，因此往往需要支付大量的人力成本。如果銷售收入的回收出現問題，有時可能會導致生死存亡的問題。本文將從法律的角度，針對用戶不支付報酬的情況，討論供應商應該考慮的事項。

首先，需要確認是否已達到可以請求報酬的狀態

• 儘管供應商已向用戶交付了成果物，但用戶並未接受交付，導致報酬請求業務也停滯不前
• 儘管認為已完成驗收，但與用戶的認識存在某種誤解，因此用戶不願支付報酬

這種情況在現實中是完全可能發生的。

此外，用戶檢查完成的系統規格並接受交付，在系統開發的術語中被稱為「驗收」。關於驗收的意義以及當其進展不順時應考慮的事項，本所在以下文章中進行了詳細解釋。

相關文章：系統開發的驗收與假定驗收條款的適用場景[ja]

關於驗收本身的整體說明，本所將在上述文章中進行，但從法律角度來看，是否可以說用戶的驗收已完成，需要考慮「假定驗收條款」的規定。

在考慮這一點的同時，假設用戶不願支付報酬，首先應考慮的點應該是以下幾點：

1. 工作是否已經完成，或者還未完成
2. 是否可能適用瑕疵擔保責任（日本民法第635條）

之所以首先需要確認上述兩點，是因為如果工作已經完成，且不適用瑕疵擔保責任（日本民法第635條），那麼即使提起訴訟，也無法期待得到報酬的支付。

那麼，具體來說，供應商方的負責人應該調查哪些事項來考慮上述兩點呢？以下本所將看一下需要確認的文件有哪些。

應確認的文件以查詢報酬請求的可行性

另外，關於如何管理應開發系統的規格變更，以及變更管理書的編寫方法等，本所在另一篇文章中進行了詳細的解釋。

相關文章：從法律角度看，系統開發中的變更管理應如何進行[ja]

接下來，確認可以請求多少報酬

關於可以請求多少金額，原則上應該在契約中有所記載。然而，如果在事後進行了規格變更等操作，也可能會出現沒有留下完整契約（或類似文件）的情況。關於基於規格變更、功能添加等後續原因的估價重新計算方法，本所在以下的文章中進行了詳細的解釋。

相關文章：系統開發的估價金額是否可以事後增加[ja]

雖然估價的重新計算方法如本文所述，但特別從考慮是否可以增加請求金額的角度來看，本所需要主要考慮以下幾點：

1. 是否有關於額外開發、功能修正部分的估價單，以及其內容
2. 用戶對估價單的反應內容
3. 是否有關於引起額外開發、功能修正的情況以及其金額的協議在問題管理清單中的記載

本所需要著重考慮的是這些點。關鍵在於，是否可以說用戶同意了「以該金額訂購業務」（也就是說，是否可以說契約已經成立）。

最後，本所來討論實際進行訴訟時的重要問題

注意可能會遭到反訴的風險

在系統開發中，無論是用戶還是供應商，一方向對方提起訴訟時，往往會遭到對方的反訴。換句話說，就是在拒絕支付報酬的情況下，用戶方也可能有一些理由。

首先，系統開發中，用戶方也有各種合作義務，但首先要明確的是，作為系統開發專家的供應商方擁有廣泛的裁量權和重大的責任。關於供應商方在系統開發中所承擔的項目管理義務，本所在以下的文章中有詳細的解釋。

相關文章：什麼是系統開發中的項目管理義務[ja]

因此，是否可以歸咎於單方面拒絕支付報酬的用戶方，這是需要事先仔細考慮的問題。從過去的判例來看，最初由供應商方提出報酬請求並提起訴訟，但用戶方反過來提出恢復原狀義務和損害賠償請求的案例是很多的。

也需要考慮是否真的對業務有利

即使供應商方的主張被接受，並且在訴訟中確認可以實際請求報酬，但如果事態發展到需要訴訟，那麼預計未來的交易將變得困難。此外，即使在訴訟中自己的主張被接受，但實際收到報酬可能需要相當長的時間，這也是需要做好心理準備的。考慮到進行訴訟所需的時間和成本並不小，找到妥協點並努力達成可能更為明智和合適。

總結

當用戶不支付報酬時，本所需要法律上審查該問題，這需要確認多種類型的文件。此外，不僅僅是需要做好文件管理，還需要考慮到如果最終決定訴訟，組織將面臨哪些風險和劣勢。

確實，日常的文件管理通常屬於現場級別的工作。然而，一旦決定根據存儲的文件和資料提起訴訟，這可能成為重大的經營決策。在這種非常規情況下，現場和管理層的團結力和組織力將受到考驗。本所應該理解這一系列的流程。