システム開発の契約は契約書無しでも成立するか

システム開発においては、契約書を作成する前に、開発業者が作業をすすめることが少なくありません。ただ、こうしたフローは、実際問題として「危険」です。契約書が作成されていないと、後からからトラブルになった場合に、発注者から「まだ契約は成立しておらず、したがって報酬を支払う必要はない」などと言われてしまうリスクがあるからです。実際のシステム開発関連紛争では、このように、契約の成立自体が争われ、そして、開発業者側に不利な判断が行われるケースが少なくありません。開発業者としては、発注者から、プロジェクトの中止や、他社への乗り換えなどがなされた場合に、報酬の支払いを受けられなくなるリスクがあるのです。また、後述するように、契約書が作成されていても契約の成立が否定されてしまうケースもあります。

ここでは、システム開発契約の成否、および契約の成立が認められなかった場合に金銭を請求する法的構成について説明します。

契約の成立

契約は、原則として、両当事者が契約の要素について合意すること（申し込みの意思表示と承諾の意思表示の合致）によって成立します。

契約が成立すると、両当事者は契約に拘束され、一方当事者が契約内容を実現しない場合、他方当事者は、裁判によって、履行を強制したり、不履行に対して損害賠償を請求したりすることができます。 「契約の要素」は、履行を強制し、不履行を認定する対象となる程度に、特定されている、または具体的であることが必要です。

システム開発契約の成立

システム開発契約の性質は、主に、請負契約および準委任契約です。請負契約は、仕事の完成とそれに対する報酬の支払いを約束するものです。有償の準委任契約は、業務の遂行とそれに対する報酬の支払いを約束するものです。

そのため、契約の要素である「仕事や業務の内容」および「報酬額」であり、それについて当事者間の合意があれば、契約は成立していると認められます。

なお、単なる口約束でも成立し、契約書は必須ではありません。

システム開発契約成立後に中止された場合の金銭請求

システム開発の契約が成立していて、ユーザーから一方的に中止するといわれた場合、法的には契約の解除を通知されたということになります。

請負契約が成立している場合、ベンダーは、ユーザーから、仕事が完成するまでの間にいつでも解除がなされ得るのですが、その際には損害賠償がなされる地位にあることが規定されています(民法641条)。そのため、ユーザーから損害賠償がなされなかった場合、その時点までにベンダーが支出した費用および得られたであろう報酬額から、システム完成を免れたことによって節約できた費用を控除した額である「損害」賠償を請求することができます。

また、準委任契約が成立している場合、委任が履行途中で終了したときには、受任者は、履行割合により報酬を請求することができます(改正民法648条3項)。そのため、ベンダーは、既に行った作業の対価の支払いを請求することができます。

システム開発契約の成否

システム内容の特定性

通常、会社間の取引、特に金額が大きい契約は書面が用いられるため、契約書が作成されていれば、契約の成立は認められやすいです。

開発対象であるシステムは様々な工程を経て徐々に具体化されていくことから、請負契約の要素である「仕事の内容」にあたるシステム内容の特定性は、システム化しようとしている範囲と概要がわかる程度の特定で足りると解されています。

裁判例では、基本契約書および秘密保持契約の締結に争いはなく、当該基本契約書に「eコマース事業技術支援、WEBサイト構築の支援及びそれら付随する業務」を委託する旨の記載はあるが、eコマース事業の具体的内容や委託業務の範囲、システムとして開発、設計する範囲が明示されていなかったという事件で、契約の成立は否定されています。

システム開発基本契約書を作成したとしても、仕事や業務内容が抽象的で特定されたとはいえず、契約の成立は認められにくいでしょう。 仕事や業務内容、報酬額が、履行を強制し、不履行を認定する対象となる程度に具体的に記載された契約書などにより、契約の成立が認められることなります。

なお、個人エンジニアと法人間における契約の注意点等は下記の記事で詳しく解説しています。

ベンダーが見積書・仕様書などを提示し、ユーザーが承認し発注

通常、会社間の取引は書面が用いられるため、契約書が作成されていなければ、契約の成立は認められにくくなります。システム開発においては契約書が作成される前に作業を始めることが多いのですが、その場合、契約の成否につきどのように考えられているのでしょうか。

裁判例(名古屋地裁平成16年1月28日判決)では、システム開発の請負契約の成立について、以下のように述べています。

• ベンダーとユーザー間の仕様確認等の交渉を経て、
• ベンダーから仕様書および見積書などが提示され、
• これをユーザーが承認して発注することにより成立する。

この裁判例では、ベンダーは、ユーザーである自治体から、財務会計システム等の導入を委託されていたところ、「総合行政情報システム導入に関する提案書の提出について(依頼)」と題するRFPが提示され、これに応じる形で提案書及び見積書を提示し、ユーザーから「採用通知」が提出されました。ベンダーは、ユーザーの業務内容等につきユーザーと打ち合わせするなど十分に検討せず、ユーザー内部においてもカスタマイズの内容や費用について具体的に検討された事実が認められず、ベンダーの提案書の内容も具体的でなく、ユーザーが何について承諾したか明確ではなく、契約の成立は認められませんでした。

裁判例で述べられた契約成立に関して、他の裁判例などもふまえて補足説明します。

ベンダーとユーザー間の仕様確認等の交渉を経て

「交渉を経て」ということから、契約の要素であるシステム内容や報酬額について「交渉中」である場合、合意に至っていないとして、契約の成立は認められにくくなります。

もっとも、請負契約においては代金を時価と定めることもできるため、システム内容、「おおよその」報酬額等につきユーザーが承認したことから、時価相当の代価による請負契約が成立したと認められた裁判例があります。

