はじめに
IT契約書で発注側が確認すべき3つのポイントでは、支払い条件・検収・知的財産権の3点を挙げましたが、その中でも実務で最もトラブルになりやすいのが「検収」です。検収基準を曖昧にしたまま契約を進めてしまい、後になって揉めるケースを数多く見てきました。なぜ検収基準の明確化がそれほど重要なのか、具体的に整理します。
「検収」とは何を確認する行為なのか
検収とは、ベンダーから納品された成果物が、契約通りの内容になっているかを発注側が確認し、正式に受け入れる手続きです。検収が完了して初めて、発注側はベンダーに代金を支払う義務が発生し、ベンダーは契約上の責任を果たしたことになります。
つまり検収は、プロジェクトにおける「お金の支払いと責任の切り替えポイント」です。この重要な手続きの基準が曖昧なままだと、プロジェクトの終盤で深刻な対立を招きます。
検収基準が曖昧だと何が起きるか
検収基準を具体的に定義せずにプロジェクトを進めると、次のような事態が起こりがちです。
- 発注側は「これでは不十分」と主張し、ベンダーは「契約通りに作った」と主張する、水掛け論になる
- 検収が長期間完了せず、支払いが滞り、ベンダーとの関係が悪化する
- 「検収に合格しない限り直し続けてほしい」という発注側の要求に、ベンダーが際限なく応じさせられる（あるいは逆に、途中で対応を打ち切られる）
- どちらの言い分にも一定の理屈があるため、第三者が見ても白黒つけにくく、裁判や調停に発展するケースさえある
こうした対立は、プロジェクトの最終盤、関係者が疲弊しきったタイミングで起きることが多く、精神的にも事業的にも大きな負担になります。
検収基準は「契約前」に具体的に決めておく
検収基準で揉めないための唯一の解決策は、契約を結ぶ前の段階で、検収の合否を判断する基準を具体的に定義しておくことです。
- 何をもって「完成」とするか（機能一覧、満たすべき性能数値など）
- 検収のテスト項目・テストケースを誰が、いつまでに用意するか
- 不合格の場合の再検収のプロセス（何回まで、どのくらいの期間で）
- 検収期間そのものの長さ（提出から何営業日以内に合否を判断するか）
これらを要件定義書や契約書の別紙として明文化しておくことで、プロジェクト終盤になってから「言った言わない」の水掛け論になることを防げます。
曖昧になりやすいポイントに特に注意する
検収基準の中でも、特に曖昧になりやすく、あとでトラブルになりやすいのが「性能要件」と「非機能要件」です。「レスポンスが速いこと」のような定性的な表現ではなく、「3秒以内に表示されること」といった具体的な数値基準に落とし込む必要があります。これらは見落とされがちですが、実際にトラブルになる頻度は決して低くありません。
まとめ
検収基準が曖昧なまま契約を結ぶと、プロジェクトの終盤で発注側とベンダーの間に深刻な対立を招きます。検収の合否基準、テスト項目、再検収のプロセスは、契約を結ぶ前の段階で具体的に定義し、文書として残しておくことが、トラブルを未然に防ぐ唯一の方法です。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント