LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

検収・受入テストとは何か――発注者が確認すべき役割と目的

システム開発における検収・受入テスト（UAT：User Acceptance Testing）とは、ベンダーが納品したシステムが発注者の業務要件と契約仕様を満たしているかを、発注者自身の観点から最終確認する工程です。

この確認工程が完了して初めて「検収完了」となり、システムの所有権や保守責任が発注者側に移ります。発注者にとっては、開発プロジェクト全体の集大成であると同時に、その後の権利保護の起点にもなる重要な節目です。

「ベンダーのテスト」と「発注者の受入テスト」の違い

ベンダーが行うシステムテスト（総合テスト）は、開発仕様書どおりにシステムが動作するかをベンダー側の技術観点で検証する工程です。一方、発注者が行う受入テストは「自社の業務で実際に使えるか」という業務観点での検証です。

仕様書どおりに動いていても、業務フローや実データで使うと問題が出るケースがあります。受入テストはそのギャップを発注者が責任をもって埋める工程です。

検収完了が民法562条（契約不適合責任）の起点になる理由

2020年4月に施行された改正民法では、請負契約に関して民法559条を通じ、562条（契約不適合責任）が準用されます。納品物が「種類、品質または数量に関して契約内容に適合しない」場合、発注者は追完請求・損害賠償請求・代金減額請求・契約解除のいずれかを行使できます^*1。

ただし、この権利を行使するには「不適合を知った時から1年以内」に通知することが必要です。検収を曖昧なまま完了させると「知った時」の特定が困難になります。

IPA（独立行政法人情報処理推進機構）が公開する「情報システム・モデル取引・契約書（第二版）」でも、ユーザー企業とITベンダーの間で「検収方法等について共通理解のもと対話を深める」ことの重要性が強調されています^*2。

受入テスト前に準備する3つのドキュメント

受入テストの成否は、テスト実施前の準備段階で8割が決まります。「実際に動かしてみて気づいた問題を片端から指摘する」というアプローチでは、際限のない修正要求につながります。事前に3つのドキュメントを整備しておくことが大切です。

テスト計画書――目的・範囲・スケジュール・体制

テスト計画書には、テストの目的・対象範囲・スケジュール・参加者と役割分担・テスト環境の5項目を明記します。発注者側の担当者だけでなく、ベンダーの窓口担当者も役割を明示しておくと、問題発生時の連絡・対応ルートが明確になります。

計画書はプロジェクトの初期段階から作成することが望まれます。受入テストの内容がシステムテストや統合テストの計画にも影響するためです。

テストケース・テストシナリオ書――業務フローから作る

テストケースは要件定義書に記載された機能を網羅する形で作成します。ただし要件定義書の項目を機械的に並べるだけでは不十分です。実際の業務フロー（受注→在庫確認→出荷指示→請求など）を一連のシナリオとしてテストケースに落とし込むことで、機能単体では問題がなくても業務全体では支障が出るケースを発見できます。

テストケースには「操作手順」「入力データ」「期待される結果」「実際の結果」「合否」の列を設けます。Excelなどの表形式で管理するのが一般的です。

合否判断基準書――「仕様適合」を客観的に定める

合否基準を「担当者が満足したら合格」という主観的な定義にすると、際限なく修正要求が続く原因になります。合否基準は「要件定義書・仕様書に記載された機能・性能を満たしているかどうか」という客観的な定義が基本です。

さらに、バグの重要度ごとに基準を設けます。致命的な不具合（画面が開かない、データが消えるなど）がゼロであること、軽微な不具合（表示崩れなど）は一定数以下であること、という形で数値化しておくと判断がスムーズになります。

受入テストの実施手順――4種類の確認項目と優先度

受入テストでは主に4種類の確認を行います。すべてを並行して進めるのではなく、優先度と依存関係を考慮して順序立てて実施することが大切です。

機能テスト――要件定義全項目を網羅する

