QA・テストの受ける相手を見きわめる｜断ってよい依頼

2026年7月19日

丸山桃子

この記事のポイント

✓QA・テストのクライアントの選び方を
✓受注後の実務から逆算して整理します
✓相談段階で確認する項目

QA・テストの仕事は、受けたあとで内容が変わりやすい職種です。契約時には「リリース前の動作確認」と言われていたのに、始めてみたら仕様書が存在せず、開発チームへの質問窓口もなく、不具合を報告しても誰も直さない。そんな状態でも納期だけは動かない。QA・テストのクライアントの選び方を調べている人の多くは、この手の消耗をもう一度繰り返したくない、という切実な動機を持っています。

結論を先に書きます。QA・テストで受ける相手を見きわめる基準は、発注側の予算規模でも、企業の知名度でもありません。「検証できる状態が用意されているか」と「不具合を直す人がいるか」の二点です。この二つが欠けている依頼は、どれだけ条件が良く見えても、テスト作業ではなく仕様の代筆と交渉業務に化けます。この記事では、相談段階で何を聞き、どこで線を引き、どう断るかを、受注後の実務から逆算して整理します。

QAとテストは同じ言葉ではない、という前提から始まる

受ける相手を選ぶ前に、発注側が使っている言葉の意味を確認する必要があります。「QAをお願いしたい」という依頼と「テストをお願いしたい」という依頼は、必要な作業量も責任範囲もまったく違うのに、発注側はしばしば同じ意味で使っています。

「QA（Quality Assurance／品質保証）」と「ソフトウェアテスト」は混同されやすい言葉ですが、指す範囲が異なります。QAは、要件定義からリリースまでの開発プロセス全体を通じて品質を作り込み、維持するための活動全般を指し、品質基準の策定やプロセス改善、レビュー体制の構築なども含まれます。一方でソフトウェアテストは、QA活動の一部として、実際にソフトウェアを動かして不具合を検出する検証作業を指します。つまりテストはQAを構成する重要な要素のひとつであり、QAはテストを含むより広い概念です。出典: stelaq.co.jp

この区別が効いてくるのは、見積もりの段階ではなく作業に入ってからです。テストの依頼だと思って受けた案件で、途中から「品質基準を決めてほしい」「レビュー会の運営もお願いしたい」と範囲が広がるのは、発注側が最初からQAを想定していたのに、言葉としてテストと言っていたからです。悪意があるわけではなく、社内にQAの経験者がいないため、区別する語彙を持っていないケースがほとんどです。

だからこそ、最初の相談で「今回お願いしたいのは、動かして不具合を出す作業までですか。それとも、品質の基準を決めるところから関わる形ですか」と聞くだけで、相手の理解度が測れます。即答できる相手は社内に判断できる人がいます。曖昧な返事しか返ってこない相手は、作業の途中で範囲が動きます。

発注側が外部に出す局面は大きく三つ

外部に検証を出す動機を知っておくと、依頼の背景が読めます。第一に、リリース直前で社内の手が足りなくなった局面。第二に、社内の開発者が自分のコードを自分で確認している状態を改めたい、という第三者検証の局面。第三に、テストの仕組み自体が社内に無く、作り方から相談したい局面です。

このうち、フリーランスが単独で受けて破綻しにくいのは第二の局面です。すでに仕様と手順があり、目線だけを外から入れれば成立します。第一の局面は、間に合わないという事実が先にあるため、作業量の見積もりが常に楽観側に振れています。第三の局面は本来QAの構築業務であり、テスト実行の単価感覚で受けると必ず持ち出しになります。

人材の希少性が依頼の質を歪めることがある

外部委託が増えている背景には、社内で育てにくい職種であるという事情があります。

第一に、QAエンジニアはテスト実行だけでなく、テスト設計・自動化・品質プロセス整備・上流品質への関与まで担う専門職です。単純なテスターとは求められるスキルが大きく異なるため、採用難が深刻化しています。経済産業省「IT人材需給に関する調査」（2019年）が示す高位シナリオでの約79万人規模の不足というIT人材不足の文脈の中でも、QAエンジニアの希少性は特に高い状況です。出典: lassic.co.jp

採りにくい職種だから外に出す、という流れ自体は健全です。問題は、社内に経験者がいない状態で発注されるため、依頼内容の粒度が荒くなりやすいことです。受け手側が粒度を揃える作業を無償で肩代わりすると、そこから関係が崩れていきます。選び方の話は、突き詰めると「粒度を揃える作業を誰の仕事として扱うか」を最初に合意できる相手かどうか、という話になります。

受ける前に必ず確認する前提条件

