この記事の要約

検収とは、開発会社が作ったシステムが注文どおりにできているかを発注者が確認する工程です。単に動くかだけでなく、仕様どおりか・実際の業務で使えるかまで確認し、不具合が見つかったら再現手順を伝えて修正・再確認することが、スムーズなシステム導入につながります。

システム開発の最後に「検収（けんしゅう）」という工程があります。

システム開発会社から「システムが完成しました」と聞くとホッとしてしまいそうですが、実はここからの検収がプロジェクトの成否を大きく左右します。
もし検収を正しく理解せず、曖昧なまま済ませてしまうと、運用が始まってから思わぬトラブルや追加費用が発生するリスクがあるのです。

本記事では、システム開発における「検収」について、意味や確認するポイント、不具合が見つかった場合の対応などを、分かりやすく解説します。

１．検収とは何か

システム開発では、システムが完成すると、発注者が「検収」を行います。
ここで大切なのは、「開発会社がシステムを完成させた＝開発終了」ではないということです。

開発会社がシステムを作った後、発注者はシステムが注文どおりに完成しているか、問題なく利用できる状態になっているかを確認します。
この確認を「検収」といいます。

つまり、検収とは、開発会社が作ったシステムが、注文どおりにできているかを発注者が確認する工程です。
検収で問題がないことを確認して、やっと開発が完了したと判断できるわけです。

では、もしこの検収をしなかったり、十分に確認しないまま終わらせたりすると、どのような問題が起こるのでしょうか。

２．検収を適当にすると何が起きる？

「忙しくてチェックする時間がない」「開発会社を信頼しているから」と、検収をスキップしたり、適当に済ませてしまったりすることは禁物です。
検収をおろそかにすると、後からプロジェクト全体に影響するような、次のような問題が発生しやすくなります。

納品後に問題が発覚し、修正のタイミングを逃す

システムを実際に動かしてみないと気づけない不具合は少なくありません。
検収を適当に済ませてしまうと、実業務が始まってから「ボタンが反応しない」「データが保存されない」といった問題が発覚する可能性があります。

業務が始まってからの修正になると、利用を一時的に止めたり、手作業で対応したりする必要が出てくる場合もあります。

実際の業務とミスマッチが起きてしまう

システムは問題なく動いていても、実際の業務の流れに当てはめると「操作しにくい」「必要な機能が足りない」といったことが起きる事もあります。
せっかくコストをかけて作ったシステムなのに現場に定着しない、ということにもなりかねません。

自動的に「合格」扱いになってしまう

一般的なシステム開発の契約では、「納品から〇日以内に連絡がなければ、検収に合格したものとみなす」というルール（みなし検収）が定められていることがほとんどです。
つまり、確認を後回しにしている間に、自動的に検収が完了した扱いになってしまうリスクがあります。

支払いなどをめぐるトラブルに発展することも

検収が曖昧なまま検収期間が過ぎて支払いの段階に進むと、発注側は「まだちゃんと動いていないから払いたくない」、開発側は「納品したのだから期限通りに支払ってほしい」と、お互いの認識にズレが生じてしまいます。
場合によっては開発会社と発注者で関係が悪化することもあります。

検収は開発会社のミスを探して責任を追及するためのものではありません。
「依頼したものが、実際に使える状態になっているか」を発注者と開発会社で一緒に確認するための工程と考えると分かりやすいでしょう。
では、具体的に検収では何を確認すればよいのでしょうか。

３．検収では何を確認する？

検収は、単に「システムが動くか」を見るだけではありません。
開発会社が行う技術的なテストとは異なり、発注者側の検収では「仕様通りか」と「実際の業務で使えるか」を確認します。

具体的には、以下のポイントを中心に確認をします。

必要な機能が実装されているか

まずは、事前に要望した機能が漏れなく揃っているかを確認します。画面上に必要なボタンや入力項目がすべて配置されているか、大枠のチェックから始めます。

想定したとおりに動くか

各機能が正しく動作するか、実際に操作して確かめます。
基本操作をすべて行い、エラーが出ずにスムーズに動くかを確認します。
たとえば、

など、実際の操作を一通り行って確認します。

データが正しく扱われているか

