テスターを辞めたい。QAのまま転職ならテスト設計を求人票で読み、実行との割合は面接で聞く

テスターを辞めたいと思った直近の場面を、まず一つ書き出してください。反復する確認、不具合の報告、開発の山場は、QAを続けても残りうる側です。一方、担当範囲、評価、仕様変更時のテスト範囲、残業の山の大きさは会社・配属で確かめます。QAのまま会社を移るなら、求人票ではテスト設計や自動化の記載を読み、実行との割合は面接で聞きます。 厚生労働省job tagは「デバッグ作業」について、バグの発見だけから原因の検討・修正まで仕事に幅があると説明しており、担当範囲は職種名だけでは決められません（「デバッグ作業 - 職業詳細」、2026年9月29日確認）。

テスターを辞めたい場面を、今の職場の値まで書く

「実行ばかり」「評価されない」「残業がきつい」のままでは、今の会社で担当を変えるべきか、別の会社へ移るべきかを比べられません。最近辞めたいと思った場面を3〜5個選び、割合、時間、回数、人数、決めた人を添えます。

例にするのは、自社SaaSのQAチーム4人で働く2年目の人です。次の値は架空ですが、求人票を読んだ後も同じ単位で使います。

辞めたい場面	今の職場の値	単位	確認先
手動の回帰テストが多く、自動化へ進めない	直近3か月は手動の回帰テストが仕事の約7割。自動化に使った業務時間は0時間	期間・仕事の割合・時間	チケット、予定表
仕様変更でテスト期間が短くなる	直近3回のリリースのうち2回、リリース前の週に仕様変更。テスト範囲は開発責任者が決定	回数・時期・決めた人	変更履歴、リリース記録
QA固有の評価項目が検出数だけ	評価項目4つのうち、QA固有の項目は検出数だけ。評価者は開発責任者	項目数・評価者	評価票、面談記録
リリース前に残業が増える	平常月15時間、リリース前の月35時間	対象期間・月の時間	勤怠
QAの意見を出しにくい	QAは4人。仕様の疑問は開発責任者へ個別に連絡し、リリース可否の会議には参加しない	人数・報告先・会議への参加	組織図、会議記録

「自動化できない」のように原因が分からない場面は、先に時間、権限、知識のどこで止まったかを書きます。この例では業務時間が0時間なので、時間配分を決める人と次の3か月の予定を確かめます。分からない値は推測せず、「未確認」と残します。

場面ごとに、最初に確かめる先を一つ決める

書いた場面は、「仕事に残りうる」「会社・配属で確かめる」「原因を今の職場で確かめる」のどこから調べるかを一つ決めます。一つの場面に仕事の性質と会社の決め方が混ざるなら、二行に分けます。

場面	最初に置く先	理由	次に確かめる値
手動の回帰テストが仕事の約7割で、自動化の業務時間が0時間	原因を今の職場で確かめる	時間、権限、知識のどこで止まっているか未確認	時間配分を決める人、次の3か月の予定
リリース前の仕様変更でテスト期間が短くなる	会社・配属で確かめる	変更後のリリース日、テスト範囲、人員の決め方を比べられる	変更の時期、範囲を決める人
QA固有の評価項目が検出数だけ	会社・配属で確かめる	評価項目と評価者は会社が決める	項目、評価者、直近の評価例
開発の山場で残業が増える	仕事に残りうる	職業説明にも残業が増える場合があると書かれている	山が来る場面
平常月15時間からリリース前の月35時間へ増える	会社・配属で確かめる	リリース日、テスト範囲、人員の決め方で山の大きさが変わる	同じ期間の最小・最大時間、範囲を決める人
QAの意見を出しにくい	会社・配属で確かめる	報告先や会議への参加は組織の決め方による	報告の流れ、QAと開発の人数、会議への参加

「会社・配属で確かめる」は、会社を移れば解決するという意味ではありません。今の会社の異動や案件変更で変わる可能性もあります。「原因を今の職場で確かめる」は行き止まりではなく、出来事と値を記録した後、ほかの二つへ置き直すための場所です。

表にない一般的な場面なら、反復する確認そのものや不具合の報告は「仕事に残りうる」、年収は「会社・配属で確かめる」、上司との関係は「原因を今の職場で確かめる」から始めます。

テスト・QAを続けると、反復する確認と不具合の報告は残りうる

テスト・QAを続けるなら、反復する確認と、不具合を見つけて伝える役割を一律になくすことは見込みません。会社を移る前に、この部分自体が一番つらいのか、担当の狭さや評価のされ方がつらいのかを分けます。

