システム開発における検収とは？トラブルを起こさないための要点を解説
一般に、システム開発会社に委託した契約（請負契約）の完了とは、発注元の検収を以って行われます。
検収を行うと、その後運用フェーズに入って発見された不具合（バグ）については開発会社の責任で一定期間無償修理されることになることが一般的ですが、それ以外の要望や認識違いについては基本的に別契約にて有償対応となります。
システム開発の検収といっても、専門のITチームを持たない会社ではやり方が分からないことが多く、適当な検収を行い後でトラブルになることも多いです。
また、システム開発における検収のことを受入テスト（ユーザテスト）とも呼びます。
- システム開発における検収とは？
- 検収の進め方（悪い例）
- 検収の進め方（良い例）
- さらに検収の質を高めるなら
- まとめ
システム開発における検収とは？
一般に、システム開発会社に委託した契約（請負契約）の完了とは、発注元の検収を以って行われます。
検収を行うと、その後運用フェーズに入って発見された不具合（バグ）については開発会社の責任で一定期間無償修理されることになることが一般的ですが、それ以外の要望や認識違いについては基本的に別契約にて有償対応となります。
システム開発の検収といっても、専門のITチームを持たない会社ではやり方が分からないことが多く、適当な検収を行い後でトラブルになることも多いです。 また、システム開発における検収のことを受入テスト（ユーザテスト）とも呼びます。
検収の進め方（悪い例）
まず悪い例を挙げます。
これは開発会社から開発完了の報告があった後に、適当に思いついたままにシステムを使い、五月雨式にバグや要望を挙げ、バグが修正されたら検収完了というものです。
何が悪いのかというと、主に以下の点になります。
Ａ．機能の網羅性が低い（テストの抜け漏れがある）
Ｂ．データの質が悪い（本番運用開始後に実データを入れてはじめてバグが見つかるというケースも少なくありません）
Ａは開発会社が結合テストという工程で網羅的なテストを実施するはずです。
Ｂは開発会社がシステムテスト（総合テスト）で本番相当のデータを使ってテストを実施するはずです。
検収の進め方（良い例）
基本的には悪い例の逆の事をします。
ａ．網羅性の高いテストを実施する。
ｂ．本運用を想定したデータを予め用意する。
ａは、設計フェーズ以前に用意されるはずの業務フロー図から、主要な業務を選定してテスト計画を行います。
システム会社の行うような異常系テストはやらないでも良いので、正常系テストは一通りの機能をテストできるよう計画しましょう。
ｂは、ａで設計した各テスト計画において、必要なデータを本番を想定して用意しましょう。
次に、納品ドキュメントの検収を行いましょう。 納品ドキュメントは契約時にどんなドキュメントを納品してもらうか記載されるはずです。
何も記載がなくてもまともな開発会社であれば、データベース関連の設計書や画面仕様書（外部仕様書）、テスト関係のドキュメントはあるはずですので、リクエストしてみると良いと思います。
ただし、これを見て何か理解をするには、システム開発の知見が深い人員を依頼側で確保していけなればなりません。
また、WEBシステムであればセキュリティについてもどのようなテストを実施したのか、レポートをもらいたいところです。
さらに検収の質を高めるなら
これは依頼者側にシステム開発の専門家がいる前提ですが、より質を高めるために以下のことを実施するとより良くなります。
・セキュリティテスト（脆弱性診断）の実施
・異常系テストの実施
・インフラ障害時の対応シミュレーション
・連携する外部システムの障害時の対応
こちらについては追って詳細を記載したいと思います。
まとめ
ここではシステム開発における検収（受入テスト）についての解説やポイントを記載しました。
こちらを実践してもらい、トラブルの低減に役立てたら幸いです。