登録したデータが、別の画面でも正しく表示されるか、集計結果に正しく反映されるかなども確認します。
たとえば、10件の申込みを登録したのに集計画面では9件しか表示されない、といったことがないかを確認します。
「登録できた」だけで終わらず、登録したデータがその後の処理でも正しく表示されているかを確認することがポイントです。

利用者ごとの権限が正しいか

システムを利用する人によって、見られる情報や操作できる機能が異なる場合は、権限設定も確認します。
たとえば、

といった設定が、依頼どおりになっているかを確認します。
権限設定は、実際の利用者を想定して確認することで、問題を見つけやすくなります。

実際の業務で使えるか

これが発注者側の検収で最も重要なポイントです。
機能チェックだけでなく、「現場の業務の流れ」に沿って一連の操作をしてみます。
例えば、「受注登録をして、請求書を発行し、売上データに反映されるか」といった実務のシチュエーションを再現して、使いづらい部分がないかを検証します。

開発会社のテストでは「仕様書通りにプログラムが動くか」を検証しています。
一方で、「実際の業務の流れにフィットしているか」は、現場の実務を知っている発注者にしか確認できません。
単なる「機能の動作確認」にとどまらず、実際の業務を想定したテストを行うと、より実用的な検収になります。

４．検収で不具合が見つかったらどうする？

検収をしていると、想定していた動作と違うところや、使っていて気になる点が見つかることがあります。
その場合は、見つけた問題をそのままにせず、発注者と開発会社で内容を確認し、必要に応じて修正してもらいます。

基本的な流れは次のとおりです。

①問題を発見する

まずは、実際にシステムを操作していて「想定と違う」「うまく動かない」と感じたところをチェックします。

②どの操作で問題が起きたかを伝える

開発会社が原因を特定できるように、「どの画面で」「どんな入力をしたら」「どうなったか」という具体的な再現手順を伝えます。
エラー画面のスクリーンショットを添えると非常にスムーズです。

③要件・仕様と照らし合わせる

次に、その動作が「不具合」なのかを確認します。
事前に決めていた「仕様」と違っているのか、それとも事前の取り決めにはなかった新しい要望なのかを、要件定義書と見比べながら開発会社と確認します。
「思っていた動きと違う」からといって、必ずしもシステムの不具合とは限りません。

④修正が必要か判断する

明らかに直すべきバグであれば修正を依頼します。
ただし、仕様どおりに動いているものの、実際の業務では使いにくいという場合には、仕様変更や追加改修として対応することもあります。
この場合は、検収時の「不具合修正」とは別に、追加の対応として扱う必要があるかもしれません。
契約内容や開発会社との取り決めによって対応は異なるため、まずは相談してみるとよいでしょう。

⑤修正後に再度確認する

開発会社側での修正が完了したら、報告のあった箇所が本当に直っているか、もう一度同じ操作をして確認（再テスト）します。

⑥問題がなければ検収完了

確認して問題がなければ、そのシステムについて検収を完了します。

検収で問題が見つかると「開発会社のミスだ」と思ってしまうかもしれませんが、必ずしもそうとは限りません。
もちろん、仕様と異なる動作をしていれば、開発会社側で修正が必要になることはあります。
しかし、システム開発では、事前に決めた仕様通りに作られていても、「実際に動かしてみたら、想定と違う挙動になってしまった」という認識のズレがどうしても発生します。
また、別の機能を直した影響で、これまで動いていた場所に新しい問題が起きてしまうことも技術的にはよくあります。

検収は作ったシステムをより良くするためのブラッシュアップ期間です。
しっかり確認をして、発注者と開発会社の双方が納得した状態で検収を完了させることが、スムーズなシステム導入につながるのです。

まとめ

今回は、完成したシステムを確認する「検収」についてご紹介しました。

検収では、単に機能が動くかどうかを確認するだけでなく、要件や仕様どおりに完成しているか、実際の業務で問題なく使えるかまで確認することが大切です。

では、検収のときに「思っていたものと違う」「どこを確認すればいいのか分からない」とならないためには、どうすればよいのでしょうか。
実は、検収の準備はシステムが完成してから始めるものではありません。開発を始める前から、検収で何を確認するのかを決めておくことが重要です。

次回のコラムでは、システム開発の検収をスムーズに進めるために、開発前に決めておきたい検収の基準についてご紹介します。