「未経験でもQAエンジニアなら入りやすいと聞いたので応募しました」——面談でそう切り出す方に、私はここ数年で何度も会ってきました。実際に間口は広く、内定も出やすい職種です。ただ入社後に話を聞くと、同じ「QAエンジニア」という肩書きなのに、任される仕事の中身がまるで違う二人がいます。

私はIT・Web業界を中心に800名以上の転職支援を担当していますが、QAエンジニアの未経験転職で明暗が分かれる原因は、本人の努力よりも先に、入社前にどこまで求人票と面接内容を読み込んでいたかにあることがほとんどです。今回は求人票の文言の違いと、面談で見抜くための質問例、実際に後悔した人・しなかった人の対比から、その分かれ目を具体的にお伝えします。

今回は、次の内容に沿ってご紹介します。

  • QAエンジニアの未経験転職が「きつい」と言われる6つの理由と、その実態
  • QAエンジニアとテストエンジニアの違いが、求人票の文言にどう表れるか
  • 後悔した人・しなかった人、二人の相談事例の対比
  • 面談・面接で「テスト実行止まりか、設計まで関われるか」を見抜く質問リスト
  • 未経験から目指す学習ロードマップと、JSTQB・キャリアパスの考え方
目次
  1. QAエンジニアの未経験転職が「きつい」と言われる理由
  2. QAエンジニアとテストエンジニアの違い、求人票の文言でここまで変わる
  3. 後悔したCさんと、後悔しなかったDさん——同じ「未経験QA」でも分かれた明暗
  4. 二人を分けたのは、入社前に何を確認していたかだった
  5. テスト実行専任からでも抜け出せるのか、Cさんに提案したこと
  6. 面談・面接で「テスト実行止まりか、設計まで関われるか」を見抜く質問
  7. 面接での回答を入社前に照らし合わせる、転職会議という選択肢
  8. 未経験からQAエンジニアを目指す学習ロードマップ、JSTQBはどこまで必要か
  9. QAエンジニアの将来性とキャリアパス、SDET・QAマネージャーという選択肢
  10. 未経験からQAエンジニアに向いている人・向いていない人
  11. よくある質問
  12. まとめ、後悔するかどうかは「入社前にどこまで確認したか」で決まる

QAエンジニアの未経験転職が「きつい」と言われる理由

QAエンジニアは「未経験可」の求人が多く、プログラミング経験がなくても応募できる求人が目立ちます。ただし入社後に「思っていたのと違った」という相談も、私が担当した中では一定数あります。

理由は一つではなく、いくつかの要素が重なっています。

QAエンジニアの未経験転職が「きつい」と言われる主な理由です。

  • 用意されたテストケースを手順書どおりに消化するだけの、単純作業の繰り返しになりやすい
  • リリース直前に検証項目が積み上がり、納期に追われる長時間労働になる時期がある
  • バグを一件見逃せば本番障害につながるという、責任の重さに対する心理的プレッシャー
  • 「もっと早く教えてほしかった」と開発チームから言われ、板挟みになりやすい立場
  • 開発のように成果物が形として残らず、仕事の成果が可視化されにくい
  • テスト実行の経験だけでは次のキャリアが見えにくい、キャリアパスの曖昧さ

このうち私が相談を受けていて一番深刻だと感じるのは、単純作業の繰り返しとキャリアパスの曖昧さがセットで起きるケースです。テストケースを与えられて実行するだけの日々が続くと、1年経っても「テストを早く正確に回せる」以上のスキルが積み上がらず、次の転職で語れる実績が乏しくなります。

一方で、納期に追われる長時間労働やバグ見逃しのプレッシャーは、テスト設計まで担う現場でも起こり得ます。むしろ設計段階から関わる分だけ責任範囲は広がるので、「きつさ」の種類は変わっても消えるわけではありません。この点を勘違いしたまま「設計に関われる現場なら楽になる」と思い込むと、別の形でギャップを抱えることになります。

開発チームとの板挟みも、未経験者ほど戸惑いやすいポイントです。リリース直前に見つけた不具合を報告すると、「今さら言われても直せない」と開発側から不満を言われることがあります。逆に細かい表記ゆれまで律儀に報告すると「そこまで指摘しなくていい」と煙たがられることもあり、どこまで厳しく見るかの塩梅は、現場ごとの暗黙のルールを掴むまで数ヶ月かかるのが普通です。

