システム開発での契約交渉・締結段階におけるトラブルを防止する方法

システム開発に関する紛争が生じる原因とは

システム開発に関する紛争の発生要因には、様々なものがあります。特に以下のようなことが要因として挙げられます。

• 重要な書類（契約書・仕様書・議事録等）に不備がある
• 契約内容の理解不足
• ベンダのプロジェクトマネジメント能力不足
• ユーザが仕様決定等に協力しない
• システムは目で見て確認することができない
• 単純な操作ミスで膨大な情報が消えてしまう
• 多くの利用者がトラブルに巻き込まれてしまう

また、システムの開発から運用までの時系列に従って、以下のような紛争が考えられます。

• 契約交渉・締結段階の紛争
• システム開発途中で発生する紛争
• システムの運用段階の紛争
• 知的財産に関する紛争

そのため、システムを開発するにあたっては、上記の紛争の発生要因に注意し、時系列ごとの注意点を考慮しながら開発をしていくことが、後々の紛争予防に効果的といえます。

契約交渉・締結段階の紛争の原因

システム開発の契約交渉は、提案書の提出、ベンダの選定などの多くのステップを経て行われます。

また、多額の投資を行うことになるため、取締役会の決議など、契約締結の意思決定にも多くのステップがあります。そのため、費用の確定や最終的な契約書の取り交わしに至るまで、多くの時間がかかることになります。

しかし、実際の開発作業は、最終的な契約書がまだ無いにも関わらず、開発作業が先行していることが大半です。そして、後に契約締結にいたらない場合に、先行していた開発が中止されることで、紛争に発展するということがあります。

このように、開発が先行する理由は、納期に関する厳しい要求が挙げられます。

ユーザの意思決定のために契約書の締結に時間がかかったとしても、システムの稼働開始時期を遅らせることを許容してくれるとは限りません。また、ベンダ側も、システムの開発のために人材等を確保してしまっているため、結局コストがかかるなら開発してしまおうという事情もあります。そのため、発注されない可能性を認識したまま、開発が先行してしまうということになります。

契約が締結されなかった場合、開発にかかった費用等の支払い

上述のように、開発が先行するという実情があるなかで、開発が先行していたのに、結局、契約が締結されなかった場合、開発にかかった費用等の支払いはどうなるのでしょうか。

その際、問題解決の指針となるのが、そもそも契約が成立しているのかどうかということです。

契約が成立していると判断されれば、民法の請負契約の規定に従って、費用を損害賠償として請求できることになります。

一方、契約が成立していないと判断された場合、民法の請負契約の規定に従った請求はできません。

ただ、一定の要件を満たした場合は、契約締結上の過失の理論で請求が可能となります。

契約が成立しているといえる場合

法律上、契約は、申込みと承諾の意思表示の合致によって成立するとされています。

そのため、契約の成立には、契約書等の書面の作成は必ずしも必要ではありません。しかし、意思表示の合致がどの範囲でなされたかの判断は難しく、システム開発に限らず、他の様々な契約において、契約の成否が問題となります。

システム開発の契約に関しても、まず、どの部分について意思の合致があるのかが問題となります。

請負契約を前提としたシステム開発委託契約の場合、請負契約の要素である「仕事の目的物（対象のシステム）」と「報酬額」が決まっていることが必要です。

ここでは、対象のシステムがどの程度具体的に合意されているかが重要になってきます。

システム開発は、要件定義・基本設計など、多数の工程を経て進められるため、対象となるシステムが具体的に確定するのが、工程がかなり進行した後ということになります。

そうすると、要件定義や設計の工程が契約の準備行為ということになりかねません。

ただ、システム開発は、個々の契約において、契約規模の大小や複雑さの違い、ベンダとユーザの取引関係や力関係等が大きく異なります。そのため、対象のシステムが何かは、個別具体的な事情のもとで判断せざるを得ません。

