システム開発の検収とは？起こりやすいトラブルや作業時の注意点

システム開発における検収は、システムの納品後に発注会社が行う重要な作業です。検収とは、簡潔にいえば納品物の検査や点検作業のことを指しますが、システム開発における検収は単なる流れ作業的なものではありません。複雑な工程を踏み、検収を完了させるというケースも少なくないのです。

本記事では、システム開発における検収の内容やそれに伴ってよく発生するトラブルの例、滞りなく検収を完了させるためのポイントも解説します。

 

目次

 

 

システム開発の検収とは

システム開発における検収とは、納品されたシステムを発注側が実際に操作して仕様どおりに作動するか否かをチェックする工程のことです。仕様書や指定した要件内容を基準に、システムが正しく動作しているかを確認し、仕様書や要件どおりに動作すれば、検収は合格となります。検収が合格となってはじめて、受注会社は発注会社から報酬を受け取れます。納品物に何かしらの不備や不具合が見つかった場合は、受注会社へ検収不合格の通知をしたうえで修正・再納品の依頼を行います。

なお、検収作業を含めたシステム開発の大まかな流れは、以下のとおりです。

1. ヒアリング
2. 契約の締結
3. 要件定義
4. 基本設計
5. 詳細設計
6. コーディング
7. 各種テスト
8. 納品および発注会社による検収
9. 運用・保守

流れからわかるように、検収作業はシステム開発の工程のうち、下流工程にあたります。システムが納品されれば、システム開発の工程が完了するわけではありません。発注会社は納品物を検収し、システムとしての合否を判断する必要があります。

検収する項目は複数あり、システムの規模やジャンルによって異なるため記事中で全てをピックアップするのは困難ですが、必ず確認すべき項目としては「実装されている機能」「プログラムの保守性」「ユーザビリティ」が挙げられます。

例えば、機能の検収では仕様書どおりのものが実装されているかだけでなく、要求していない機能が盛り込まれていないかもチェックすると良いでしょう。要求していない機能が搭載されていると検収の時間が長引いてしまううえ、運用時の混乱につながる可能性もあります。

プログラムの保守性チェックでは、「わかりやすくメンテナンスしやすいプログラムになっているか否か」をみると良いでしょう。具体的には、コードがシンプルでわかりやすく、他者が解読しやすいものになっているかを確認することが重要です。プログラミングやコーディングの知識がある社内のメンバーに協力してもらいながら、以下の点をチェックしましょう。

• 一つの処理ブロックが20～30行に収まっているか

• 適切な字下げによりブロックの分かれ目がわかりやすくなっているか

• わかりづらい変数名が使用されていないか

• 適切な位置に適切なコメント、メモが残されているか

ユーザビリティのチェックは、使用ユーザーの使い勝手を想定した検収作業です。システムの利用シーンを想定したシナリオを用いて、システムの操作性や使用感をテストします。例えば、業務システムであれば「実際の業務フローに沿って操作できるUI（ユーザーインターフェース）になっているか」「ボタンの配置はわかりやすいか・誤操作しやすい配置になっていないか」などの点をチェックすると良いでしょう。

 

システム開発の検収で起こりうるトラブルと知っておきたい用語

システム開発の検収で起こりやすいトラブルと、その対処法をご紹介します。合わせて、「契約不適合責任」「瑕疵担保責任」など、検収時に踏まえておきたい関連用語についても解説します。

 

●契約不適合責任と瑕疵担保責任

システム開発における「契約不適合責任」とは、開発会社に課せられる責任の一つです。契約内容に適合しない障害や欠陥が納品物に発生した際、開発会社は契約不適合責任に則って納品物を修正・再納品しなくてはなりません。2020年4月に民法の「瑕疵担保責任」が改正され、現在の契約不適合責任になったという経緯があります。契約不適合責任では、以下のような改正がなされています。

• （改正前）瑕疵担保責任：成果物の納品完了から1年間

• （改正後）契約不適合責任：成果物の不具合発覚から1年間

1年という期限に変化はありませんが、修正の責任が発生するタイミングが「納品完了後」から「不具合発覚後」へ改正されているのがポイントです。上記の期限内にシステムの不具合や欠陥が発覚した場合、開発会社には納品物を修正する責任があります。検収後の修正依頼でトラブルにならないためにも、契約不適合責任と瑕疵担保責任の違いをしっかり把握しておきましょう。

 

●システム開発における検収期間の目安は？

システム開発における一般的な検収期間の目安は、2週間～1ヶ月程度です。検収期間が短すぎると十分な確認ができず、不具合を見逃してしまいかねません。かといって、検収期間を長く取りすぎると報酬の支払いが先延ばしになるため、受注側の経済的な負担が大きくなります。「機能や性能を十分にチェックできる」「受注側を待たせすぎない」という点を踏まえて、短くても2週間程度の検収期間を設けると良いでしょう。

 

●不具合の対応方法の違いがわかりづらい

システム開発の契約形態によって、修正依頼や不具合対応の方法が異なります。「請負契約」「準委任契約」の2つのケースを例に挙げて、それぞれの報酬の対象物や不具合の対応などの違いを簡潔にまとめました。

上記の表からわかるとおり、準委任契約には契約不適合責任が適用されません。ただし、「善管注意義務」は契約形態にかかわらず適用されます。善管注意義務とは、「善良な管理者の注意義務」の略語です。善管注意義務により、業務を委託された受注側は、一般的に要求される程度の注意義務を払い業務に当たらなくてはなりません。善管注意義務を怠ったことが確認できれば、準委任契約であってもシステムの再修正・納品依頼が認められる可能性があります。

