ソフトウェアテスト・QA業務委託の検収基準

1. テスト業務の取適法上の位置づけ

1-1. 情報成果物作成委託としての整理

テスト業務は、 テスト仕様書・テスト結果報告書といった 情報成果物を作成させる委託として、 取適法上の情報成果物作成委託に該当します。
フリーランスのテストエンジニアへの発注であれば、 フリーランス新法の適用対象にもなりえます。 ソフトウェア開発の一工程として自然に組み込まれているだけに、 独立した委託契約としての意識が薄れがちな点にも注意が必要です。
成果物の形が見えにくい分、記載要件の確認がより重要になります。

1-2. 開発委託との組み合わせ

開発自体は自社で行い、 テストのみを外部委託するケースと、 開発・テストを一括して委託するケースとでは、 発注書面の記載範囲が変わってきます。 一括委託の場合、テスト部分だけを取り出して確認する視点も必要です。

1-3. IT開発業界の取適法対応との関係

業種別 取適法対応ポイント（建設業・IT開発・デザイン制作）はこちらで整理しており、 テスト業務特有の論点とあわせて確認するとよいでしょう。
IT業界全体の傾向を踏まえた上で、テストという工程固有の事情を上乗せして考えます。

2. 検収基準の考え方

2-1. 「バグが見つからないこと」は不合格の理由にならない

テスト業務の成果物は、 テストケースの実施記録・結果報告書であり、 「重大なバグが見つからなかったから成果が出ていない」として 検収を拒否することは、 テスト業務の性質を誤解した対応です。 むしろ丁寧なテストほど、細かな不具合が多く見つかることもあります。
検収基準の決め方はこちらも参照してください。

2-2. テストカバレッジの事前合意

どの範囲・観点をテストするかという テストカバレッジを発注段階で明確に合意しておくことで、 後になって「テストが不十分」という 一方的な評価を避けやすくなります。
「なんとなく網羅的に」という曖昧な依頼は、後の認識違いの元になります。

2-3. 追加テストの依頼と対価

当初合意した範囲を超えたテストを 追加で依頼する場合、 追加の対価支払いなしに求めることは 買いたたきに該当するリスクがあります。 「念のため念入りに」という善意の追加依頼も、対価の話とは切り分けて考える必要があります。
下請代金の減額・買いたたきの禁止はこちらも参照してください。

3. リリース後にバグが見つかった場合

3-1. 検収完了後の責任範囲

一度検収が完了した後にリリース後のバグが発見された場合、 受託側のテスト漏れなのか、 テスト対象外だった範囲なのかを 明確に切り分けて判断する必要があります。
感情的な対立になりやすい場面だからこそ、事実に基づいた冷静な確認が求められます。

3-2. やり直し要求の範囲

合意したテストカバレッジの範囲内で テスト漏れが判明した場合のやり直し対応と、 範囲外の不具合まで無償対応を求めることとは 区別して考える必要があります。 「見つからなかったから受託側の責任」と単純化しないことが大切です。
不当な給付内容の変更・やり直しの禁止はこちらも参照してください。

3-3. 契約書での責任範囲の明確化

テスト業務委託契約書に、 保証期間・瑕疵担保責任の範囲を あらかじめ明記しておくことで、 リリース後のトラブルを未然に防ぎやすくなります。
口頭でのなあなあの合意は、いざという時に双方の記憶が食い違う原因になります。

4. 継続的な委託関係での実務

4-1. リリースサイクルに合わせた継続発注

アジャイル開発でリリースのたびにテストを依頼する場合、 継続的業務委託に該当する可能性があります。 スプリントごとの発注が積み重なるうちに、継続的な関係へと自然に移行していきます。
継続的業務委託の定義はこちらも参照してください。

4-2. 60日ルールとリリーススケジュール

テスト完了（検収）から支払いまでの60日ルールが、 頻繁なリリースサイクルの中で 確実に守られているかを台帳で管理する必要があります。 リリースの頻度が高いほど、支払期日を見落とすリスクも高まります。
60日ルールの起算点・運用はこちらも参照してください。

4-3. テスト担当者の異動・引継ぎ

社内のプロジェクトマネージャーが異動する際、 テスト会社との契約条件・過去の合意事項を 正確に引き継ぐ体制が重要です。 異動時の引き継ぎ漏れが、後々の認識違いの温床になります。
発注担当者の異動・引継ぎ時のチェック体制はこちらも参照してください。

よくある質問

Q. テスト結果報告書の書式が期待と違う場合、検収拒否できますか？

発注時に書式・記載項目を明確に合意していた場合に限り、 その基準を満たしていないことを理由に 修正を求めることができます。
合意のない後出しの要求は問題視される可能性があります。
事前の合意事項をメールや契約書で残しておくことが、後の対応をスムーズにします。

Q. テストの自動化ツール導入費用は誰が負担しますか？

契約内容によりますが、 発注側の指示で特定ツールの導入を求める場合、 その費用負担についても事前に取り決めておくことが望ましいです。
ツール選定の主導権がどちらにあるかによっても、考え方が変わってきます。

Q. フリーランスのテストエンジニアへの直接発注の注意点は？

フリーランス新法の特定受託事業者に対する 業務委託として、発注書面の交付義務・ 相談窓口の周知等が求められます。 技術力の高いフリーランスほど、契約面の丁寧さが信頼関係の構築につながります。
フリーランス新法の特定受託事業者とは何かはこちらも参照してください。

Q. 海外のQAベンダーに委託する場合はどうなりますか？

取引の実態によって取適法の対象になるかが変わります。
海外事業者への業務委託の確認ポイントはこちらも参照してください。

Q. セキュリティテスト（脆弱性診断）も同じ考え方になりますか？

基本的な考え方は共通していますが、 診断範囲・対象システムの明示がより重要になる分野です。
専門性の高さゆえに、発注側の技術理解が追いつかないことも多く、 仕様の擦り合わせに十分な時間を確保することをおすすめします。

まとめ

ソフトウェアテスト・QA業務委託は、 「バグを見つけること」が成果という特殊性から、 一般的な検収の考え方をそのまま当てはめると トラブルになりやすい分野であり、双方の共通認識づくりが特に重要になります。
テストカバレッジの事前合意、 リリース後の責任範囲の明確化、瑕疵担保責任の期間設定、 継続的なリリースサイクルにおける期日管理など、 業界特有の実務を踏まえた発注管理が重要です。 専門性の高い業務ほど、発注側の理解不足がトラブルの引き金になりやすい点にも注意します。 専門性の高い分野だからこそ、契約時点での丁寧な擦り合わせが後のトラブルを防ぎます。
本記事は運用の観点整理であり、法的助言ではありません。
個別の判断は専門家にご確認ください。