№1766 難しいシステム開発契約のトラブル
IT関係の中でもシステム開発契約はきわめて特殊だ。
頼んだのはこんな内容ではなかったとか、お金を取り過ぎているとか、納入後の修正が多いとかこういうトラブルは多い。
顧客の要求がまずあって、ベンダー、開発者側が個々に提案し、それを顧客が承認していく過程がある。最初から何もかも決まっているわけではない。顧客の知識が不十分であるため、多くを要求したり、あとから要求事項が増えてくることもある。
契約の成立過程でも、システム構築過程でも顧客の協力なしではことが運ばないのであるが、この協力に対する顧客の認識が軽いこともトラブルの原因となる。IT開発者は最初に顧客の協力が必要であることをきちんと述べておく必要がある。
システム開発は通常、ウォーターフォール方式で共同作業が決められていく。つまり、基本設計をもとにして作業を区分し、詳細設計を作る。担当者は詳細設計をもとにプログラムを作っていく。完成されたプログラムはいくつかのテスト（単体テスト→結合テスト→システムテスト→運用テスト）と段階を経たテストが実施される。
契約の観点から言えば、システム全体の構造を確定するのは基本設計の段階なので、開発契約、請負契約の一種だが、これは「基本設計」をもって契約内容が確定することになる。普通に言っても、基本設計を基に見積もりが出され、発注が確定するので、この時点で契約成立ということになるだろう。
ややこしいのは、基本設計ができてからの次のような変化だ。変化した部分が追加発注として新たな代金が発生するかが問題となる。
① 基本設計そのものをいじる場合
② 詳細設計、その後のプログラミングにおいていじる場合
③ テストによる不具合が発生して追加する場合
大阪地裁の事例では、納入後テスト中の追加部分について、追加工事であるため、ユーザーは追加工事代金を支払えと命じた（H26.1.23 判時2278号83頁）。
名古屋Ｅ＆Ｊ法律事務所へのお問い合わせはこちら
