QA・テストエンジニア採用で媒体比較の前に決めること
QAという職種名は非常に広く、同じ「QA経験5年」でも担当範囲が違います。仕様書に沿ってテストを実行してきた人、テスト観点やケースを設計してきた人、自動テストを実装してきた人、品質指標やリリース基準を設計してきた人、QA組織を立ち上げた人では、採用後に任せられる仕事が異なります。媒体選定の前に、今回のポジションを最低でも「テスト実行」「テスト設計」「自動化・SET」「品質戦略・QA Lead」に分けて定義します。
TechSuiteの職種DBでは、QA・テストエンジニアのミッションを「品質戦略、テスト設計、自動化、品質改善を通じ製品品質を高める」と整理しています。強い証拠は、テスト設計、自動化、品質分析、CI、プロセス改善です。逆に「手動テスト実行のみ」は、テスター採用では有効でも、自動化や品質戦略を担うQAエンジニアの証拠としては十分ではありません。この区別をせずに広いダイレクトスカウトDBへ入ると、母集団は増えても面談化しない、現場レビューの工数だけ増えるという問題が起きます。
ビズリーチ・リクルートダイレクトスカウト・dodaダイレクト比較
以下は2026年9月16日時点の公式情報とTechSuiteの編集整理です。料金、プラン、スカウト通数、会員数などは変動するため、契約前・公開前に各社の最新資料で確認してください。ここでは変動しやすい数字ではなく、QA採用での使い分けに焦点を当てます。
| 媒体 | 公式上の位置づけ | QA採用で狙いやすい役割 | 使い方のポイント |
|---|---|---|---|
| ビズリーチ | 即戦力人材のデータベースから企業が候補者を検索し、直接スカウトできる中途採用サービス | QA Lead、品質責任者、Senior QA、Senior SET、マネジメント経験者 | 役職名ではなく品質戦略・組織設計・自動化基盤・開発連携まで経験を分解する |
| リクルートダイレクトスカウト | ハイクラス層を中心に、企業やエージェントからスカウトを届けるサービス | QA Manager、品質保証責任者、テックリード級QA、専門性の高い中堅〜上位層 | レジュメ上の職種名だけでなく、求人要件との一致点を品質課題単位で見る |
| dodaダイレクト | dodaの人材データベースから企業が候補者を検索し、直接スカウトする中途向けサービス | テスト設計、QAエンジニア、若手〜中堅、自動化へ広げたい近接人材 | 幅広い母集団を活かしつつ、テスター・QA・SETを検索条件で分ける |
ビズリーチが向くケース：QA Leadや品質責任者を狙う
ビズリーチは即戦力・管理職・専門職の中途採用で比較対象になりやすい媒体です。QA採用では、品質保証部門の責任者、QA Manager、QA Lead、複数プロダクトを横断する品質改善、SETチームのリードなど、経験の希少性が高いポジションで優先候補になりやすいでしょう。
ただし「QA Manager」「テストマネージャー」という役職名だけで絞ると、テスト工程の進捗管理に強い人と、プロダクト品質を開発プロセスから改善した人が混在します。スカウト前に、品質指標の設計、障害分析、テスト戦略、開発責任者との役割分担、QA採用・育成、自動化投資の判断、リリース基準の設計などを見ます。Senior SETなら、単にE2E自動化を実装しただけでなく、テスト基盤のアーキテクチャ、CI実行時間、フレーク、データ管理、環境管理をどこまで改善したかが重要です。
スカウト文では年収や役職だけでなく、「今の品質課題」と「任せたい変革」を具体化します。たとえば、QA組織を新設する、属人的な回帰テストから自動化基盤へ移行する、障害対応中心から予防型の品質活動へ変えるなどです。上位層ほど、単純な欠員補充より、自分の経験が組織にどんな影響を与えられるかを判断材料にします。
リクルートダイレクトスカウトが向くケース：ハイクラス人材を別DBでも広げたい
リクルートダイレクトスカウトも、ハイクラス層を中心としたスカウトサービスとして、QA Leadや品質マネジメント経験者を探す際の主要候補です。ビズリーチと同じ候補者像だけをそのまま複製して探すのではなく、検索結果の分布を比較し、どちらのDBで対象経験者が見つかりやすいかを実画面で確認する運用が合理的です。
QAの上位職では、職種名が必ずしも「QA」になっていません。品質保証、品質管理、テストマネージャー、開発マネージャー、Engineering Manager、SRE、ソフトウェアエンジニアなどの経歴から品質活動をリードしている場合があります。レジュメ上の肩書だけでなく、「品質戦略」「テスト自動化」「CI/CD」「障害分析」「プロセス改善」「シフトレフト」など、責任範囲を表すキーワードで横断的に探す方が候補者を拾いやすくなります。
一方で、キーワードを詰め込みすぎると検索から落ちる候補者も増えます。最初は必須要件を2〜3個に絞り、QA専任経験がある層と、開発から品質領域へ広げられる近接層を別検索にするのが安全です。
dodaダイレクトが向くケース：幅広い中途層からQA候補を作る
dodaダイレクトは、dodaの人材データベースから企業が直接検索・スカウトするサービスです。QA採用では、ハイクラスだけに寄せず、テスト設計経験者、中堅QA、SIerや第三者検証会社のテストエンジニア、開発経験からQAへキャリアを広げたい人などを探索するときに比較しやすい媒体です。
特に重要なのは、手動テスト経験者を一律に除外しないことです。手動テストからスタートし、テスト設計、品質分析、自動化、リーダー経験へ広げている人は少なくありません。検索条件では「手動テスト経験あり/なし」ではなく、現在までにどこまで責任範囲が広がったかを確認します。テストケース作成、レビュー、探索的テスト、APIテスト、E2E自動化、CI連携、品質指標、障害分析などの複数条件で段階的に母集団を作ります。
また、若手〜中堅を採る場合、完成されたQA Leadを探すのではなく「自動化に挑戦したいテスト設計経験者」「開発経験を品質改善に活かしたいエンジニア」のようなポテンシャル層を別枠で作ると、母集団を広げられます。スカウト文も、現在の経験を否定せず、次の役割として何を任せるかを示すことが重要です。
QA採用で3媒体を分ける検索設計
| 採用役割 | 検索で見る証拠 | 優先チャネルの考え方 |
|---|---|---|
| QA Lead / Manager | 品質戦略、組織設計、採用育成、開発責任者との連携、品質指標 | ハイクラスDBを優先し、ビズリーチ/RDSを比較 |
| Senior QA | テスト戦略、要求分析、品質分析、プロセス改善、自動化方針 | 3媒体すべてで検索し、候補者密度を比較 |
| SET / 自動化QA | Playwright/Selenium/Cypress等、CI/CD、テストコード設計、フレーク改善 | 総合DB＋Findy/LAPRAS等のエンジニア特化型 |
| テスト設計中心QA | テスト分析・設計、リスクベース、探索的テスト、レビュー | dodaダイレクト等の幅広いDBも活用 |
| ポテンシャルQA | 開発経験、テスト設計、品質改善への志向、学習・改善経験 | 総合DBと特化型を併用し近接人材を探索 |
Findy・LAPRAS・Offers・paizaを補完に使う理由
QA・テストエンジニアの中でも、自動化・SET・QA Platformはソフトウェアエンジニアリング色が強いため、総合型ダイレクトスカウトだけでは候補者の開発背景を拾い切れないことがあります。その場合は、Findy、LAPRAS、Offers、paizaなどエンジニア採用向けサービスを補完にします。
たとえば、SET候補を探すときに「QA Engineer」だけで検索せず、フロントエンド/バックエンドの開発経験を持ち、E2E、CI、テスト容易性、品質ゲートに関わった人も対象にします。QA専任ではなくても、テスト基盤を改善した経験があれば候補になります。反対に、品質保証のマネジメントや業務系システムの受入テストなど、公開コードが評価材料になりにくいポジションでは、総合型DBの方が候補者探索に向くこともあります。
スカウト文で伝えるべき5項目
QA経験者は求人票の「テスト業務」だけでは仕事内容を判断できません。スカウトでは、①どの品質課題を解決したいか、②QAが開発プロセスのどこから関与するか、③手動テストと自動化の比率ではなく自動化の目的、④開発者・PdM・SREとの責任分担、⑤入社後に任せる改善テーマを具体化します。
たとえば「回帰テストが重いので自動化率を上げたい」という説明より、「E2Eが不安定でリリース前の確認時間が読めないため、テストピラミッドとCI運用から再設計したい」と伝える方が、候補者は課題の難易度を理解できます。QA Leadには「品質文化を作る」、SETには「基盤の技術課題を解く」、テスト設計中心QAには「上流からリスクを見つける」など、役割ごとに訴求軸を変えます。
3媒体運用でよくある失敗
1. 同じ検索条件を3媒体へコピーする
各DBでプロフィールの持ち方や候補者分布は異なります。同じ検索式を貼るだけでは比較になりません。まず各媒体で対象候補者を30〜50名程度目視し、どの条件でノイズが出るかを確認して調整します。
2. QA経験年数だけで絞る
年数より責任範囲を見ます。手動テスト5年と、2年でも自動化基盤や品質改善を担った経験では、任せられる業務が異なります。
3. ツール名をMUSTにしすぎる
Playwright、Selenium、Cypress、Appiumなどは移行可能なケースがあります。重要なのは自動化の設計思想、保守性、CI連携、原因分析です。ツールは補助条件とし、コア能力をMUSTにします。
4. QAと第三者検証の経験を一律評価する
第三者検証会社出身でも、要件分析、テスト設計、顧客折衝、リーダー経験が豊富な人は有力候補です。逆に事業会社のQAでも実行のみの場合があります。会社名より担当範囲を確認します。
媒体選定の実務ステップ
- 採用役割をテスター、QA、SET、QA Leadに分ける
- 必須経験を「ツール名」ではなく「責任範囲」で3〜5個にする
- 3媒体で対象候補者をサンプル検索し、母集団の質と量を比較する
- 上位層はビズリーチ/RDS、幅広い中途層はdodaダイレクトなど仮説を置く
- 自動化・SETはFindy/LAPRAS等も追加し、チャネル別に返信率・面談化率ではなく有効面談数を追う
- 2〜4週間ごとに検索条件とスカウト文を見直す
媒体選定は契約時の一度きりの意思決定ではありません。QA採用は役割定義によって母集団が大きく変わるため、運用データを見ながら検索条件、優先媒体、訴求を調整することが重要です。
よくある質問
QA・テストエンジニア採用では3媒体のどれを最初に使うべきですか？
QA Leadや品質責任者など即戦力の上位層ならハイクラスDBを優先し、幅広いテスト設計・QA経験者ならdodaダイレクト等の総合DBも確認します。自動化QAやSETはエンジニア特化型を併用します。
検索条件にPlaywrightやSeleniumを入れるべきですか？
入れてもよいですが、必須にしすぎない方が安全です。自動化方針、テストコード設計、CI連携、フレーク改善などの責任範囲を優先して見ます。
QA Leadは職種名だけで探せますか？
難しい場合があります。品質保証、テストマネージャー、Engineering Manager、SREなど別職種名で品質改善を担っている人もいるため、経験内容から横断検索します。
自動化QAは総合型媒体だけで十分ですか？
十分な場合もありますが、SETや開発経験者からの近接採用を狙うならFindy、LAPRAS、Offers、paizaなどエンジニア特化型を組み合わせる余地があります。
更新日・参照元
更新日：2026年9月16日。料金、プラン、会員数、送信可能数、機能、契約条件は変更される可能性があります。契約前には必ず各サービスの最新公式情報・資料をご確認ください。