テスト自動化エンジニアのフリーランス案件の選び方｜契約前に確かめたいこと

フリーランスのテスト自動化の案件を選ぶときは、報酬や稼働日数に加えて、自動化の局面と既存テストの状態、担う層と範囲、CIや環境を変える権限、テスト環境とデータ、落ちたテストを見る体制、成果の定義とコードの権利、稼働の振れ幅と費用の負担の7点を契約前に確かめておくことが大切です。テスト自動化の案件は、募集の文面が似ていても、この7点の違いで負担が大きく変わります。

特に見落としやすいのは、自動テストを直すために必要な権限と環境が与えられるかです。テストコードを書く権限だけがあり、CIの設定もテストデータも触れない案件では、不安定なテストの原因が分かっても直せません。この記事では、テスト自動化に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

テスト自動化の案件選びで差が出る理由

テスト自動化の案件票は、「E2Eテストの自動化」「テスト自動化の推進」のように書かれることが多く、今の状態や任される範囲までは読み取りにくいものです。参画してから想定との違いに気づくことも少なくありません。

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

• 新しく作る案件だと思っていたら、落ち続けている大量のテストの立て直しだった
• 自動化の担当として入ったのに、リリース前は手動のテストの実行が中心になった
• 原因が環境にあると分かったが、テスト環境を触る権限がなく、待つしかなかった
• 「自動化率」を目標として示され、意味の薄いテストを増やす方向に引っぱられた

こうしたずれは、面談と条件の確認の段階で、聞き方を工夫すれば多くを防げます。

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

1. 自動化の局面と、既存テストの状態

最初に確かめたいのは、立ち上げ・拡充・立て直し・CIの整備のどの局面かです。既存のテストがある場合は、次の点を聞きます。

• テストの量と、E2E・API・単体の内訳
• CIで定期的に流れているか、最近どのくらい落ちているか
• 書いた人がまだチームにいるか、引き継ぎの資料はあるか

立て直しの案件を避ける必要はありません。原因を分けて直した経験は、次の案件で評価されやすい経験です。ただ、状態を知ったうえで受けることが大切です。局面ごとの働き方はテスト自動化エンジニアの仕事内容で解説しています。

2. 担う層と、仕事の範囲

E2Eだけか、APIや単体のテストの仕組みまで見るのかを確かめます。あわせて、次のような周辺の仕事が含まれるかも聞いておきます。

• 手動のテストの実行や、リリース前の確認の手伝い
• 不具合票の起票と管理
• テスト観点の洗い出しや、テスト仕様書の作成

含まれること自体は問題ではありません。含まれるなら、自動化に使える時間がどれだけ残るかを見込んでおくことが大切です。面談では「最初の1か月で最も期待されている成果は何か」を聞くと、範囲の実態が見えやすくなります。

3. CIと環境を変える権限

テスト自動化では、テストコードの外側を触れるかどうかで、できることが大きく変わります。

• CIの設定ファイルを自分で変えられるか、変更の依頼先は誰か
• テスト用の環境の再起動や設定の変更ができるか
• 開発のリポジトリにテストを置くのか、別のリポジトリか。レビューは誰がするか

権限が限られていても受けられる案件はあります。その場合は、依頼したら誰がどのくらいで対応してくれるかを確かめておくと、待ち時間で稼働が無駄になるのを防げます。

4. テスト環境とテストデータ

不安定なテストの原因の多くは、環境とデータにあります。

• テスト専用の環境があるか、手動のテストや他のチームと共有しているか
• テストデータを作る手段（APIや投入の仕組み）があるか、毎回作り直せるか
• 外部のサービスとつながる部分を、模擬の仕組みに置き換えられるか

共有の環境で、データを自由に作れない案件では、テストを安定させる難しさが上がります。受ける場合は、その前提を発注元と共有し、安定させるまでの期間を見込んでおきましょう。

5. 落ちたテストを見る体制と、チームとの分担

