QAエンジニアが自動化転職で書類選考に落ちる理由

定時後、会社支給のノートPCではなく私物のノートPCを開き、練習用に用意したサンプルアプリにPlaywrightのテストコードを書き足す——。そんな時間を3か月近く続けていたQAエンジニアの方がいました。

私はIT・Web業界を中心に800名以上の転職支援を担当していますが、テスト実行専任からテスト自動化エンジニア(SDET)への転身で書類選考に落ち続ける相談は、自動化スキルそのものより、実績の「書き方」でつまずいているケースがほとんどです。今回は、業務外の練習をどう職務経歴書の実績に落とし込めば選考が動き出すのか、実際にあった相談事例を交えてお伝えします。

目次

1. 手動テストの実行専任からSDET転職で書類選考に落ちた理由
2. SDET求人が必須要件に挙げる「自動化の実装・運用経験」
3. 未経験からSDETの求人に応募できるか
4. 「テスト実行」だけの職務経歴書が見送られる理由
5. 自動化の実績がない状態で、どう「実績」を作ったか
6. 現場に自動化を提案できない場合はどうするか
7. SeleniumとPlaywright、独学するならどちらを選ぶか
8. JSTQB Advanced Level(テスト自動化エンジニア)は取るべきか
9. 手動QAからSDETへの移行に何年かかるか
10. SDETの年収相場と、手動QAとの差
11. まとめ、自動化の実績は「業務指示があったか」では測らない

手動テストの実行専任からSDET転職で書類選考に落ちた理由

Mさん(36歳・経験10年)は独立系SIerに所属し、通信キャリア向け基幹システムの受託開発案件でずっと検証チームに客先常駐していました。担当は一貫してテストケースの設計・実行と不具合管理で、開発工程そのものに関わったことは一度もありません。

転機になったのは、担当していた回帰テストの重さでした。220項目ある検証項目を一巡させるのに丸3日かかり、リリース前になるとこの作業だけで残業が積み上がります。同じ手順書を睨みながら同じ画面を何百回とクリックする日々の中で、「この作業自体をなくせないか」と考えるようになったとMさんは振り返っています。

「これを自動化できたらチームの負担が減る」と考えたMさんは、業務後に私物のPCで、練習用のサンプルアプリを相手にPlaywrightとTypeScriptを独学で触り始めました。誰に頼まれたわけでもなく、資格手当がつくわけでもない、純粋に自分の興味と危機感からの行動でした。

3か月ほど続けたところで、テスト自動化エンジニア(SDET)の求人に目が留まるようになり、転職活動を始めました。応募したのは11社。ところが、書類選考を通過した企業は一社もありませんでした。

11社のうち、書類選考の結果を具体的に教えてくれた企業はありませんでした。定型文の不採用通知が並ぶだけで、どこが評価されなかったのかも分からないまま、Mさんは「独学の自動化スキルが実務レベルに届いていないのだろう」と思い込み、私に相談に来た時点では転職活動そのものをやめようかと考えていたそうです。

相談に来たMさんの職務経歴書を見て、私はまず違和感を覚えました。業務内容の欄には「テストケースの設計・実行」「不具合管理」「テスト計画書の作成」としか書かれておらず、Playwrightの文字はどこにもなかったからです。理由を聞くと、業務として指示されたわけではないので書いていいのか分からなかった、という答えが返ってきました。自動化スキルがゼロだったのではなく、この思い込みが書類選考を止めていたというのが実態でした。

相談の場でMさんが繰り返していたのは、「Playwrightで書いたのは業務の本流じゃないので、経歴として名乗っていいのか自信がない」という言葉でした。10年間、テストケースの実行と不具合管理という決まった役割の中にいた人にとって、指示されていない領域に足を踏み出した経験を「自分の実績」と言い切ることには、想像以上に抵抗があるようです。私はこの手の相談を何度も受けてきましたが、遠慮が一番強く出るのはこの手動QAからSDETへの転向のケースだと感じています。