「交渉を経」たといえるために、ベンダーは、ユーザーの業務内容、システム内容等につきユーザーと打合わせなどして十分検討したことを、メールや議事録などで記録に残すとよいでしょう。

ベンダーから仕様書および見積書などが提示され、これをユーザーが承認して発注

• ユーザーから発注書や注文書が出されると、契約成立が認められやすいです。ベンダーが請書を提出したり、発注書などに基づく作業をしたりすれば、より「合意」があるとして、契約成立が認められやすくなるでしょう。
• ユーザーの内示書は、今後契約締結予定という内容であることが多く、契約成立が認められにくいものといえます。もっとも、その旨の記載がなく、契約の要素であるシステム開発の内容や報酬額について可能な限り具体的に記載してもらえば、契約成立が認められる方向にはたらくでしょう。
• 覚書・協定書・確認書は、別途を契約締結する前提であったり、抽象的な内容であったりした場合には、契約成立は認められにくいです。
• 契約書案に印鑑が押されていない場合、押印をもって締結という意味合いであり、契約成立は認められにくいです。
• 見積書は、当事者間で合意された報酬額を認定する際の証拠になります。

なお、 システム開発においてある程度工程が進んだ段階で、事後の仕様変更や、機能の追加を求められた場合、事前の見積り金額に上乗せした請求が可能か等の詳細は以下の記事にて詳しく解説があります。

精算合意

契約を締結することを前提にユーザーから指示を出されて作業を行った場合、作業中止時にはそれまでの作業の対価を精算するという「精算合意」が認められることがあります。 この合意がより認められやすくなるように、契約締結に至らなかった場合の報酬の精算方法について、ユーザーに内示書等書面に記載してもらう、またはベンダーが作成した書面に対しユーザーの権限ある者の承諾を取得しておくとよいでしょう。

契約の成立が認められなかった場合に金銭を請求する法的構成

契約締結上の過失

契約締結に向けた交渉を始めると、当事者は、相互に相手方の財産を侵害しないよう努める信義則上の義務(民法1条2項)を負うことになります。契約締結に至らなかった場合、相手方に、契約成立が確実であると期待させる客観的事情と有責性があれば、当該義務に違反したとして、損害賠償請求をすることができます。これを契約締結上の過失といいます。

裁判例で契約締結上の過失が認められた事案の概要を紹介します。

• ベンダーがユーザーからの要請により要件定義を終了させ、基本設計、詳細設計の一部も実施していたところ、ユーザーから他社を入札させる行為につき社長に稟議を通すための形式的なものであると説明がなされたが、契約締結直前に他社が選定され、契約締結に至らなかった。
• ベンダーがユーザーから納期を守ることを求められて作業を進め、契約締結予定日も間近に確定していたところ、ユーザー社内では自社開発のための準備が進められていたが、それを秘匿され、契約締結に至らなかった。
• ベンダーがユーザーから構築事業者と決定したと通知され、見積書に対する疑問などを述べられることもなく、ユーザーとの打ち合わせに基づき仕様確定等の作業を行い、費用の支出についてもユーザーから認識されていたところ、見積金額が合意できないという理由で契約締結が拒絶された。

逆に、契約締結上の過失が認められなかった裁判例として、他社選定可能性や契約締結に至る条件が明示されていたものがあげられます。

ユーザーの求めに応じて作業を進めたのに、自社以外が選定される可能性や合意条件などについて明示されることなく、それらを理由に不意打ち的に契約交渉が破棄された場合には、損害賠償請求が認められることがあるのです。

その場合の「損害」の範囲に、それまでに支出した費用が含まれることは争いがありません。それにプラスして、実際に行った作業分の利益が含まれるとされた裁判例があります。また、他社からの申し込みを断って、それ以降作業をした場合に得られたであろう利益相当分の損害を被ったことが認められる証拠を提示すれば、それについても含まれ得ることを述べている裁判例もあります。

商法512条

ベンダーがユーザーのためにシステム開発に関する行為をしたとして、商法512条に基づき、相当な報酬を請求することができます。

システム開発について交渉を始めたら、システム内容や報酬額に関して、メールや議事録などを用いて双方で認識し合い、契約締結が確実と思わせる事情や、契約の要素が具体化されていたことを推認させる証拠を残していくとよいでしょう。

現に、契約書を交わしていないなどという理由で、支払いを拒絶されている場合でも、上記のとおり金銭請求が認められることがあります。

まとめ

このように、裁判所は、契約書が存在しない場合の契約関係について、少なくとも受託側の企業の認識と比較すると「ネガティブ」な判断を行いやすいものといえます。受託側の企業から見れば、「一旦先に稼働するだけで、契約書は事後的に締結して貰えるはずだったのであり、契約自体は成立している」と言いたいところですが、この主張は、常に認められるものではありません。

また、契約成立が否定された場合、上記のように、契約締結上の過失や商法第512条といった法律構成で金銭を請求できるケースもありますが、これも決して「確実」な話ではありません。

契約書締結前の作業を開始せざるを得ない場合は、

• そもそもそれはリスクのある行為であり、そのリスクを踏まえてもなお当該案件のために工数を用いるべきか経営判断を行う（特に中小企業やスタートアップ企業の場合、大企業からの案件受託だと、その大企業との取引実績を得るために「先に動く」という経営判断を行わざるを得ない場面はあります。それは、リスクが織り込まれていれば、あり得る経営判断ではあります。）
• 契約契約成立に至らなかった場合に備えて清算合意書などを締結できないか検討する

といった思考を行う必要があると言えます。