成果の可視化されにくさも侮れません。開発なら「機能を実装した」という目に見える成果がありますが、QAの成果は「バグを未然に防いだ」という、起きなかったことの証明です。評価面談で「今期は何をしましたか」と聞かれたときに、テストケースの消化件数以外を語れないと、自分の仕事の価値を自分でも見失いがちになります。

QAエンジニアとテストエンジニアの違い、求人票の文言でここまで変わる

QAエンジニアとテストエンジニア(テスター)は、求人サイトでは同じカテゴリに並んでいることが多いのですが、業務範囲は本来別物です。テストエンジニアは主に「作られたテストケースを実行し、結果を記録する」役割で、QAエンジニアは本来「何をどうテストするか」を設計し、品質そのものに責任を持つ役割です。

ただし実際の求人票では、この線引きがそのまま職種名に反映されているとは限りません。「QAエンジニア」という肩書きで募集していても、業務内容を読むとテスト実行専任の枠だった、というケースを私はかなりの数見てきました。ここは求人票の言葉そのものから見抜くしかありません。

業務範囲よく使われる文言実際の仕事の中心
テスト実行寄り「テスト実施」「手順書に沿ってテストを行う」「テスト項目のチェック」「バグ報告書の作成」用意されたテストケース・シナリオの消化、結果の記録
テスト設計まで「テスト設計」「テスト計画の立案」「品質計画」「テスト戦略の策定」「開発初期からの品質保証」仕様からテスト観点を洗い出し、テストケースそのものを作る

求人票の中心が「テスト実施」なのか、それとも「設計」「計画」「戦略」という言葉が入っているかで、求人票の性格はかなり変わります。もちろん未経験の場合は最初の数ヶ月がテスト実行中心になるのは自然なことですが、その先に設計フェーズへ進む道が求人票の文言に匂わされているかどうかは、応募前に確認できる情報です。

似た構図は未経験転職の求人票全般に言えることで、以前「未経験可」求人の実態を扱った記事でも触れましたが、QA職の場合はさらに一段階細かく、業務内容の「質」の違いにまで踏み込んで読む必要があります。

ややこしいのは、テスト実行専任の求人でも「品質保証」「QA」という肩書きを堂々と使っている企業が珍しくないことです。応募者の目には設計から関われそうに見えるよう、職種名だけは格上げしておき、業務内容欄には当たり障りのない書き方でぼかす。これは意図的な誇張というより、採用担当者自身が現場の業務内容を細かく把握していないまま求人票を作っているケースも多いというのが、私が企業側とやり取りしてきた実感です。だからこそ、求人票の言葉を鵜呑みにせず、面接で直接確認する工程が欠かせません。

後悔したCさんと、後悔しなかったDさん——同じ「未経験QA」でも分かれた明暗

同じ時期に未経験からQAエンジニアへ転職した二人がいます。年齢も前職もまったく違う二人でしたが、入社してから半年〜1年で、私のところに来る相談の温度がはっきり分かれました。

Cさん(32歳・前職は製造業の品質保証部門)は、工場での品質管理経験を活かせると考え、SES企業に未経験QAエンジニアとして入社しました。配属された客先常駐先は大手ECサイトの検証チームで、業務はテストケースの実行が中心でした。1日に処理するテストケースが150件を超える日もあり、Excelとテスト管理ツールへの結果記入だけで定時が埋まっていきます。

半年ほど経った頃、Cさんから「このままだと市場価値が上がらない気がする」と連絡がありました。実際に職務経歴書を作ってみると、書けることは「テストケースを正確に消化した件数」くらいしかなく、テスト設計や改善提案の実績がまったくないことに、そこで初めて気づいたそうです。面談で伝えていた希望と違い、配属先ではその希望が反映されていませんでした。

一方のDさん(27歳・前職はアパレル販売職)は、未経験からQAエンジニアを目指すにあたって、応募先を絞り込む段階で求人票を読み比べていました。従業員150名ほどの自社開発企業(BtoCアプリ)に応募し、一次面談で「テスト実行だけでなく、要件からテスト観点を考える仕事がしたい」と率直に伝えたところ、面接官から「最初の3ヶ月はテスト実行で仕様を覚えてもらうが、その後はテストケースの作成にも入ってもらう」と具体的な回答が返ってきました。

入社後は実際にその通りの流れで業務範囲が広がり、8ヶ月目にはJSTQB Foundation Levelを取得、開発チームと一緒にテスト自動化の小さなPoC(技術検証)にも参加するようになっていました。Dさんは「テストを作る側に回れて、初めて仕事が楽しいと思えた」と話しています。