以前QAエンジニア未経験転職はきつい？後悔する人・しない人でも触れましたが、テスト実行専任のまま経験年数だけを重ねると、次のキャリアで語れる実績が乏しくなりがちです。SDETはそこから抜け出す選択肢の一つですが、抜け出し方を間違えると、Mさんのように応募数だけが積み上がる結果になります。

SDET求人が必須要件に挙げる「自動化の実装・運用経験」

SDETの求人票を見ると、必須要件の書き方に共通点があります(以下は執筆時点で公開されていた求人票の内容で、募集条件は今後変わる可能性があります)。ある家計簿・経営管理サービスの企業が出しているSDET求人では、「テスト自動化に対する知識や経験」「Webサービスでのテスト計画立案・実行経験を含むエンジニア経験3年以上」が必須要件として明記され、単体・結合・システムレベルでの自動化実装や品質分析の改善が業務内容に含まれています(出典:MoneyForward SDET求人票)。

別の不動産テック企業のQAエンジニア・SDET求人でも、必須スキルに「テスト自動化の実装・運用経験」が明記され、シフトレフト・シフトライトの枠にとらわれない品質向上活動が業務内容として書かれています(出典:estie QAエンジニア・SDET求人票)。手動テストの実行経験だけでは、この一文をクリアできません。

2社の求人票をよく読むと、必須要件と歓迎要件の線引きにも違いがあります。MoneyForwardの求人ではJSTQB Foundation Level同等以上の知識が必須要件に含まれる一方、estieの求人では資格への言及自体がありません。共通しているのは、必須要件に必ず「自動化の実装・運用経験」が含まれている一方、資格への言及は必須要件の主役ではなく、あってもなくても選考の入口には影響しにくいというのが実務上の感覚です。

歓迎要件に目を移すと、CI/CDツールの運用経験やプログラミング言語(TypeScript、Python、Javaなど)の実務経験が並ぶことが多く、必須要件を満たした上でどこまで幅広く自動化基盤に関われるかを見ている印象です。ここは応募者側が「持っていない」を理由に諦める部分ではなく、面接で今後どう埋めていくつもりかを話せれば十分にカバーできる領域だと私は考えています。

「テスター」「QAエンジニア」「SDET」という呼び方は、会社によって指す仕事の範囲がずれているのも紛らわしい点です。私が求人票を見てきた範囲では、テスターは主にテストケースの実行そのもの、QAエンジニアはテスト設計から品質保証プロセス全体への関与、SDETは開発者としてテスト基盤や自動化フレームワークそのものを作り運用する役割、という重心の違いがある傾向が強いと感じています。Mさんが応募していたのは名称こそ「QAエンジニア」の求人も含まれていましたが、業務内容の記載を読むと実質はSDETと同じ自動化実装が中心でした。

企業がここまで自動化経験にこだわるのは、自動化コード自体が保守対象のプロダクトになるからです。テストコードを書けるかどうかだけでなく、CI/CDに組み込み、壊れたら直し、運用し続けられるかどうかを見ています。「Seleniumを触ったことがある」という程度の申告では、この運用視点があるかどうかを採用側は判断できません。

未経験からSDETの求人に応募できるか

自動化の実務経験がまったくない状態で、いきなりSDET専業の求人に応募して通るケースは、私が見てきた範囲では多くありません。ただし「エンジニア経験3年以上」のような必須要件は、開発経験だけでなくテスト業務での経験年数を含めてカウントする企業がほとんどです。Mさんのようにテスト実行専任として10年働いていた経歴自体は、エンジニア経験としての年数要件を満たすうえでは不利になりません。

不利になっていたのは経験年数ではなく、その年数の中で自動化に関わった痕跡が職務経歴書のどこにも見当たらないことでした。未経験可の表記がない求人でも、応募書類に自動化の実装経験が具体的に書かれていれば、書類選考の土俵には乗ります。逆に言えば、経験年数だけでは土俵に上がれないのがSDET求人の特徴です。

