テスト仕様は納品直前の確認表ではありません。契約目的、要件、合否基準、証跡、支払、契約不適合責任をつなぐ実務文書として設計します。
テスト仕様は納品直前の確認表ではありません。
合否基準を客観化し、発注者の主観と受注者の形式納品の間に共通資料を置きます。
検収のために必要なテスト仕様の事前合意とは、単にテスト項目表を作る作業ではありません。何をもって成果物が契約に適合していると判断するのかを、契約締結時または要件定義・設計確定時までに、客観的・再現可能・証拠化可能な形式で合意することです。
次の比較表は、検収と結び付く実務上の効果を整理したものです。読者にとって重要なのは、テスト仕様が品質確認だけでなく、支払、契約不適合責任、本番稼働、監査証跡にも影響する点を読み取ることです。
| 効果 | 実務上の意味 | テスト仕様で決めること |
|---|---|---|
| 報酬・代金の支払 | 検収完了日を請求可能日や会計処理の根拠とすることがあります。 | 検収単位、合格条件、条件付き検収、検収日を定めます。 |
| 完成・納入確認 | 請負では仕事の完成、売買では引渡し・品質確認と結び付きます。 | 対象成果物、納入物一覧、受入テスト範囲を明確にします。 |
| 契約不適合責任 | 検収後にどこまで修補、損害賠償、解除が可能かが問題になります。 | 検収後の責任、隠れた不具合、通知期間、例外を定めます。 |
| 本番稼働 | システム利用開始、業務切替、データ移行完了の判定と連動します。 | 移行、性能、運用、セキュリティの合格基準を入れます。 |
| 監査証跡 | 内部統制、情報セキュリティ監査、委託先管理の証拠になります。 | 証跡ファイル、承認ログ、欠陥管理票、検収書を保存します。 |
検収、受入テスト、テスト仕様、合否判定、トレーサビリティを先にそろえます。
用語の合意は、検収テスト仕様の前提です。次の一覧は、契約上の判定手続と技術上の確認作業を分けるためのものです。読者は、受入テストは品質確認の手段であり、検収は契約上の合否判断であるという違いを読み取ってください。
契約書、仕様書、合意済みテスト仕様、設計書、変更合意に照らして、受領可能かを判断する手続です。
発注者側が、実運用に近いデータや利用者参加により、成果物が業務に適合するかを確認します。
対象、条件、手順、入力データ、期待結果、判定基準、証跡、実施者、承認者、再テスト条件を定めます。
要件ID、設計書、テストケース、証跡、欠陥票、検収結果を相互に追跡できる状態にします。
次の比較表は、完成、納品、受入テスト、検収、本番稼働を分けるためのものです。本番稼働した事実を検収済みと扱う契約もあれば、暫定運用として検収と分ける契約もあるため、各概念の意味と契約上の注意点を読み取ってください。
| 概念 | 意味 | 契約上の注意点 |
|---|---|---|
| 完成 | 受注者が契約で予定された作業・成果物を完成した状態です。 | 請負契約では報酬請求や責任判断に関係します。 |
| 納品 | 成果物を発注者に引き渡す行為です。 | 検査期間や支払期日の起算点とされることがあります。 |
| 受入テスト | 発注者が利用目的・要件適合性を確認するテストです。 | 環境、データ、役割分担が必要です。 |
| 検収 | 発注者が契約上受領可能かを判定する手続です。 | 合否通知、みなし検収、修補手続と結び付きます。 |
| 本番稼働 | 実運用を開始することです。 | 検収合格後に行うのか、条件付きで先行するのかを定めます。 |
検収条項、契約類型、取適法、V字モデルを同時に見ます。
法務上は、検収条項で検査対象、検査基準、検査期間、不合格時の効果、検収後の責任を定めます。次の表は、検収条項が最低限含めるべき事項を示します。テスト仕様が契約書本文の別紙として機能するために、どの項目を契約文書化する必要があるかを読み取ってください。
| 項目 | 定める内容 | 実務上の焦点 |
|---|---|---|
| 検査対象 | 納品物、成果物、作業完了状態を特定します。 | 検収単位を機能、移行、運用、資料ごとに分けます。 |
| 検査基準 | 契約書、仕様書、テスト仕様書、設計書、変更票のどれに照らすかを定めます。 | 文書間の優先順位を明記します。 |
| 検査期間 | 納品後何営業日以内に実施・通知するかを定めます。 | 取適法対象取引では支払期日と整合させます。 |
| 合格条件 | どの程度の不具合残存を許容するかを重大度別に定めます。 | 条件付き検収と修補計画を組み合わせます。 |
| 検収後の責任 | 契約不適合責任、保証、保守、SLA、隠れた不具合を定めます。 | 検収合格で何が確定し、何が残るかを明確にします。 |
検収テスト仕様は、契約類型と法令の影響を受けます。次の比較表は、売買、請負、SaaS・クラウド、取適法対象取引の違いを示します。どの法令番号が通知・支払・責任範囲に関係するかを読み取り、テスト仕様の合否基準と契約条項を同じ方向にそろえることが重要です。
| 類型 | 関係する制度 | 検収テスト仕様への反映 |
|---|---|---|
| 売買 | 民法562条の追完請求、商人間売買では商法526条の検査・通知義務が問題になります。 | 引渡し、数量、品質、検査期間、発見時の通知方法を明確にします。 |
| 請負 | 民法636条は注文者の材料・指図に起因する不適合、民法637条は不適合を知った時からの通知期間を扱います。 | 完成、検収、発注者支給資料、環境提供、修補範囲を切り分けます。 |
| SaaS・クラウド | 継続サービスであり、単発の納品物検収だけでは足りません。 | SLA、セキュリティ、データ管理、終了時移行、サービス仕様を確認対象にします。 |
| 取適法対象取引 | 2026年1月1日施行の改正後は、支払期日や委託内容の明示を検収運用と矛盾させない必要があります。 | 検収未了を理由に支払を遅らせず、検査期間と支払期日を整合させます。 |
技術上は、テスト仕様は要件定義の品質を映します。次の表は、上流成果物と対応するテストをつなぐものです。要件の不整合や検証不能性を下流で発見すると、手戻りと紛争が大きくなるため、どの上流文書がどの検収確認に対応するかを読み取ってください。
| 上流成果物 | 対応するテスト | 検収との関係 |
|---|---|---|
| 契約目的・業務要件 | 受入テスト・業務シナリオテスト | 事業目的を達成できるかを確認します。 |
| 機能要件 | 総合テスト・受入テスト | 合意した機能が動作するかを確認します。 |
| 非機能要件 | 性能・可用性・セキュリティ・運用テスト | 本番運用に耐える品質かを確認します。 |
| 基本設計 | 結合テスト・画面遷移テスト | 業務の流れと設計が一致するかを確認します。 |
次の比較表は、機能だけでは検収できない理由を示します。登録や検索が動くだけでなく、性能、可用性、セキュリティ、データ移行、操作性、運用性、法令・規程適合まで検査可能な基準に落とすことを読み取ってください。
| 区分 | 例 | 合否基準の例 |
|---|---|---|
| 機能 | 登録、検索、承認、出力、通知 | 仕様書記載の入力条件、権限、画面遷移、出力結果と一致します。 |
| 性能 | 応答時間、バッチ処理時間、同時接続数 | 指定負荷条件で95パーセンタイル応答3秒以内など、数値で定めます。 |
| セキュリティ | 認証、認可、ログ、脆弱性 | 重大・高リスク脆弱性が残存しない、権限逸脱がない状態にします。 |
| データ移行 | 件数、整合性、文字化け、重複 | 移行対象件数、エラー件数、照合差異が許容値内であることを確認します。 |
検収単位から証跡パッケージまで、合意の順番を固定します。
10段階プロトコルは、検収単位、要件との対応、作成時期、定量基準、重大度、環境、役割、再テスト、変更管理、証跡を順に固めるためのものです。次の時系列では、上から下へ進む順番に意味があります。後工程で揉めやすい項目ほど早い段階で合意する必要があると読み取ってください。
システム全体、機能、リリース、データ移行、運用手順など、何を単位に合否判断するかを決めます。
要件ID、設計書、テストケース、証跡、検収結果を対応させます。
誰がいつ案を作り、誰がレビューし、合意後に契約文書へ組み込むかを決めます。
正常に動作することではなく、数値、条件、対象範囲、許容値、証跡で合否を説明できる形にします。
致命的、重大、軽微、改善要望を分け、残存欠陥が検収不可、条件付き検収、変更管理のどれに当たるかを決めます。
本番相当環境、データ量、権限、外部連携、マスキング、利用可能時間を明記します。
Responsibleは実行責任、Accountableは最終責任、Consultedは相談先、Informedは報告先として、発注者、受注者、法務、情報システム、業務部門の役割を分けます。
不合格通知、原因調査、修補計画、再テスト、再検収、費用負担を定めます。
仕様変更、追加要望、スコープ変更があった場合に、テスト仕様と検収基準も更新する手続を定めます。
検収書、テスト結果、ログ、欠陥管理票、議事録、承認履歴をまとめ、後日の説明に使える状態で保存します。
次の表は、検収単位一覧の例です。一部機能の不具合で全体の支払が止まるのか、重大な未完成が部分検収済みとして扱われるのかを防ぐため、対象、検収方式、特記事項を分けて記載する方法を読み取ってください。
| 検収単位ID | 対象 | 検収方式 | 備考 |
|---|---|---|---|
| AC-001 | 顧客マスタ機能 | 機能テスト＋権限テスト | 個人情報を含むため監査ログ確認を含みます。 |
| AC-002 | 請求書発行機能 | 業務シナリオテスト | PDF、CSV、会計連携を含みます。 |
| AC-003 | データ移行 | 移行リハーサル＋照合 | 旧システムとの差分照合を行います。 |
| AC-004 | 性能 | 負荷テスト | ピーク時同時利用を想定します。 |
次の対応表は、要件と検収証跡を1本の線でつなぐためのものです。不合格理由を感覚ではなく、要件ID、テストケース、証跡に基づいて説明できる状態を作ることが重要です。
| 要件ID | 要件内容 | テストケースID | 合否基準 | 証跡 |
|---|---|---|---|---|
| REQ-001 | 顧客情報を登録できる | TC-001-01 | 必須項目、重複チェック、権限制御が仕様どおり | 画面、DBログ |
| REQ-014 | 請求書PDFを出力できる | TC-014-03 | レイアウト、税額、宛名、番号体系が一致 | PDF、計算表 |
| NFR-003 | ピーク時にも検索可能 | PT-003-01 | 同時500ユーザで95%応答3秒以内 | 負荷試験レポート |
別紙化、承認手続、不合格通知、みなし検収、条件付き検収を条項化します。
契約書に組み込む条項は、本文に原則を書き、詳細は別紙の検収テスト仕様へ置く構成が実務的です。次の一覧は、主要条項の役割を整理したものです。テスト仕様の承認、変更、証跡、検収後責任まで一連で定める必要があると読み取ってください。
| 条項 | 目的 | 確認点 |
|---|---|---|
| 検収基準 | 契約、個別契約、仕様書、要件定義、設計書、変更合意、検収テスト仕様を接続します。 | 文書間の優先順位を定めます。 |
| 検収期間 | 納入から何営業日以内に検査し通知するかを定めます。 | 短すぎず、支払規制とも矛盾しない期間にします。 |
| 不合格通知 | 検収単位、テストケースID、期待結果、実際結果、証跡、重大度、業務影響を求めます。 | 追加要望を不合格理由にしないための歯止めになります。 |
| みなし検収 | 合理的な不合格通知がない場合に検収合格とみなします。 | 資料未提供や重大欠陥、隠れた不適合の例外を設けます。 |
本件成果物の検収基準は、本契約、個別契約、仕様書、要件定義書、設計書、変更管理手続により承認された変更内容、および別紙「検収テスト仕様」に定めるものとする。これらの文書間に矛盾がある場合の優先順位は、個別契約、本契約、変更合意書、検収テスト仕様、仕様書、設計書の順とする。発注者が不合格を通知する場合、当該通知には、不合格と判断した検収単位、テストケースID、期待結果、実際結果、証跡、重大度、業務影響を合理的に特定して記載するものとする。発注者は、検収基準に含まれない事項または承認済み変更管理手続を経ていない追加要望を理由として、不合格とすることはできない。次の標準構成は、検収テスト仕様書をどの章立てで作るかを示します。テストケースだけでは、適用範囲、用語、環境、欠陥管理、承認、証跡保存が抜けるため、各章の法務上の意味を読み取ってください。
| 章 | 内容 | 法務上の意味 |
|---|---|---|
| 目的 | 検収判断のためのテストであることを明記します。 | テストと検収の関係を明確にします。 |
| 適用範囲 | 対象成果物、対象外、前提条件を記載します。 | 不合格理由の範囲を限定します。 |
| 環境・データ | 環境構成、データ量、権限を定めます。 | 再現性と証拠性を確保します。 |
| テストケース | 手順、入力、期待結果、判定基準を定めます。 | 合否判断の中心になります。 |
| 欠陥管理 | 重大度、修補、再テストを定めます。 | 不合格後の手続を明確にします。 |
| 承認 | 署名、電子承認、版管理を定めます。 | 合意成立の証拠になります。 |
機能、権限、性能、移行、セキュリティを検査可能な形にします。
合否基準は、正常に動作すること、十分な性能、安全であること、といった抽象表現では足りません。次の比較表は、悪い基準を検査可能な基準へ置き換える例です。条件、対象範囲、数値、許容値、証跡を入れることが重要だと読み取ってください。
| 抽象的な基準 | 改善した基準 |
|---|---|
| 画面が正しく表示されること | 画面設計書UI-03の項目、入力制御、エラーメッセージ、権限別表示が、合意したブラウザで一致すること。 |
| 検索が速いこと | テスト環境に100万件の顧客データを投入し、同時100ユーザの条件で、検索APIの95パーセンタイル応答時間が2秒以内であること。 |
| セキュリティに問題がないこと | 合意した診断範囲で重大度Critical/Highの未対応脆弱性が存在しないこと。Medium以下は別紙対応計画に従うこと。 |
| データ移行が完了すること | 移行対象テーブル別に件数一致率100%、金額項目の合計差異0円、文字化け件数0件、重複エラーは別紙許容リスト内であること。 |
次の重大度表は、残った欠陥が検収合否にどう影響するかを整理するものです。軽微な欠陥が残るたびに全体検収を止めるとプロジェクトが進まず、重大欠陥を残したまま合格にすると本番リスクが高まるため、定義、例、検収への影響を読み取ってください。
| 重大度 | 定義 | 例 | 検収への影響 |
|---|---|---|---|
| A ― 致命的 | 業務継続、本番稼働、法令遵守、重大情報セキュリティに直接支障があります。 | ログイン不能、請求額誤計算、個人情報の権限外閲覧、データ消失。 | 原則として検収不可。修補・再テスト必須です。 |
| B ― 重大 | 主要業務に大きな支障があるが、限定的な回避策があります。 | 承認手順の一部停止、月次帳票の一部不整合。 | 件数・内容により検収不可または条件付き検収です。 |
| C ― 軽微 | 業務への影響が限定的で、回避策が容易です。 | 表示崩れ、文言誤り、限定条件下の軽微エラー。 | 修補計画を条件に検収可能とする設計があります。 |
| D ― 改善要望 | 契約仕様外の利便性向上要望です。 | 追加検索条件、画面配置変更。 | 検収不合格理由とせず、変更管理の対象にします。 |
次のテストケース例は、機能、権限、性能、移行、セキュリティを同じ形式で記載するためのものです。目的、前提条件、手順、期待結果、証跡をそろえることで、再テストや紛争時の説明が容易になる点を読み取ってください。
| 対象 | 目的 | 期待結果 | 証跡 |
|---|---|---|---|
| 機能テスト | 一般ユーザが正しいID・パスワードでログインできることを確認します。 | 3秒以内にトップ画面へ遷移し、ユーザ名が表示され、認証成功ログが記録されます。 | 画面、アクセスログ、監査ログ。 |
| 権限テスト | 一般ユーザが管理者画面にアクセスできないことを確認します。 | アクセス拒否画面が表示され、管理者情報は表示されず、不正アクセス試行ログが記録されます。 | 画面、権限ログ。 |
| 性能テスト | ピーク時検索性能を確認します。 | エラー率0.1%以下、95パーセンタイル応答3秒以内、CPU使用率平均80%以下です。 | 負荷試験レポート。 |
| データ移行 | 顧客マスタ移行の完全性・正確性を確認します。 | 対象件数一致、必須項目欠落0件、文字化け0件、金額集計差異0円です。 | 移行ログ、照合レポート、差分一覧。 |
| セキュリティ確認 | 重大な認証・認可不備がないことを確認します。 | Critical/High相当の未対応脆弱性が残存しません。 | 診断レポート、対応計画。 |
承認ルート、変更管理、証跡保存、AI評価指標まで設計します。
検収テスト仕様は、法務部門だけで完結しません。次の承認ルート表は、金額・リスクに応じて誰を関与させるかを示します。基幹システム、個人情報、AI・データ利用では、技術・法務・経理・内部監査・セキュリティの観点が分断されると検収後に重大リスクが残るため、追加確認の読み方が重要です。
| 金額・リスク | 承認者 | 追加確認 |
|---|---|---|
| 少額・低リスク | 部門長、情報システム担当 | 標準検収チェックリスト。 |
| 中額・業務影響あり | 部門長、情報システム、法務、購買 | テスト仕様、支払条件、変更管理。 |
| 高額・基幹システム | 役員、法務、情報システム、経理、内部監査、セキュリティ | 非機能要件、移行、本番判定、BCP、SLA。 |
| AI・データ利用 | データ法務、AIガバナンス担当、研究開発、事業部 | 評価指標、権利処理、説明責任、モデル監視。 |
次の一覧は、アジャイル開発や準委任型支援でも検収的な確認を機能させるためのものです。一括検収ではなく、スプリント、リリース、ユーザーストーリー、Definition of Doneの単位で小さく合意を積み重ねる点を読み取ってください。
| 項目 | アジャイルでの設計 |
|---|---|
| 契約目的 | プロダクトゴール、事業仮説、MVP範囲を定義します。 |
| 検収単位 | スプリント、リリース、ユーザーストーリー、エピック単位で確認します。 |
| 合否基準 | 受入条件、Definition of Done、リリース判定基準を定めます。 |
| 変更管理 | プロダクトバックログの優先順位変更と契約上の費用・期間管理を連動させます。 |
| 証跡 | チケット、レビュー記録、デモ、承認ログ、リリースノートを保存します。 |
AI・データ処理案件では、通常の機能テストと違い、確率的・統計的な評価が必要になります。次の表は、AIモデルの検収で合意すべき項目を示します。評価データ、指標、閾値、再現性、人間の確認、運用後劣化を事前に定める必要があると読み取ってください。
| 論点 | 合意事項 |
|---|---|
| 評価データ | 学習データ、検証データ、テストデータを分離します。 |
| 指標 | Accuracy、Precision、Recall、F1、AUC、MAEなどを選択します。 |
| 閾値 | 業務リスクに応じた合格基準を設定します。 |
| 人間の確認 | Human-in-the-loopの要否を定めます。 |
| モデル劣化 | 運用後の再評価・再学習条件を定めます。 |
未合意のまま検収に入らないため、立場別に確認事項を固定します。
チェックリストは、契約締結前に抜けを見つけるためのものです。次の発注者側一覧では、業務目的、非機能要件、証跡、規制確認まで含めています。受入テストを情報システム部門だけに任せず、業務部門、法務、セキュリティ、内部監査を必要に応じて関与させる点を読み取ってください。
| 発注者側チェック項目 | 確認 |
|---|---|
| 契約目的が業務要件として具体化されているか | □ |
| 検収単位が定義されているか | □ |
| 検収テスト仕様が契約文書に組み込まれているか | □ |
| 合否基準が客観的・定量的か | □ |
| 非機能要件、データ移行、運用、セキュリティ、権限、ログが含まれているか | □ |
| 不合格通知、修補・再テスト、みなし検収、条件付き検収が定められているか | □ |
次の受注者側一覧では、仕様外要求、発注者協力義務、変更管理、みなし検収、支払期日、証跡保存を確認します。検収不合格の理由が曖昧だと、無償対応の範囲や支払時期が不安定になるため、各項目を契約書または別紙で説明できるか確認してください。
| 受注者側チェック項目 | 確認 |
|---|---|
| 契約範囲外の要望が検収不合格理由にならない条項があるか | □ |
| 発注者の確認・承認期限が明記されているか | □ |
| 不合格通知には具体的証跡が必要とされているか | □ |
| 発注者支給データ、外部連携、環境提供の責任が明確か | □ |
| 軽微不具合で全体検収が止まらない仕組みがあるか | □ |
| チケット、ログ、議事録、承認履歴を保存しているか | □ |
次の失敗予防一覧は、検収紛争につながりやすい典型例をまとめたものです。仕様書、業務部門参加、非機能要件、重大度、仕様変更、みなし検収、発注者協力、支払規制のどれが抜けても、検収テスト仕様が機能しにくくなると読み取ってください。
検収は発注者が確認する、だけでは何をどう確認するか不明です。別紙で対象、基準、証跡を定めます。
画面やAPIは動いても、実際の業務の流れで使えないことがあります。代表業務シナリオを確認します。
性能、可用性、セキュリティ、移行、運用性を確認しないと、本番後に重大障害が出やすくなります。
事前合意では、契約書本文だけでなく別紙や証跡も一体でそろえる必要があります。次の一覧は、検収前にそろえるパッケージと検収書に残すべき事項を示します。何が合意済みで、どの欠陥が残り、いつまでに修補するのかを後から説明できる状態にすることが重要です。
| 文書・記録 | 主な内容 | 確認者 |
|---|---|---|
| 検収テスト仕様書 | 目的、適用範囲、環境、データ、テストケース、重大度、承認欄。 | 発注者・受注者 |
| 欠陥管理票 | 欠陥ID、重大度、発見日、担当、修補期限、再テスト結果。 | PMO・品質保証 |
| 検収書 | 納品日、検収日、対象成果物、合否、条件付き検収の内容、残存欠陥、修補計画。 | 権限ある承認者 |
| 証跡一式 | テスト結果、ログ、画面、議事録、承認履歴、版管理情報。 | 法務・内部監査 |
回答は一般的な制度説明であり、具体的な条項設計は取引内容により変わります。
一般的には、全文を契約書本文に書く必要はありません。本文で検収基準の原則、作成・承認手続、合否基準、効果を定め、詳細は別紙の検収テスト仕様書に置く方法が多いとされています。ただし、別紙が契約の一部であること、版数と承認履歴が明確であることが重要です。
一般的には、条件付き検収を認め、軽微不具合の定義、件数、修補期限、未修補時の効果を定めている場合、検収可能とする設計が考えられます。ただし、本番稼働、法令遵守、情報セキュリティ、主要業務に影響する不具合を軽微として扱うべきではありません。
一般的には、受注者案は有用ですが、発注者の業務目的、業務シナリオ、内部統制、法令・規程適合、データ移行、運用性は発注者側でなければ判断しにくいとされています。発注者は業務部門、情報システム、法務、セキュリティ、内部監査のレビューを行うことが望ましいです。
一般的には、一概にはいえません。契約条項、検収書の記載、契約不適合責任、保証条項、保守契約、SLA、隠れた不適合、発見可能性、通知期間によって結論が変わります。具体的には、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、発注者の確認遅延を防ぐために有用とされています。ただし、必要資料の未提出、テスト環境の不備、重大欠陥、隠れた契約不適合、発注者協力義務の履行状況などで結論が変わる可能性があります。具体的な文言は、検査期間、不合格通知の具体性、例外事由を合わせて設計する必要があります。
一般的には、不要ではありません。詳細仕様を最初に固定しない場合でも、スプリント、リリース、ユーザーストーリー、受入条件、Definition of Done、リリース判定基準を継続的に合意する必要があります。
一般的には、契約書、仕様書、要件定義、議事録、テスト結果、納品物一覧を整理し、暫定的な確認基準を当事者間で書面化することが考えられます。ただし、未合意の範囲、追加要望の有無、契約類型、支払規制、発注者側の協力状況によって対応は変わります。具体的な判断は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。