システム開発の契約交渉・締結段階でよくあるトラブルとは？

システム開発契約交渉・締結段階におけるよくあるトラブルの例

システム開発契約の交渉や締結段階おいてよくあるトラブルの1つに、最終的には契約締結に至らなかった場合に、受注の可能性が高いと見込んでベンダーが最終的な委託契約書を取り交わす前に行った作業の報酬や費用の支払いを求め、ユーザーがこれを拒否することがあります。

最終的な契約を締結する前に、ユーザーはベンダーから正確な見積もりを得たいと考えることが少なくありません。
しかし、システム開発にかかる費用を正確に見積もることはボタン1つでできるようなものではなく、ユーザーの要求を正確にヒアリングし定義をしたうえでFit&Gap（パッケージシステムを導入する際に、ユーザーの業務や使用シーンとシステムの機能が、どれだけ適合（Fit）し、どれだけズレ（Gap）があるかを分析すること）などをする必要があり、多くの工数を要します。
また、この作業をするにあたって、下請け会社に一部の作業を外注することも少なくありません。

このように、手間や工数のかかる作業を最終契約の締結前に行うのは、ベンダー側がユーザー側の担当者との会話やメール等のやり取りなどを踏まえ、受注がほぼ確実であると見越しているからこそだといえます。
そのまま発注に至れば問題とならないものの、結果的にユーザーがそのベンダーへ発注しない場合もあります。

この場合、ベンダー側は発注を仄めかすユーザーの言動を信じて工数をかけたり下請け会社に外注費を支払ったりしたため、少なくともその分の費用は負担して欲しいと考えるでしょう。
一方、ユーザーは最終的な契約を締結していない以上、支払いの義務はないと主張します。
これが、システム開発契約の交渉や締結段階におけるよくあるトラブルの1つです。

システム開発契約交渉・締結段階でトラブルとなった場合の検討の流れ

システム開発契約の交渉や締結段階において先ほど紹介したようなトラブルに発展した場合、法的責任は次の流れで検討することが一般的です。

• 契約は成立していたか検討する
• 契約締結上の過失が認められるか検討する

契約は成立していたか検討する

はじめに、ベンダーとユーザーの間で契約が成立していたかどうかを検討します。
検討の結果、契約が成立していると判断される場合は、ユーザーに報酬支払義務または損害賠償義務があることとなります。

契約締結上の過失が認められるか検討する

ベンダーとユーザーの間での契約が成立していないと判断される場合は、契約を締結する上での過失の有無を検討します。
具体的には、契約が成立しなかったことについて、信義誠実の原則に照らしユーザー側に過失があるかどうかを検討します。
ユーザー側に過失があると認められる場合は、ユーザーに損害賠償義務があることとなります。

契約が成立していたかどうかの考え方

契約が成立していたかどうかに関する考え方は、次のとおりです。

原則の考え方

法律上、契約は口頭でも成立します。
民法522条1項では契約の成立について「契約は、契約の内容を示してその締結を申し入れる意思表示に対して相手方が承諾をしたときに成立する」と規定されているうえ、さらに同2項では「契約の成立には、法令に特別の定めがある場合を除き、書面の作成その他の方式を具備することを要しない」とされているためです。

そのため、最終契約書を取り交わしていないからといって、契約が成立していないと断定されるわけではありません。

契約書がない場合に不利となる理由

法律上は契約書がなくても契約が成立し得るとはいえ、実務上は契約書がないことは不利となります。
なぜなら、ベンダー側がたとえ口頭での契約成立があったと主張したところで、口頭だとその証拠がないことが多いためです。

また、会社と会社との間で有効に契約を成立させるには、契約締結権限を持つ者（原則として代表取締役、会社が権限を委譲している場合は委譲を受けている支配人など）との合意が必要となるところ、口頭で契約をしたとされるユーザー側の担当者がこの権限を持っていないことも少なくありません。

さらに、システム開発委託契約は高額となることが多く、正式に発注する際は契約書を取り交わすビジネス慣行があるものといえます。
裏返すと、契約書を取り交わしていないということは、双方ともに契約が未成立であることを認識していた可能性が高いと判断されやすくなります。

契約の成立が否定されやすい事情

次のような事情がある場合は、契約の成立が否定されやすくなります。

• 作業に着手することで報酬が発生する認識がユーザー側にないこと
• 目的や作業内容が明確となっていないこと
• 契約書原案はあるものの押印に至っていないこと

ただし、ここで紹介するのはあくまでも裁判例などをもとにした個別事情によるものです。
これらに当てはまるからといって諦めるのではなく、システム開発委託契約に詳しい弁護士へご相談ください。

作業に着手することで報酬が発生する認識がユーザー側にないこと

契約締結前にベンダーが行う作業の量や性質はユーザー側からは見えづらく、営業活動との区別がつきにくいものです。
そのため、ベンダーがその作業に着手することで報酬が発生するとの認識がユーザー側にない場合は、契約成立が消極的に捉えられる可能性があります。

目的や作業内容が明確となっていないこと

先ほど解説したように、民法は契約の成立時期について「契約の内容を示してその締結を申し入れる意思表示に対して相手方が承諾をしたときに成立する」としています。
そのため、作業の目的や内容が明確となっていなかった場合は、契約成立が消極的に捉えられる可能性があります。

