検収とは？発注者がやるべきテスト

ようやく開発会社から「システムが完成しました」と連絡が来た。画面をひと通り見て、動いているようには見える。ここでハンコを押せば検収完了、そのあとは契約通りに残金を支払う段取りになっている。しかし、実際に何を確認すればよいのか、どこまで細かくチェックすれば十分なのか、誰も教えてくれない。ひとりで情シスや総務のIT担当を兼任している方であれば、開発が完了した安堵と同時に、この「最後の確認作業」に一抹の不安を感じたことがあるのではないでしょうか。

結論から言うと、検収とは、納品されたシステムが契約書や仕様書の内容を満たしているかどうかを発注者自身が確認し、受け入れるかどうかを判断する手続きです。そして検収に合格したという意思表示（検収合格の通知や検収書への押印など）をした瞬間から、代金の支払い義務が確定し、その後に見つかった不具合の扱いも大きく変わります。つまり検収は、発注者にとって「契約内容通りのものが届いたか」を確認できる、実質的に最後のチェックポイントです。

この記事では、発注者として検収の段階で何をテストし、何を確認すればよいのかを、民法の条文を確認しながら実務目線で整理します。読み終える頃には、「とりあえず動いているから大丈夫」という感覚的な判断ではなく、何を根拠にどこまで確認すればよいのかを、自分の言葉で説明できるようになるはずです。

この記事で分かること

開発が完了し、検収の段階に入ったものの何をすればよいか分からない担当者が抱える疑問に、順番に答えていきます。

• 検収とは、法律上どのような位置づけの手続きなのか
• 検収に合格すると、発注者・開発会社それぞれに何が起きるのか
• 検収で確認すべきテストの種類と、具体的なチェック項目
• 検収期間はどれくらい確保すればよいか
• 不具合が見つかったとき、検収に合格させてよいのか
• 検収後に不具合が見つかった場合、発注者はどんな主張ができるのか

一つずつ、順を追って見ていきます。

検収とは何か。契約書・仕様書との照合作業

検収とは、開発会社から納品されたシステムが、契約書・仕様書・要件定義書などに記載された内容を満たしているかどうかを、発注者自身が確認する手続きです。確認の結果、内容を満たしていると判断すれば「検収合格」として受け入れ、満たしていなければ「検収不合格」として修正を求めることになります。

ここで重要なのは、検収は開発会社が「できました」と言えば自動的に完了するものではなく、あくまで発注者側が主体的に確認し、合否を判断する行為だという点です。動いているように見える、画面のデザインが良い、といった印象だけで判断してしまうと、契約書に書かれていた機能が実は抜けていた、性能要件を満たしていなかった、といった不備を見逃すことになりかねません。

• 検収は発注者が行う確認作業であり、開発会社が主張する「完成」をそのまま鵜呑みにする手続きではない
• 確認の基準は、契約書・仕様書・要件定義書などに記載された内容であり、発注者の主観的な好みではない
• 検収の結果（合格・不合格）は、その後の代金支払いや不具合対応の扱いに直結する

検収という言葉自体は民法に明文で定義されているわけではなく、実務上の用語として広く使われているものです。ただし、検収という行為が持つ法的な意味合いは、民法上の請負契約に関する条文と密接に結びついています。次の見出しで、この結びつきを具体的に見ていきます。

検収と報酬支払いの関係。民法第633条が定める原則

システム開発の多くは請負契約、あるいは請負的な性質を持つ契約として発注されます。請負契約における報酬の支払い時期について、民法第633条は次のように定めています。

報酬は、仕事の目的物の引渡しと同時に、支払わなければならない。ただし、物の引渡しを要しないときは、第六百二十四条第一項の規定を準用する。（民法第633条）

この条文が示しているのは、報酬（開発費用）の支払いは「仕事の目的物の引渡し」と同時が原則だということです。実務上のシステム開発では、この「目的物の引渡し」を受けて発注者が内容を確認し、契約内容を満たしていると判断する手続きが検収にあたります。つまり検収合格は、報酬支払い義務が確定する引き金になる行為だと理解しておく必要があります。

実際の契約書では、民法の原則そのままではなく、次のような形で検収と支払いの関係が具体的に定められているのが一般的です。

