テスター・QAから開発職へ転職するには？経由ルートと職務経歴書例

この記事でわかることはこちらです。

• テスター・QAエンジニアから開発職へ進む経由ルート
• SESでテスト案件に固定されたときの、営業への相談方法
• 開発職への応募に使う職務経歴書の例文と求人の確認ポイント

「開発をやりたくて入社したのに、次の案件もテストだった」
「QAの経験はあるけど、開発経験がないと応募できないのかな」

今の仕事を続けながら、どうやって作る側へ移るのか。
そこが見えないと、勉強を始めても不安が残りますよね。

テスターやQAから開発職へ進む方法には、いくつか選択肢があります。
今の職場で担当を変える方法や、自動化の仕事を経由する方法などです。

僕は、今あるテスト経験と、これから補う開発経験を分けて考えると整理しやすいと思っています。
この記事では、案件変更の相談から応募先の確認まで、具体例を交えて書いていきます。

テスター・QAから開発へ進む前に、今の担当範囲を整理する

まずは、職種名よりも「自分が実際に担当した作業」を確認してみてください。
同じテスターやQAという名前でも、仕事の中身は職場によって違うからです。

QA（品質保証）は、製品の品質を保つための活動です。
テスト実行に加えて、仕様の確認や開発の進め方の改善を担当する職場もあります。

テストの仕事も、決められた手順を実行する作業だけではありません。
確認内容を考えるテスト設計や、不具合の分析、自動化などがあります。
こうした業務の広がりは、ISTQBのテスト基礎資格の公式案内でも確認できます。

開発職への転向を考えるときは、次のように経験を分けると整理しやすいです。

表の作業を全部経験している必要はありません。
担当していない作業まで、無理に広げて書かなくて大丈夫です。

一方で、テスト経験が長いだけで、開発経験として扱われるとは限りません。
テストで何ができるかと、コードで何を作れるか。
この両方を説明できるようにするのが、応募に向けた準備になります。

開発職へ進む方法は、社内異動・自動化・直接転職から考える

今の職場で担当を変えられるか、コードを書く仕事に近づけるかを確認しましょう。
それによって、どの進み方を選ぶかも変わります。

今の会社で開発業務に移る

社内に開発チームがあるなら、異動や担当変更を相談する方法があります。
今の仕事ぶりを知っている人に、学習内容や希望を見てもらえるのが特徴です。

ただ、「いつか開発をやりたいです」だけでは、具体的な話になりにくいですよね。
希望する仕事と、現時点でできることをセットで伝えてみてください。

たとえば、自作した機能を見せたうえで、既存機能の小さな修正に参加できるか相談します。
レビュー（書いたコードを他の人に確認してもらうこと）を受けられるかも聞いておきたいです。

開発部署があっても、未経験者を受け入れる枠があるとは限りません。
担当変更の条件と、次に相談する時期まで確認できると、待つ間の準備が決まります。

テスト自動化を経由して、コードを書く経験を積む

テスト自動化は、手作業で確認していた操作や判定をプログラムに任せることです。
今の業務でコードを書く機会を作れるなら、経由ルートとして検討できます。

たとえば、ログイン画面の確認を自動化する場合。
入力する値や期待する結果を決め、失敗した理由を調べてコードを直します。
テストで身につけた確認の観点を、プログラムに落とし込む作業ですね。

ブラウザー操作を自動化するツールには、Playwrightがあります。
公式ドキュメントでは、Webアプリの動作を確認するための機能が紹介されています。
Webアプリは、ブラウザーから利用するアプリのことです。

ここで、自分でコードを作成・修正する担当かどうかも確認してください。
テストコードは、確認する操作や判定を書いたプログラムです。
自動テストを起動して結果を見る担当と、コードを作る担当では経験が変わります。

自動化を担当した後も、製品の機能を作る経験は別に補っていきましょう。
自動化の経験が増えても、開発職へ移る仕組みがない職場では、担当が変わらない可能性があります。

成果物を用意して、開発職に直接応募する