相談の段階で確認しておく項目を、優先度の高い順に並べます。ここで一つでも「未定」が返ってきたら、その未定を埋める作業自体を仕事として見積もりに含めるか、辞退するかの二択になります。

検証対象が動く状態にあるか

もっとも基本的で、もっとも見落とされる条件です。テスト環境が用意されているか、テスト用のアカウントが発行されるか、外部サービスと連携する部分はどう扱うか。決済や外部APIが絡む機能で、本番のキーしか無い状態のまま「動作確認をお願いします」と言われる依頼は珍しくありません。

確認の仕方は具体的にします。「検証環境のURLとアカウントは、着手日に受け取れますか」「メール送信やプッシュ通知は、検証環境でも実際に飛びますか」「データを初期状態に戻す手順はありますか」。この三つに即答できる相手は、過去に外部へ検証を出した経験があります。

環境が無い状態で始まった案件では、最初の数日が環境構築の待ち時間で溶けます。その待ち時間は多くの場合、稼働として認められません。着手日の条件として環境の受け渡しを明記できるかどうかが、受けるかどうかの分水嶺になります。

仕様の根拠になる資料があるか

不具合とは「仕様と違う挙動」のことです。仕様が文書化されていなければ、報告した現象が不具合なのか仕様なのかを決められません。決められないまま報告を続けると、「それは仕様です」という返答が積み上がり、作業した時間が成果として認められなくなります。

完璧な仕様書を求める必要はありません。実務で足りるのは、画面遷移の一覧、入力項目とその制約、正常系の想定動作、この三つが何らかの形で残っていることです。チケット管理ツールの起票内容でも、企画時のスライドでも構いません。逆に、口頭説明だけで「見ればわかります」と言われる依頼は、後で必ず揉めます。

資料が無いこと自体は断る理由になりません。無いなら、既存の挙動を仕様として書き起こす作業を最初の工程として立て、その分の期間を確保する。それを認めない相手だけが、断ってよい相手です。

不具合を直す人が確保されているか

見落としやすい条件がこれです。検証だけを外に出し、修正する開発者が別案件で手一杯、という構図はよくあります。この場合、報告した不具合は放置され、リリース判定の直前に「重大なものだけ選んでください」という相談が来ます。選別の責任を外部の受け手に押しつける流れです。

聞くべきことは単純です。「見つかった不具合は、どなたが、どのくらいの期間で修正されますか」「修正後の再確認は、今回の範囲に含めますか」。修正担当者が決まっていない案件は、テストの案件ではなく、リリース可否の判断を外注しようとしている案件です。

合否の判断を誰がするか

リリースしてよいかどうかを最終的に決める人が、発注側の中に立っていることを確認します。決裁者が不在のまま検証だけが進むと、判断できないという理由で検証の範囲だけが際限なく広がります。「念のためこちらも見てください」が繰り返される案件の根っこは、たいていここにあります。

断ってよい依頼の型

条件を一つずつ確認していくと、断ったほうがよい依頼にはいくつかの決まった型があることが見えてきます。

範囲が「全部」としか書かれていない依頼

「サイト全体をひととおり見てほしい」「一通り触って気づいた点を挙げてほしい」。この形の依頼は、作業量の上限が存在しません。上限が無い作業を固定額で受けると、終わりの判断が受け手側の良心に委ねられ、必ず持ち出しになります。

対処は、範囲を機能単位に割ってもらうことです。「今回、必ず確認すべき機能を挙げていただけますか」と聞き、返ってきたリストに対して見積もる。リストが出せない相手は、社内でも優先順位が決まっていません。

不具合ゼロを納品条件にする依頼

「テストが終わったあとに不具合が出ないようにしてほしい」という条件は、技術的に達成できません。テストは不具合の不在を証明する作業ではなく、決められた観点で決められた範囲を確認する作業です。この前提を共有できない相手とは、リリース後に必ず責任の押し付け合いになります。

契約書に「瑕疵が発見された場合は無償で対応する」といった条項が入っている場合、その瑕疵の定義を確認します。定義が「不具合全般」であれば、受けてはいけません。定義が「実施したテストケースの実行漏れや誤判定」であれば、妥当な範囲です。

検証環境の準備までこちらに求める依頼

サーバーの構築、テストデータの作成、外部サービスのサンドボックス契約。これらを「テストの一部だから」と無償の前提で振ってくる依頼があります。実際には別の技術領域の作業で、工数も責任も別建てです。準備作業を工程として見積もりに立てられるなら受けてよく、立てさせない相手は断る側に入ります。

期間だけが先に決まっている依頼