• 納品後、一定の期間（例:2週間や30日など）を「検収期間」として設定する
• 検収期間内に発注者から不合格の通知がなければ、自動的に検収合格とみなす「みなし検収」条項を置く
• 検収合格の通知（検収書の発行や書面での合格通知）をもって、残代金の請求権が発生する

検収期間や「みなし検収」の条件は契約書ごとに異なります。とくに「◯日以内に連絡がなければ検収合格とみなす」という条項がある場合、忙しさにかまけて確認を先延ばしにしていると、実際には十分に確認できていないまま検収合格が確定してしまうことがあります。契約書に検収期間の定めがあるかどうかは、納品前の段階で必ず確認しておくことをおすすめします。

このように、検収合格は単なる形式的な儀式ではなく、契約上・法律上の重要な意味を持つ行為です。次の見出しでは、検収に合格した後に何が起きるのか、もう少し踏み込んで整理します。

検収合格後に起きる2つの変化

検収に合格すると、発注者にとって大きく2つの変化が起きます。

1. 代金支払い義務の確定: 前述の通り、検収合格をもって残代金の請求権が発生し、発注者は契約書に定められた期日までに支払う義務を負います
2. 不具合対応の位置づけの変化: 検収合格後に見つかった不具合は、「未完成の成果物」としての修正要求ではなく、「契約内容に適合しない部分」としての契約不適合責任の問題として扱われるようになります

この2つ目の変化は見落とされがちですが、実務上は非常に重要です。検収前であれば「まだ完成していないので直してください」という単純な話で済みますが、検収後は「契約内容と違う部分がある」ことを発注者側が主張し、根拠を示す必要が出てきます。この違いについては、記事の後半で詳しく取り上げます。

検収で確認すべき3種類のテスト

検収の段階で行うべき確認作業は、大きく3種類に分けて考えると整理しやすくなります。

機能テスト:仕様書に書かれた機能を一つずつ確認する

機能テストは、契約書や仕様書に記載された機能が、記載通りに動作するかを一つずつ確認する作業です。もっとも基本的でありながら、もっとも見落としが起きやすい確認でもあります。

• 仕様書・要件定義書に記載された機能の一覧を洗い出し、チェックリスト化する
• 一覧の項目を一つずつ実際に操作し、期待した結果が返ってくるかを確認する
• 「動いた」だけでなく、「仕様書に書かれた通りの挙動か」を照合する（見た目が動いていても、条件分岐や計算結果が仕様と違うことがある）

とくに注意したいのは、正常な操作だけでなく、異常な操作（誤った値を入力した場合、必須項目を空欄にした場合など）に対してどう振る舞うかも、仕様書に記載があれば確認対象になるという点です。正常系のテストだけで「動いている」と判断してしまうと、実際の運用で想定外の操作をしたときに不具合が表面化することがあります。

非機能テスト:数値や基準で示された要件を確認する

非機能テストは、「画面の表示速度は3秒以内」「同時に50人がアクセスしても問題なく動作する」といった、機能そのものではなく品質面の基準を確認するテストです。

• 契約書・仕様書に、性能・セキュリティ・可用性などの数値目標が明記されているかを確認する
• 明記されている場合は、その基準を満たしているかを実測または開発会社からの報告で確認する
• 明記されていない場合は、検収の合否判断に非機能面の不満をそのまま持ち込めない可能性があることを理解しておく

非機能要件は、契約前の要件定義の段階で具体的な数値として合意できていないと、検収の時点になって「動作が遅い気がする」という感覚的な不満はあっても、契約内容に照らして不合格にできる根拠が弱くなってしまいます。この点は、検収の話でありながら、実は発注の初期段階の準備がものを言う部分でもあります。

業務シナリオテスト:実際の業務の流れで通しても動くか

業務シナリオテストは、個別の機能が単体で動くかではなく、実際の業務の流れに沿って一連の操作を通しで行っても問題なく完結するかを確認するテストです。

• 「受注入力→在庫引き当て→出荷指示→請求書発行」のように、実際の業務フローの順番で操作してみる
• 複数の担当者が関わる業務であれば、可能な範囲で実際にその業務を担当する予定の人にも操作してもらう
• 月末・期末など、特定のタイミングでのみ発生する処理（締め処理、集計処理など）があれば、その動作も確認対象に含める