社内で担当変更が難しい場合は、開発職への応募も選択肢です。
その場合、実務で担当したことと、自主学習で作ったものを分けて伝えます。

応募先は、「開発の実務経験が必須」か「実務未経験でも応募可能」かを確認してください。
後者でも、求められる学習内容や、入社後に任される仕事は会社ごとに違います。

成果物は、採用担当者がコードや工夫を確認する材料になります。
ただし、作ったものがあれば採用される、と約束できるものではありません。
求人の条件と照らして、足りない経験を確認しながら応募先を選びましょう。

SESでテスト案件に固定されたときは、次の担当と相談期限を具体化する

SES（技術者の業務支援を提供するサービス）で働いているなら、営業との相談も必要です。
希望する業務を伝え、今の契約や案件の区切りで変更できるか確認します。

「テストをやめたい」だけで話が終わると、次の案件を選ぶ条件が曖昧になります。
開発を希望する理由と、次に担当したい作業まで伝えるほうが相談しやすいですよ。

営業には、学習内容と希望する作業を伝える

相談するときは、たとえばこんな伝え方ができます。
次の文面は架空の例なので、学習内容や時期は自分の状況に置き換えてください。

次の案件では、プログラムの作成・修正を含む業務を希望しています。
現在はJavaを学び、登録したデータを編集できる小さなアプリを作っています。
開発補助や、テストコードの作成を担当できる案件があるか確認したいです。
次の契約更新前に、候補と必要なスキルを相談できますか。

「開発補助」という言葉を使う場合も、どの作業を指すか確認が必要です。
資料の更新が中心なのか、コードを直す仕事なのかで、積める経験が変わります。

営業から追加の学習を求められたら、何を作れば候補案件に近づくのか聞いてみましょう。
「もっと勉強しておいて」で終わらせず、具体的な課題にすると取り組みやすくなります。

「次は開発」の話は、案件の中身まで確認する

案件の名前だけで判断せず、担当予定の作業を確認してください。
可能な範囲で、次の内容を聞いておきたいです。

• 自分がコードを作成・修正する予定はあるか
• 最初の担当業務と、その後の担当変更の条件は何か
• 使用する言語と、教えてもらえる相手は誰か
• 案件が決まらなかった場合、いつ方針を相談し直すか

「最初はテスト、その後に開発」と言われた場合も同じです。
開発へ移る条件や過去の配属例を聞くと、準備する内容が見えてきます。

口頭で相談した内容は、日付を添えてメールなどに残しておくと確認しやすいですよ。
担当者が変わったときにも、相談の経緯を共有できます。

担当変更の見通しが立たなければ、外の求人とも比べる

希望を伝えても、会社が持っている案件に合う仕事がなければ変更は難しくなります。
その場合は、学習を続けながら他社の求人も確認してみてください。

僕なら、次に会社へ相談する時期を決めつつ、外の募集条件も見てみます。
社内で必要と言われたスキルが、応募先でも求められているか比較できるからです。

相談するたびに時期が延びるなら、延期の理由と次の判断日を確認しましょう。
案件候補がないのか、スキルが足りないのかで、次に取る行動が変わります。

学習は、応募したい仕事に合わせて小さな機能を作る

学習する言語は、応募したい求人や、社内で使っている言語を見て選びましょう。
最初からいくつも学ぶより、一つの言語で機能を作ってみるほうが進めやすいです。

テスト経験を活かせる題材で、機能を実装する

作るものの例として、不具合を記録する小さなアプリがあります。
普段の仕事に近いので、必要な項目や操作を考えやすいですよね。

まずは、次のような機能から作れます。

• 不具合のタイトルと発生手順を登録する
• 対応状況を変更し、一覧で確認する
• 必須項目が空欄なら、入力を促す表示を出す
• 登録した内容を保存し、開き直しても確認できるようにする

最初から全部を完成させなくても大丈夫です。
登録する機能を作ったら、空欄や長い文字列を入力して、想定した動きになるか確かめます。