「来週の金曜がリリースなので、それまでにお願いします」から始まる依頼です。作業量の見積もりより先に納期が確定している場合、後から範囲を削る交渉ができるかどうかがすべてになります。相談の段階で「範囲と期間のどちらを優先しますか」と聞き、期間を優先すると答えた相手なら、範囲を削る前提で受けられます。両方を譲らない相手は、遅延の責任だけが受け手に残ります。

単価の話を最後まで避ける依頼

条件の詳細を詰めても金額の話が出ず、「まずは小さく始めて様子を見ましょう」と繰り返す相手には注意が必要です。小さく始めること自体は合理的ですが、その先の条件が一切示されないまま試用が長引く場合、次の契約に進む意思が無い可能性があります。次の段階に進む条件を、金額ではなく判断基準として聞いておくと見分けられます。

支払いの条件が曖昧な依頼

作業条件が整っていても、支払いの条件が決まっていない依頼は別の意味で危険です。検収の基準が示されないまま進むと、報告書を提出したあとに「まだ確認中です」という状態が続き、支払いだけが後ろにずれていきます。検収の基準と支払期日を、口頭ではなく書面で確認できるかどうかは、相手の事務体制がどれだけ整っているかの指標になります。

確認の仕方は難しくありません。「検収はどのような基準で判断されますか」「請求書の締めと支払いのタイミングを教えてください」。この二つに答えられない相手は、外部への発注の経験が浅いか、社内で経理と現場が分断されています。どちらの場合も、作業が終わったあとの手間が増えます。

相談段階のやり取りから読み取れること

条件の確認と並行して、やり取りそのものを観察します。契約前の数往復に、その後の数か月が凝縮されています。

質問への返答の速度と粒度

環境やアカウントについて質問したとき、返答が具体的で早い相手は、社内で情報が整理されています。「確認して折り返します」が三往復続く相手は、着手後も同じ速度で止まります。テストは待ち時間が発生すると稼働が止まる仕事なので、返答速度は単価と同じくらい実質的な条件です。

過去のテストの痕跡があるか

以前に作ったテストケースや、不具合の管理表が残っているかを聞きます。残っていれば、社内に検証の文化が少しでもあるということです。「今回が初めてです」という答えでも構いませんが、その場合は仕組みづくりの工数が乗ることを最初に共有しておきます。

開発者と直接話せるか

窓口が営業や企画の担当者だけで、開発者と直接やり取りできない体制は、不具合の再現条件を詰める段階で必ず詰まります。「不明点は開発の方に直接確認できますか」と聞いておくだけで、後の消耗が大きく変わります。

契約の形で守れること、守れないこと

条件の確認が済んだら、契約の形に落とします。QA・テストで問題になりやすいのは、成果物の定義と、追加作業の扱いです。

準委任と請負のどちらで受けるか

決められた期間、決められた範囲を確認する働き方は準委任が馴染みます。テストケースの作成と実行という成果物が明確に切れる場合は請負でも成立しますが、請負では「不具合が出ないこと」を成果と誤解されるリスクが上がります。契約書の中で、成果物を「テストケース一式と実行結果報告」と明記できるかどうかを確認します。

追加作業をどう扱うか決めておく

仕様変更による再テスト、修正確認の追加ラウンド、範囲外の機能の確認依頼。これらが発生したときの扱いを、発生してから相談すると必ず揉めます。「仕様変更が入った場合は、影響範囲を確認したうえで別途お見積もりします」という一文を最初に入れておくだけで、交渉の土台ができます。

フリーランスとの取引条件については、取引条件の明示や支払期日に関する法制度の整備が進んでいます。制度の詳細は所管の情報を確認するのが確実です（公正取引委員会）。条件を書面で受け取ること自体が、相手の姿勢を測る材料にもなります。

断り方は理由を一つに絞る

断ると決めたら、理由を並べずに一つに絞ります。「今回の範囲では、検証環境の準備期間を確保できないため、ご期待の日程に間に合わせられません」のように、日程か体制のどちらかに絞って伝える。複数の理由を並べると、相手はすべてを潰しにかかり、断る作業自体が長引きます。関係を残したい相手であれば、条件が変わった場合に再度相談してほしい旨を添えれば十分です。

相手の準備度合いを点数で見ない

条件を確認していくと、すべてが揃っている相手はほとんどいないことに気づきます。環境はあるが仕様書が無い、仕様書はあるが修正担当者が決まっていない。こうした状態は普通であり、欠けていること自体を理由に断ると、受けられる依頼がほとんど残りません。

