「検収」は、発注者にとって最も重要なプロセス
ソフトウェア開発を依頼して、開発が完了したあと。次に行うのが「検収」です。検収とは、納品されたシステムが仕様通りに動作するかを発注者が確認し、問題なければ受け入れるプロセスのことです。
検収に合格して初めて、納品が完了し、報酬の支払いが発生します。逆に言えば、検収は発注者にとってお金を払う前に確認できる最後の機会です。
検収で確認すべき3つのこと
1. 依頼した機能が動いているか
最も基本的な確認事項です。最初に合意した仕様書や要件定義書をもとに、依頼した機能がすべて実装されているかを確認します。
- ログイン、登録、検索、一覧表示 — 基本機能の動作確認
- 管理画面から設定変更 — 管理者権限での操作確認
- メール通知や決済 — 外部サービスとの連携確認
2. 想定外の操作でエラーが起きないか
正常な操作だけでなく、想定外の操作をしたときの挙動も確認しましょう。
| 確認パターン | 内容 | チェック観点 |
|---|---|---|
| 空欄のまま送信 | 必須項目を入力せずに送信 | エラーメッセージが表示されるか |
| 大量のデータ | 一度に多くのデータを登録 | レスポンスが極端に遅くならないか |
| スマートフォン | モバイルブラウザでの表示 | レイアウト崩れがないか |
すべてのパターンを網羅する必要はありませんが、実際の利用場面を想像しながら触ってみることで、開発段階では見つからなかった問題が見えてくることがあります。
3. 納品物の一覧が揃っているか
ソフトウェア本体だけでなく、以下のような納品物が含まれているかを確認しましょう。
| 納品物 | 内容 | 重要度 |
|---|---|---|
| ソースコード | 開発したプログラムの原本 | 必須 |
| 設計書・仕様書 | 何をどう作ったかの記録 | 必須 |
| テスト結果 | どのようなテストを行い、結果がどうだったか | 推奨 |
| 操作マニュアル | システムの使い方の説明 | 推奨 |
ヒント: これらは、将来的にシステムを改修したり、別の開発会社に引き継いだりする際に必要になります。納品時にまとめて受け取っておくことをおすすめします。
検収でトラブルを防ぐための3つのルール
ルール1:検収の基準を事前に決めておく
何をもって検収完了とするかを開発開始前に合意することが重要です。
- どの機能が動けば合格とするか
- 軽微なバグ(表示崩れなど)がある場合、検収を通すかどうか
- 検収後に見つかった不具合の対応期間はいつまでか
ルール2:検収期間を十分に確保する
検収は1〜2日で終わるものではありません。実際に業務で使ってみて初めて気づく問題もあります。一般的には1〜2週間程度の検収期間を設けることが多いです。
検収期間が短すぎると、問題を見つけきれないまま受け入れてしまうリスクがあります。逆に長すぎると、開発会社側の負担が大きくなります。双方にとって妥当な期間を、事前に合意しておきましょう。
ルール3:検収後の不具合対応を契約に盛り込む
検収が完了したあとに不具合が見つかった場合、どこまで無償で対応してもらえるのかを確認しておきましょう。一般的な請負契約では、納品後1年間は開発会社に修正の義務(契約不適合責任)があります。
ただし、仕様変更や追加機能の要望は、不具合対応とは別です。この線引きも、事前に明確にしておくことが大切です。
Appspectの納品プロセス
Appspectでは、納品の摩擦をできる限り減らすために、以下のプロセスで進めています。
- 開発中から段階的に確認 — 完成してからまとめて確認するのではなく、できた機能から順にご確認いただく
- ダッシュボードで進捗共有 — 今何が完成していて、何がまだかをリアルタイムで把握できる
- 契約・書類はオンラインで完結 — 見積書・契約書・検収書のやり取りをすべてオンラインで行い、紙のやり取りを不要にしている
成果: 段階的に確認を進めることで、最終検収の時点で想定と違うというリスクを最小限に抑えています。
まとめ
ソフトウェアの検収・納品で押さえるべきポイントは3つです。
- 検収は確認できる最後の機会 — 依頼した機能が動いているか、想定外の操作でエラーが出ないか、納品物が揃っているかを確認する
- 基準と期間を事前に決める — 何をもって合格とするか、検収期間はどれくらいかを、開発開始前に合意しておく
- 段階的に確認する — 完成してからまとめて見るのではなく、開発中から順に確認することで、手戻りを防ぐ
納品や検収の進め方についてご不明な点があれば、お気軽にご相談ください。初回のご相談は無料でお受けしています。