ここで、テスターとしての確認の習慣が使えます。
動かない条件を見つけたら、コードを修正し、ほかの操作に影響がないか確認しましょう。

コードと一緒に、作った理由と直した点を残す

成果物を見せるときは、使い方や工夫も添えておきたいです。
面接で説明する材料を、作業中に少しずつ残す感覚ですね。

Git（ファイルの変更履歴を管理する仕組み）を使うと、変更の経緯を記録できます。
変更前の状態を確認できる仕組みは、Gitの公式解説でも説明されています。

GitHub（コードを保存・共有できるサービス）に成果物を置くなら、説明も一緒に用意しましょう。
README（プロジェクトの説明ファイル）には、次の内容があると見てもらいやすいです。

• 何のために作ったかと、実装した機能
• 動かす手順と、動作を確認した環境
• 工夫した点、不具合を直した経緯、まだ対応していない点

教材を参考にした場合は、参考元と自分で変更した範囲も書いておきましょう。
会社や顧客のコード・データを持ち出さず、自作の題材や架空のデータを使ってください。

テスト経験は、対象・判断・共有内容まで説明する

職務経歴書を書く前に、普段の仕事を少し細かく思い出してみましょう。
「テストを実施した」だけだと、対象や担当範囲が伝わりにくいからです。

たとえば、画面の動作確認でも、入力内容を変えたのか、手順書どおりに実行したのか。
不具合を見つけた後、自分で発生条件を調べたのか、担当者に引き継いだのか。
その違いを書くと、自分の仕事を説明しやすくなります。

手順書どおりの作業が中心でも、対象と記録方法は書けます。
調査や設計を担当していなければ、その範囲は分けて記載してください。

成果の数字は、記録で確認できるものを使いましょう。
件数や改善率がわからなくても、担当作業と役割を具体的に書くことはできます。

開発職への応募に使う職務経歴書の例文

職務経歴書では、実務経験と自主学習を分けて書くのがおすすめです。
テストの仕事で経験したことと、個人で実装したことの両方を確認してもらえます。

以下は書き方を示すための架空の例文です。
自分が実際に担当・作成した内容に置き換えて使ってください。

実務経験の記載例：テスト実行・不具合報告が中心の場合

Web予約システムの予約登録・変更画面で、手順書に沿った動作確認を担当しました。
確認結果と画面の画像を記録し、期待した結果と異なる動作を報告しました。
不具合報告には、発生時の入力内容と操作手順を記載しました。
原因調査とプログラム修正は、開発担当者が実施しました。

この例では、実行・記録・報告が本人の担当範囲です。
開発者が担当した修正まで、自分の実績に含めないようにしましょう。

SQL（保存されたデータを検索・更新するための言語）を使ったなら、その用途も足せます。
たとえば、登録結果の確認に使ったのか、テストデータの作成に使ったのかを書き分けます。

実務経験の記載例：自動化のコードを担当した場合

既存の自動テストで、予約画面の入力欄変更に伴うテストコードの修正を担当しました。
変更対象を確認し、修正後は関連する予約操作も実行して結果を確かめました。
修正内容は開発担当者のレビューを受け、指摘箇所を反映しました。

既存コードの修正を担当した例なので、「自動化の仕組みを新規開発」とは書きません。
ツール名や使用言語、レビューを受けた範囲も、実際の経験に合わせて記載してください。

自主学習の記載例：自作アプリで開発の準備を伝える

個人学習で、不具合情報を登録・編集できるWebアプリを作成しました。
Javaを使用し、入力内容の確認とデータの保存処理を実装しました。
必須項目の空欄や、保存後の再表示を確認し、見つかった不具合を修正しました。
コードと動かす手順は、GitHubに掲載しています。

掲載していなければ、最後の文は変更してください。
説明できるようにしておきたいのは、「どこを自分で考え、どこで困ったか」です。

面接での転向理由も、今までの仕事と結びつけると伝えやすくなります。
次の例も、自分の動機に合う部分がある場合の参考にしてください。