判断すべきは、欠けているかどうかではなく、欠けている部分を埋める作業を仕事として扱えるかどうかです。仕様が無いなら整理の工程を立てる、環境が無いなら準備の期間を確保する、修正担当が未定ならその決定を着手条件にする。この提案に対して相手がどう反応するかが、本当の判断材料になります。

提案を受け入れる相手は、外部に依頼するということの意味を理解しています。「それも含めてお願いします」と無償の前提で返してくる相手は、こちらの作業を無限に見積もっています。同じ「準備が足りない案件」でも、この一点で結果がまったく変わります。

費用の組み立て方が、相手を選ぶ材料にもなる

条件を提示する側の組み立て方によって、相手の反応は変わります。どこで揉めるかを先回りして示すと、相性の良し悪しがその場で分かります。

時間で出すか、範囲で出すか

作業量が読めない依頼を範囲で見積もると、読み違えた分がそのまま損失になります。逆に、範囲が明確な依頼を時間で出すと、発注側は総額が読めず決裁が通りません。判断の基準は単純で、確認する対象が確定していれば範囲で、確定していなければ時間で出します。

ここで相手の反応を見ます。範囲が未確定であることを説明したうえで時間での提示に理解を示す相手は、社内で見積もりの不確実性を扱える人がいます。「総額を先に確定してほしい」と譲らない相手は、上流の予算が固まっており、その枠に作業を押し込む圧力が後から来ます。押し込まれる余地があるかどうかを、この時点で判断できます。

準備と報告の時間を見える形にする

見積もりに載せ忘れやすいのが、環境の受け取りと初期確認、報告書の作成、打ち合わせへの参加です。実行そのものより、その前後の作業のほうが時間を食う案件も珍しくありません。内訳として分けて提示すると、発注側は削る箇所を自分で選べるようになります。削る判断ができる相手は、その後の交渉も具体的に進みます。

内訳を出したときに「実際に触っている時間だけを支払いたい」と言われた場合は、注意が必要です。準備と報告を無償の前提で考えている相手は、作業が始まってからも同じ考え方で追加の依頼をしてきます。

変更が起きたときの扱いを先に書く

仕様変更、追加機能、再確認の回数増加。これらが起きたときにどうするかを、見積書の備考として一文でも書いておきます。書いてある内容に相手が同意した記録が残るだけで、後の交渉が事実の確認で済むようになります。ここで難色を示す相手は、変更が発生することを想定していないか、発生した分を受け手に吸収させる前提でいます。

依頼の種類によって見るべき点が変わる

同じ「テストをお願いしたい」でも、依頼の種類によって成立条件は違います。種類を特定しないまま条件を確認しても、聞くべきことが漏れます。

リリース前の受け入れ確認

決められた機能が要件どおり動くかを確認する依頼です。この種類では、要件の一覧が確定していることが絶対条件になります。要件が固まっていない段階で受け入れ確認を依頼してくる相手は、開発の進捗が遅れており、その遅れを検証工程で吸収しようとしています。要件一覧の版数と更新日を確認し、着手後に版が上がる可能性をどう扱うかを先に決めておきます。

修正後の回帰確認

改修した箇所以外に影響が出ていないかを見る依頼です。影響範囲を判断する材料が必要になるため、変更内容の説明を誰から受けられるかが要になります。「変更点の一覧はいただけますか」と聞いて出てこない場合、影響範囲の推定作業そのものが仕事になります。全機能を毎回確認する形にすると作業量が膨らむため、確認する範囲の決め方を最初に合意します。

観点を任される探索的な確認

手順書を作らず、経験に基づいて触りながら問題を見つける依頼です。成果が属人的になるぶん、報告の形式を先に決めておかないと評価がぶれます。何を見たか、どこまで触ったかを残す形式を合意しておくと、「思ったより見つからなかった」という評価を避けられます。時間を区切って成果を報告する形にすると、双方の期待が揃います。

自動化を含む依頼

テストコードの作成や、継続的インテグレーションへの組み込みを含む依頼です。この種類は開発業務に近く、必要なスキルも成果物の形も別物になります。既存のコードベースに触る権限が出るか、実行環境を誰が保守するか、作ったコードの保守を誰が引き継ぐかを確認します。作って終わりにできない性質があるため、引き継ぎまでを範囲に含めるかどうかで見積もりが変わります。

進め方と道具を先に合わせておく

条件が揃った依頼でも、進め方と道具の合意が抜けていると、途中で余計な作業が発生します。

使うツールを最初に決める

不具合の管理をどこで行うか、テストケースをどの形式で残すか。発注側の管理ツールに参加させてもらえるのか、こちらの形式で提出するのか。表計算ソフトで管理する現場も、専用のテスト管理ツールを使う現場もあります。どちらでも実務は回りますが、途中で移し替えることになると転記の手間だけが増えます。

