テストから開発へ移る|第二新卒が現職で作れる材料と順番【2026年版】
〜「このままテストだけで終わるのでは」と感じ始めた人へ〜
未経験からIT業界に入った人の多くが、最初にテストや検証の仕事を担当します。入口としては合理的で、ここで製品の全体像と品質の考え方を覚えます。
ただし、1年、2年と経つうちに、「このまま開発側に移れるのだろうか」という不安が出てきます。実際、テストの仕事を長く続けても自動的に開発へ移れるわけではありません。
移れる人と、移れないまま数年経つ人の差は、能力ではなく「意識的に材料を作ったかどうか」です。
この記事では、現職で作れる材料と、移り方の順番を整理します。
1. 結論:押さえるべきは3点
テストから開発へ移るときの3つの前提
① 年数だけでは移れない(材料を意識的に作る必要がある)
② 最も効く材料は「テストを自動化した経験」
③ 社内異動のほうが早い場合がある(転職より先に検討する)
②が核心です。手作業でテストを実行し続けた経験は、開発職の書類ではあまり評価されません。
一方で、「同じテストをコードで自動化した」という経験は、そのまま開発の実績になります。作ったのがテストコードであっても、コードを書いて動かした事実は変わりません。
2. 移れる人と移れない人の差
| 移れる人 | 移れないまま経つ人 | |
|---|---|---|
| テストの実行 | 手順を疑い、改善する | 指示どおりに実行する |
| コード | 自動化に手を出している | 触っていない |
| 不具合の報告 | 原因の見当まで書く | 現象だけ書く |
| 開発チームとの関係 | 仕様の背景を聞きに行く | 依頼されたものだけ受ける |
| 学習 | 業務外で継続している | していない |
「不具合の報告に原因の見当まで書く」は、今日から始められて、最も効く行動です。
「この画面でエラーが出る」だけの報告と、「この条件のときだけ発生し、ログにこの記録が残っているので、この処理が関係している可能性がある」という報告では、書き手の理解度がまったく違って見えます。
そしてこれは、開発チームからの信頼にも直結します。社内異動の話が来るかどうかも、ここで決まります。
3. 現職で作れる4つの材料
今の職場で作れるもの
① テストの自動化(規模は小さくてよい)
② 原因の切り分けまで書いた不具合報告
③ テスト設計への関与(実行だけでなく、何を試すかを考える)
④ 手作業の削減(集計、環境の準備、データの作成)
④は見落とされがちですが、開発職の面接で使えます。
テストの前後には、データを用意する、結果をまとめる、環境を初期化するといった作業が必ずあります。ここをスクリプトで置き換えた経験は、立派な「コードを書いて課題を解いた」実績です。
考え方は運用保守から開発へ移る|第二新卒が現職で作れる材料と移り方の順番と共通しています。
自動化を始める順番
いきなり全体を自動化しようとすると挫折します。
小さく始める順番
・毎回同じ手順で作っているテストデータを作るスクリプト
・結果の集計を自動でまとめる処理
・繰り返し実行する確認のうち、一つだけを自動化
・そこから対象を増やす
最初の一つは、30分の作業を5分にする程度で十分です。面接で問われるのは規模ではなく、何に気づいて、どう手を入れたかです。
4. 話を聞いた例:2年目で異動した人
知人に、テスト担当から社内で開発チームへ異動した人がいます。
その人がやっていたのは、次のことでした。
異動までの1年でやったこと
・テストデータの作成を、手作業からスクリプトに置き換えた
・不具合の報告に、ログの該当箇所と推測を添えるようにした
・仕様が分からないとき、開発担当に直接聞きに行くようにした
・業務外でプログラミングの学習を続けた
異動のきっかけは、開発チーム側からの声かけだったそうです。
「報告の内容が具体的で、話が早い」という理由でした。本人が異動を希望していると伝えたのは、その後です。
ここで重要なのは、順番です。「異動させてほしい」と先に言うより、開発チームから見て一緒に働きたい人になっているほうが、話が通ります。
社内異動の仕組みは社内公募の使い方|辞めずに職種を変える手順にまとめています。
5. 社内異動と転職、どちらを先に検討するか
| 社内異動 | 転職 | |
|---|---|---|
| 必要な材料 | 日々の仕事ぶり | 書類で示せる実績 |
| 年収 | 大きくは変わらないことが多い | 変動する |
| 環境 | 既知 | 未知 |
| 難易度 | 制度と枠があれば現実的 | 未経験扱いになる場合がある |
| 時期 | 制度の時期に依存 | 自分で決められる |
制度がある会社なら、社内異動を先に検討する価値があります。
理由は、テストから開発への転職では「開発未経験」として扱われる場合があり、年収が下がる可能性があるためです。社内で移れるなら、その負担を避けられます。
一方で、会社に開発部門がない、または異動の実績がない場合は、転職が現実的な選択になります。
6. 学習の順番
推奨する順番
① 業務で使われている言語から始める(周りに聞ける人がいる)
② テストコードを書く(業務と直結し、成果になる)
③ 小さいものを一つ作る(動くところまで)
④ バージョン管理の使い方を覚える
⑤ コードレビューを受ける機会を作る
①が最も効率的です。業務で使われている言語なら、詰まったときに聞ける相手がいます。
②は、学習と業務が同時に進む数少ない方法です。テストコードは開発の一部であり、書いた経験はそのまま実績になります。
言語選びの全体像は最初に学ぶプログラミング言語の選び方|第二新卒が目的別に決める順番、学習時間は働きながら学習時間を作る|平日30分の設計を参照してください。
7. 職務経歴書での書き方
テストの経験を、開発職向けにどう書くかが分かれ目です。
| 弱い書き方 | 強い書き方 |
|---|---|
| テストを実施した | 何件のうち何件を自動化した |
| 不具合を報告した | 原因の切り分けまで行い、修正の方向を提案した |
| 仕様書を確認した | 仕様の矛盾を指摘し、確認して修正につなげた |
| テストデータを作成した | 作成をスクリプト化し、作業時間を短縮した |
左側は「言われたことをやった」、右側は「考えて手を入れた」と読めます。
同じ業務でも、書き方でここまで印象が変わります。嘘を書く必要はありません。実際にやったことのうち、考えて動いた部分を拾い上げてください。
書類の作り方はエンジニアの職務経歴書|書く順番と3つの必須欄、翻訳の手順は未経験職種の自己PR|第二新卒が経験を翻訳する3手順と例文7パターンにまとめています。
8. 面接で聞かれることと答え方
| 質問 | 見られていること | 答え方の軸 |
|---|---|---|
| なぜ開発へ移りたいか | 動機の具体性 | テストで感じた限界から話す |
| コードを書いた経験は | 実際の水準 | 自動化した内容を具体的に |
| テストの経験は活きるか | 自己認識 | 品質の視点として説明する |
| 何を学んでいるか | 継続性 | 期間と教材を具体的に |
| 年収が下がる可能性は | 覚悟の確認 | 理解していることを示す |
「テストに飽きたから」は避けたい回答です。
代わりに、「不具合の原因を追ううちに、直す側に関心が移った」という形にします。テストの経験を否定せず、そこから続いている話にするのが自然です。
また、「テストの経験は開発でも活きる」というのは事実です。壊れ方を知っている人が書くコードは、そうでない人のものとは違います。ここは自信を持って主張して構いません。
9. よくある質問
何年目で動くのがいいですか
年数より材料です。自動化を一つ作った時点で、動く材料は揃います。1年目でも2年目でも構いません。
QAエンジニアとして深めるのは違いますか
違いません。品質保証を専門として深めるのも、確立したキャリアです。自動化を進めていくと、開発とQAの境目は薄くなります。QA側の情報はQAエンジニアの面接で聞かれる12問|第二新卒が未経験から通る答え方を参照してください。
手動テストしかやっていません
今日から自動化の対象を探してください。テストそのものでなくても、データ作成や結果の集計から始められます。
年収は下がりますか
転職の場合、開発未経験として扱われると下がる可能性があります。社内異動なら影響は小さくなります。考え方は未経験エンジニアの年収|第二新卒が下がる幅と戻るまでの期間にまとめています。
常駐先でテストをしています
案件によって触れる範囲が変わるため、自動化に手を出せるかは配属先に依存します。難しい場合は、業務外での学習と、次の案件の希望を出すことから始めてください。構造はSESから抜けるための準備|案件を経歴に変える3ステップにまとめています。
ポートフォリオは必要ですか
あると有利ですが、業務で自動化した経験があるなら、そちらのほうが強い材料です。考え方は未経験エンジニアのポートフォリオ|第二新卒が評価されるのは「何を作ったか」ではないを参照してください。
上司に希望を伝えるべきですか
伝える価値はあります。ただし、材料を作ってから伝えるほうが話が進みます。順番を意識してください。
テストの経験は書類でマイナスになりますか
なりません。むしろ「品質の視点を持っている」という強みとして書けます。書き方次第です。
10. まとめ:今週やる3つのこと
テストから開発へは、意識的に材料を作れば移れる道です。年数を重ねるだけでは移れません。
今週やる3つのこと
① 毎回同じ手順でやっている作業を1つ見つける
② それをスクリプトにできないか調べる
③ 次の不具合報告に、原因の見当を1行足す
③は今日からできて、開発チームからの見られ方が変わります。異動の話は、そういうところから来ます。
この先、読むべき記事
- 運用保守から開発へ移る|第二新卒が現職で作れる材料と移り方の順番(同じ構造の移り方)
- 社内公募の使い方|辞めずに職種を変える手順(社内異動という選択)
- QAエンジニアの面接で聞かれる12問|第二新卒が未経験から通る答え方(QAとして深める道)
- エンジニアの職務経歴書|書く順番と3つの必須欄(書類での見せ方)
- 最初に学ぶプログラミング言語の選び方|第二新卒が目的別に決める順番(学習言語の決め方)
- テスト自動化へ進む|第二新卒が手動テストから移る順番(自動化という進み方)
この記事を書いた人
木戸 悠介(きど ゆうすけ)/なぜキャリア?運営者。1996年生まれ、神戸市出身。
23歳で上場企業子会社に新卒入社し、メディア広告営業を担当。25歳で第二新卒として障がい福祉領域のSaaS企業へ転職し、営業から営業企画へ職種を変えた。2ヶ月で10社に応募し2社から内定。その後スタートアップに3人目の社員として参画し、現在は自分の会社を経営している。