二人を分けたのは、入社前に何を確認していたかだった

CさんとDさんの適性やポテンシャルに、大きな差があったとは私は思っていません。Cさんも品質管理の現場で数字にこだわる姿勢を評価されていましたし、面談での受け答えも堅実でした。分かれ目は能力ではなく、入社前にどこまで具体的な業務範囲を確認していたかにあります。

Cさんは「品質保証の経験を活かせる」という求人票の一文に安心してしまい、業務内容の詳細や配属先の裁量については深く確認しないまま選考を進めていました。SESという業態上、配属先は入社後の営業判断に左右される部分があり、面談で聞いた希望がそのまま反映されるとは限らない、という構造上のリスクも見落としていました。

Dさんは逆に、面接の場で「最初の3ヶ月」「その後」という時間軸まで踏み込んで質問し、回答の具体性を確認していました。抽象的な「成長できる環境です」という答えではなく、業務がどう変化していくかの見通しを、面接官の口から具体的に引き出していたことが結果的に効いています。

ポイント: 未経験QAエンジニアの転職で後悔するかどうかは、入社後の努力量よりも先に、応募前・面接中にどこまで業務範囲を掘り下げて確認したかで大きく決まります。

テスト実行専任からでも抜け出せるのか、Cさんに提案したこと

すでにテスト実行専任の現場に入ってしまった人に、私は「その経験がすべて無駄になるわけではない」と伝えています。Cさんにも実際にそう話しました。ただし、何もせず待っているだけでは設計側に回してもらえる可能性は低いというのも事実です。

Cさんにまず提案したのは、担当しているテストケースの中で「なぜこの手順で確認しているのか」を自分なりにメモに残すことでした。仕様書と突き合わせて、抜けていそうな観点を見つけたら、たとえ採用されなくてもリーダーに一言提案してみる。この積み重ねが、次の職務経歴書で「テストケースの改善提案を行った」という一行に変わります。

もう一つ勧めたのが、SESという業態の性質を逆手に取ることです。契約更新のタイミングで営業担当に「次の現場では設計工程に関わりたい」と明確に伝え、それが通らないなら転職という選択肢も検討する。Cさんは結局、次の契約更新のタイミングで転職活動を再開することを選びましたが、テスト実行専任だった期間の経験も「大量のテストケースを正確かつスピーディに消化した実績」として職務経歴書に落とし込めるよう、一緒に整理しました。今いる場所の経験をゼロ扱いにせず、次にどう接続するかを考えることが、後悔を長引かせないための現実的な一歩です。

面談・面接で「テスト実行止まりか、設計まで関われるか」を見抜く質問

求人票の文言だけでは、実際の配属先まで見通せないこともあります。特にSESや客先常駐型の求人では、面接で聞いた話と実際の配属先の業務が食い違うリスクがあるため、私は未経験でQAエンジニアを目指す求職者に、面談・面接の場で次の質問をするよう勧めています。

面談・面接で確認しておきたい質問リストです。

  • 「テストケースは誰が作成していますか。入社後、自分がテストケースの作成に関わる時期の目安はありますか」
  • 「開発の要件定義・設計フェーズに、QAチームが同席することはありますか」
  • 「直近でQAチームから開発チームに、仕様の改善提案をした事例はありますか」
  • (SES・客先常駐の場合)「配属先はどのように決まりますか。面談で伝えた希望は、配属判断にどこまで反映されますか」
  • 「テスト自動化への取り組み状況はどうですか。担当できる可能性はありますか」
  • 「QAエンジニアからのキャリアパスとして、社内にどんな前例がありますか」

特に効くのが、最初の質問への回答の具体性です。「もちろん関われます」とだけ返ってくる場合と、Dさんが受けたように「最初の3ヶ月は〜、その後は〜」と時間軸まで具体的に説明できる場合とでは、実際の配属先での裁量に差があることが多いというのが、私の見てきた実感です。

配属先の判断に希望がどこまで反映されるかという質問は、聞きにくいと感じる方もいますが、ここを曖昧にしたまま入社すると配属後にギャップが表面化するケースが目立ちます。遠慮せず、選考の初期段階で確認しておくべき項目です。

面接での回答を入社前に照らし合わせる、転職会議という選択肢

