QAテスターへのテスト委託で決める合格条件｜バグ件数と完了の定義 2026

2026年5月2日

中西直美

この記事のポイント

✓QAテスター委託の検収で失敗しないために
✓合格条件・バグ件数の基準・完了の定義をどう契約書に落とし込むかを
✓費用相場と発注先の選び方まで含めて具体的に解説します

「QAテスターに外部委託したいけれど、納品されたテスト結果をどう検収すればいいのか分からない」。そんなご相談を受けることが増えています。バグ件数がゼロにならない限り不合格にすべきなのか、それとも一定の基準を満たせば合格としてよいのか。この曖昧さが、発注者とテスターの間のトラブルの火種になっています。この記事では、QAテスターへのテスト委託における合格条件の決め方、バグ件数の扱い方、そして「完了」をどう定義すれば双方が納得できるかを、契約実務の観点から具体的にお伝えします。

QAテスター委託を取り巻く市場の現状

ソフトウェア開発の現場では、開発とテストを分業する体制が一般的になりました。自社に専任のQAエンジニアを抱える体力がない中小のシステム開発会社や、スタートアップのプロダクトチームが、テスト工程だけをフリーランスのQAテスターや外部の検証会社に委託するケースが年々増えています。

背景にあるのは、開発スピードへの要求の高まりです。リリースサイクルが短くなるほど、テスト工程がボトルネックになりやすい。かといって社内でテスト要員を常時雇用するのは固定費の負担が大きく、繁忙期だけ人手が必要という発注側の事情ともかみ合いません。結果として、案件単位・工程単位で外部のQAテスターに委託する「業務委託型のテスト外注」が、開発委託の一形態として定着しつつあります。

一方で、この分野特有の難しさもあります。ソフトウェア開発の外注では「完成したシステムを納品する」というゴールが分かりやすい一方、QAテスト業務の委託では「テストが完了した」という状態の定義が曖昧になりがちです。バグを100件見つけたら完了なのか、それとも仕様書に書かれたテストケースを全て実行したら完了なのか。この基準が発注前に合意されていないと、検収の段階で「まだテストが甘い」「いや、契約範囲は全部実施した」という水掛け論になります。

システム開発の委託契約実務においては、この種の紛争は珍しくありません。

ベンダの報酬請求権は，ベンダが請負契約の目的物であるシステムを完成させ，完成したシステムをユーザに引き渡したときに発生します（民法633条本文）。多くの開発委託契約では，納品とともにユーザが検査を行い，その検査に合格したとき（検収合格ともいいます。）に納入物の引き渡しが完了することとされています。この場合には検収合格により報酬請求権が発生します。出典: it-houmu.com

つまり「検収」という手続きは、単なる社内チェックではなく、報酬支払いの発生条件そのものです。QAテスターへの委託でも同じ構造が当てはまるため、検収の基準を曖昧にしたまま契約すると、支払いのタイミングそのものが宙に浮いてしまいます。

そもそも「検収」とは何を指すのか

検収とは、発注者が納品物を受け取った後、それが契約で定めた内容・水準を満たしているかを検査し、合格・不合格を判定する手続きのことです。QAテスターへの委託で言えば、テスターが提出する「テストケース実行結果」「バグレポート」「テスト完了報告書」といった成果物が、事前に合意した基準を満たしているかを発注者側が確認する工程にあたります。

検収の考え方は、委託の契約形態によって大きく変わります。ここが多くの発注者が最初につまずくポイントです。

請負契約と準委任契約で検収の扱いが違う

QAテスターへの委託契約は、大きく「請負契約」と「準委任契約」のどちらかで結ばれます。この違いを理解しないまま契約書を作ると、検収の主張が通らなくなることがあります。

請負契約は「仕事の完成」を約束する契約です。テストの完了という成果物の完成に対して報酬を支払う形になるため、検収というプロセスがそのまま馴染みます。発注者は納品されたテスト結果を検査し、合格すれば報酬を支払う義務が生じ、不合格であれば修正を求めることができます。

準委任契約は「業務の遂行」自体を約束する契約で、成果物の完成そのものは契約の目的になりません。テスターが定められた稼働時間や工数の範囲で誠実にテスト業務を行えば、その時点で契約上の義務は果たされたことになります。この場合、法律上は検収という手続きは必須ではありません。

準委任契約は検収が不要であるのに対し、同じく業務委託契約の一種である請負契約では検収が求められます。出典: biz.moneyforward.com

