システム開発契約において、契約が成立しているかの判断ポイントを解説【２０２１年１２月１８日】

システム開発契約は、いつの時点で成立するの？

システム開発において、よく問題になるのが、そもそも契約が成立しているのかという問題です。

約束みたいのはしたけど…ちゃんとした契約はしていないし、契約書は巻いていない…

そんな、システム開発の契約について、解説します。

契約の成立について

そもそも、契約って、どの時点で成立するのでしょうか。

法律上は、契約とは「申込みと承諾という2つの意思表示の合致によって成立する」のであって、書面による契約書を取り交わすことは要件とされていません。

よって、口約束であっても、意思表示が合致していれば、契約が成立するのが原則です。

このように書くと、非常に簡単な話のようですが、実際には様々な問題が生じます。

どの部分について、合意しているか

「意思表示の合致」といっても、どの部分について合致していればよいのかが問題となります。

システム開発委託のような複雑な業務において、「やりましょう」「お願いします」といったやり取りだけでは契約が成立しないのは当然です。

例えば、請負契約を前提としたシステム開発委託契約の場合、原則として請負契約の要素になる以下の点を決める必要があります。

• 仕事の目的物（開発対象となるシステム）
• 報酬額（もしくは報酬額の決め方）

「開発対象となるシステム」が、どの程度、具体的に合意されていれば、契約の内容になるかということで、重要になってきます。

システム開発は、要件定義、基本設計など多数の工程を経て進められます。

対象となるシステムが、具体的に確定するのは設計工程がだいぶ進行した後ということになります。そうすると、要件定義や設計の工程がすべて契約締結のための準備行為ということになりかねません。

この点、裁判例では、仕様書が提示され、それをユーザが承認することによって成立すると述べています。

誰と誰との間で、合意が成立している必要があるか

企業間取引において「意思表示の合致」とは、誰と誰の間において合致していればよいのでしょうか。

株式会社の場合、原則として代表取締役のみが会社を代表して契約を締結する権限があります。よって、契約書の宛名のところには、「株式会社●●　代表取締役～～」と記載されるのが、通常です。

契約書は作成されている必要があるか

前述の通り、契約の成立においては、口頭でも成立し、契約書を締結する必要はありません。

しかし、大きな金額のシステム開発になると、当然に契約書が存在しているはずと裁判所は、考えます。

つまり、契約者がない＝システム開発の契約が成立していないと判断されることがあるのです。そして、紛争となるのは、システム開発委託契約書が締結されていない案件です。

システム開発契約の締結が問題となった事例

この点、以下のような裁判例があります。

業務用コンピューターソフトの作成やカスタマイズを目的とする請負契約は、業者とユーザ間の仕様確認等の交渉を経て、業者から仕様書及び見積書などが提示され、これをユーザが承認して発注することにより相互の債権債務の内容が確定したところで成立するに至るのが通常であると考えられます。

ユーザが、ベンダから提示された「仕様書及び見積書など」を承認して、発注することによって、初めて成立すると判示しています。

開発の目的が明らかになっていない段階では契約は、成立していないと判断しているということなのです。

本裁判例では、べンダから提案書が出され、ユーザからは当該ベンダを採用する旨の採用通知が提出されていたことを根拠に、ユーザは契約が成立していると主張しました。しかし、この点について裁判所は、以下のことを理由に、ベンダから提出された提案書について契約の申込みとは認めず、ペンダに交付された採用通知は承諾だとは認められないとしました。

ベンダらが、本件提案書を作成するに当たりユーザの業務内容等につきユーザと打合せをするなどして十分に検討した事実は認められない

また、ユーザにおいても、ベンダらから本件提案書等を受領してからベンダに採用通知を送付するまでの間、ベンダらの提案するシステムを導入するにあたり、パッケージソフトのカスタマイズを要するか否か、カスタマイズを要するとしてどのような内容、程度のものが必要となるか、これに要する費用がどの程度となるか等につき、具体的に検討した事実は認められない

契約が成立しているかは、個別判断によるところが大きい

上記判例があるからといって、一般論として、提案書の提出が契約の申込みに当たらないとまではいえないことに注意が必要です。

上記のとおり、本件の提案書は、ユーザからのヒアリング等が十分に行われない段階で提出されたもので、契約の要素である目的物に関する記載が具体的でなかったと見られ、むしろ営業資料的な意味合いが強いものでした。

また、採用通知も、交渉相手を絞り込んだという程度の意味しか持たないとしています。

例えば、ユーザからベンダに対して具体的なシステム化要件が記されたRFPが提示され、十分な検討期間を経て、開発の目的となるシステムの仕様、構成や金額等の契約の要素を含む提案書が、ペンダから当該RFPに応答する形で提出されていた場合には、当該提案書の提出をもって契約の申込みと評価できる可能性はあります。

東京地裁平成16年3月10日判決では、提案書の記載内容が契約書の一部を構成することが、当然の前提となっている判示があります。

また、東京地裁平成20年7月29日判決では、以下のような事例があります。

この事案で、そもそも契約が成立していたのかが問題になりましたが、裁判所は、契約の成立を否定しました。ポイントは、以下の通りです。

• ユーザ内部において、本件事業の方針や具体的内容が定まっておらず、本件事業の提携先や提携業務の範囲も未確定で、本件システムとして開発、設計する範囲さえも明確になっていなかった
• 本件事業の方針や提携先との関係、本件システムとして開発、設計する範囲等が確定したのは、ユーザによる契約締結拒絶の通告後のことであること
• 本件事業は、ユーザがeコマース事業の一環として並行して進めていた複数の事業の一つであるところ、本eコマース事業の具体的内容も委託業務の範囲も明示されていなかったこと
• 本件基本契約が締結された当時、ペンダは、本件事業だけではなく、eコマース事業の一つであるポイント還元ショップ事業のシステム開発にも携わっていたこと

このように、裁判例では、eコマースシステムに関する要件定義作業は進行していたとしつつも、契約の要素たる開発、設計範囲が明確になっていなかったとして契約の成立を否定しました。

Tweet