テストで仕様と実際の動作を確認する中で、機能を作る仕事にも関わりたいと考えました。
現在は個人開発で、機能の実装と不具合修正を学んでいます。
テスト経験で身につけた確認の習慣を活かしながら、開発の実務経験を積みたいです。

求人は「開発エンジニア」の名前より、入社後の担当業務を確認する

応募先では、入社後にどの作業を担当する予定か確認しましょう。
求人の職種名だけでは、最初の配属や担当範囲までわからないことがあります。

求人票で確認したいこと

応募前は、次の項目を見てみてください。

• 開発経験の必須条件と、実務未経験者の応募条件
• 担当業務に、コードの作成・修正が含まれているか
• 使用言語や、扱うシステムの種類
• 研修後の配属例と、配属先を決める方法
• コードを確認・指導してくれる体制

「研修あり」と書かれていても、研修内容と配属先は別に確認したいです。
研修でプログラミングを学んでも、その後の仕事がテスト実行中心になる可能性はあります。

面接では、最初の作業と担当変更の条件を聞く

面接では、たとえば次のように質問できます。

テスト経験はありますが、開発の実務経験はありません。
同じような経歴で入社した方は、最初にどのような作業を担当しましたか。
プログラムの作成・修正に参加するまでの条件も教えていただけますか。

答えが曖昧な場合は、配属が決まる時期や、まだ確定していない事項を確認します。

テスト業務を経験してから開発へ移る配属を提示されたら、移る条件も聞いておきましょう。
過去の事例があっても、自分の配属が同じになるかは別に確認が必要です。

転向までの期間・年収・つまずきやすい点

転向を考えると、学習期間や収入も気になりますよね。
ここは一律の数字で決めず、今の経験と応募先の条件を分けて見ていきましょう。

何か月勉強すれば、開発職に移れる？

必要な期間は、今の経験、学習時間、応募先によって変わります。
「半年で必ず転向できる」といった期限は決められません。

準備の区切りには、次のような状態を使ってみてください。

• 小さな機能を自分で作り、動作を確認できる
• 不具合の原因を調べて修正し、変更理由を説明できる
• 実務経験と自主学習を分けて職務経歴書に書ける
• 応募したい求人の必須条件を確認している

コードを読む経験がある人と、初めて書く人では出発点が違います。
応募先から確認された内容を踏まえて、次の学習課題を決める方法もあります。

開発職に移れば、年収は上がる？

開発職へ転向しても、年収が上がるとは限りません。
テストの実務経験があっても、開発の経験はこれから積む人として採用される場合があります。

提示された条件は、基本給や賞与、残業代の扱いまで確認してください。
固定残業代（一定時間分の残業代をあらかじめ含める仕組み）があるなら、その時間数も見ます。

収入の条件と一緒に、担当業務や指導体制も比べましょう。
希望する経験を積めるかまで確認して、生活を続けられる条件を考えたいですね。

自動化や勉強を続けても、開発へ近づいている感じがしない

その場合は、今やっている作業と、目指す求人の条件を照らし合わせてみてください。
たとえば、自動テストの実行だけが増えているなら、コードを修正する機会を相談できます。

教材を写す学習が続いているなら、小さな仕様変更を自分で加えてみましょう。
入力欄を一つ追加するだけでも、保存処理や確認する内容が変わります。

学習量を増やす前に、「次にどの作業ができるようになりたいか」を決める。
そのほうが、営業への相談や応募先の選び方にもつなげやすいと思っています。

おわりに

テスター・QAから開発職への転向を考えるなら、今の担当作業を書き出してみてください。
コードを書く機会が職場にあるかを確認すると、社内異動や自動化を経由する道も検討できます。

SESで案件変更を相談するなら、次に担当したい作業と、相談し直す時期まで伝えましょう。
転職先でも、最初に任される仕事を確認しておくと、希望との違いに気づきやすくなります。

全部を一度に進めなくても大丈夫です。
僕なら、今週は担当作業を整理して、気になる求人を一つ読んでみます。
その条件と今の経験を比べ、足りない部分から一つずつ準備していきましょう。