QAエンジニアのフリーランス案件の選び方｜契約前に確かめたい7つの点

フリーランスのQAエンジニアの案件を選ぶときは、報酬や稼働日数に加えて、担う工程の実態、テストの環境と端末、テストの期間の確保、不具合と打ち切りの判断の線、契約の形と責任、稼働の振れ幅、作業の場所と情報の扱いの7点を契約前に確かめておくことが大切です。QAの案件は、同じ「テスト」の募集でもこの7点の違いで負担と責任が大きく変わります。

特に見落としやすいのは、テストの期間が開発の遅れでどう扱われるかです。開発が遅れてもリリースの日が動かなければ、しわ寄せはテストの期間に来ます。この記事では、QA案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

QA案件の選び方で差が出る理由

QAの案件票は、「テスト担当」「QAエンジニア募集」「品質保証の支援」のように、仕事の範囲が読み取りにくい書き方になりやすいものです。参画してから想定との違いに気づくことが少なくありません。

よくあるずれは次のようなものです。

• 設計から任されると思っていたら、決まったケースの実行と記録だけだった
• 検証環境やテスト用のアカウントがそろっておらず、最初の数週間は待ちが続いた
• 開発の遅れでテストの期間が半分になったのに、確かめる範囲は変わらなかった
• リリースの後に見つかった不具合について、テストで見逃した責任を問われた

案件票の読み方は案件票の読み方の記事で解説しています。こうしたずれは、面談と条件の確認の段階で、聞き方を工夫すれば多くを防げます。

契約前に確かめたい7つの点

1. 担う工程の実態

最初に確かめたいのは、自分が担う工程の実態です。テストの計画・設計・実行・報告のどこを担うのか、テストの段階（結合のテスト、システムのテスト、受入れ）のどこに入るのかを確かめます。QAの肩書きで募集されていても、実際は実行だけのこともあれば、逆に実行の募集なのに計画づくりまで求められることもあります。

面談では、「参画して最初の1か月で、最も期待されている成果物は何か」を聞くと、工程の実態が見えやすくなります。答えが「決まった範囲の実行の完了」なら実行が中心、「テストの観点の一覧とケース」なら設計、「テスト計画と報告の型」なら計画や管理の役割です。担う工程によって働き方がどう変わるかはQAエンジニアの仕事内容で整理しています。

2. テストの環境・端末・データの準備状況

テストに必要なものがそろっているかを確かめます。

• 検証環境はできているか、本番とどのくらい近いか
• テスト用のアカウントやデータは誰が用意するか、いつまでにそろうか
• モバイルや機器のテストなら、検証の端末や機器は何台あり、どこにあるか
• テスト管理や不具合の管理に使う仕組みは決まっているか

環境やデータがそろわないまま参画すると、待ちの時間が続きます。待ちの時間が稼働として扱われるかもあわせて確かめておきましょう。

3. 開発の状態とテストの期間の確保

案件票に書かれていない「今の状態」を確かめます。

• 開発は予定どおり進んでいるか、遅れているか
• テストの期間は計画でどう確保されているか
• 開発が遅れたとき、リリースの日とテストの期間のどちらを動かす考え方か

遅れのある案件を避ける必要はありません。ただ、状態を知ったうえで受けることが大切です。テストの期間が短くなったときに、確かめる範囲を誰と相談して決めるのかを確かめておくと、参画後に一人で抱え込まずに済みます。

4. 不具合と打ち切りの判断の線

QAが自分で決められることと、ほかの人が決めることの線を確かめます。

• 不具合の重さは誰が決めるか（QAが付けた重さを開発や責任者が見直すか）
• 直すか直さないかを決めるのは誰か
• テストを終えてよいかを判断するのは誰か
• 出荷の判断に、QAとしてどう関わるか（判断するのか、材料を渡すのか）

フリーランスのQAは発注元の社員ではないため、出荷の判断そのものは発注元に残るのが一般的です。そのうえで、決める人が明確になっているかが大切です。決める人があいまいな案件では、残った危うさの説明だけがQAに求められやすくなります。

5. 契約の形と、負う責任の範囲

フリーランスのQAエンジニアは、多くの場合、準委任契約で参画します。準委任では、不具合をすべて見つけることそのものではなく、テストの業務を専門家として通常求められる注意を払って行うことが約束の中身になります。

確かめたいのは、契約書や発注の書面の書き方が、この考え方と合っているかです。

• 「不具合のない状態で納品する」のように、結果を約束する書き方になっていないか
• リリース後に見つかった不具合に対して、損害賠償を求める定めがないか
• 不具合の件数やケースの消化件数が、報酬の条件になっていないか
• 成果物の納品が求められる場合、その範囲は何か（テストケース、結果の記録、報告書など）