自動テストは、落ちたときに誰かが見なければ価値を失います。

• 落ちたテストを最初に見るのは誰か。自分だけか、開発者も見るか
• 不具合として開発者に渡す流れは決まっているか
• QAの担当者との分担（自動化する観点と人が確かめる観点）は文書になっているか

すべてを自分が見る体制だと、稼働日以外にも対応を求められやすくなります。分担が決まっていない場合は、参画後の早い時期に文章にまとめる前提で受けると、後のずれを防げます。

6. 成果の定義、契約の形、コードの権利

テスト自動化の案件で揉めやすいのは、何をもって成果とするかです。

• 「自動化率◯%」「テストケース◯本」を完成の条件や報酬の基準にしていないか
• 契約の形は準委任か請負か。請負なら、何が完成で、仕様が変わったときの扱いはどうなるか
• 書いたテストコードの権利の扱いと、自分が以前から使っている共通の部品を持ち込む場合の扱い

本数や割合を目安として共有するのはかまいません。ただ、それを完成の条件にすると、保守しやすさより数を優先する方向に引っぱられやすくなります。契約の形の違いは準委任契約と請負契約の違い、権利の考え方は著作権の記事で解説しています。準委任の契約なのに、発注元の社員から細かな作業の指示や勤務時間の管理を受ける働き方は、偽装請負の問題につながるおそれがあります。詳しくは偽装請負の記事をご覧ください。

7. 稼働の振れ幅と、費用の負担

• リリース前に、回帰テストの確認や夜間の対応が増えるか
• 精算幅を超えたときの扱いと、稼働が少ない月の扱い
• CIの実行時間、クラウドの実機のサービス、負荷をかける計算機の利用料を誰の契約で使うか

テストを増やすほど、実行の費用はかさみます。自分の契約で立て替える前提になっていないかを確かめておきましょう。精算の仕組みは精算幅の記事をご覧ください。

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

面談や事前の確認で聞いた内容は、契約の前に書面と照らし合わせます。フリーランス法では、業務を委託した事業者は直ちに、業務の内容、報酬の額、支払期日などの取引条件を、書面またはメールなどで明示することとされています。また、6か月以上継続して業務を委託している場合に、契約を解除したり更新しなかったりするときは、少なくとも30日前までに予告することが求められています（2026年10月時点、公正取引委員会の案内による）。明示される事項はフリーランス法で明示される取引条件をご覧ください。

テスト自動化の案件では、特に次の点が書面に反映されているかを確かめます。

1. 業務の内容に、担う層と範囲（E2E、API、CIの整備、手動のテストの手伝いの有無など）が書かれているか
2. 本数や自動化率を完成の条件にする書き方になっていないか
3. 稼働の幅と、超えたときの精算方法
4. テストコードの権利と、持ち込む共通部品の扱い
5. 契約期間と更新の時期

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

よくある質問

落ち続けているテストが大量にある案件は避けたほうがよいですか？

避ける必要はありません。原因を分けて直した経験は、次の案件で評価されやすい経験です。ただし、現状を調べる期間、テスト環境やCIを触る権限、稼働の上限と精算方法を、参画前に確かめてから受けることをおすすめします。

案件票に使うツールが書かれていない場合はどうすればよいですか？

ツールが決まっていないのか、書いていないだけなのかを確かめます。決まっていない場合は、選定まで任されるのかを聞いておきましょう。選定から関われる案件は、方針を決めた経験として残せる一方、説明や調整の時間がかかります。

報酬の高い案件と、権限のはっきりした案件で迷ったらどうしますか？

一概には言えませんが、テスト自動化の案件では、権限がないまま不安定なテストの責任だけを負う状態が続くと、待ち時間と手戻りで稼働が増えることがあります。報酬の額だけでなく、稼働の見込みと権限の範囲を合わせて比べるとよいでしょう。報酬の決まり方はテスト自動化エンジニアの報酬の記事で解説しています。