厚生労働省job tagの「デバッグ作業 - 職業詳細」は、仕事には、バグを見つけるだけの人から、原因を検討して修正まで行う人まで幅があると説明しています。バグは想定外の場所にもあるため、しらみつぶしに確認するとしています。発見だけを担う場合は、起きた状況と誤った動きを報告にまとめ、作成者へ連絡することも挙げています（2026年9月29日確認）。

同じ職業説明では、細かな作業を繰り返し丹念に行う根気強さが求められ、開発担当者との連携が必要なこともあるとされています。不具合を作成者へ報告する役割は前段の仕事内容に含まれます。

一方、IT系の転職支援サイトの記事でも、不具合を見逃せないプレッシャーが辞めたい理由に挙げられています。この記事では、テスト・QAを続けると残りうる側に置きます。

同じ職業説明では、開発の山場や問題点が見つかった場合などは、残業が増えることもあるとされています。残業の山が一番の悩みなら、山をゼロと決めず、応募先で大きさとテスト期間の決め方を確かめます。反復する確認、不具合の報告、見逃せないプレッシャーそのものが一番つらい場合は、会社を移っても残る可能性を前提にします。別職種への移り方は、この記事では扱いません。

転職の前に、今の会社で案件や担当を変えられるか確かめる

辞めたい原因が担当の狭さなら、求人を探す前に、今の会社で担当を変えた実例があるかを確認します。希望を伝えたことがなければ、転職しなければ変わらないとはまだ決まりません。

SES・派遣・第三者検証会社で働く場合は、案件の変わり目に、テスト設計や自動化を含む案件を希望できるかを聞きます。「上流へ行きたい」ではなく、次の3点まで確かめます。

• 希望を誰へ、いつ伝えるか
• 過去にテスト実行からテスト設計へ移った人がいるか
• 希望が通らない場合、次の案件を決める基準は何か

自社のQAなら、仕様レビュー、自動化、別の開発チームへ担当を広げた直近の人について、入社から何年目に、何を任され、誰が決めたかを聞きます。例の人は、自動化の業務時間が0時間なので、まず「次の3か月に自動化へ使う時間を誰が決めるか」を、時間配分を決める人へ聞けます。

応募したい求人の必須要件がテスト設計経験で、今は実行しか担当していないなら、今の会社でテストケース作成や設計を任される時期と道筋を聞きます。今の会社に実例がなく、担当も変わらないと分かったら、同じ質問を応募先へ移します。経験がなく必須要件に届かない場合の別職種への移り方は、この記事では扱いません。

求人票で記載を読み、実際の割合・評価・残業は面接で聞く

QAの求人を1件開きます。求人票で見るのは、テスト設計や自動化を仕事として書いているかです。入社後に何割を任されるか、評価されるか、リリース前に何時間残業するかは、求人票だけで決めず面接へ回します。

求人票は欄をまたいで読む

仕事内容だけでなく、会社説明、勤務地、組織、募集背景、勤務時間、PR、給与まで見ます。残業の数字が勤務時間欄ではなく、仕事内容に書かれている場合もあります。

読む項目	求人票で探す記載	読めること	求人票だけでは読めないこと
担当する仕事	テスト設計・計画・ケース作成、要件定義・仕様レビュー・プロセス改善、自動化とツール名	会社が仕事として書く範囲	実行・設計・自動化の割合、任される時期
働く場所と案件	客先・派遣先・プロジェクト先、第三者検証、自社プロダクト	勤務先や会社の説明	常駐期間、次の案件、希望の通り方
QAの組織と開発との関係	QAのチーム・組織、開発チームの一員、スクラム、第三者検証	組織や働き方の記載	報告の流れ、発言のしやすさ、評価者
評価と次の役割	キャリアパス、リーダー、スペシャリスト、評価制度	将来の役割や制度の記載	QAの評価項目、リリース判断への参加
残業と年収	月の残業時間と対象、平均・範囲、年収の幅、手当	会社が示す数字と役割	配属先の平常時・繁忙時、同じ役割の年収

QAの組織があり、各開発チームにもQAが入る会社は両方に印を付けます。QA組織がなく、プロジェクトごとに一人で入る形も、そのまま記録します。第三者検証会社のように会社全体がテスト・QAを担う場合は、自社のQA組織の有無とは別に、客先の開発チームとの関わり方、報告先、自社の評価者を記録します。「開発チームの中」と「QA組織」は二択ではありません。