私が扱ってきた求人票の範囲では、「テスト自動化未経験可」と明記されたSDET専業ポジションはごくわずかです。多くは「自動化経験者歓迎」ではなく「自動化経験必須」という書き方で、テスター・QAエンジニアからの応募自体は歓迎しつつも、自動化の実務経験がゼロの状態での応募は事実上、選考の対象外になりやすいというのが実情です。

「テスト実行」だけの職務経歴書が見送られる理由

Mさんの元の職務経歴書は、開発と検証を分業してきた組織にいれば自然に書いてしまう内容でした。ただSDETの採用担当者が最初に見るのは、テストケースの網羅性ではなく、テストコードを書いた経験があるかどうかです。ここが空欄に見える時点で、書類は読み進められる前に見送りの束に入ってしまいます。

採用担当者が職務経歴書に最初に目を通す段階では、「Selenium」「Playwright」「CI/CD」「GitHub Actions」といった固有名詞の有無を、経験の裏付けとしてかなり早い段階で確認しています。文章の巧拙より先に、この手のキーワードが実務内容の中に一つも見当たらないと、それだけで「対象外」と判断されやすいというのが実際の選考現場の動きです。

書き直す前の職務経歴書には「テストケースの設計・実行、不具合管理、リリース判定資料の作成」とだけありました。書き直した後は「回帰テスト220項目中60項目をPlaywright+TypeScriptで自動化し、実行時間を1周6時間から2.5時間に短縮(自動化率27%)。GitHub Actionsに組み込み、毎晩自動実行する仕組みを構築」という一文に変わっています。

採用担当者やエージェントが1通の職務経歴書に目を通す時間は、決して長くありません。「担当した」「対応した」という動詞ばかりが並ぶ書類は、実際に手を動かしたのか指示を受けて確認しただけなのかが読み取れず、忙しい選考の現場では良い方に解釈してもらえないのが実情です。

動詞の選び方も、Mさんの書類が変わった点の一つでした。「テスト自動化ツールの導入に協力した」という曖昧な書き方を、「回帰テスト60項目のPlaywrightスクリプトを設計・実装し、CIに組み込んだ」という主体を明確にした書き方に変えただけで、同じ経験でも重みがまったく違って伝わるようになります。

同じ人物、同じ実務期間でも、書き方一つで採用担当者に伝わる情報量がまったく違います。実績は「業務として指示されたこと」の範囲でしか書けない、という思い込みを外すことが、この書き直しの一番の肝でした。

自動化の実績がない状態で、どう「実績」を作ったか

Mさんと相談して決めたのは、個人の学習を業務の言葉に変換することと、現場で小さくてもいいから自動化を実行に移すことの二本立てでした。「個人の勉強は経歴に書けない」という思い込みを外すだけでなく、実際に業務内で自動化を動かした事実がもう一つあれば、書類の説得力は大きく変わると考えたからです。

一番苦労したのは、業務時間内に自動化の実装時間を確保することでした。上長は「まずは通常のテスト業務を優先してほしい」という反応だったため、Mさんは60項目という範囲を最初から狭く区切り、リリース判定への影響が少ない機能から着手する計画を提示しました。範囲を絞って見せたことで、「まずやってみていい」という承認が取りやすくなったといいます。

実行時間の「6時間から2.5時間」という数字も、思いつきで書いた数字ではありません。自動化前後でそれぞれ3回ずつ実行時間を計測し、スプレッドシートに記録した平均値を職務経歴書に載せました。面接で数字の根拠を聞かれた際に、計測方法まで即答できたことが、担当者から「実際に運用まで見ている人だ」と評価された理由の一つだったとMさんは振り返っています。

実装が進むにつれて、テストの壊れやすさという別の壁にもぶつかりました。画面のレイアウト変更のたびにセレクタが効かなくなり、最初の1か月は自動化した項目の半分近くが誤検知を出していたそうです。ここを地道に直し続けた経験も、職務経歴書には「自動化テストの安定運用」として一文にまとめました。

現場に自動化を提案できない場合はどうするか

