システム開発に限らず、建設工事でも似たようなことはよく起こります。
東京高裁令和6年1月31日判決の事例は、このような場合に何に気を付けるべきかを考えるうえで参考になります。
判決事例は複雑ですが、裁判所が認定した事実を単純化すると、次のとおりです。
・システム開発契約が締結され、作成予定システムの内容が確定した（いわゆる「要件定義」がなされた）。
・その後、発注者が多くの追加の注文を行った。
・システム開発会社は、その注文が当初の決定内容の範囲内か範囲外かを十分に整理しないまま対応を続けた。
・当初完成を約束した時期を過ぎても多数のバグが残っていたため、開発会社はその修正を継続した。
・開発会社は、上記の整理不足を謝罪しつつ、当初の範囲外の機能追加については追加費用がかかる旨を説明した。
・発注者は、約1年間システムを利用し続けたが、バグが解消されないことや納期遅延を理由に契約を解除した。
このような状況で、①発注者は、完成の遅れを理由に、既払の開発代金約2000万円の返還と損害賠償を請求し、②逆にシステム開発会社は、発注者の解除により未完成となったに過ぎず、完成した場合と同様の報酬請求が認められるとして、完成時報酬から既払額を差し引いた約1500万円を請求しました。
裁判所は、
①発注者が協議を続けながら約1年間もシステムを利用していたことなどから、バグの主張は採用できず、また納期遅延についても黙示に承諾していたと評価し、発注者の請求を棄却しました。
②他方で、開発会社についても、当初契約の範囲外の部分について十分な整理を行わなかったことが、システム未完成の一因であるとして、その請求の一部を棄却し、約200万円のみを認めました。
この裁判例から学べることは、次の4点です。
① 発注者は、バグを見つけたらすぐに主張すべし。
本件では、バグを発見しても直ちに強く主張せず、協議を続けてしまったことが不利に評価されています。
バグに限らず、契約不適合を見つけた場合には、早い段階で「問題がある」という姿勢を明確にしておかないと、後で不利に評価されるおそれがあります。
② 発注者は、使い始めたら「お金を払う方向」に傾くと覚悟すべし。
不具合のある家でも住み続ければ、それを受け入れたと評価されかねません。
不満がある状態で利用を続けること自体がリスクになります。
③ 請負人は、契約外のことを安易にサービスしない。
ある程度であれば無償で対応してしまいがちですが、それが常態化すると、契約外の要求にも応じるのが当然と扱われかねません。
範囲外の対応については、早い段階で追加費用の話をすべきです。
④ 謝罪はやはりリスクになる。
本件でも、開発会社が整理不足を認めて謝罪したことが、不利な事情として扱われています。
米国では安易に謝らない文化があると言われますが、日本でも、法的紛争を見据える場面では注意が必要です。
↓↓弁護士ブログの人気ランキングです。↓↓
金沢市の人気ブログランキング
↑↑参加しています。クリックでご協力お願いします。↑↑