欄が空、欄同士が食い違う、応募要件に経験があるだけ、将来の話だけ、会社全体の平均しかない場合は「確認できず」とします。テスト設計の語がなくても「実行だけ」とは読まず、書いてあっても入社後に設計を担当できるとは決めません。必須要件にテスト設計経験があり満たせない場合は「応募要件に未到達」と分け、前節の今の会社で経験を作る道筋へ戻ります。歓迎要件なら必須要件と混ぜません。

求人票に書かれる語から、面接へ回す項目を選ぶ

2026年9月29日時点で当サイトPREVIOに掲載中の求人のうち、職種にテスター・検証エンジニア・QAを含み、題名からQA・テスト・検証・評価・品質保証の仕事と読める求人を、勤務地を絞らず会社単位で全件集計すると、テスト設計・計画を書く会社は約75%、仕様レビュー・要件定義・プロセス改善などを書く会社は約65%、どちらかを書く会社は約85%、自動化を書く会社は約65%でした。職種タグに混じる開発職や未経験者向けのIT総合職は題名で除きました。「書いてある」は対象求人のどれか1件に該当する語があり、「書いていない」はどの求人にもない会社です。割合は5%単位に丸めています。これは求人票にその語を書く会社の割合で、入社後にその仕事へ使う時間の割合ではありません。

テスト設計・計画や、仕様レビュー・要件定義・プロセス改善は多くの会社が書く語なので、語があるだけでは応募先を絞れません。実行の多さならテスト設計・自動化、仕様変更なら仕様レビュー・プロセス改善の記載を探し、語があれば実際の比重を、なければ仕事内容を面接で聞きます。

同じ求人票には、QAのチーム・組織、開発チームの中で働く形、キャリアパスの記載もあります。これらは組織の実態や評価方法を示すものではなく、面接でQAの人数・開発の人数・評価者を聞く項目を選ぶための手がかりです。

客先・派遣先で働くか、第三者検証・テストの会社かも求人票から探せます。ただし、その記載がない求人には受託開発、SIer、コンサル、メーカー、技術者派遣も含まれるため、自社プロダクトとは読みません。客先・テスト会社の求人は残業や資格支援の語を、客先・テスト会社と読めない会社はCI/CD・ツール名・開発チーム・QA組織の語を多く書いていました。後者は大半が自社プロダクトの会社で、客先・テスト会社の側は少数です。この違いには求人票の書き方の違いも含まれます。

今の職場と同じ単位で質問する

例の人なら、求人票で見つけた記載を次の質問へ変えます。

項目	今の職場の値	求人票で見た記載	面接で聞く質問
実行・設計・自動化	手動の回帰テストが約7割、自動化は0時間	テスト設計、自動化	配属予定先では、直近3か月のテスト実行・設計・仕様レビュー・自動化は仕事の何割でしたか。自動化のコードは誰が書きますか
仕様変更とテスト範囲	直近3回中2回、リリース前の週に変更	要件定義、仕様レビュー	直近3回のリリースでは、仕様変更はいつ入りましたか。リリース日が動かないとき、テスト範囲と人員を誰が決めましたか
評価	QA固有の評価は検出数だけ	QA組織、評価制度	QAの評価項目は何で、誰が評価しますか。直近の評価で不具合の予防や仕様レビューをどう扱いましたか
QAと開発	QA4人、リリース可否の会議には不参加	QA組織、開発チームの一員	QAと開発は何人で、QAはどのチームに属しますか。仕様の疑問は誰に聞き、リリース可否の判断にQAは入りますか
残業	平常月15時間、リリース前の月35時間	月平均残業	この数字は会社・部署・配属予定先のどれですか。配属予定先の直近3か月で、月の残業の最小と最大は何時間でしたか

テスト会社・SESで面接時に案件が決まっていない場合は、「配属予定先」を「直近に入社した人の最初の案件」に替えます。実行・設計・自動化の割合は、現在の案件のうち、実行中心、設計を含む、自動化を含む案件がそれぞれどのくらいあるかでも聞けます。

客先の評判と給与の決まり方が不満なら、「評価者は客先と自社の誰ですか」「客先の評判は自社の評価項目にどう入りますか」「契約単価が変わったとき、給与を見直す人と時期はどう決まりますか」と聞きます。求人票の記載だけで、評価や給与への反映を決めません。

リリース周期が同じなら、平常時と直近のリリース前を同じ期間で聞きます。1週間スプリントのように「リリース前の月」がない会社では、双方を直近3か月の月ごとの最小・最大にそろえるか、直近3回のリリース前1週間に増えた時間へそろえます。会社平均と配属予定先の数字は並べて比較しません。