機能テストで個々の機能が正しく動いていても、業務の流れの中で使うと想定外の不具合が出ることがあります。たとえば、ある機能で入力したデータが、別の画面での表示や計算に正しく反映されていない、といったケースです。実際に使う人の目線で一連の流れを確認することは、機能テストだけでは見つけにくい不具合を発見するために欠かせません。

業務シナリオテストは、情シス担当者ひとりだけで完結させようとせず、実際にそのシステムを使う現場の担当者に協力を依頼することをおすすめします。日々の業務を知っている人でなければ気づけない違和感は少なくありません。検収期間が限られている中で協力を仰ぐのは気が引けるかもしれませんが、検収後に業務が回らなくなるリスクと比べれば、早い段階での協力依頼のほうが結果的に負担は小さく済みます。

検収チェックリスト:最低限確認したい項目

ここまでの内容を踏まえて、検収の際に最低限確認しておきたい項目を整理します。

• 契約書・仕様書に記載された機能が、すべて実装されているか（一覧化して照合したか）
• 正常な操作だけでなく、誤った入力や想定外の操作をした場合の挙動を確認したか
• 契約書・仕様書に性能・セキュリティなどの数値基準が明記されている場合、その基準を満たしているか
• 実際の業務フローに沿って、一連の操作を通しで行っても問題なく完結するか
• データ移行を伴う開発の場合、移行後のデータに欠落・誤変換がないか
• マニュアルや運用手順書など、契約書に定められた成果物がすべて揃っているか
• 検収期間として契約書に定められた日数が、実際に確認するのに十分な長さか

最後の項目は見落とされがちですが重要です。契約書に「納品後2週間以内に検収を行う」といった条項がある場合、その期間内に前述の3種類のテストを完了できるかどうかを、納品前の段階で見積もっておく必要があります。期間が足りないと判断した場合は、納品前の打ち合わせで検収期間の延長を相談することも検討してください。

検収期間は、いつ・どうやって確保するか

検収期間は「納品されてから初めて考える」のではなく、契約前の段階である程度見積もっておくことをおすすめします。

• システムの規模・複雑さに応じて、機能テスト・非機能テスト・業務シナリオテストにそれぞれどれくらいの日数がかかりそうか、ざっくりでも見積もっておく
• 現場の担当者に業務シナリオテストへの協力を依頼する場合、その担当者のスケジュールも考慮に入れる
• 検収期間が短すぎると感じた場合は、契約締結前の打ち合わせで開発会社に相談する

小規模なシステムであっても、業務の重要度が高い（止まると本業に支障が出る）場合は、検収期間を短く見積もりすぎないことが大切です。一方で、検収期間を必要以上に長く取ると、開発会社側の入金サイクルにも影響が出るため、双方にとって現実的な期間を事前に相談しておくのが望ましい進め方です。

「みなし検収」条項には特に注意する

契約書によっては、「納品後、発注者から一定期間内に異議の申し出がない場合は、検収に合格したものとみなす」という、いわゆる「みなし検収」の条項が入っていることがあります。

• みなし検収条項がある契約書では、確認作業を先延ばしにしていると、意図せず検収合格が確定してしまう
• 業務が忙しく確認の時間が取れない場合は、期限内に「まだ確認中である」旨を書面やメールで開発会社に伝えておくことが望ましい
• 確認が間に合わない見込みが早い段階で分かった場合は、検収期間の延長を早めに相談する

みなし検収条項自体は、開発会社にとって「いつまでも代金を回収できない」という事態を避けるための合理的な仕組みでもあります。発注者側としては、この条項の存在を理解したうえで、確認のスケジュールを計画的に組むことが重要になります。

不具合が見つかったら、検収に合格させてよいのか

検収の過程で不具合が見つかった場合、「合格にしてよいのか」「どう対応すればよいのか」で迷う場面が出てきます。ここでは、不具合の深刻度に応じた考え方を整理します。

