検収書にサインをした翌週、担当者の携帯が鳴った。納品されたばかりの業務システムで、在庫データが夜間バッチのタイミングによって二重に計上されることがあると、現場のパートスタッフから報告があったのだ。慌てて開発会社に電話をすると、返ってきたのは「検収完了後の修正になりますので、追加のお見積りをお出しします」という一言だった。あの薄い一枚の紙にハンコを押しただけで、無償で直してもらえるはずだった不具合が、有償の追加案件に変わってしまった。担当者は契約書も検収書のひな形も、社内の誰かが作った定型フォーマットをそのまま使い、細かい文言までは見ていなかった。サインという行為の重さを、後になって思い知らされる展開である。
この記事を読んでいるということは、あなたはまさに今、納品を受けたシステムの検収書にサインしようとしている、あるいはこれからサインする場面が近づいている担当者だろう。当社olana.jpのコラムには以前、UAT(受け入れテスト)の進め方について書いた記事があるが、あちらはテストの設計や実施の話が中心だった。今回はテストの先、つまり検収書という書類そのものに焦点を当てる。何を書けばいいのか、何を書いてはいけないのか、サインする前に何を確認すべきなのか。契約実務の一般的な知識として、地に足のついた形で解説していく。
検収書とは何か、サインすることで法的に何が起きるのか
検収書とは、発注者が受け取った成果物(この場合は業務システム)について、契約内容に適合していることを確認し、受領したことを証明する書類である。単なる領収書や受け取りの控えとは意味が違う。検収書にサインをするという行為は、法的には「この成果物は契約で定めた仕様や品質を満たしている」という発注者側の意思表示になる。
これが重要なのは、多くの請負契約において、検収の完了が代金支払い義務の発生条件になっているからだ。同時に、検収完了後に見つかった不具合は「契約不適合」として扱われるかどうかの境界線にもなる。民法改正(2020年施行)により、かつての「瑕疵担保責任」は「契約不適合責任」という枠組みに変わったが、いずれにせよ、検収完了という事実は、発注者と開発会社の間で「ここまでは合格」というラインを引く行為であることに変わりはない。
つまり検収書は、単なる事務手続きの一枚ではなく、後々の追加費用の発生有無、無償修正の範囲、そして万が一トラブルになった際にどちらの主張が通りやすいかを左右する、契約上の重要な証拠書類なのである。現場で日々システムと向き合う担当者にとっては地味な作業に見えるかもしれないが、この一枚が会社の数十万円、時には数百万円の追加コストの発生を左右すると考えれば、決して軽く扱ってよい書類ではない。
検収書に記載すべき基本項目
検収書のフォーマットは会社によってさまざまだが、最低限、次の項目は明記されているべきである。曖昧な検収書は、後になって「言った言わない」の水掛け論を招く最大の原因になる。
- 検収対象の名称と範囲(システム名、対象モジュール、バージョンなど。「システム一式」のような曖昧な表現ではなく、契約書や仕様書のどの部分に対応する成果物なのかを明記する)
- 検収日(実際にテストを完了し、確認が取れた日付。サインした日と一致しない場合は両方を分けて記載する)
- 確認者の氏名・部署(現場でテストを行った担当者と、最終承認をした責任者が異なる場合は両方記載する)
- 検収の判定基準(仕様書のどの項目を、どのテストケースで確認したか。可能であればテスト結果報告書やUATの合格記録を添付資料として紐づける)
- 留保事項の有無(未解決の不具合や保留にした仕様がある場合、その内容と対応方針。詳細は次章で述べる)
- 支払い条件との関連(この検収書の提出がどの支払いのトリガーになるのか。分割検収の場合は、どの工程の検収なのかを明記する)
意外と見落とされがちなのが、検収の「範囲」の明記である。「システム一式について検収完了」とだけ書かれた検収書は、開発会社にとって都合よく解釈される余地を残してしまう。逆に発注者側からすれば、明確な範囲指定こそが、後から「ここは検収対象外だったはずだ」という主張を裏付ける材料になる。壁を越えて交渉し、現場と経営の橋渡しをする担当者ほど、この一行の解像度にこだわってほしい。
未解決の不具合がある場合の「留保事項」の書き方と重要性
システム開発の現場では、検収のタイミングですべての不具合がゼロになっているケースはむしろ稀だ。優先度の低い表示崩れ、特定の環境でしか再現しない軽微な不具合、次のフェーズで対応予定の機能拡張など、「今は残っているが致命的ではない」項目が必ずと言っていいほど存在する。ここで重要になるのが「留保事項」の書き方である。
留保事項とは、検収は完了させるが、特定の不具合や未完了項目については別途対応することを明記する条項のことだ。口頭で「これは後で直します」と言われただけで安心し、書面に何も残さないまま検収書にサインしてしまうと、その約束は法的にはほぼ存在しないのと同じになる。担当者個人の記憶やメールの文面だけを頼りにするのではなく、検収書という正式な書類の中に、次のような形で明記しておく必要がある。
- 不具合の内容(現象、発生条件、影響範囲を具体的に)
- 対応方針(無償修正か、追加費用が発生するか)
- 対応期限(いつまでに修正するか、具体的な日付か、次回リリースのタイミングか)
- 対応が完了しなかった場合の取り扱い(再度協議するのか、契約解除やペナルティの対象になるのか)
「検収書は完了扱いにするが、別紙のとおり3件の不具合については9月末までに無償で修正する」といった一文があるだけで、後々の交渉の土台がまったく変わってくる。逆にこの一文がなければ、検収完了イコール契約適合という前提の上に、開発会社が「追加のご要望」として見積りを出してきても、発注者側は強く反論しにくい立場に置かれる。留保事項は、担当者が現場で戦うための、数少ない有効な武器の一つなのである。
サインする前に必ず確認すべきポイント
検収書にサインをするという瞬間は、多くの場合、プロジェクトの佳境を越えてほっと一息つきたいタイミングと重なる。だからこそ、意識的に立ち止まる必要がある。サイン前に、次の点を必ず確認してほしい。
- 仕様書や契約書と照らし合わせ、記載された検収範囲に漏れがないか
- テストで発見された不具合が、すべて留保事項として書面に反映されているか(口頭合意だけになっていないか)
- 検収書の日付と、実際にテストを完了した日付に不自然なズレがないか
- この検収書が、どの支払いの根拠になるのかを理解しているか(全額の支払いなのか、一部工程の支払いなのか)
- 社内の決裁ルール上、自分にサインする権限があるか、上長の確認が必要ないか
- 検収書に「今後の追加要望は別契約とする」といった、開発会社側に有利な一文が紛れ込んでいないか
特に最後の項目は見落とされやすい。開発会社が用意した検収書のフォーマットをそのまま使う場合、発注者側の権利を制限するような文言がさりげなく盛り込まれていることがある。すべての条項を自分で作る必要はないが、少なくとも「この一文は自社にとって不利にならないか」という視点で、一度は目を通す姿勢が要る。忙しい現場の中でその数分を惜しまないことが、後の数十万円の交渉を左右する。
よくある失敗パターン
実際の現場でよく見られる失敗パターンを、あらためて整理しておく。自分の状況と照らし合わせてみてほしい。
- 開発会社から「検収書だけ先にいただけますか、支払い処理の都合で」と急かされ、テストが完了しきっていないのにサインしてしまう
- 不具合の存在は認識していたが、開発会社の担当者から「後で直しますので」と口頭で言われただけで安心し、検収書には何も残さなかった
- 検収対象の範囲が「システム一式」としか書かれておらず、後から「このオプション機能は検収対象外だった」と主張されてしまう
- 現場担当者がテストして合格と判断したが、決裁権限のない自分がそのままサインしてしまい、後から上長との認識にズレが生じた
- 検収書のひな形を開発会社側が用意し、発注者側は内容を精査せずそのまま押印してしまった
これらに共通するのは、「サインは事務作業の一つに過ぎない」という感覚で処理してしまっていることだ。プロジェクトの現場で走り続けてきた担当者ほど、最後の書類作業を軽く扱ってしまいがちだが、実際にはここまでのすべての苦労の成果を、法的に固定するのがこの一枚の紙である。だからこそ、最後まで気を抜かずに向き合う価値がある。
まとめ
検収書は、単なる受け取りの証ではなく、発注者と開発会社の間で「ここまでは合格」というラインを引く、契約上重みのある書類である。検収対象の範囲、検収日、確認者、そして何より未解決の不具合がある場合の留保事項を、口頭ではなく書面に明記することが、後々の無用なトラブルや追加費用の発生を防ぐ最大の防御線になる。
サインする前には、仕様書との照合、留保事項の反映漏れの確認、支払い条件との関連、そして自分にサインする権限があるかどうかまで、一つずつ丁寧に確認してほしい。急かされても、疑問があればその場で止める勇気を持つこと。それは決して臆病な態度ではなく、システムを発注し、現場と経営の間に立って責任を背負う担当者だからこそできる、静かで確かな仕事である。地味に見えるその一枚のサインの先にこそ、プロジェクトを本当の意味で成功させる分かれ道がある。