システム開発の最後の関門が検収である。納品されたものが、求めていたものになっているかを確認し、完了と認める手続きである。ここで「思っていたものと違う」という食い違いが表面化することは少なくない。また、検収を通った後に不具合が見つかったとき、誰がどこまで対応するのかも、トラブルになりやすい論点である。

本記事は、検収と、納品後の不具合対応（契約不適合責任と呼ばれることがある）の考え方を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門である。検収の基準をどう決めるか、不具合への対応をどう捉えるかという観点を持っておくと、完了の判断やその後の対応で慌てずに済む。なお、契約不適合責任の範囲や期間については法律上の定めが関わり、個別の判断には事情が影響するため、最終的な判断は弁護士など専門家への確認を前提としていただきたい。

結論：検収基準を先に決め、不具合対応の範囲を明確にする

検収と不具合対応のトラブルを避けるには、判断の基準を先に決めておくことが欠かせない。GXOが発注者にすすめるのは、次の3点である。

  • 何をもって完了とするか、検収の基準を開発前に決めておく
  • 検収の手順と期間を取り決め、確認の体制を用意する
  • 納品後の不具合対応の範囲と期間を、契約で確認しておく

検収は、開発が終わってから基準を考えるのでは遅い。要件定義の段階で「どうなっていれば完成か」を意識しておくと、検収もスムーズになる。

なぜ検収と不具合対応が重要か

検収は、成果物を受け入れるかどうかの判断であり、その後の支払いや責任の起点になる。基準が曖昧だと、完了の判断をめぐって対立し、いつまでも検収が終わらない事態になりかねない。

検収と不具合対応の取り決めが不十分だと、次のような問題につながりやすい。

  • 完了の基準がなく、検収が終わらず支払いも進まない
  • 検収後に不具合が出たとき、対応の範囲で揉める
  • 不具合対応の期間が曖昧で、いつまで対応してもらえるか分からない

検収は、開発の品質を確認する最後の機会である。契約形態が請負か準委任かによって、完成責任の捉え方も変わる。契約形態の違いは請負契約と準委任契約の違いで扱っている。

検収基準を先に決める

何をもって完了とするか

検収の基準は、開発が始まる前、できれば要件定義の段階で意識しておきたい。求めていた機能が、求めていた条件で動くこと、というように、確認できる形で基準を持っておくと、判断がぶれない。

検収の手順と期間

検収は、誰が、どんな手順で、どのくらいの期間で確認するのかを取り決めておきたい。期間が定められていないと、確認が長引いたり、逆に十分に確認できなかったりする。

取り決める項目内容の例
検収の基準要件で定めた機能が動作すること
確認する人業務を担当する社内のメンバー
検収の手順テスト項目に沿って確認する
検収の期間納品からの確認に充てる日数

検収の基準は、要件定義で固めた内容と結びつく。要件をどう固めるかは要件定義でもめないための準備も参考になる。

納品後の不具合対応（契約不適合責任）

検収を通った後でも、契約で定めた内容に適合しない不具合が見つかることがある。このとき、開発会社がどこまで対応するのかが、契約不適合責任と呼ばれる論点である。

  • 対応の範囲：どんな不具合が対応の対象になるのか。仕様どおりに動かない不具合か、運用上の改善要望かで扱いが変わる。
  • 対応の方法：修正で対応するのか、別の方法をとるのか。
  • 対応の期間：いつまでの間に見つかった不具合が対象になるのか。

不具合対応の範囲や期間は、法律上の定めや契約の取り決めが関わる。契約書にどう書かれているかを確認し、不明な点は弁護士など専門家にも確認することをおすすめする。なお、仕様の範囲なのか追加の要望なのかの線引きが難しいこともあり、その判断には仕様変更・追加要件の扱いの視点も役立つ。

