見出し画像

システム開発契約のトラブル事例①

システム開発のプロジェクトを成功させるためには、具体的にどのようなリスクがあるのかを理解したうえで、リスクを回避するための対策を適切に講じることが重要です。
そこで本記事では、システム開発でよくあるトラブル事例について、ベンダ目線でまとめてみたいと思います。


1.契約書の締結前に業務を開始して、代金の支払いを拒否された事例

◆概要

ベンダは、契約書を正式に締結する前だったが、業務開始について口頭でユーザの合意が得られた(=契約が成立した)と考えて、業務を開始した。
しかし、最終的にユーザ社内の稟議が通らず、システムの導入は延期となり、ユーザは「契約は成立していないため、代金は払わない」と主張した。
裁判所はユーザの主張を認め、業務にかかった費用は全てベンダの負担となった。

※東京地判平17.3.28 をもとに作成

◆ポイント

①「口頭による契約の成立」を立証するハードルは高い
原則として、契約は口頭であっても成立します。しかし、裁判となった場合には「言った言わない」の水掛け論になり、契約の成立が認められないリスクがあります。

②契約書を締結してから作業に入る
業務にかかった費用が無駄にならないよう、ユーザとの間で契約書を締結してから作業を開始しましょう。
もしそれが難しい場合には、口頭でのやり取りを議事録にしてユーザに確認してもらう、発言内容を確認するメールをユーザに送るなど、契約の成立を証明する証拠を残しておきましょう。

2.追加費用の支払いを拒否された事例

◆概要

ベンダは、ユーザとの間でシステム開発契約を締結した。
その後、ユーザの指示により業務内容が一部変更になり、追加開発の費用が発生した。しかし、ユーザは「本来の業務の範囲内であり、当初の委託代金でカバーされている」と主張した。
裁判所はユーザの主張を認め、追加費用は全てベンダの負担となった。

※東京地判平7.6.12をもとに作成

◆ポイント

①合意内容を明確にしておく
追加費用が認められるかは、ユーザの要求事項が当初の合意内容の範囲かどうかによって決まります。
たとえば、元の仕様に加えて別の機能を追加する場合には、合意内容の範囲外であるとして、追加費用の請求が認められます。
一方で、要件定義で定めた機能の詳細化など、合意内容を明確化したに過ぎない場合には、追加費用の請求が認められません。
このように、合意内容が何であるかは非常に重要ですので、双方の役割分担や、確定した仕様の内容は、文書で明確にしておくことが重要です。

②追加費用が発生することを合意して作業を開始する
たとえ追加費用が法的に認められるケースであっても、ユーザが「追加費用がかかると聞いていなかった」として、費用の支払を拒否する可能性があります。
そのようなトラブルを避けるために、追加費用の発生とその金額についてユーザと合意したうえで作業を開始するようにしましょう。

参考文献

  • 難波ほか『裁判例から考える システム開発紛争の法律実務』(商事法務, 2017)

  • 飯田耕一郎=田中浩之『企業訴訟実務問題シリーズ システム開発訴訟』(中央経済社, 2017)

  • 情報システム・ソフトウェア取引高度化コンソーシアム編「情報システム・ソフトウェア取引トラブル事例集」(2010)