ここまで挙げた質問は、面接の場で担当者や面接官から直接引き出す情報です。ただし面接官の回答がどこまで配属後の実態を反映しているかは、こちらが確認できる範囲に限りがあり、入社してみるまで分からない部分がどうしても残ります。面接で聞いた話を、別の角度から照らし合わせる材料も知っておくと安心につながります。

その一例として、社員・退職者の口コミを企業ごとに読める「転職会議」を紹介します。

入社前に確認する材料の一つ

社員・退職者の口コミを企業ごとに確認できる転職口コミサイト

企業の口コミ・評判を見る【転職会議】

会員登録後、口コミの続きを閲覧できます(無料)

転職会議は企業ごとの口コミをカテゴリ別に分けて掲載しており、その中に「入社理由、入社後に感じたギャップ」という項目があります。Cさんが経験したような「面談で聞いた希望と、実際の配属先の業務が違った」というギャップは、その企業に先に入社した別の人がすでに感じている可能性があり、該当カテゴリの口コミを読んでおくと、面接で確認すべき論点をより具体化する材料になります。

ただし口コミの中身を私が保証できるわけではありません。口コミは投稿した本人の主観であり、私が求職者とやり取りしてきた実感としては、在籍中の人より、不満を抱えて辞めた人の方が投稿するモチベーションが高くなりやすい傾向があるように感じます。書かれている内容をそのまま鵜呑みにするのではなく、面接で確認すべき論点を見つけるための材料として使うのが、実務的な使い方だと私は考えています。掲載されている口コミのカテゴリ分けや会員登録の条件は公式サイトの記載に基づくもので、私自身が閲覧して検証した体験として書いているわけではない点は断っておきます。

未経験からQAエンジニアを目指す学習ロードマップ、JSTQBはどこまで必要か

未経験からQAエンジニアを目指す場合、応募前にどこまで学習しておくべきか迷う方も多いはずです。私が求職者に勧めているのは、次の順番です。

未経験からQAエンジニアを目指す学習ロードマップです。

  • ①テストの基本用語と目的を理解する(テスト計画・テスト設計・テスト実行・テスト管理の流れ)
  • ②同値分割・境界値分析・デシジョンテーブルといった基本的なテスト技法を書籍や無料教材で学ぶ
  • ③簡単なWebアプリやスマホアプリを題材に、自分でテストケースを書いてみる
  • ④HTML・CSSの基礎程度でよいのでプログラミングの基本文法に触れておく
  • ⑤余裕があればJSTQB Foundation Levelの学習を始める(資格取得は入社後でも間に合う)

JSTQBはソフトウェアテスト技術者を対象にした国際的な資格制度の日本版で、Foundation・Advanced・Core Expert・Testing Specialistという段階に分かれています。未経験の段階で目指すのはFoundation Levelで十分です。試験はピアソンVUEが運営するCBT方式に移行していて、決まった実施日を待たず、予約が取れる日であればいつでも受験できます(参考:日本科学技術連盟 JSTQB Foundation Level CBT)。

私の感覚では、Foundation Levelの資格そのものが選考通過率を大きく押し上げるわけではありません。ただし「テスト用語を正しく使えるかどうか」は面接で必ず見られる部分なので、資格取得を目指す過程で用語を体系的に学んでおくと、面接の受け答えの精度が上がります。応募前に無理に取得を急ぐより、入社後の実務と並行して学習を進める方が、身につく知識の質は高くなるというのが私の見立てです。

QAエンジニアの将来性とキャリアパス、SDET・QAマネージャーという選択肢

テスト実行だけの業務にとどまっていると、キャリアパスが見えにくいのは事実です。ただしテスト設計や品質改善の提案まで経験を積んだQAエンジニアには、複数の広がり方があります。

QAエンジニアから広がる主なキャリアパスです。

  • SET・SDET(テスト自動化エンジニア):テストコードの実装や自動化基盤の構築を担う、開発寄りのキャリア
  • [QAマネージャー](/blog/qa-manager-management-experience-salary-gap/):チームのテスト計画・品質基準づくりを統括する、マネジメント寄りのキャリア
  • QAコンサルタント:複数プロジェクト・複数企業を横断して品質保証の仕組みづくりを支援するキャリア
  • PM・プロダクトマネージャー:品質を軸に、要件定義や開発プロセス全体に関わるキャリア