契約書原案はあるものの押印に至っていないこと

契約書原案のやり取りがされていたのであれば、その後押印することで契約を成立させる意思が双方にあったものと考えられます。
そのため、契約原案があっても押印に至っていない場合は、契約が成立していないことは双方ともに認識していたはずであると考えられ、その段階での契約成立が消極的に捉えられる可能性があります。

契約締結上の過失が認められるかどうかの考え方

検討ステップ2について、ユーザーに契約締結上の過失が認められるかどうかの考え方は、次のとおりです。

契約締結上の過失（契約の破棄）に関する原則の考え方

契約の交渉段階においては、当事者が交渉を破棄して契約しないことを選択することも、原則として自由です。
交渉を始めただけで契約すべきとなると、世の中の営業活動は事実上成り立たなくなってしまうでしょう。

一方で、契約交渉の過程において、不誠実といえる方法で一方的に契約を破棄したことにより相手方が損害を被った場合は、損害賠償責任を負う可能性があります。
不誠実であるかどうかは「信義誠実の原則（民法1条2項に定められている「権利の行使及び義務の履行は、信義に従い誠実に行わなければならない」との規定による原則」）」に照らして判断されます。

システム開発委託契約においては、ベンダーはユーザーから委託を受けることで収益をあげることとなるため、一般的にベンダーはシステム開発の委託を受けることを目指しています。

契約締結がほぼ確実であるかのようにユーザーが見せかけた結果、ベンダーがこれを信じて契約締結前にFit&Gapなど工数がかかる作業に取り掛かったり下請会社に作業を発注したりしたにもかかわらず契約締結を一方的に破棄した場合は、誠実とはいえない交渉の破棄であるとして損害賠償責任を負う可能性があります。

ユーザー側の過失が肯定された裁判例

契約が成立しなかったことについてユーザー側の過失が肯定された主な裁判例には、次のものがあります。

• ベンダーが見積書どおりの納期を守るために開発作業を開始して実際に多くの成果物を開発し、ユーザーも開発に必要なツールのアカウントを利用可能とする環境整備をしたケース（東京地裁平成29年1月13日判決）
• 契約を複数フェーズに分けて行っていた場合においてフェーズ2の契約成立が争われた事案において、フェーズ1とフェーズ2が基本設計工程を2分割したものに過ぎず、先行するフェーズでも注文書の交付前からユーザーの協力のもとでベンダーの作業が開始されていたケース（東京地裁平成19年11月30日判決）

ユーザー側の過失が否定された裁判例

契約が成立しなかったことについてユーザー側の過失が否定された主な裁判例には、次のものがあります。

• 元々そのベンダーを含めた3社を比較して選定する前提となっており、そのベンダーに発注する旨を明示的に発言したことがなかったケース（東京地裁平成17年3月28日判決）
• 契約を複数フェーズに分けて行っておりフェーズ3の契約成立が争われた事案において、金額の調整がつかなければ契約キャンセルがあり得ると告げられていたケース（東京高裁平成27年5月21日判決）

システム開発契約交渉・締結に関するトラブル予防策

システム開発契約の交渉や締結に関するトラブルを予防するための主な対策には、次のものが挙げられます。
ただし、いずれも最低限度行っておくという程度に過ぎず、正式な契約の締結に代わるほど確実なものではないので、注意が必要です。

• 有償の作業に取り掛かる前に通知をする
• 報酬額が明記された仮発注書の交付を求める

有償の作業に取り掛かる前に通知をする

1つ目は、有償の作業に取り掛かる前にその旨をユーザーに対して通知することです。
これにより、たとえその有償の作業後に最終的な契約締結をしないことになったとしても、有償であることを通知した分については報酬が請求できる可能性が高くなります。

たとえば、Fit&Gapなど工数がかかる作業に取り掛かる前や下請け会社に外注する前にユーザーに対して有償となる旨の通知をしたり、最終的な契約を締結するかどうかの意思決定を求めたりすることなどが考えられます。

報酬額が明記された仮発注書の交付を求める

2つ目は、報酬額が明記された仮発注書の交付を求めることです。

たとえば、Fit&Gapなど工数がかかる作業を発注された時点で、仮発注書や内示書などの交付を求めることなどが考えられます。
ここに報酬額や報酬の計算方法を記載することで、たとえ最終的な契約締結には至らなかった場合であっても、作業中止までの費用を回収できる可能性が高くなります。

まとめ

システム開発委託契約の交渉や締結段階では、トラブルに発展することが少なくありません。

代表的なトラブルは、最終契約の締結前にベンダーが契約成立を見越して作業に取り掛かったものの、結果的に契約に至らずそこまでにかかった工数や下請会社への発注代金などの支払いを求めることによるものです。
この場合は、事実上契約が成立していたと言えるかどうかや、最終契約の締結に至らなかったことについてユーザー側の過失があったかどうかなどが争点となります。

このようなトラブルを避けるには、ベンダー側は有償作業に取り掛かる前にその旨をユーザーに対して通知したり、ユーザーからの仮発注書の交付を求めたりするとよいでしょう。
また、システム開発委託契約に関してトラブルに発展するおそれがある場合や、すでにトラブルが生じている際は、システム開発委託契約に詳しい弁護士へご相談ください。