機能テストは要件定義書に記載されたすべての機能が実装されているかを確認します。機能の多い案件では、仕様変更が生じた機能とその周辺機能を優先的にテストします。変更後の機能が既存の機能に影響を与えていないかを確認するリグレッション（退行）テストとして実施します。

シナリオテスト（業務フロー検証）――実業務の通し確認

機能テストで個別機能の動作確認が完了したら、次は実際の業務フローに沿った通し確認を行います。例えば「新規顧客登録→受注→在庫照合→出荷指示→請求書発行」という一連の流れを実データで操作します。

この際、テスト担当者は実際にその業務を担当するメンバーが行うことが望まれます。業務知識のない担当者では、画面の動作に問題がなくても「実業務では困る」という問題を発見できません。

システム間連携テスト――データ受け渡しの正確性確認

新システムが既存の外部システム（会計システム・ECモール・物流システムなど）とデータ連携する場合は、連携テストが必要です。データのフォーマット・タイミング・数値精度が正確に受け渡されているかを確認します。

連携テストは双方向で行います。新システムからデータを送信して外部システムが正しく受信するかだけでなく、外部システムから受信したデータを新システムが正しく処理するかも確認します。

現新比較テスト――既存システムとの出力照合（移行案件向け）

既存システムからリプレイスする案件では、同一のインプットに対して新旧システムの出力結果を照合する現新比較テストが有効です。帳票・集計値・データ量に差異がないかを確認します。

なお、テストは本番に近い環境・実データで行うことが求められます。テスト専用データや開発環境では発見できない問題が、本番環境や大量データでは発生することがあります。

合否判断の基準設定と「みなし検収」リスク

テストの実施とともに、合否判断の運用方法も事前に合意しておくことが重要です。あいまいなまま進めると、検収が長期化したり、発注者・ベンダー双方にとって不利な状況を招くことがあります。

合否基準を仕様書ベースで客観化する手順

合否基準の中心は「要件定義書・仕様書に記載された機能・性能を満たしているか」です。これに加えて、以下の観点を事前に合意しておくと判断がスムーズになります。

• Critical（致命的不具合）：業務が完全に停止する、データが消失・破損するなど。1件でも存在する場合は不合格。
• High（高重要度不具合）：主要業務フローが機能しない。合格条件はゼロ件が望ましいが、代替手段がある場合は期日付き修正を条件に仮合格とする場合もある。
• Medium（中重要度不具合）：業務は行えるが操作に不便がある。件数上限を事前に合意する。
• Low（軽微な不具合）：表示ずれ・誤字など。本番稼働後の修正対応として受け入れるかどうかを合意する。

この分類はIPAのモデル契約書でも採用されている考え方で、「客観的な検収基準の明確化」はベンダーとの関係を守るためにも発注者側が主導して定めることが実務上推奨されています^*2。

検収期間とみなし検収条項（IPAモデル契約書の実務）

IPAの「情報システム・モデル取引・契約書（第二版）」には、「みなし検収」と呼ばれる実務慣行が反映されています。納品後に一定期間（たとえば10営業日以内など）発注者から何も通知がない場合、検収が完了したとみなす条項です^*2。

この条項は発注者にとって不利に見えますが、実際にはプロジェクトが際限なく延長されるリスクを双方が回避するための合理的な仕組みです。発注者としては、検収期間内に結果（合格・不合格・条件付き合格）を書面で通知することが求められます。

検収期間を延長する場合も、書面でベンダーに通知し、延長理由と新たな期限を明記することが大切です。

不合格が出たときの対応手順

受入テストで指摘事項が出ることは珍しくありません。重要なのは、発見された問題を適切に分類・整理し、期限を明示した修正依頼として伝えることです。

バグ重要度の分類（Critical / High / Medium / Low）

前述した4段階の重要度分類に従い、発見した問題を整理します。Critical・Highに分類された不具合は本番稼働前の修正が必須です。Medium・Lowは本番稼働後の対応として受け入れるかどうかをプロジェクト体制内で判断します。

