系統開發的合約是否能在無合約書的情況下成立?

在系統開發中，開發商在製作合約書之前就開始進行工作的情況並不少見。然而，這種流程實際上是「危險」的。如果沒有製作合約書，一旦後來出現問題，訂單方可能會說「合約還沒有成立，因此不需要支付報酬」，這就存在風險。在實際的系統開發相關爭議中，常常會有合約是否成立的爭議，並且開發商方面往往會受到不利的判決。作為開發商，如果訂單方中止項目或轉向其他公司，就存在無法收到報酬的風險。此外，即使有合約書，也有可能被否定合約的成立。

在這裡，本所將解釋系統開發合約的成敗，以及在合約未被認定成立的情況下，如何進行金錢索賠的法律結構。

合約的成立

合約的成立，原則上，是雙方當事人對於合約的要素達成一致（申請意向與接受意向的一致）。

一旦合約成立，雙方當事人將受到合約的約束，如果一方當事人未能實現合約內容，另一方當事人可以通過法院強制履行，或者對不履行行為提出損害賠償。 「合約的要素」需要被確定到足以強制履行和確認不履行的程度，或者需要具體化。

系統開發合約的成立

系統開發合約的性質主要是承包合約和準委託合約。承包合約是承諾完成工作並支付報酬的合約。有償的準委託合約是承諾完成業務並支付報酬的合約。

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

因此，如果雙方當事人對於合約要素「工作或業務的內容」和「報酬金額」達成一致，則認為合約已經成立。

另外，即使只是口頭約定，也可以成立合約，並不一定需要合約書。

系統開發合約成立後被中止的金錢請求

如果系統開發的合約已經成立，但用戶單方面表示要中止，法律上將視為收到了合約的解除通知。

如果承包合約已經成立，供應商可以在任何時間在工作完成之前從用戶那裡獲得解除，並且在此情況下，供應商有權獲得損害賠償（日本民法第641條）。因此，如果用戶未支付損害賠償，供應商可以請求「損害」賠償，該賠償金額為供應商至該時間點已經支付的費用和應得的報酬金額，扣除因系統完成而節省的費用。

另外，如果準委託合約已經成立，當委託在履行過程中結束時，受託者可以根據履行比例請求報酬（日本民法第648條第3項）。因此，供應商可以請求已經完成的工作的對價支付。

系統開發合約的成敗

系統內容的特定性

通常，公司間的交易，特別是金額較大的合約，會使用書面形式，因此，如果已經製作了合約書，合約的成立就容易被認可。

開發目標的系統會經過各種工程逐漸具體化，因此，承包合約的要素之一「工作內容」的系統內容的特定性，只要能理解系統化的範圍和概要的特定程度就足夠了。

在法院判例中，基本合約書和保密協議的簽訂沒有爭議，基本合約書中有「委託e商務業務技術支援、網站建設支援及其相關業務」的記載，但並未明確說明e商務業務的具體內容、委託業務的範圍、作為系統開發、設計的範圍，因此，合約的成立被否定。

即使製作了系統開發基本合約書，如果工作或業務內容抽象，不能說明已經特定，合約的成立就難以被認可。只有當工作或業務內容、報酬金額等被具體記載在合約書等文件中，到達可以強制履行、認定不履行的程度，合約的成立才可能被認可。

另外，關於個人工程師與法人間的合約注意事項等，本所在下面的文章中詳細解釋。

https://monolith-law.jp/corporate/engineer-joint-enterprise-contract[ja]

供應商提供報價單・規格書等，用戶批准並下訂單

通常，公司間的交易會使用書面形式，因此，如果沒有製作合約書，合約的成立就難以被認可。在系統開發中，常常在製作合約書之前就開始工作，那麼，在這種情況下，合約的成敗應該如何考慮呢？

在法院判例（名古屋地方法院2004年（平成16年）1月28日判決）中，對於系統開發的承包合約的成立，有以下的說明：

• 經過供應商和用戶間的規格確認等交涉後，
• 供應商提供規格書和報價單等，
• 用戶批准並下訂單，從而達成合約。

在這個判例中，供應商接受了用戶自治體的委託，引入財務會計系統等，並提出了「關於提交綜合行政信息系統引入提案書（請求）」的RFP，供應商根據此提出提案書和報價單，用戶提交了「採用通知」。供應商沒有充分研究用戶的業務內容等，與用戶進行討論，也沒有證據顯示用戶內部具體研究了定制內容和費用，供應商的提案書內容也不具體，不清楚用戶批准了什麼，因此，合約的成立不被認可。

關於判例中提到的合約成立，本所將結合其他判例等進行補充說明。

經過供應商和用戶間的規格確認等交涉後

從「經過交涉」這個語境來看，如果合約的要素，如系統內容和報酬金額等，仍在「交涉中」，則可能會被認為尚未達成一致，合約的成立就難以被認可。