ここで発注者として意識しておきたいのは、「不具合」と「改善要望」は別物だという点である。契約で定めた内容どおりに動かないのは不具合だが、「使ってみたらもっとこうしたくなった」というのは改善要望にあたることが多い。前者は対応の対象になりやすいが、後者は新たな依頼として扱われることがある。この区別を意識しておくと、検収後のやり取りで認識がずれにくい。検収の段階で見つかった問題が、どちらにあたるのかを開発会社と確認しておくとよい。

検収・不具合対応でよくある失敗

検収と不具合対応では、次のような失敗が起きやすい。いずれも、事前に基準と範囲を決めておけば避けられる。

  • 検収基準を決めない：何をもって完了とするかが曖昧で、判断が長引く。
  • 検収を形だけで済ます：十分に確認せず通してしまい、後で不具合が多発する。
  • 対応範囲を確認しない：不具合が出てから、対応の範囲をめぐって対立する。
  • 期間を意識しない：不具合対応の期間を確認せず、対象外になってから気づく。

検収は、品質を確認する大切な機会である。基準を持って確認し、不具合対応の範囲を契約で押さえておきたい。

検収・不具合対応のチェックリスト

検収に臨む前、そして納品後の不具合に備えて、次の点を確認しておきたい。事前に基準と範囲を押さえておくほど、判断に迷わずに済む。

  • 何をもって完了とするか、検収の基準を要件定義の段階で意識したか
  • 検収を行う社内の担当者を決めたか
  • 検収の手順（テスト項目に沿って確認するなど）を用意したか
  • 検収に充てる期間を取り決めたか
  • 納品後の不具合対応の範囲が契約に記載されているか
  • 不具合対応の期間が契約で確認できるか
  • 仕様どおりの動作と、新たな改善要望の線引きを意識したか

これらが整理されていれば、検収の場で「完了かどうか」の判断がぶれにくく、納品後に不具合が出たときも、対応の範囲を契約に照らして判断できる。

検収を形だけにしないために

検収は、忙しさの中で形だけになりがちな工程である。しかし、ここで十分に確認しないと、業務で使い始めてから不具合に気づき、対応に追われることになる。検収には、実際に業務を担当する人が関わることが望ましい。開発を発注した担当者だけでなく、日々その業務を行う現場の人が確認することで、実用上の問題に気づきやすくなる。

確認の際は、よく使う操作や、業務上重要な処理を中心に試したい。すべての機能を網羅するのは難しくても、使用頻度の高い部分を丁寧に確認することで、実際の運用で困る不具合を見つけやすくなる。検収で見つかった問題は、その場で記録し、対応の要否を開発会社と確認しておきたい。検収基準のもとになる要件の固め方は要件定義でもめないための準備も参考になる。

関連記事

よくある質問

Q1. 検収では、どこまで細かく確認すればよいですか

要件で定めた機能が、想定した業務の場面で正しく動くかを確認したい。すべてを網羅するのは難しいが、業務上重要な機能や、よく使う操作を中心に確認すると、実用上の問題を見つけやすい。確認項目を事前に整理しておくとよい。

Q2. 検収後に不具合が見つかったら、無償で直してもらえますか

契約で定めた内容に適合しない不具合であれば、対応の対象になることが多いが、対応の範囲や期間は契約の取り決めや法律上の定めによる。仕様どおりの動作と、新たな改善要望は扱いが異なるため、線引きが難しい場合は専門家にも確認するとよい。

Q3. 不具合対応の期間は、どのくらいが一般的ですか

期間は契約によって定められることが多く、案件の規模や性質によっても変わるため、一律の目安を断定することは避けたい。契約書にどう記載されているかを確認し、自社にとって適切かどうかは弁護士など専門家に相談しながら判断することをおすすめする。

検収基準と不具合対応の範囲を、発注前に整理しませんか

GXOでは、システム開発の検収にあたり、完了の基準、確認の手順、納品後の不具合対応の捉え方を整理し、後のトラブルを避けるための準備をご支援します。契約不適合責任など専門的な判断は専門家と連携しながら進めます。

検収・不具合対応を相談する

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。