ただし実務上は、準委任契約であっても発注者側が「テスト業務が契約通りに行われたか」を確認したいという要望は自然にあります。そのため多くの現場では、準委任契約であっても契約書や業務委託仕様書のなかに「検収に準じる確認プロセス」を任意で盛り込むケースが一般的です。法的な義務ではなくても、実務上の安心材料として確認工程を設けておくべきだということです。

QAテスターへの委託を検討する際は、まず自分が結ぼうとしている契約が請負なのか準委任なのかを明確にし、そのうえで検収の要否と手続きを契約書に明記することが出発点になります。

合格条件をどう設計するか

検収でもっとも揉めやすいのが「何をもって合格とするか」の基準です。ここを曖昧にしたまま発注してしまうと、テスターは「契約範囲の作業は終えた」と主張し、発注者は「まだバグが残っているから不合格だ」と主張する、典型的な平行線に陥ります。

バグ件数を基準にするのは危険

「バグをゼロにすること」を合格条件にしたいという発注者の気持ちはよく分かります。しかし、これは現実的な基準として機能しにくいという点は押さえておく必要があります。

ソフトウェアには「バグがゼロである」ことを証明する方法が原理的に存在しません。テスターがどれだけ網羅的にテストしても、テストケースに含まれていない操作パターンや、特定の環境でしか再現しない不具合は発見できない可能性が残ります。「バグゼロ」を合格条件にすると、テスターは無限に責任を負わされる立場になり、まともな契約が成立しません。

代わりに実務でよく使われるのが、以下のような多段階の基準です。

重大度（Critical / High / Medium / Low）ごとにバグの残存許容件数を分けて定義する
「事前に合意したテストケースを100%実行し、その実行結果と発見バグの一覧を提出すること」を成果物の完了条件にする
Critical・Highレベルのバグは全件修正確認まで含めて検収対象とし、Medium・Lowレベルは別途改修計画を合意すれば合格とする

例えば「重大度Highのバグは0件、Mediumは3件以内であれば合格」といった数値基準を契約前に握っておくと、検収時の判断がぶれません。重大度の定義自体も、発注者とテスターの間で認識が食い違いやすい部分なので、「ユーザーの基本操作が止まる不具合はCritical」「表示崩れなど操作継続可能な不具合はLow」というように、具体例つきで擦り合わせておくことをおすすめします。

「完了」の定義を仕様書レベルで明文化する

もう一つ重要なのが「テストの完了」をどう定義するかです。これは検収仕様書、あるいはテスト計画書と呼ばれる文書に落とし込むのが最も確実な方法です。

検収仕様書等の記載事項に沿ってシステムなどを制作しなければ、検収段階で不合格となり、修正や納品のやり直しが生じてしまいます。受注者としては、検収仕様書等の記載事項をあらかじめよく確認して、その内容に忠実に納品物を制作することが大切です。実際の開発担当者（開発者）に対しても、検収仕様書等の内容の遵守を徹底させましょう。検収仕様書等の内容に疑義がある場合には、受注の段階で発注者に確認して解消しておきましょう。また、制作途中で疑義が生じた場合にも、その都度発注者に確認して疑問点を解消すべきです。出典: corporate.vbest.jp

この考え方はシステム開発の受託者向けに書かれたものですが、QAテスターへの委託を検討する発注者側にとっても示唆に富みます。つまり、検収でもめる根本原因の多くは「発注時点で仕様（この場合はテスト範囲・合格基準）が具体的に文書化されていなかったこと」にあります。口頭やチャットでの合意だけに頼らず、以下の項目は必ず書面（検収仕様書や業務委託契約の別紙）に落とし込んでおくべきです。

テスト対象の範囲（画面・機能・API・対応ブラウザやOSのバージョンなど）
使用するテスト手法（探索的テスト、シナリオテスト、リグレッションテストなど）
テストケース数の目安、またはテスト工数の上限
バグの重大度分類とその判定基準
合格基準（残存バグの重大度別許容件数）
検収期間（納品後何営業日以内に検収結果を通知するか）
不合格時の再修正・再テストの回数と追加費用の有無

これだけの項目を並べると身構えてしまうかもしれませんが、実際にはテンプレートを一度作ってしまえば、次回以降の発注では流用できます。最初の1回に時間をかける価値は十分にあります。

検収期間が過ぎた場合の扱いにも注意する

検収でもう一つ見落とされがちなのが「検収期間」の設定です。納品されたテスト結果をいつまでに確認し、合否を通知するかという期限を契約書に明記していない発注者は少なくありません。