年収については、調査元によって数字の幅が非常に大きいので注意が必要です。外資系ハイクラス紹介会社Morgan McKinleyの2026年版年収ガイドでは、東京の事業会社所属QAエンジニアの基本給ベースの目安として、経験の浅い層でおよそ600万円、中堅層で700万円、ニッチなスキルを持つ上位層では1,000万円程度の水準が示されています(参考:Morgan McKinley 年収ガイド QAエンジニア(事業法人・東京))。ただしこれは外資系・ハイクラス紹介会社が扱う経験者・シニア層寄りのデータで、未経験入社時点の年収を示すものではありません。

未経験からの入社時点では、この水準よりかなり低いところからスタートするのが実情です。私が担当してきた実例でも、未経験QAエンジニアの初年度年収は前職の水準やポテンシャル評価によって幅があり、一律の相場を示せるほど数がまとまっているわけではありません。大事なのは初年度の金額そのものより、テスト設計・自動化・マネジメントのどこに向かうキャリアかを、入社前にある程度描けているかどうかです。

Dさんの場合、入社時点でQAマネージャーを目指すか、SDETとして自動化に寄せるかまでは決めていませんでした。ただし「テスト設計を経験した上で選びたい」という順序だけは面接の段階から明確にしていて、これが8ヶ月でテスト自動化のPoCに呼ばれるという実績につながっています。キャリアパスの終着点を最初から決め打ちする必要はなく、設計を経験できる環境に身を置いておけば、選択肢は後から自然に増えていくというのが、Dさんを見ていて感じたことです。

未経験からQAエンジニアに向いている人・向いていない人

これまでの内容を踏まえると、未経験からQAエンジニアに向いているかどうかは、性格的な適性だけでなく「何を確認して入社したか」にも左右されます。ただし傾向として言えることはあります。

細かい手順を淡々とこなすことに苦を感じず、かつ「なぜこの手順になっているのか」を自分から確認したくなるタイプは、テスト実行の現場からでも設計側へ引き上げられやすい印象があります。逆に、決められた作業を早く正確にこなすこと自体にやりがいを感じるタイプであれば、テスト実行中心の現場でも不満なく働けるケースもあり、一概に「設計に関われないと不幸」というわけでもありません。

向いていないと感じるのは、開発チームに意見を伝えることへの抵抗が強い人です。QAエンジニアは仕様の矛盾やバグを指摘する役割上、開発者から歓迎されない場面もあります。ここで萎縮してしまうと、テスト設計まで任されても提案が形にならず、結局は「言われたことをやるだけ」の立ち位置に戻ってしまいます。

よくある質問

プログラミングスキルは必須ですか。 未経験入社の時点では必須ではありません。ただし将来的にSET・SDETのようなテスト自動化のキャリアを考えるなら、簡単なスクリプトが書ける程度のスキルはいずれ必要になります。入社後にテスト自動化ツールの操作を通じて身につける人が多く、最初から完璧である必要はありません。

文系出身でも活躍できますか。 できます。私が担当してきた未経験QAエンジニアも、文系学部出身や接客・販売職からの転職者が半数以上を占めます。テスト設計に必要なのは「仕様の抜け漏れに気づく観察力」や「利用者目線で考える想像力」で、これは理系の専門知識よりも前職での対人経験が活きる場面が多いというのが私の印象です。

AIによるテスト自動化が進むと、QAエンジニアの仕事はなくなりますか。 テスト実行の一部は今後も自動化が進みますが、「何をテストすべきか」を判断する設計工程は当面なくなりません。むしろ自動化ツールを使いこなしつつ、テストケースの妥当性を判断できる人材の需要は高まる方向にあると私は見ています。テスト実行専任のまま留まり続けることの方が、長期的にはリスクになり得ます。

まとめ、後悔するかどうかは「入社前にどこまで確認したか」で決まる

QAエンジニアの未経験転職が「きつい」と言われる理由は確かに存在しますが、その多くは職種そのものの宿命ではなく、テスト実行専任の現場に配属されるかどうかという配属の問題です。CさんとDさんの差は、能力でも運でもなく、求人票の文言と面接での質問の掘り下げ方にありました。

「未経験可」という言葉に安心して応募を決めるのではなく、テスト設計・品質計画といった言葉が求人票にどこまで具体的に書かれているか、面接で業務範囲の変化を時間軸込みで説明してもらえるかを、入社前に確認してください。それができるかどうかが、私がこれまで見てきた「後悔する人」と「後悔しない人」の、一番はっきりした分かれ目です。

面接で聞いた話の裏側を確認する手段の一つとして、転職会議で気になる企業の口コミを覗いてみるのも一つの選択肢です。