• 業務に支障が出るレベルの不具合: 検収不合格とし、修正を求めたうえで再度検収を行うのが基本的な対応です。契約書・仕様書の内容を満たしていない以上、合格させる理由はありません
• 軽微な表示崩れなど、業務に支障のない不具合: 検収自体は合格としつつ、修正すべき事項を書面（検収書の備考欄や別紙の指摘事項リストなど）に明記し、いつまでに対応してもらうかを合意しておく方法が実務上よく取られます
• 仕様書に記載がなく、発注者が期待していた動きと異なる部分: これは「不具合」ではなく「認識のズレ」である可能性があります。契約書・仕様書に立ち返り、記載があるかどうかをまず確認する必要があります

検収を「合格」か「不合格」かの二択でとらえすぎると、軽微な指摘のたびに検収不合格を繰り返すことになり、双方の負担が増えてしまいます。実務では、致命的でない不具合について「指摘事項を明記したうえで条件付き合格とする」という運用が広く行われています。ただし、この場合は指摘事項と対応期限を必ず書面に残し、口頭だけの合意で終わらせないことが重要です。

とくに注意したいのが、「仕様書に記載がない」ことを理由に、開発会社から「それは今回の契約の範囲外です」と説明される場面です。発注者が期待していた動きであっても、契約書・仕様書に明記されていなければ、原則としてその実装は契約上の義務の範囲外だと判断されます。この場合、追加の作業として別途対応を依頼する（追加費用が発生する可能性がある）か、次回以降の改修で対応するかを協議することになります。

検収不合格にした場合、その後どうなるか

検収不合格とした場合は、指摘した不具合の内容を書面で明確に伝え、開発会社に修正を依頼します。修正後、再度納品を受けて検収をやり直す、という流れが一般的です。

• 指摘事項は、口頭ではなく書面（メールを含む）で残す
• 「いつまでに修正するか」の期限を、可能な範囲で合意しておく
• 再検収の際は、指摘した箇所が修正されているかだけでなく、その修正によって他の機能に影響が出ていないか（デグレードが起きていないか）も確認する

修正のたびに検収をやり直すサイクルが繰り返されると、当初のSOW（作業範囲記述書）で想定していた検収期間を超過することがあります。想定より繰り返しが多くなりそうな場合は、経営層やプロジェクト関係者に早めに状況を共有しておくことをおすすめします。

検収後に見つかった不具合。契約不適合責任という考え方

検収に合格した後、しばらく使ってみて初めて不具合に気づく、というケースも実務上は少なくありません。この場合、発注者はもう何も主張できないのでしょうか。結論としては、一定の条件のもとで、開発会社に修正等を求めることができます。この根拠になるのが、民法上の契約不適合責任という考え方です。

請負契約における契約不適合責任について、民法第636条は次のように定めています。

請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき（その引渡しを要しない場合にあっては、仕事が終了した時に仕事の目的物が種類又は品質に関して契約の内容に適合しないとき）は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。（民法第636条）

やや読みにくい条文ですが、要点は「納品されたシステムが契約内容に適合しないものであった場合、発注者は開発会社に対して修正等を求めることができる」という点です。ただし、この条文には重要な期間制限があります。民法第637条を確認します。

前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。（民法第637条第1項）

つまり、検収後に不具合（契約内容に適合しない部分）が見つかった場合でも、それに「気づいた時から1年以内」に開発会社へ通知しなければ、修正や損害賠償を求める権利を失ってしまうということです。この「1年」という期間は、不具合が発生した時からではなく、発注者が「不適合に気づいた時」から数える点にも注意が必要です。

• 検収後にシステムを使っていて不具合に気づいたら、できるだけ早く、遅くとも1年以内に開発会社へ書面で通知する
• 「そのうち直してもらえばいいか」と放置していると、通知が遅れて権利を失うリスクがある
• 通知の記録（メールの送信日時など）は、後日の証拠として残しておく

なお、この契約不適合責任に関する条文は、契約書側で別の期間や条件が定められている場合、契約書の内容が優先されることが一般的です（民法の規定は任意規定であり、当事者間の合意で変更できる部分が多いため）。実際に自社が締結した契約書に、契約不適合責任について独自の定めがないかを確認しておくことをおすすめします。

検収合格と契約不適合責任の関係を整理する

ここまでの内容を整理すると、検収の前後で発注者が主張できる内容の性質が変わることが分かります。