テストの工程を請負で受ける場合は、決められた成果物を完成させる責任を負います。役割と契約の形が合っているかを確かめましょう。契約の形の違いは準委任契約と請負契約の違い、QAの報酬と責任の関係はQAエンジニアの報酬の記事で解説しています。

また、準委任の契約なのに、発注元の社員から作業の手順を逐一指示されたり、勤務時間を管理されたりする働き方は、偽装請負の問題につながるおそれがあります。テストの実行は作業の指示と結びつきやすいため、指示の流れにも注意が必要です。詳しくは偽装請負の記事をご覧ください。

6. 稼働の振れ幅と精算

QAの稼働は、テストの期間の終わりとリリースの前に大きく振れます。

• リリース前や移行の週末に、夜間や休日の確認作業があるか
• 本番での不具合が起きたときの確認に、自分が入るか
• 精算幅を超えたときの扱いと、テストの対象がそろわず待ちになった月の扱い

QAは「確かめないと出せない」場面が多いため、稼働の上限を超えやすい役割です。超過した時間の扱いを確かめておかないと、責任感から無償で対応し続けることになりかねません。精算の仕組みは精算幅の記事をご覧ください。

7. 作業の場所と情報の扱い

作業の場所と、テストで扱う情報の決まりを確かめます。

• リモートか、拠点での作業があるか。拠点の作業は週何日、どの作業のためか
• 検証の端末を自宅に持ち帰れるか、紛失や故障のときの扱い
• 本番に近いデータや個人情報を扱うか、決められた端末からしか入れないか
• 画面の記録の保存先と、発売前の製品の情報の扱い

リモートの可否と端末の扱いはQAエンジニアのリモート案件の記事で詳しく解説しています。

確かめた内容を書面と照らし合わせる

面談や事前の確認で聞いた内容は、契約の前に書面と照らし合わせます。フリーランス法では、発注する事業者は業務を委託したら直ちに、給付の内容、報酬の額、支払期日、役務の提供を受ける場所などの取引条件を、書面またはメールなどの電磁的な方法で明示することとされています。口頭だけの明示は認められていません。報酬の支払期日は、給付を受け取った日から60日以内のできる限り短い期間で定めることとされています（2026年10月時点、公正取引委員会の案内による）。明示される事項はフリーランス法で明示される取引条件、支払期日の考え方は60日以内の支払いの記事をご覧ください。

QAの案件では、特に次の点が書面に反映されているかを確かめます。

1. 業務の内容に、担う工程（計画、設計、実行、報告など）と対象が書かれているか
2. 不具合のない状態を約束する書き方や、見逃した不具合の責任を負う書き方になっていないか
3. 稼働の幅と、超えたときの精算方法
4. 作業の場所と、拠点で作業する日の扱い
5. 契約期間と更新の時期が、テストの期間やリリースの予定と合っているか

契約期間については、6か月以上継続して業務を委託している場合に、契約を解除したり更新しなかったりするときは、原則として少なくとも30日前までに予告することが求められています（2026年10月時点、公正取引委員会の案内による）。テストの期間の終わりと契約の更新の時期が重なる案件では、見通しを早めに確かめておきましょう。詳しくは契約解除・不更新の予告の記事で解説しています。

面談で聞いておくとよい質問はQAエンジニアの面談でよく聞かれる質問と答え方の逆質問の項目でも紹介しています。一般的な逆質問の考え方は面談で聞いておくべき逆質問をご覧ください。

よくある質問

テストの実行だけの案件は選ばないほうがよいですか？

選ぶかどうかは、目指す方向によります。実行の案件でも、ケースにない観点で不具合を見つけたり、報告の型を整えたりした経験は、次の案件で評価の材料になります。設計や計画に広げたい場合は、実行の案件のなかで設計に近い作業を担えるかを面談で確かめておくとよいでしょう。

開発が遅れている案件で、テストの期間が短くなりそうなときはどうしますか？

確かめる範囲と優先順位を誰と決めるかを、参画前に確かめておくことをおすすめします。期間が短くなったときに、確かめない範囲とその危うさを報告として残せる体制であれば、無理な約束をせずに済みます。稼働の上限を超えたときの扱いもあわせて確かめておきましょう。

報酬の高い案件と、工程の範囲がはっきりした案件で迷ったらどうしますか？

一概には言えませんが、QAの案件では、範囲があいまいなままテストの期間の終わりに作業が集中すると、稼働が増えて時間あたりの報酬が下がることがあります。報酬の額だけでなく、稼働の見込みと担う範囲を合わせて比べるとよいでしょう。報酬の決まり方はQAエンジニアの報酬の記事で解説しています。