「納品されました」と言われて画面を触ってみたら一応動く。でも、これで「検収完了」のサインをしてしまっていいのか、判断がつかない——。個人でシステム開発を発注した人の多くが、この場面で立ち止まります。検収は、契約書の条項の中でも特に発注者側の作業量が大きい工程でありながら、何をどこまで確認すればよいかの基準を誰も教えてくれません。
この記事で分かること
- 検収で発注者が確認すべき5つのチェック項目
- 請負契約と準委任契約で、検収の位置づけがどう変わるか
- 検収でサインした後に何が変わるか（契約不適合責任の通知期限）
- 「対応完了」と言われたのに直っていない場合、どう対応すべきか
結論から言うと、検収とは納品物が契約・仕様書どおりに完成しているかを発注者自身が確認し、正式に受け取る手続きです。サインする前に確認すべきことを確認しきっていれば怖くありません。逆に、確認せずにサインしてしまうと、後から見つかった不具合を「無償修正の対象外」と言われるリスクが上がります。
検収とは何を確認する作業か
検収は、要件定義書・仕様書に書かれた機能がすべて動くかを、発注者自身の目と手で確かめる作業です。 「開発会社が動作確認したから大丈夫」ではなく、発注者側が別途確認する工程だと理解しておく必要があります。
一般的な検収チェックの観点は、大きく5つに分かれます。
- 機能要件の充足: 要件定義書・仕様書に定めた機能が、書かれたとおりに動作するか
- 非機能要件の確認: 表示速度・同時アクセス時の挙動など、契約書やRFPで合意した水準を満たしているか
- 異常系の挙動: 想定外の入力、通信が途切れた場合など、正常系以外の動きが破綻していないか
- ドキュメントの完備: 操作マニュアル、設計書など、契約で「納品物」に含めていた資料が揃っているか
- データ移行の整合性: 既存データを移行した場合、件数や内容にズレがないか
あなたの案件がまだ小規模な個人向けサービスであれば、5つすべてを本格的な試験計画書に落とし込む必要はありません。ただし、「主要な機能を実際に自分で一通り操作してみる」という受け入れテストだけは、検収書にサインする前に必ず行うのが基本です。仕様書に書かれた通りの手順で操作し、書かれた通りの結果になるかを一つずつ照合します。
請負契約と準委任契約で、検収の重みが変わる
検収という手続きが持つ意味は、契約形態によって実は異なります。個人が発注する際に結ぶ契約は、多くの場合 請負契約 か 準委任契約 のどちらかです。両者の基本的な違いは個人が開発を発注するときに知っておきたい契約の基本で解説していますが、検収との関係だけを取り出すと次のようになります。
- 請負契約: 「仕事の完成」を約束する契約のため、検収は「完成したかどうか」を判定する重要な手続きになる。検収に合格して初めて報酬請求権が確定する、という設計の契約書が多い
- 準委任契約: 「業務の遂行」自体が契約の対象であり、成果物の完成を約束する契約ではないため、検収という手続きが契約書に存在しない、あるいは形式的なものにとどまる場合がある
つまり、あなたが結んでいる契約が請負なのか準委任なのかによって、「検収書にサインするかどうか」の重みがまったく違います。契約書を読んで、まず自分の契約がどちらなのかを確認してください。準委任契約なのに、開発会社から請負契約と同じような重い検収手続きを求められている場合は、契約書の内容と実際の運用がずれている可能性があるため、質問して確認する価値があります。
検収書にサインすると、何が変わるのか
検収書にサイン（検収完了の連絡）をすると、その時点から契約不適合責任の通知期限のカウントが始まる、という点が最も重要です。
民法上、納品物が契約内容に適合しない場合、発注者はその不適合を知った時点から1年以内に開発会社へ通知しなければ、修正や損害賠償を請求する権利を失う可能性があります（民法559条・566条）。検収に合格したという事実は、「その時点で見つけられる不具合は無い」という発注者側の確認を意味するため、検収後に見つかった不具合は、この通知期限や契約書の個別条項に沿って対応してもらうことになります。
多くの契約書では、検収期間（納品から何日以内に検収するか）が定められています。 この期間が自分の業務スケジュールに対して現実的かどうかは、契約前の段階で確認しておきたいポイントです。検収期間の確認自体は契約書レビューの一部であり、詳しくは契約書で必ず確認したい条項（知的財産権・検収・保守）でも触れています。
検収期間中に不具合を見つけても判断に迷う場合は、その場でサインを保留し、開発会社に質問する、または対応を依頼してから改めて確認する、という順番を守ることが自分の権利を守ることにつながります。「早く終わらせたいから」という理由だけで、疑問が残ったままサインしないことが基本です。
「対応完了」と連絡が来たのに、直っていないとき
検収で不具合を指摘し、開発会社から「対応完了しました」と連絡が来たものの、実際に確認すると直っていない、あるいは別の箇所に新しい不具合が出ている——これも実際によくある場面です。
このときにまず行うべきことは以下の3点です。
- 「対応完了」の定義を確認する: 修正が完了したという連絡は、開発会社側の作業完了報告であって、発注者側の確認・合格を意味しません。自分で再度動作確認し、合格するまでは検収完了にしないという原則を崩さないことが重要です
- 不具合の再現手順を具体的に伝え直す: 「直っていません」だけでは開発会社側も対応しづらいため、どの操作をした結果、期待した動きと何が違ったかを、検収時と同じ粒度で記録して伝えます
- やり取りを書面（メール・チャットのログ）に残す: 口頭でのやり取りだけで済ませず、いつ・何を指摘し・どう回答されたかの記録を残しておくと、後で「対応完了」の解釈が食い違ったときの根拠になります
何度も対応が繰り返されて埒が明かない場合、契約書に定められた検収期間・再検収の手続きに従いつつ、契約不適合責任に基づく修正請求として改めて書面で申し入れるという対応も選択肢になります。ここまで来ると自己判断でのやり取りが難しくなるため、契約金額や状況次第では弁護士への相談も検討してください（この記事は制度の入口整理までを扱うものであり、個別の契約書の解釈や交渉の代行は専門家の領域です）。
契約から検収完了までにどれくらいの期間を見込んでおくべきかというスケジュール感については、契約から検収まで、開発期全体でかかる期間の目安で整理しています。この記事で扱った「何を確認するか」と合わせて確認しておくと、検収の見通しが立てやすくなります。
まとめ：検収は「サインする前」が勝負
検収でもっとも重要な判断は、サインした後ではなく、サインする前にあります。仕様書と実際の動きを自分で突き合わせる、疑問が残ったら聞く、契約が請負か準委任かで検収の重みが違うことを理解しておく。この3点を押さえておけば、検収は「よく分からないまま流される手続き」ではなく、「自分のサービスを正式に受け取るための最後の確認」として機能します。
まだ発注前で、契約書に検収の条項がどう書かれているかを確認する段階であれば、開発会社との初回打ち合わせで、必ず聞くべきことも合わせて確認しておくと、検収の基準についても早い段階で認識をそろえやすくなります。