Mさんは客先常駐先の理解があり、小さな範囲であれば提案を実行に移せる環境でした。ただ相談を受けていると、常駐先のルールで検証環境に手を加えられない、あるいは提案自体を聞いてもらえる立場にないという方も少なくありません。

その場合でも、個人開発の範囲でやれることはあります。公開されているオープンソースのデモアプリやサンプルECサイトを対象にE2Eテストを書き、GitHub Actionsで毎晩自動実行させる、あるいは自分が管理している趣味のWebサイトの表示崩れチェックを自動化する、といった小さな題材で構いません。重要なのは題材の華やかさではなく、手を動かした量と、そこで起きたつまずきを具体的に語れるかどうかです。面接では「なぜその題材を選んだか」「どこでつまずいたか」を聞かれることが多く、業務経験がなくてもここは十分に語れます。

現場での提案が難しい場合、いきなり自動化そのものを提案するのではなく、まずテストケース一覧の整理やテスト観点の言語化といった、自動化の前段にあたる地味な提案から始める方が通りやすいこともあります。自動化に直結しない提案でも、「業務改善を自分から動かした経験」として職務経歴書に書ける材料にはなります。

SeleniumとPlaywright、独学するならどちらを選ぶか

相談の初期に「SeleniumとPlaywright、どちらを勉強すればいいか」とよく聞かれます。Mさんの場合は、応募を検討していた求人の多くがPlaywrightもしくはCypressを歓迎要件に挙げていたこと、TypeScriptなら普段のWeb画面の仕様確認で触れていた知識が流用できたことから、Playwrightを選びました。要素の表示待ちを自動で処理してくれる分、Seleniumより誤検知が出にくく、独学段階でつまずきにくいという利点もあります。

一方で、応募先が既存のテスト資産をSeleniumとJavaで運用している現場なら、無理に流行りのツールに寄せず、現場の技術に合わせて学習する方が理にかなっています。ツール選定そのものより、選んだ理由を自分の言葉で説明できるかどうかを、面接では見られていると考えた方がいいでしょう。

Mさんは自動化した60項目のコードとREADMEを、社内のレビューを担当してくれた先輩エンジニアに見てもらい、命名規則やディレクトリ構成の指摘を受けて直しました。この一往復を経たことで、「個人で書いたコード」から「レビューを通した実務コード」に近い体裁に整い、面接で構成の意図を聞かれても答えに詰まらなくなったといいます。

こうした行動を経て、応募し直した7社のうち5社で書類選考を通過し、3社の一次面接、2社の最終面接に進みました。内定は1社で、SDETとしてのオファー年収は586万円。現職の520万円から66万円の上積みでした。

JSTQB Advanced Level(テスト自動化エンジニア)は取るべきか

Mさんは転職活動と並行して、JSTQB Advanced Level Specialist テスト自動化エンジニア(TAE)の勉強も始めていました。「資格があれば書類選考の心証が良くなるのでは」という発想です。

ただ確認してみると、日本語での実施は2024年が初めてで、期間限定のトライアル的な位置づけであることが分かりました。受験資格はFoundation Level合格者に限られ、受験料は2万円台、しかも次回以降の試験日程は現時点で未定のままです(出典:JSTQB「テスト自動化エンジニア(TAE)」実施に関するプレスリリース)。

資格そのものを否定するつもりはありませんが、「資格があるから採用されるわけではない」というのが求人票を見てきた実感です。MoneyForwardやestieの求人でも、資格の保有は歓迎要件にすら明記されておらず、問われているのは実装・運用経験そのものでした。資格の勉強時間を、実際に手を動かして自動化コードを書き、その成果を言語化する時間に振り替えたほうが、選考では効きます。

Foundation Levelのようにテストの基礎知識を体系的に確認できる資格と、実施実績がまだ乏しいAdvanced LevelのTAEとでは、選考での見られ方がまるで違います。Mさんには、TAEの勉強を今すぐやめる必要はないが優先順位を下げ、自動化コードの実装を先に進めるよう伝えました。実際、内定が出た2社はいずれも資格の有無を聞いてすらこず、面接の大半は自動化コードの設計判断についてでした。