不具合の記録には「発見日・再現手順・期待結果・実際の結果・重要度・担当ベンダー・修正期限・ステータス（未対応/対応中/修正完了/再テスト待ち）」の項目を設けたバグ管理表を使います。

修正依頼書の書き方と期限の設け方

ベンダーへの修正依頼は口頭ではなく書面（またはメール・チケット管理ツール）で行います。記載事項は「不具合番号・発生箇所・再現手順・期待値・重要度・修正期限」です。

修正期限は重要度に応じて設定します。Criticalは翌営業日〜3営業日、Highは1週間以内を目安とする場合が多く、具体的な期限はプロジェクト状況に応じてベンダーと合意します。期限の設定と記録は後のトラブル防止のために不可欠です。

改正民法の契約不適合責任（民法562条）に基づく追完請求

修正対応が完了せず、発注者の要求仕様を満たさないシステムが納品されたと判断される場合は、改正民法562条（民法559条を通じた請負への準用）に基づく追完請求（修補請求）が可能です^*1。

権利行使には「不適合を知った時から1年以内の通知」が必要です。このため、受入テストの結果（合格・不合格・指摘内容）は記録として残し、いつ・どのような不適合を発見したかを証明できる状態にしておくことが重要です。

追完請求に応じない場合には、代金減額請求・損害賠償請求・契約解除へとエスカレートできます。ただし、これらの権利行使は最終手段であり、まずはベンダーとの協議・書面による修正要求を経るのが実務の基本です。

受入テストを円滑に進める発注者側の体制と準備

受入テストの品質は、発注者側の体制と準備に大きく左右されます。「ベンダーに任せる」という姿勢では、発注者にとって本当に必要な確認が抜け落ちます。

テスト担当者の選定――「実際の業務担当者」が参加すべき理由

テスト担当者は情報システム部門だけでなく、実際に新システムを使う現場担当者を含めることが大切です。情報システム部門はシステムの動作を確認しますが、営業・経理・物流など各部門の担当者でなければ「この操作で実業務が回るか」は判断できません。

代表的なユーザー数名がテストに参加する体制が現実的です。全員を集めることが難しい場合は、業務の熟練者1〜2名を「テストリード」として指名し、その後に残りのメンバーへの操作研修を組み合わせる方法が有効です。

発注者だけで難しい場合の専門パートナー活用

テストケースの設計・バグ管理・ベンダーとの折衝など、受入テストには専門的な知識と工数が必要です。情報システム部門のリソースが限られている場合や、大規模案件でテスト範囲が広い場合は、専門パートナーへの支援依頼が選択肢になります。

専門パートナーが支援に入る場合、テスト計画書やテストケースの雛形を用意し、発注者側の業務担当者が業務シナリオに合わせて補足・修正する形で進めることが多いです。これにより網羅性と業務適合性を両立したテストを実現できます。

元請（プライムベンダー）として開発から受入テスト支援まで一貫して対応できる体制を持つパートナーを選ぶことで、ベンダー管理の負荷も軽減できます。

まとめ――受入テスト・検収を成功させる3つの判断軸

本稿ではシステム開発の検収・受入テストの進め方を整理しました。発注者として押さえておくべき要点を3つにまとめます。

第一に、受入テストはベンダーのテストとは別に発注者の業務観点で実施することです。技術的な正確性ではなく「自社の業務で実際に機能するか」を確認する工程であり、発注者の責任で行います。

第二に、テスト計画書・テストケース・合否基準書の3つを事前に整備し、客観的な判断基準を合意しておくことです。主観的な「満足いかない」による際限のない修正要求を防ぎ、検収を円滑に完了させるための基盤になります。

第三に、検収完了は改正民法562条の契約不適合責任の権利行使起点であることを意識することです。不具合の発見記録を残し、「いつ・どのような問題を発見したか」を証明できる状態を保つことが、発注者の権利保護につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：咲くやこの花法律事務所「契約不適合責任とは？責任内容や期間・免責などをわかりやすく解説」（2020年改正民法対応版）／根拠法令：民法559条・562条（2020年4月施行）
2. *2　出典：IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）

Tweet