系统开发的合同是否可以在没有合同书的情况下成立

在系统开发中，开发商在制定合同之前就开始工作的情况并不少见。然而，这样的流程实际上是“危险”的。如果没有制定合同，一旦后来出现问题，发单方可能会说“合同还没有成立，因此没有必要支付报酬”，这就存在风险。在实际的系统开发相关纠纷中，经常会有合同是否成立本身成为争议点，而且往往对开发商不利的判断。作为开发商，如果发单方中止项目或转向其他公司，就存在无法收到报酬的风险。此外，即使制定了合同，也有可能被否定合同的成立。

在这里，我们将解释系统开发合同的成败，以及在合同未被确认成立的情况下索取金钱的法律构造。

合同的成立

原则上，合同是通过双方当事人对合同要素达成一致（申请意向和接受意向的一致）而成立的。

一旦合同成立，双方当事人将受到合同的约束，如果一方当事人未能实现合同内容，另一方当事人可以通过法院强制执行，或者对不履行行为提出赔偿要求。”合同要素”需要被明确或具体到足以强制执行和确认不履行的程度。

系统开发合同的成立

系统开发合同的性质主要是承包合同和准委托合同。承包合同是承诺完成工作并支付报酬的合同。有偿的准委托合同是承诺完成业务并支付报酬的合同。

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

因此，如果双方当事人对合同要素”工作或业务内容”和”报酬金额”达成一致，就可以认为合同已经成立。

另外，即使只是口头承诺，也可以成立合同，不一定需要合同书。

系统开发合同成立后被中止的金钱索赔

如果系统开发合同已经成立，但用户单方面表示要中止，从法律角度来看，这被视为通知解除合同。

如果承包合同已经成立，供应商可以在任何时候在工作完成之前被用户解除，但在这种情况下，供应商有权获得赔偿（日本民法第641条）。因此，如果用户没有支付赔偿，供应商可以要求赔偿其到那时为止的支出和应得的报酬，减去由于系统未完成而节省的费用。

另外，如果准委托合同已经成立，当委托在履行过程中终止时，受托人可以根据履行比例要求报酬（日本修订民法第648条第3款）。因此，供应商可以要求支付已经完成的工作的对价。

系统开发合同的成败

系统内容的特定性

通常，公司间的交易，特别是金额较大的合同，都会使用书面形式，因此，如果已经制定了合同，那么合同的成立就容易被接受。

作为开发目标的系统会经过各种工序逐渐具体化，因此，承包合同要素中的“工作内容”即系统内容的特定性，只要能理解系统化的范围和概要的程度就足够了。

在判例中，基本合同书和保密协议的签订没有争议，虽然在该基本合同书中有“委托电子商务业务技术支持、网站建设支持及其附带业务”的条款，但是电子商务业务的具体内容、委托业务的范围、作为系统开发、设计的范围并未明确，因此，合同的成立被否定。

即使制定了系统开发基本合同书，如果工作或业务内容过于抽象，不能被特定，那么合同的成立就难以被接受。只有当工作或业务内容、报酬金额等被具体化到可以强制执行和确认不履行的程度，通过合同书等，合同的成立才可能被接受。

另外，关于个人工程师与法人之间的合同注意事项等，我们在下面的文章中进行了详细的解释。

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条等法律构成来索取金钱，但这也绝非“确定”的事情。

如果不得不在签订合同书之前开始工作，那么就需要：

• 首先，这是一种有风险的行为，即使考虑到这个风险，也需要做出是否应该为该项目投入工时的经营决策（特别是对于中小企业或创业公司，如果是从大公司接受项目，为了获得与大公司的交易记录，他们可能不得不做出“先行动”的经营决策。如果考虑到了风险，这是一个可能的经营决策。）
• 考虑在合同未能成立的情况下，是否可以签订清算协议等

可以说，需要进行这样的思考。