然而，在承包合約中，也可以將代價定為市價，因此，如果用戶已經批准了系統內容和「大致的」報酬金額等，則可能會認為已經達成了按市價支付代價的承包合約，有相關的判例。

為了能夠說明「經過交涉」，供應商應該與用戶討論用戶的業務內容、系統內容等，充分研究，並將這些記錄在電子郵件或會議記錄等文件中。

供應商提供規格書和報價單等，用戶批准並下訂單

• 如果用戶發出訂單或訂購單，則合約的成立更容易被認可。如果供應商提交請求書，或根據訂單等進行工作，則更容易被認為存在「合意」，合約的成立就更容易被認可。
• 用戶的內示書通常表示將來打算簽訂合約，因此，合約的成立較難被認可。然而，如果沒有這種記載，並且能夠盡可能具體地記載合約的要素，如系統開發的內容和報酬金額等，則有利於認可合約的成立。
• 如果備忘錄、協議書、確認書是在預定簽訂其他合約的前提下，或者內容抽象，則合約的成立較難被認可。
• 如果合約書案上沒有蓋章，則蓋章意味著簽訂，合約的成立較難被認可。
• 報價單可以作為確認雙方已經同意報酬金額的證據。

另外，如果在系統開發的某個階段，被要求更改規格或增加功能，是否可以在預先估計的金額上增加請求等詳細內容，本所在下面的文章中有詳細的解釋。

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

結算協議

如果在預定簽訂合約的前提下，根據用戶的指示進行工作，則在停止工作時，可能會認可對到目前為止的工作進行「結算協議」。為了使這種協議更容易被認可，如果合約未能簽訂，應該讓用戶在內示書等書面上記載報酬的結算方法，或者讓有權限的用戶對供應商製作的書面表示批准。

當合約成立未被承認時，索取金錢的法律結構

締結合約的過失

一旦開始進行締結合約的談判，當事人就有義務根據誠信原則（日本民法第1條第2項）努力不侵犯對方的財產。如果合約未能締結，且存在讓對方期待合約確定成立的客觀情況和有責任性，則可以因違反該義務而提出損害賠償請求。這稱為締結合約的過失。

以下將介紹一些法院認定存在締結合約過失的案例概述。

• 供應商應用戶的要求完成了需求定義，並實施了一部分的基本設計和詳細設計。雖然用戶解釋說讓其他公司參與投標的行為只是為了通過公司總裁的審議，但在合約締結前夕，選定了其他公司，未能締結合約。
• 供應商應用戶的要求保持交貨期並推進工作，合約締結預定日也即將確定。然而，用戶公司內部正在進行自家開發的準備，但這一情況被隱瞞，未能締結合約。
• 供應商被用戶通知已被選為建設商，並未對報價單提出疑問，根據與用戶的會議進行了規格確定等工作，用戶也認識到了費用的支出。然而，由於無法同意報價金額，合約締結被拒絕。

相反，法院認定不存在締結合約過失的案例包括明確表示可能選擇其他公司或達成合約的條件的情況。

如果應用戶的要求進行了工作，但未明確表示可能選擇其他公司或達成合約的條件，並以此為理由突然取消合約談判，則可能被承認提出損害賠償請求。

在這種情況下，「損害」的範圍包括已經支付的費用，這一點毫無爭議。此外，還有法院認為包括實際進行的工作部分的利潤的案例。另外，如果能提供證據證明拒絕了其他公司的申請，並在此後進行的工作中可能獲得的利潤相當部分的損害，則也可能包括在內。

日本商法第512條

如果供應商為用戶進行了與系統開發相關的行為，則可以根據日本商法第512條請求相當的報酬。

一旦開始關於系統開發的談判，就應該使用電子郵件或會議記錄等方式確認雙方對系統內容和報酬金額的認識，並留下證據以確認合約締結的確定性和合約元素的具體化。

即使由於未交換合約書等原因被拒絕支付，也可能被承認索取金錢，如上所述。

總結

如此，法院在沒有契約書的情況下，對於契約關係的判斷，相較於受託方企業的認知，往往容易做出「負面」的判斷。從受託方企業的角度來看，他們可能會認為「只是先開始工作，契約書應該會在事後簽訂，契約本身已經成立」，但這種主張並不總是被接受。

另外，如果契約成立被否定，如上所述，也有可能根據契約簽訂的過失或「日本商法」第512條等法律條款來要求金錢，但這也並非「確定」的事情。

如果不得不在簽訂契約書之前開始工作，則需要：

• 首先，這是一種有風險的行為，即使考慮到這種風險，也需要做出是否應該為該案件投入工時的經營決策（特別是對於中小企業或初創企業，如果是從大企業接受案件，為了獲得與該大企業的交易經驗，可能需要做出「先行動」的經營決策。如果風險已經考慮在內，這是一種可能的經營決策。）
• 如果契約未能成立，考慮是否可以簽訂清算協議等

可以說，需要進行這樣的思考。