2026年9月29日時点の当サイトPREVIOの掲載中求人から、職種と題名を前述の条件で絞り、勤務地を限定せず会社単位で全件集計すると、残業時間の数字を書く会社は約20%で、そのうち、残業時間の数字を書いている求人のすべてで20時間以下だった会社は約85%でした。固定残業の説明と残業代の計算例は実績から除き、「書いてある」は対象求人のどれか1件に記載がある会社とし、割合は5%単位に丸めています。20時間以下という記載があっても、多くは会社・部署の平均で、配属予定先やリリース前の値ではありません。 繁忙期やリリース前の残業を書く会社は全対象会社の5%未満なので、20時間以下の求人でも対象範囲と山の大きさを上の質問で確かめます。

年収は求人票の幅を読み、面接では同じ役割の人の年収幅と、テスト設計や自動化を担ったときに等級がどう変わるかを聞きます。

この見分け方で分からないこと

求人票と面接で分かるのは、書かれた内容と説明時点の実績までです。入社後も同じ配属、担当割合、評価、仕様変更の決め方、残業、年収が続くとは限りません。

求人の集計は、当サイトに掲載された求人の構成を示すもので、日本のQA求人全体を示しません。自社プロダクトのQAに偏り、SES・テスト会社に近い求人は少数です。会社単位では、求人を多く出す会社ほど、どれか1件に語があって「書いてある」に入りやすい数え方です。

語の有無から、実行だけの仕事か、入社後の仕事の比重、評価のされ方は分かりません。短い求人は、実態がなくて書いていないのか、説明が省かれているのかも区別できません。

厚生労働省job tagの職業説明は、開発の中でデバッグする人も含み、QA専任者だけの説明ではありません。残業や開発担当者との連携の説明を、QA専任者すべてに当てはめることはできません。連携は「必要なこともある」という強さで、QAは必ずリリース前に残業が増えるとも言えません。job tagに載る年収は、統計データがこの職業だけの値ではないため、この記事では使っていません。就業形態は、この職業の回答ではあるもののゲームテストのアルバイトを含むため、使っていません。

会社を変えれば全部解けるとも、テスト・QAを辞めるしかないとも判定できません。最初の表で一番変えたい場面を一つだけ選び、第2節の3つの置き先のどこから確かめるか決めます。「仕事に残りうる」ならQAを続けるかを考え、「原因を今の職場で確かめる」なら時間や権限を決める人へ聞き、「会社・配属で確かめる」なら今の会社で担当を変えられるかを先に確かめます。今の会社で変わらないと分かってから、QAの求人を1件開きます。

よくある質問

QAエンジニアとテスターは何が違うのですか？

職種名だけで仕事の範囲は決まりません。厚生労働省job tagの「デバッグ作業」は、バグの発見だけを行う人から、原因を検討して修正まで行う人まで幅があると説明し、QAテスターとQAエンジニアを職業別名に挙げています。求人票では職種名より、テスト実行・設計・仕様レビュー・自動化のどれを書くかを読み、実際の割合を面接で聞きます。

テスト設計と書いてある求人なら、入社後に設計を任されますか？

求人票に書いてあるだけでは分かりません。配属予定先で直近3か月にテスト実行と設計へ使った割合、設計を任された直近の人が入社から何年目だったか、自動化のコードを誰が書くかを聞きます。

SES・テスト会社から自社プロダクトのQAへ移れば変わりますか？

一律には言えません。客先・テスト会社の求人と、客先・テスト会社と読めない会社の求人では、残業・資格支援と、CI/CD・ツール名・開発チーム・QA組織の語の書かれ方に違いがありました。後者は大半が自社プロダクトの会社で、客先・テスト会社の側は少数です。求人票の書き方の違いも含まれるため、自社プロダクトだから解決すると決めず、担当割合、評価、仕様変更時のテスト範囲、残業を同じ質問で確かめます。

開発との板挟みは会社を変えればなくなりますか？

なくなるとは断定できません。不具合を作成者へ伝える仕事があり、開発担当者との連携が必要なこともあります。開発チームの中で働くという記載は関係の近さの手がかりですが、指摘する役がなくなることを示しません。不具合の報告の流れ、仕様の疑問を聞く相手、リリース可否を決める人を面接で確認します。

テスターから抜け出すには、開発職へ移るしかありませんか？

QAのままでも、テスト設計、仕様レビュー、自動化、リーダーへ担当を広げる道が求人票に書かれる場合があります。まず今の会社で担当を変えた実例を聞き、変わらなければ求人票で記載を探し、実際の割合と任される時期を面接で確かめます。開発職など別職種への移り方は、この記事では扱いません。