検収期間を定めずに放置してしまうと、発注者側の都合でいつまでも検収が完了しない状態が続き、テスター側の報酬支払いも先延ばしになってしまいます。これはテスター側にとって大きな負担であると同時に、発注者側にとっても「検収期間内に何も通知しなければみなし合格になる」という規定が契約書にある場合、うっかり確認を怠ってバグの残った成果物をそのまま受け入れてしまうリスクにつながります。

一般的な実務では、検収期間は納品後5営業日から2週間程度で設定されることが多いです。テスト対象の規模が大きい場合はもう少し長く取ることもありますが、いずれにせよ「いつまでに」「誰が」「どのような方法で」合否を通知するかを契約書に明記しておくことが、双方にとっての安全策になります。

QAテスター委託でよくあるトラブルとその回避策

実際の現場で起きやすいトラブルのパターンを整理しておきます。事前に知っておくだけで、多くは回避可能です。

トラブル1：テストケースの解釈がずれる

発注者が想定していたテスト範囲と、テスターが実際に実施したテスト範囲が食い違うケースです。「基本機能は当然テストするだろう」という発注者側の思い込みと、「明示された仕様書の範囲だけをテストする」というテスター側の受け止め方がずれることで発生します。対策は、テストケース一覧を事前にレビューし、双方が合意したうえで着手してもらうことです。

トラブル2：バグの再現手順が不十分で修正側が対応できない

テスターが発見したバグの報告に、再現手順・環境情報・スクリーンショットが不足していると、開発側が修正できず検収が進みません。バグレポートのフォーマット（発生条件、再現手順、期待結果と実際の結果、重大度、証跡）をあらかじめ指定しておくことで防げます。

トラブル3：修正後の再テスト範囲でもめる

一度バグを指摘して修正してもらった後、その修正が別の機能に影響していないかを確認する「リグレッションテスト」の範囲について、追加費用が発生するのか、当初の契約範囲に含まれるのかで対立するケースです。契約時点で「軽微な修正後の再テストは1回まで契約範囲に含む」など、再テストの回数と範囲をあらかじめ定義しておくと安心です。

トラブル4：検収の合否判断者が曖昧

発注者側の担当者が複数いる場合、誰が最終的な合否判断を下すのかが不明確だと、テスター側は誰の指摘に従えばよいのか分からなくなります。検収の責任者を1名に明確化し、その人物の承認をもって正式な合格とするフローを決めておくべきです。

私自身、自分が運営するオンラインカウンセリングの予約システムを外部に発注した際、この「合否判断者の曖昧さ」で苦労した経験があります。私と業務パートナーの二人がそれぞれ別のタイミングで別の指摘をテスターに伝えてしまい、テスター側から「どちらの指摘を優先すればよいか分からない」と困惑された連絡を受けました。窓口を一本化していなかった自分のミスだと反省し、以降は必ず検収の最終判断者を1人に決めてから発注するようにしています。小さなことのようですが、これだけで進行のスムーズさがまるで違います。

費用相場と仲介・直接依頼のコスト差

QAテスターへの委託費用は、テストの規模や難易度、期間によって幅があります。目安としては、単発の探索的テストであれば1案件あたり3万円から15万円程度、継続的な稼働を伴う準委任契約であれば月15万円から40万円程度が一つの相場感です。テストケースの設計から任せるのか、既存のテストケースに沿って実行だけを依頼するのかによっても費用は変わります。

ここで発注者が意識しておくべきなのが、依頼先の選び方によるコスト構造の違いです。テスト会社や制作会社を経由して発注する場合、その会社に所属するテスターへの人件費に加えて、会社としての管理費・営業経費が上乗せされます。これに対し、フリーランスのQAテスターに直接依頼すれば、この中間マージンが発生しません。同じ予算であれば、より多くのテスト工数を確保できることになりますし、テスター側から見ても報酬の手取りが厚くなります。手数料0%で仲介する直接契約型のマッチングサービスを使えば、この構造上のメリットをそのまま享受できます。

もちろん、直接契約にはデメリットもあります。テスト会社であれば複数人体制でのバックアップや品質管理の仕組みが整っている一方、個人のフリーランスに依頼する場合は、その人が体調を崩した場合の代替要員がいないといったリスクは残ります。テスト対象の規模やリスク許容度に応じて、どちらの発注形態が適しているかを判断する必要があります。

失敗しないQAテスターの選び方

検収でトラブルを起こさないためには、そもそも発注前の選定段階で見極めるべきポイントがあります。