くわえて、準委任契約には従来の「履行割合型」のほかに「成果完成型」という契約形態があります。こちらは完成したシステム（=納品物）が報酬の対象となっているため、「システムに不具合やバグが多い」「未完成のまま納品された」という場合、受注側に債務不履行責任を問うことが可能です。契約不適合責任が必ずしも適用されるとは限りませんが、細かな契約条件によっては受注側に対処してもらえる作業量が増えるという点も覚えておくと良いでしょう。

 

●検収後に不具合が見つかる

検収が完了し、受注側に報酬を支払ってから不具合が見つかることも考えられます。このケースでは、返金を求めるのは難しいという考えが一般的です。しかし、不適合責任の範囲内で修正を依頼したり、賠償を求めたりすることは可能です。

ITシステムの検収では、専門的な知識や視点が必要となる部分が少なくありません。確認事項が多く煩雑になりやすいため、発注側が全ての不具合を検知しきれないことも考えられます。特に、発注側にIT知識が少ないケースは注意が必要です。「できる限りのリソースと知識で検収をしたが、それでも後になって看過できない不具合が見つかった」という事態に発展し、検収後の報酬の支払いや損害賠償の請求などを巡ったトラブルにつながるおそれがあります。

こうしたトラブルを避けるためには、契約不適合に該当するトラブルの範囲や対処内容などを書面に残しておくようにしましょう。また、IT法務の専門家やコンサルタントなどIT知識のある第三者に、トラブルを未然に防ぐために相談しておくのも一つの手です。

 

システム開発の検収をする前の注意点

検収を滞りなく進めるための注意点やポイントを、以下で4つご紹介します。

 

●成果物の定義を明確にする

システム開発における成果物とは、開発工程で製作されたプログラミングしたソースコードや設計書などです。「どのような成果物をもって納品したとみなすのか」という点を明確にしておき、発注側と受注側の双方ですり合わせしておきましょう。成果物（納品物）とみなされるものの例としては、以下が挙げられます。

• 各種ソースコード

• システムの基本設計書

• システムの詳細設計書

• テスト仕様書

• テスト結果報告書

• 実行ファイル1セット

• 運用／仕様説明書

• システム管理者向けマニュアル

• ユーザー向け操作マニュアル

合わせて、検収の内容を明確にすることも重要です。仕様書に、検収内容やその際に用いるチェックリスト、「どのような作業をもって検収完了とするのか」といった情報を盛り込んでおくと、すり合わせがスムーズになります。話し合いのうえで、認識を統一しておきましょう。

 

●明確な検収期間を定め周知する

検収期間も明確に定めましょう。この時、発注側・受注側がお互いの都合を押し付け合っては検収が滞ってしまいます。「システムの規模や性質、検収担当者の知識レベルを踏まえたうえで検収期間を設定したい」「締め日や支払日などを踏まえて期間を設定したい」など、双方が意見をきちんと言語化して話し合いを進めなくてはなりません。受注側から短期間での検収を依頼された場合は、「一部テストの協力を依頼する」といった妥協点を探す必要もあるでしょう。

 

●具体的な合格基準を定め周知する

何をもって検収を合格とするのか、具体的かつ合理的な基準を明示することが大切です。具体的には、以下のような点を盛り込むと良いでしょう。

• 要件定義や仕様書で記した要件が満たされているか

• バグや不具合が少ないか

• 処理能力や応答速度の要件は満たされているか

• 必要に応じたメンテナンスや拡張を簡単に行えるか

• 直感的に作業でき、わかりやすいUIになっているか

具体的な合格基準は、検査仕様書やテスト仕様書などのドキュメントに記載しておくと、認識のすり合わせ時に役立ちます。

 

●不合格時の通知に関する取り決めも行う

検収結果が不合格となった場合、受注側へ不合格通知を出すことになります。不合格通知を送信する際のルールや、「みなし検収」についての取り決めを行っておきましょう。みなし検収とは、成果物の納品から一定期間が過ぎて検収の合否の通知がない場合は、検収を合格したと「みなす」ことです。みなし検収に関するルールは「みなし検収条項」と呼ばれ、システム開発の契約書に盛り込まれているケースが多くみられます。

みなし検収条項の目的の一つは、検収の長期化防止です。成果物を納品しても、発注側が検収に応じずいつまでも合否が判然としないというケースがあります。こうした事態に備えて、「成果物の納品より◯日間、具体的な根拠を示しての合否通知をしない場合には検収に合格したとみなす」という規定を盛り込むのがみなし検収条項です。双方で話し合いのうえ、みなし検収の期間や合否通知を送る期間を取り決めて契約書へ盛り込みましょう。なお、不合格通知に明示する内容は、以下のとおりです。

• 検収不合格の旨

• 不合格の理由（具体的かつ合理的なもの）

• 修正と再納品を依頼する旨

システム開発における検収は、発注側・受注側の双方にとって重要な工程です。思わぬトラブルに巻き込まれないためにも、システム開発の依頼時には検収に関する知識も身につけておきましょう。同時に、信頼できてコミュニケーションを円滑にとれる開発会社をパートナーとして選定することも大切です。

システム開発会社の発注先にお悩みの方は、ぜひ発注ナビまでお気軽にご相談ください。

発注ナビであれば、全国5000社以上の中から、ご要望や案件内容に合った開発会社を厳選してご紹介いたします。『自社に合った開発会社がわからない』『選定にできるだけ時間をかけずにスムーズに導入したい』とお考えのご担当者様は、ぜひ一度ご検討してみてはいかがでしょうか。

 

 

 

■システム開発に関連した記事