この違いを理解しておくと、「検収に合格させてしまったら、もう何も言えなくなるのでは」という不安が過剰であることも分かります。検収後であっても、契約内容に適合しない部分があれば、期間内であれば修正等を求めることができます。ただし、検収前の「未完成」を理由にした主張よりも、検収後は「契約内容と具体的にどう違うか」を発注者側が示す必要があるという点で、立証のハードルが上がる面はあります。だからこそ、検収の段階でできる限り丁寧に確認しておくことに意味があるのです。

検収を丸投げしないための社内体制づくり

検収は、情シス担当者ひとりで抱え込むと、確認の抜け漏れが起きやすい作業でもあります。丸投げにしないための工夫をいくつか紹介します。

• 確認項目をチェックリスト化し、関係者と共有する: 何を確認するかを事前にリスト化しておくと、確認漏れが減るだけでなく、複数人での分担もしやすくなります
• 業務シナリオテストは、必ず現場の利用予定者を巻き込む: 情シス担当者だけでは気づけない、業務特有の使い方や例外パターンを拾い上げてもらえます
• 検収の合否判断とその根拠を、経営層にも簡潔に共有する: 検収は代金支払いに直結する重要な意思決定です。担当者個人の判断だけで進めず、少なくとも結果と根拠を上長に報告しておくと、後日のトラブル時にも経緯を説明しやすくなります
• 指摘事項・合意事項は必ず書面（メールを含む）に残す: 口頭だけのやり取りは、後になって「言った・言わない」の水掛け論になりやすい部分です

とくに、ひとりで情シスや総務を兼任している方の場合、検収作業に十分な時間を割けないまま期限が迫ってしまうケースが少なくありません。前述の「みなし検収」条項がある契約では、この時間不足がそのまま検収合格の確定につながってしまうリスクがあります。可能であれば、開発の終盤に差し掛かった段階で、検収に充てられる時間を業務スケジュールの中であらかじめ確保しておくことをおすすめします。

検収に合格した後にやっておきたいこと

検収に合格した後も、いくつかやっておきたい作業があります。

• 検収合格の記録を残す: 検収書への押印や、検収合格を通知したメールの控えなど、いつ・誰が・何を確認して合格としたかの記録を保管しておきます
• 契約不適合責任の通知期限を意識しておく: 前述の通り、不適合に気づいてから通知までの期間が問われるため、システムを使い始めた後もしばらくは注意深く動作を確認する期間を設けておくと安心です
• 保守契約の内容を再確認する: 検収合格後の不具合対応が、無償の契約不適合責任の範囲なのか、有償の保守契約の範囲なのかは、契約書上区別されていることが一般的です。この境界があいまいなままだと、いざ不具合が起きたときに「これは無償ですか、有償ですか」というやり取りで時間を取られることになります

検収は「終わり」ではなく、システムを実際の業務で使い始める「始まり」でもあります。検収合格をゴールとせず、その後の運用・保守フェーズへの引き継ぎとして位置づけておくと、検収後のトラブルにも落ち着いて対応しやすくなります。

まとめ:検収は発注者が主体的に行う最後の確認機会

検収とは、納品されたシステムが契約書・仕様書の内容を満たしているかを発注者自身が確認し、受け入れるかどうかを判断する手続きです。民法第633条が示す通り、検収合格は報酬支払い義務の確定という重要な法的効果を持つため、「動いているように見えるから大丈夫」という感覚的な判断ではなく、機能テスト・非機能テスト・業務シナリオテストという3種類の観点から、契約書・仕様書と照合しながら確認することが欠かせません。

検収後に不具合が見つかった場合でも、民法第636条・第637条に基づく契約不適合責任として、気づいた時から原則1年以内であれば修正等を求めることができます。ただし、検収前の「未完成」を理由にした主張よりも立証のハードルが上がる面があるため、検収の段階でできる限り丁寧に確認しておくに越したことはありません。

検収は情シス担当者ひとりで抱え込む必要はなく、現場の利用予定者や経営層を巻き込みながら進めることで、確認の抜け漏れを減らせます。次は、検収に至るまでの過程である見積書の読み方や、契約形態そのものの違いについて解説した記事もあわせてご覧ください。発注の準備段階から検収までを一連の流れとして理解しておくことが、トラブルの少ない外注につながります。