以下の検索ボックスを利用して、IT法務関連のページから検索できます。問題の所在システム開発契約においては、少なくとも製造段階の開発は通常は請負契約と考えられています。この場合のベンダー(開発側)の義務のうち最大のものは、開発目的物(システム)を完成させる義務です。請負契約では、システムの完成がないと、請負代金を請求することができないのが原則です。納入された成果物に不具合があった場合、これが未完成なのか、完成しているが瑕疵があるのかの判断は、必ずしも容易ではありません。システムの完成と未完成をどのように判断するのでしょうか。この点少なくない裁判例は「最終工程基準」に基づいて完成未完成を判断しています。例となる裁判例としては、東京地裁平成14年4月22日判決(判例タイムズ1127号161頁)があります。同事件で裁判所は、「請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできない。〈9〉データ移行までの各工程を終了し、順次納品を行い、平成9年10月から本件システムを本格稼働させ、同10年10月ころまで使用を継続していることが認められることから、本件システムを完成させたと判断しました。基づいて完成未完成を判断しました。確かに、システム開発においては、多くの場合、画面表示や一部の処理に誤りが残ることは珍しくなく、処理速度などの性能も、本番環境での稼働の段階ではじめて不十分であることが判明する場合もあります。そのため、本番環境での稼働後に、こうした不具合を一つ一つ修正していくという方法は、きわめて一般的です。採用されることは合理的と考えられます。完成判断の要素~検収まず、ソフトウェア開発の標準的な工程では、検収の終了により運用に移行するため、検収の終了があった場合、通常は仕事の完成を認定してよいと考えられています。テスト仕様書等が挙げられます。発注者(ユーザ)が検収書への押印を拒否する場合システムの完成の有無が問題となり紛争となるケースでは、発注者側が検収書への押印を拒否する場合が少なくありません。受注者(ベンダー)側で検収前の作業を全て完了し、成果物(システム)が、所定の仕様や性能を客観的に満たす状態になっていれば、完成を認定するのが妥当であると考えられています。この場合、完成を示す諸要素の有無を踏まえ判断されることが多いと思われます。具体的には、納品済のシステムをユーザーが実際の業務で運用しているか否か、保守契約締結の有無、納品からどれだけ期間が経過しているか、マニュアルの制作とユーザによる受領の有無、納品からの期間の経過といった事情がこれに含まれます。ユーザーの主張する不具合の種類、程度等からも、成果物の完成の有無の判断要素となりえます。未完成であっても請負代金を請求できる可能性がある場合なお、厳密な意味でシステムが未完成とみられる場合でも、請負代金が請求できる可能性がある場合もあります。未完成の部分が全体の中で小さい場合です。この点、東京地裁平成17年4月22日判決は、未完成部分が全体の分量に比べて少量であることから、この点を請負業務の未完成の理由として主張することは「信義則上」許されないと判断しました。弊所の弁護士費用のうち、以下のものについては、オンラインで自動的に費用の目安を知ることができます。弊所へのご相談・弊所の事務所情報等については以下をご覧ください。発行し、比較的最近の判例を通じ、ビジネスに直結する法律知識と実務上の指針を提供しております。学術的で難解な判例の評論は極力避け、分かりやすさと実践性に主眼を置いています。社員が知っておくべき知的財産とビジネスに必要な法律知識を少しずつ吸収することができます。メルマガの購読は無料です。以下のフォームからご登録ください。バックナンバーはこちらからご覧になれます。本ページの内容は、執筆時点で有効な法令に基づいており、執筆後の法改正その他の事情の変化に対応していないことがありますので、くれぐれもご注意ください。