検収とシステム仕様の確定について ～IT法務～
１．検証とは
検収とは、成果物が、ユーザー側の注文した仕様どおりであるか否かを検査することです。
検収仕様書を作成しこれに基づき進めていくことが重要です。
検収にかかわるトラブルは頻発します。
例えば、契約上、ベンダーの報酬請求権は、納品後の検収を完了した時点で発生するとされていることが多いです。
そのため、ユーザーから、検収中にバグが発見されたことを理由に、検収を一通り完了したものの、報酬の支払いを拒むユーザーもいます。
しかし、裁判例では、ベンダーの報酬請求権の発生について、システムの完成の有無を判断基準とするものが見られます。
つまり、予定されていた最後の工程まで終了していれば、システムは完成したと認められ、これによってベンダーの報酬請求権は発生すると判断されています。
システムにはバグがつきものですから、上記裁判例のような判断はベンダーにとって参考になります。
また、検収後の製品にバグ（瑕疵）があった場合、補修をユーザー・ベンダーどちらの責任で行うべきかについても、トラブルになりがちです。
そのため、検収後の瑕疵が判明した場合の取り決めも極めて重要です。
システムの検収後、瑕疵があれば、通常はベンダーの責任で補修することになります（瑕疵担保責任）。
それでは、いつまでベンダーは責任を負わなければならないのでしょうか。
この点、請負の瑕疵担保責任について、民法は引渡し後1年、商法は6ヶ月と定めています。
もっとも、これらの期間が長すぎるとして、契約上短く決めておくことは可能です。
例）
|
但し、ベンダーとしては、自己の責に基づく瑕疵の場合とする文言がある方が良いでしょう。
さらに、近年、分割検収もよく用いられます。
分割検収とは、例えば、工程を、基本設計、詳細設計・制作、テストなどに分け、各検収ごとに報酬支払とすることです。
これによって、ベンダーは、資金を途中で得ながら開発に取り組むことができます。
ユーザーも、途中で検収することで、完成後のトラブルを未然に予防できます。
２．システム仕様の確定
システム仕様の確定が曖昧な場合に生じるトラブルは、後に変更が生じた場合に、それが仕様の変更なのか、追加なのかが分からなくなることです。
そのため、事前に双方合意の下確定しておくことが要されます。
システム開発は、ベンダーから提案書が作られ、細部聴取の上、仕様書が作られます。
ここでは、ユーザー・ベンダーの協力体制が不可欠です。
そのため、システム開発に必要な情報を共有する場を設けることが必要です。
あとあとのトラブルを予防するため、その議事録を記録し、出来上がった仕様書に対するユーザーの承認が残るようにすることも重要です。
承認は、署名だけでなく、契約書上に承認した旨を盛りこんでおくことでも代替可能です。
作業の変更が行われた場合、追加報酬の問題が生じます。
作業の変更があれば、新たな請負契約が成立したとして、ベンダーに報酬請求権が発生します。
しかし、単なる修正程度のものであれば、もともとの契約の範囲内の作業として、報酬請求権は生じません。
どのような契約書にすれば良いかお悩みの方、また、検収後のトラブルにお困りの方、ぜひ弁護士へ一度ご相談下さい。