第一に、過去の実績で扱った対象領域を確認することです。Webアプリケーションのテスト経験が豊富なテスターと、組み込み機器のテスト経験が豊富なテスターでは、得意とする観点がまったく異なります。自社のテスト対象と近い領域での経験があるかを確認しましょう。

第二に、バグレポートのサンプルを事前に見せてもらうことです。過去にどのようなフォーマットでバグを報告していたかを確認すれば、コミュニケーションの精度をある程度事前に判断できます。再現手順が具体的か、重大度の判断基準が明確かをチェックしてください。

第三に、テストケースの設計を任せられるかどうかです。既存のテストケースを実行するだけのテスターと、要件からテストケースを設計できるテスターとでは、スキルレベルも報酬水準も異なります。自社の状況（すでにテストケースがあるのか、ゼロから設計してほしいのか）に応じて、必要なスキルを持つ人材を選定する必要があります。

第四に、見積もりの内訳を必ず比較することです。私が初めて外部のQAテスターに発注しようとしたとき、複数の見積もりを取らずに最初に連絡が来た1社の提示額だけで即決してしまい、後になって別の候補者がほぼ同じ内容をより明確なテストケース設計込みで提示していたことを知りました。金額だけでなく、見積もりに含まれる作業範囲の粒度まで比較しないと、安いように見えて実は必要な工程が抜けている、ということが起こり得ます。以来、最低でも2〜3件は見積もりを取り、金額と作業範囲の両方を突き合わせるようにしています。

運営者の視点から見えるQAテスター委託の実態

フリーランス・在宅ワーク市場を長く運営してきた立場から見ていると、QAテスターとして継続的に案件を受けている人ほど、単発のテスト実行だけで終わらせず、発注者側の「合格条件をどう決めればよいか分からない」という不安に寄り添う提案をしていることに気づきます。バグレポートのテンプレートを自分から提示したり、テスト範囲の切り分け方を発注前に一緒に整理したりするテスターは、次の案件でも指名される傾向が強い。技術力だけでなく、検収という手続きを発注者と一緒に設計できる姿勢が、継続発注につながっているように見えます。

もう一つ運営者として見えてきたのは、中間マージンが乗らない直接契約の構造が、発注者とテスターの双方に無理のない関係を作りやすいという点です。仲介会社を通した契約では、発注者が支払う金額とテスターの手取りの差が大きくなりがちで、その差額分を埋め合わせるために、どうしても検収の基準や修正対応の範囲がシビアになりやすい傾向があります。一方、直接契約で手取りが厚い状態であれば、テスター側にも「多少の追加確認には応じよう」という余裕が生まれやすく、結果として検収のやり取りも柔らかくなる。金額の大小だけでなく、その予算がどう配分されているかという構造が、実務の摩擦の少なさに直結しているというのが、長く現場を見てきた実感です。

契約実務を進めるうえでの内部リンク情報

QAテスターへの委託を含め、業務委託契約全般で押さえておくべき基本事項をまとめたチェックリストとしては、業務委託契約書テンプレート｜発注者向けチェックリスト付き【2026年版】が参考になります。検収条項や合格基準の記載例など、契約書に落とし込む際の実務的なひな型を確認できます。

また、テストだけでなく開発工程全体を外部に委託することを検討している場合は、アプリケーション開発のお仕事のガイドで、開発フェーズごとにどのような外注の切り分け方があるかを把握しておくと、QAテスターを単独で発注すべきか、開発とテストをまとめて依頼すべきかの判断がしやすくなります。

マーケティングや広告運用など他の業務領域を外注する際の費用感と比較したい場合は、マーケティング業務委託の費用相場｜代理店vs個人フリーランス比較でも、代理店経由と個人フリーランス直接依頼のコスト差について解説しています。QAテスターの委託と同様に、仲介の有無が費用構造に与える影響という点で共通する考え方が確認できます。

QAテスター自身の年収・単価相場を把握しておきたい発注者の方は、近しい職種としてソフトウェア作成者の年収・単価相場のデータも参考になります。開発側の相場感を知っておくことで、テスト工程に妥当な予算を割り当てる判断材料になります。

検収の基準づくりは、一見すると面倒な事前作業に思えるかもしれません。ですが、ここに時間をかけておくことが、後々の「言った言わない」のトラブルを防ぎ、テスターとの信頼関係を長く続けるための一番の近道です。バグ件数の基準、完了の定義、検収期間。この3つを契約前に明文化することから、ぜひ始めてみてください。