QAエンジニアのフリーランス案件|報酬の決まり方と単価を上げる考え方
公開 2026-10-29 監修:株式会社エージェントベスト
QAエンジニアのフリーランス案件の報酬は、テストの実行・設計・計画・管理・QAの立ち上げのどこを担うか、リリースを出してよいかの判断にどこまで関わるか、対象の業界、まとめるチームの規模、出社の有無、商流で決まります。QAエンジニアの単価について公的な統計はなく、案件ごとに大きく変わります。
QAの案件は、工程によって「人数を補う発注」と「判断を任せる発注」に分かれやすく、報酬の差もそこから生まれます。単価を上げるには、決められたテストをこなす役割から、何をどこまで確かめるかを決める役割へ移り、その判断を説明できるようにすることが近道です。
「人数の補充」か「判断を任せる」かで報酬の決まり方が違う
| 担う工程 | 発注側の見方 | 報酬への影響 |
|---|---|---|
| テストの実行 | 決められた手順を正確にこなす人数を補う | 担える人が多く、ほかの人と並べて比べられやすい |
| テスト設計 | 仕様から観点を洗い出し、テストケースを作る | 設計の考え方を説明できるかで差がつく |
| テスト計画・見積もり | 範囲・期間・体制を決める | 計画の誤りが全体の遅れにつながるため、任せられる人が限られる |
| テストの管理・リーダー | 進捗と不具合を管理し、品質を報告する | まとめる人数と、報告の相手の階層で差がつく |
| QAの立ち上げ | QAの担当がいない組織で、進め方を作る | 方針から作れる人が少なく、条件が上がりやすい |
実行が中心の仕事は、会社員や派遣の働き方でも募集されるため、業務委託では比べられる相手が多くなります。工程ごとに求められるスキルはQAエンジニアのスキルの記事、独立の準備はQAエンジニアがフリーランスになるにはで解説しています。
報酬を左右する主な要素
1. リリースの判断への関わり
もっとも差がつくのは、「このまま出してよいか」の判断にどこまで関わるかです。残っている不具合の影響を整理し、出す・止める・条件付きで出すといった選択肢を示せる人は、品質の責任を一部背負う役割として見られます。
2. 対象の業界とシステム
金融の業務システム、医療や車載の機器のソフトウェア、決済を伴うWebサービス、ゲームなど、対象によって確かめる観点と必要な知識が違います。業務の流れや規制が複雑な分野では、業務を理解しているQAエンジニアが少なく、評価されやすくなります。
3. まとめるチームの規模と報告先
テストのリーダーとして何人をまとめるか、品質の状況を誰に報告するかで、責任の重さが変わります。開発のプロジェクトマネージャーや事業の責任者に向けて、品質の見通しを説明する役割まで担うと、管理の色が強くなります。進捗や課題の管理が中心になる場合は、PMOの報酬の記事の考え方も参考になります。
4. 技術の幅
SQLでデータを確かめる、APIを直接呼んで確かめる、簡単な自動化を書く、といった力があると、手作業だけの人より担える範囲が広がります。自動化を中心に担う場合はテスト自動化エンジニアの報酬の記事で解説しています。
5. 出社の有無と資格
スマートフォンの実機や専用の機器で確かめる案件は、出社が前提のことがあります。出社が必要な分、応募できる人が限られ、条件に表れることもあります。資格だけで報酬が決まることは多くありませんが、JSTQBの資格にはFoundation Levelのほか、Advanced Levelにテストマネジメントやテストアナリストなどの区分があり(2026年10月時点のJSTQBの案内による)、計画や設計の知識の裏付けとして見られることがあります。
単価が上がりやすい経験・下がりやすい経験
上がりやすい経験
- テストの範囲を決めて、削る判断をした:期間が足りないときに、どこを優先し何を後回しにするかを決めた
- 品質の状況を数字と言葉で報告した:不具合の傾向から、残っているリスクを説明した
- QAの進め方を組織に根づかせた:レビューの仕組みやテストの方針を作り、開発チームが使うようになった
- 開発の早い段階から関わった:仕様のあいまいな点を、作る前に見つけた
下がりやすい状況
- 実行だけを長く続けている:説明できる経験が増えず、比べられる相手が多いまま
- 自動化で置き換わる作業が中心:繰り返しの確認が自動化されると、手作業の量は減る
- 報告が件数の集計にとどまる:判断の材料にならない報告は、役割の広がりにつながりにくい
テストの工程ならではの契約の注意
テスト期間の圧縮と後ろ倒し
開発が遅れると、テストの開始が遅れたり、期間が縮められたりします。その結果、ある月に稼働が集中し、精算幅の上限を超えることがあります。反対に、開発の遅れでテストを始められず、稼働が下限を下回ることもあります。超過と控除の計算方法、待機の時間の扱いを、参画前に確かめておきましょう。計算の仕方は精算幅の記事で解説しています。
不具合の件数を報酬の条件にしない
「不具合を◯件以上見つける」といった条件を、報酬や評価に結びつけることは避けたほうが無難です。不具合の数は、作られたものの品質で変わります。件数を目標にすると、重要でない指摘が増え、本来確かめるべきリスクから目がそれます。成果は、計画どおりに確かめた範囲と、報告した品質の状況で示す形が向いています。
見逃した不具合の責任
業務委託のテストは、多くの場合、作業を行うことに対して報酬が支払われる準委任の形です。決められた範囲を、取り決めた方法で丁寧に確かめることが求められ、「不具合がひとつも残らないこと」を約束するものではありません。請負の形でテストを受ける場合は、何をもって完成とするかを確かめましょう。違いは準委任契約と請負契約の違いで解説しています。
同じQA案件でも提示額が違う理由
- 担う工程が違う:実行・設計・計画・管理のどこを担うか
- 業界とシステムが違う:業務の理解が必要な分野か
- 出社の条件が違う:実機や専用の機器が必要か
- 契約までの経路が違う:事業会社と直接か、テスト会社や開発会社を経由するか。詳しくは商流の記事を参照
月額だけでなく、精算幅、稼働日数、契約期間、支払期日までそろえて比べましょう。全体像はフリーランスの単価の決まり方でまとめています。
交渉で示せる材料
| 材料 | 例 |
|---|---|
| リリースへの貢献 | 重大な不具合をリリースの前に見つけ、判断の材料を示した |
| 進め方の改善 | 観点の整理やレビューの仕組みで、テストの手戻りを減らした |
| 役割の広がり | 実行から設計へ、設計から計画やリーダーへと担当が広がった |
| 組織への貢献 | テストの方針やひな形を作り、ほかのメンバーが使うようになった |
更新の前や、担当する工程が変わるときは、条件の見直しを相談しやすい時期です。伝え方は単価交渉の記事、面談での見せ方はQAエンジニアのスキルシートの記事をご覧ください。
よくある質問
QAエンジニアの単価の相場はいくらですか?
QAエンジニアの単価について公的な統計はなく、担う工程、業界、チームの規模、出社の有無、商流によって大きく変わります。相場の数字より、ご自身の経験が実行・設計・計画・管理のどこまで届いているかを整理し、複数の案件で条件をそろえて比べるほうが判断の材料になります。
テストの実行だけの案件は避けたほうがよいですか?
避ける必要はありませんが、実行だけを長く続けると、説明できる経験が増えにくくなります。実行の案件の中でも、観点の追加の提案や不具合の傾向の報告など、設計や判断に近い役割を引き受けると、次の案件の選択肢が広がります。
JSTQBの資格を取ると報酬は上がりますか?
資格だけで報酬が決まることは多くありません。ただ、テストの用語や技法を共通の言葉で話せることを示す材料になり、計画や設計を任される案件では知識の裏付けとして見られることがあります。資格で学んだ内容を、実務の判断の場面で使った経験と合わせて伝えると効果的です。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。