道具の話は些細に見えて、相手の準備度合いがよく出ます。「不具合はどこに起票すればよいですか」という質問に即答できる相手は、社内の受け入れ体制ができています。「メールで送ってください」という運用の場合は、報告が埋もれて対応されないリスクがあるため、一覧で管理する形を提案しておきます。

報告の形式と頻度を決める

日次で状況を共有するのか、区切りごとにまとめて報告するのか。報告の頻度は作業時間に直結します。毎日の報告を求められる場合、その時間も稼働に含める前提で見積もります。報告に含める項目は、実施件数、未実施の残り、発見した問題、判断が必要な事項の四つに絞ると、双方の確認が早く済みます。

進め方の手順を四段階で握る

実務の進め方は、範囲の確定、観点と手順の作成、実行と報告、再確認、という四段階に分かれます。この四段階のうちどこまでを今回の範囲とするかを、契約前に文章で残します。範囲を口頭で決めた案件は、再確認のラウンドが何回発生するかで揉めます。「修正後の再確認は一巡までを範囲とし、それ以降は別途相談」といった線を引いておくと、追加作業の交渉が具体的になります。

必要になるスキルを自分の側でも整理する

受ける相手を選ぶ話は、裏返せば自分が何を提供できるかを整理する話でもあります。手順に沿って実行する力だけなのか、観点を設計できるのか、環境を自分で作れるのか、自動化まで踏み込めるのか。提供できる範囲を自分で言語化しておくと、依頼の種類を聞いた時点で受けられるかどうかを即座に判断できます。判断が早い受け手は、それだけで相手にとって扱いやすい相手になります。

続く関係になる相手には共通点がある

ここまで条件と型の話をしてきましたが、実務の感触としてはもっと単純な指標があります。二回目以降も声がかかる関係になる相手は、初回の相談の時点で「こちらの質問に答えることを面倒がらない」という共通点を持っています。

20年この市場を見てきた立場から言えば、長く続く受け手ほど、単発の作業をこなす速度ではなく、依頼を整える手間をどれだけ減らせるかに時間を使っています。検証の観点を先に示す、報告の形式を最初に合意する、判断が必要な箇所だけを絞って相談する。この積み重ねが「この人に任せると楽だ」という評価になり、次の依頼につながります。逆に、条件が曖昧なまま受けて頑張り切ってしまうと、次も同じ曖昧さで来ます。丁寧に条件を聞く行為は、相手を疑うことではなく、次の仕事を作る作業です。

もう一点、仲介の構造も見ておく価値があります。中間マージンが乗らない直接の取引では、依頼側は同じ予算でより多くを頼め、受け手は同じ作業でも手取りが厚くなります。手数料0%という条件は、金額の話に見えて実際には関係の質の話です。マージンを埋めるために作業量を詰め込む必要がないぶん、条件の確認や報告の精度に時間を回せる。運営者として見てきた限りでは、この余裕がある関係のほうが、結果として長く続いています。

検証や品質保証まわりの仕事がどんな形で発注されているかは、QA・テスト・コードレビューのお仕事で募集の実態を確認できます。テストの依頼は単独で出ることもあれば、開発やセキュリティ診断とまとめて出ることもあり、AI・マーケティング・セキュリティのお仕事のような隣接領域の募集を見ておくと、依頼の背景を推測しやすくなります。

条件を判断する材料として、職種ごとの水準を把握しておくことも有効です。ソフトウェア作成者の年収・単価相場では開発職全体の水準を職種別に確認できます。自分の提示する条件が市場からどれだけ離れているかを知っておくと、断る判断にも根拠が持てます。

技術的な裏付けを示したい場面では、資格の有無が話を早くすることがあります。ネットワークやインフラが絡む検証を受ける機会が多いなら、CCNA（シスコ技術者認定）のような認定は、環境構築まで踏み込めることの説明材料になります。国内案件だけで条件が合わない場合の選択肢としては、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で、海外案件側の商習慣との違いを押さえておくと視野が広がります。

最後に、選別を機械的に回すための順序をまとめておきます。相談を受けたら、まず検証対象が動くかを聞く。次に仕様の根拠を聞く。次に修正担当者を聞く。次に合否の決裁者を聞く。この四つが埋まった依頼だけを見積もりの土俵に乗せ、埋まらない依頼は「埋める作業を工程として立てられるか」で判断する。立てられないなら断る。この順序を守るだけで、受注後に消耗する案件の大半は入口で止まります。