名古屋地判平成16年1月28日では、契約書を取り交わさないまま開発が途中で頓挫したため、契約の成否が争点の一つになったものです。

裁判所は、システム開発やカスタマイズ契約成立の一般論として、次のように述べています。

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

要するに、契約は、ユーザがベンダから提示された仕様書や見積書などを承認して、発注して初めて成立するとしています。

次に、意思表示の合致が誰と誰の間でなされているかが問題になります。

ベンダの営業担当者とユーザのシステム部門の担当者同士が合意していたとしても、それぞれが会社を代表する権限を有しているとは限りません。当該契約に関して、会社を代表する権限を有している者同士が合意することが必要です。

上述のように、契約の成立には、契約書は必ずしも必要ではありません。

しかし、契約成立が問題となった紛争の多くは、契約書が取り交わされていない事例です。そのため、紛争の予防という観点からも、代表権のある者の記名捺印のある契約書を作成しておくべきです。

契約の成否を分ける事情

上述のように、契約が成立しているかどうかを一律に決めることはできず、結局は個別具体的な判断をするしかありません。そこで、以下、裁判例で契約の成否の判断の考慮要素になったものを挙げます。

• 記名押印のある契約書がない場合は消極的に判断
• 契約書案の送付等のやり取りがあっても捺印がない場合は消極的に判断
• 目的物や作業内容が明確でない場合は消極的に判断
• 作業に着手していても有償であるとの認識がない場合は消極的に判断

以上のように、両当事者間で明確な合意がない場合は、作業に着手していたとか、担当者による通知があったといった周辺の事情のみで、契約の成立を認めることは困難といえます。

契約が認められない場合

契約の成立が認められない場合、契約に基づいて費用等の請求をすることはできません。

しかし、契約締結上の過失理論によって、損害賠償請求として費用の請求をすることが可能な場合があります。

契約締結上の過失理論とは、契約成立過程における一方当事者の故意・過失によって相手方が損害を被った場合には、一定の要件を充たせば、何らかの責任を肯定すべきであるという法理をいいます。

要するに、一方当事者の事情で交渉が破棄された場合に、もう一方の当事者が被った損害を賠償させようという考えです。このような理論で賠償責任が認められるかは、以下の要素を考慮して判断されます。

• 交渉の進捗状況
• 先行行為や準備行為の存在（相手方の信頼を生じさせるような積極的な行為等）
• 交渉のイニシアティブ（契約成立への期待をさせる行為の有無）
• 挫折の原因とその主たる惹起者

この理論で賠償責任が認められた場合、損害賠償の範囲は信頼利益に限られるとされています。

信頼利益とは、契約が有効であると信じたことによる損害をいい、契約準備、契約交渉、履行準備にかかる費用などをいいます。

一方、契約が履行されていたら得られたであろう履行利益は含まれないため、逸失利益は請求できないことが一般的です。

裁判例では、ユーザによって契約交渉が破棄された場合における、ユーザの契約締結上の過失を認めるかどうかの判断は、以下の事情等を総合考慮して判断されます。

責任を認める方向の事情

• 他社に委託することが確定していたにも関わらず、それを秘して作業を継続させる
• 契約に至らなかった事情がもっぱらユーザにのみ存すること
• 無償の作業が相当長期間に及ぶこと
• 内示書や仮注文書等の書面が交付されていること
• 担当者同士でのやり取りでは、委託することが確定していたこと

責任を認めない方向の事情

• 他社に委託する可能性が示されていたこと
• 社内の意思決定プロセスが相手方に伝えられていたこと
• 金額や作業範囲等の交渉が成熟していなかったこと
• 契約締結に至るまでの前提条件について当事者間で共通認識があったこと

契約不成立による損害発生や、紛争化のリスクを回避するためには、依頼された段階で、内示書や仮発注書等の文書の提示を求めるべきです。

さらには、その文書に、契約締結に至らなかった場合の費用や報酬の精算方法を入れておくことも有効的です。