手動QAからSDETへの移行に何年かかるか

「今から自動化の勉強を始めて、何年でSDETに転職できるか」という質問にも、決まった答えはありません。現職で自動化案件にどれだけ触れられるかで、必要な期間は大きく変わります。

すでに現場でSelenium運用の保守やテストコードのレビューに関わっている人であれば、半年から1年ほどの実務経験の積み増しで応募に踏み切れることが多い印象です。一方Mさんのように、現場に自動化の機会そのものがない場合は、個人の学習で土台を作り、そのうえで現場に小さな提案を通す時間が必要になるため、もう少し長い期間を見ておいた方が現実的です。

Mさんの場合、独学を始めてから内定までにかかった期間はおよそ10か月でした。内訳は、個人のサンプルアプリでの独学に3か月、客先での自動化提案が承認されてから実装が形になるまでに3か月、その実績を職務経歴書に反映してから転職活動を再開し内定に至るまでが4か月です。現場で提案を実行に移せるかどうかが、期間を左右する一番の分岐点でした。

もし今の現場に自動化を提案できる余地がまったくない場合は、遠回りに見えても、自動化案件のある現場への異動や転職を先に済ませ、そこで1年前後の実務経験を積んでからSDET専業の求人に応募し直す方が、結果的に近道になるケースもあります。

これまで支援してきた中では、すでに自動化案件を持つ現場にいた候補者が3〜4か月ほどで転職を決めた例もあれば、Mさんのように土台作りから始めて1年近くかかった例もあります。期間の長さそのものより、その期間で何を実装し何につまずいたかを言語化できているかの方が、選考結果への影響は大きいというのが率直な実感です。

SDETの年収相場と、手動QAとの差

dodaの職種別平均年収ランキングでは、QA・テスターに近い「デバッグ・テスター」の平均年収は390万円で、年代別に見ると20代345万円から50代655万円まで幅があります(出典:doda 平均年収ランキング)。これに対しSDETの求人は、私が実際に扱ってきた求人票を見る限り、もう一段上のレンジで募集されているケースが目立ちます。

テスト実行専任の経歴のままこの帯に応募すると届きにくく、面接では希望年収を自動化の実装経験でどこまで裏付けられるかが問われます。手動QAとSDETの間にある年収差は、資格や肩書きではなく、自動化コードを書いて運用まで責任を持った経験の有無で説明がつくというのが、Mさんの選考結果を見ても感じたことでした。

「SDETの年収は600万円から1,200万円」という幅の広い書き方をしている情報も見かけますが、この振れ幅は会社の規模やフェーズによるところが大きいというのが実感です。自動化基盤をゼロから構築するポジションを募集するメガベンチャーやSaaS企業では上限に近い提示が出ることもありますが、伝統的なSIerが社内に新設した自動化チームでは、既存のテスター職の給与テーブルに近い水準からのスタートになることも珍しくありません。求人票の年収レンジだけでなく、自動化の権限や裁量がどこまであるポジションかを併せて確認したほうが、入社後のギャップは小さくなります。

まとめ、自動化の実績は「業務指示があったか」では測らない

Mさんのケースで一番印象に残っているのは、自動化のスキルがゼロだったわけではなく、業務として指示されていない努力を実績と認めていなかった点です。個人の学習も、現場での小さな提案も、数字と固有名詞に落とし込めば立派な実績になります。

自動化の学習ロードマップや資格の情報はネット上にいくらでも見つかりますが、それをどう職務経歴書の一文に変換するかまで踏み込んで書いてある情報は多くありません。テスト実行専任からSDETを目指すなら、自動化コードを書いてみることと同じくらい、それを職務経歴書にどう書くかを見直すことが選考通過の近道だというのが、この記事で一番伝えたかったことです。

同じテスト実行専任の立場から動き出そうとしている方は、まず職務経歴書を読み返し、業務外でやってきたことが一行も書かれていないかを確認してみてください。それだけで、次に応募する数社の結果が変わる可能性は十分にあります。