SESでテストしかしてない人の転職先5つ｜開発・QAへ進む90日計画

「テストしかしていない」を、品質の五段階へ分ける

最初に経験を「テスト実行」「テスト設計」「不具合分析」「品質の可視化」「予防・改善」の五段階へ分けます。テスト実行では、誰かが作った手順と期待結果に沿って操作し、証跡を残した範囲。テスト設計では、要求、仕様、変更差分、利用者、障害リスクから条件と組合せを作った範囲です。一つの案件で複数段階を担当していても、最終判断者と自分の責任を分けます。

実行経験にも説明できる事実があります。対象機能、テストレベル、環境、データ準備、前提条件、結果判定、証跡、不具合票、再テストを並べます。手順どおりに進まない時、環境かデータか製品かをどの順で確認したか。期待結果が曖昧な時、誰へ何を確認したか。件数だけでなく、正しい判定を支えた行動を残してください。

テスト設計では、正常系だけでなく境界値、異常系、権限、状態遷移、並行処理、外部連携、日付、性能、復旧など、どのリスクから観点を作ったかを示します。設計書をゼロから作っていなくても、既存項目の不足を提案した、仕様変更に合わせて影響範囲を直した、レビュー指摘を観点表へ反映した経験は分けて書けます。

不具合分析では、再現条件、発生頻度、入力データ、ログ、通信、DB、画面、環境差分を確認し、原因候補を要求・設計・実装・データ・環境へ絞った範囲を整理します。原因を修正した開発者の成果を自分の成果にはしません。一方、再現手順と影響範囲を整え、修正判断を早めた事実は品質への寄与として説明できます。

品質の可視化と予防では、合否数を報告するだけでなく、機能別の不具合傾向、未実施のリスク、修正後の再発、仕様の曖昧さを関係者へ戻したかを見ます。レビュー観点の更新、テンプレート、テストデータ、確認順、自動化候補を残したなら再現性のある改善です。測っていない削減率や品質向上率は作らず、実際に変えた手順と利用者を示します。

• 実行: 前提・操作・期待結果・証跡・再テスト
• 設計: 要求・変更・品質リスクから観点を作る
• 分析: 再現条件・影響・原因候補を切り分ける
• 可視化: 不具合傾向・残存リスク・未確認を共有する
• 予防: レビュー・手順・データ・自動化へ戻す

転職先5つを、テストを捨てるかではなく次の責任で比べる

一つ目は、QA・テストエンジニアです。テスト計画、分析、設計、実行管理、不具合分析、品質報告などへ範囲を広げます。「テスター」という職名でも実行中心の場合があり、「QAエンジニア」でも開発チーム内の品質改善を持つ場合があります。求人ではテストレベル、成果物、レビュー、品質判断、開発との分担を確認します。

二つ目は、テスト自動化エンジニア、SET、品質基盤の担当です。ブラウザ操作を自動化するだけでなく、自動化対象の選定、テスト容易性、実行環境、データ、失敗分析、保守、CIへの組込みまでが仕事になり得ます。ツール名だけで応募せず、何をコードとして管理し、誰がレビューし、開発コードへどこまで関わるかを聞きます。

三つ目は、アプリケーション開発エンジニアです。テストで得た仕様理解、境界値、不具合再現、影響範囲の経験を、設計・実装・単体テストへつなげます。ただし、テスト経験だけを開発実務として扱うことはできません。現職の改修補佐、小さなツール、レビュー付きの実装など、コードを変更して結果を検証した実務を一段ずつ作ります。

四つ目は、社内SE・情報システム部門で受入と品質を持つ道です。利用部門の要求整理、ベンダーが納品したシステムの受入、移行、問い合わせ、障害、改善まで一続きで関わる求人があります。客先常駐を離れられるかだけで選ばず、内製と外注、受入基準、利用者対応、障害当番、ベンダーへの指示、入社90日の仕事を確認します。

五つ目は、品質管理、テストリーダー、PMO、リリース管理です。複数チームの計画、進捗、欠陥傾向、変更、リリース可否の判断材料を整える役割です。会議や集計だけの仕事と、品質リスクを分析して工程を改善する仕事は違います。管理職名を急がず、何の判断を支え、どの成果物を持ち、技術的な分析をどこまで行うかを確認してください。

• QA・テスト: 計画・設計・分析・品質報告を持つ
• テスト自動化: コード・実行基盤・保守まで持つ
• 開発: 仕様理解を設計・実装・単体テストへつなぐ
• 社内SE・受入: 利用部門とベンダーの間で品質を持つ
• 品質管理・PMO: 複数工程のリスクと判断材料を持つ

90日で、現職の隣にある責任を一つ増やす

最初の30日は、直近三案件を五段階へ棚卸しします。使用技術より先に、受け取った要求・仕様、作ったテストデータ、追加した観点、起票した不具合、調べたログ、関係者へ戻した情報を並べます。「担当していない」「判断者を知らない」欄も残すと、次に作る経験を選びやすくなります。顧客名、画面、内部データ、障害詳細は持ち出しません。

31〜60日は、現在の作業に接する成果物を一つ選びます。実行だけなら仕様差分から追加観点を三つ作ってレビューを依頼する。設計までなら不具合を原因候補と影響範囲へ分類する。分析までなら再発しやすい観点をチェックリストへ戻す。成果物、レビュー担当、期限を決め、口頭の「今後任せる」を経験として数えません。

開発へ進みたい場合は、現職で小さな改修、テストデータ生成、ログ確認ツール、テスト容易性の改善など、レビュー付きでコードを扱える範囲を相談します。機密情報を個人環境へコピーせず、会社の開発・AI利用・ソースコード管理ルールを守ります。担当できない場合は、公開してよい自作題材で学習できますが、自己学習と本番実務を職務経歴書で分けます。

自動化へ進みたい場合は、繰り返しが多いという理由だけで対象を決めません。仕様が安定しているか、失敗時に原因を判断できるか、テストデータを再現できるか、実行時間と保守負担が見合うかを整理します。小さな候補を手動結果と照合し、誤検知・見逃し・保守の記録を残すと、ツール操作ではなく品質判断として説明できます。

61〜90日は、現職で次の担当と開始日を確認し、同時に求人十件を同じ表で読みます。現職でレビュー付きの設計・実装・分析を増やせるなら、期限を決めて残る選択があります。案件構造上ずっと実行だけで、担当変更の条件もないなら、転職で変える必要が具体化します。応募、内定承諾、退職は別の日に判断してください。

• 1〜30日: 三案件を実行・設計・分析・可視化・予防へ分ける
• 31〜60日: 隣の成果物を一つ作り、レビューを受ける
• 開発志望: 小さな実装とテストをレビュー付きで持つ
• 自動化志望: 対象・判定・データ・保守まで検証する
• 61〜90日: 現職の計画と求人十件を同じ表で比べる

職務経歴書は、件数ではなく品質判断の流れを書く

職務経歴書へ「テストを担当」「一日百件を実施」とだけ書いても、速さ以外の強みが伝わりません。一案件ごとに、システム用途、チーム、自分の役割、テスト対象、レベル、入力資料、設計した観点、実行・分析の範囲、成果物、結果を書きます。件数を出すなら、期間、対象、数え方を説明できる場合だけにします。

実行中心の経験は、判定の正しさを支えた事実へ変えます。たとえば仕様書と画面の差分を発見し、判断者へ確認して期待結果を更新した。テストデータの前提が案件ごとに違ったため、準備条件と確認手順を一覧化した。不具合の再現に必要な入力、権限、時刻、環境をそろえた、といった行動です。作業を大きく見せず、判断の入口と出口を書きます。

設計経験は、テスト項目数より品質リスクとの接続を示します。「境界値を追加」だけでなく、金額上限、日付跨ぎ、権限差、状態遷移など、どの仕様と利用リスクから追加したかを書きます。レビューで採用されなかった提案も、提案と最終判断を分ければ説明できます。チーム全体のテスト設計を自分一人の成果にしません。

不具合は発見数を競わず、再現、重要度、影響、原因候補、修正確認の流れを書きます。重要度や優先度を自分が決めていないなら、判断材料を整理して担当者へ渡した範囲にとどめます。修正後は対象機能だけでなく、類似箇所や回帰範囲をどう決めたかを出すと、局所的な確認から品質全体への視点を示せます。

応募先で並び順を変えます。QA求人なら計画・設計・分析、テスト自動化なら対象選定・コード・実行・保守、開発なら仕様調査・影響範囲・小さな実装、社内SEなら利用部門・受入・ベンダー協働を前へ出します。経験の事実は変えず、未経験の工程を正直に書き、補佐から持てる次の責任を添えます。

• 入口: 要求・仕様・変更差分・品質リスク
• 判断: 追加観点・再現条件・影響範囲・原因候補
• 成果物: 観点表・項目書・不具合票・品質報告・改善手順
• 境界: 自分・設計者・開発者・責任者の担当を分ける
• 結果: 根拠のある数字か、確認できる手順変化だけを書く

求人票と面接で、入社後の仕事を7項目まで確定する

一問目は、入社後30・60・90日に担当する製品、工程、成果物です。「QA募集」「開発へ挑戦」と書かれていても、最初の配属がテスト実行だけで固定される場合があります。テスト計画、設計、実行、分析、自動化、開発の時間割合と、誰が配属を決め、希望外の時にどう見直すかを聞きます。

二問目は、品質要求とテストレベルです。単体、結合、システム、受入、探索的テスト、性能、セキュリティのうち何を持つか。要求・設計レビューへ入れるか。合否とリリース可否の最終判断者は誰か。項目を実施するだけか、品質リスクを定義して結果を説明するかを区別します。

三問目は、開発との分担とレビューです。QAが開発チームへ常時参加するのか、別会社・別部署から検証するのか。コード、設計、テストコード、バグ票を誰がレビューするのか。開発職を希望するなら、実装へ移った事例だけでなく、移る条件、評価、時期、空きポジションを確認します。事例は自分への保証ではありません。

四問目は、自動化の実態です。使用ツールだけでなく、対象を選ぶ人、コード管理、CI、テストデータ、環境、失敗分析、保守時間、品質指標を聞きます。自動化率が高くても、既存スクリプトの実行だけなら責任は広がらない場合があります。逆に手動テストでも探索・リスク分析を持つ求人はあります。

五問目は、チームと案件の継続性。六問目は、評価と次の役割。七問目は、給与と労働条件です。チーム人数、客先常駐・持ち帰り・自社の別、契約終了時の配属、待機、教育、評価日、基本給、固定残業、賞与、試用期間、業務・就業場所の変更範囲を書面で照合します。希望職名より、次に残る成果物と責任を優先してください。

• 入社30・60・90日の工程・成果物・配属決定者
• 品質要求・テストレベル・リリース判断の責任
• 開発との分担・レビュー・職種変更の条件
• 自動化対象・コード管理・CI・データ・保守時間
• チーム人数・常駐形態・案件終了後・待機条件
• 評価する品質成果・次の役割・見直し時期
• 給与内訳・試用期間・業務と就業場所の変更範囲

相談先は、対象条件と探す求人の違いで二社まで選ぶ

TechGoは、確認した主な利用条件では主に実務経験二年以上のITエンジニアが対象の目安です。テスト実行だけの在籍年数を開発経験へ置き換えず、テスト設計、不具合分析、自動化、実装など現在の証拠で紹介可能な求人を確認します。QA、開発、ITコンサルなど希望ごとに、選定理由と不足条件を具体化できるかを比べる候補です。

STRATEGY CAREERは、確認した主な利用条件ではエンジニア経験者、主に20〜30代、東京・大阪エリアでの就職希望が対象の目安です。公式ページにはQAからDevOpsへ進んだ一つの掲載事例がありますが、選ばれた事例であり、同じ転職や年収を保証しません。現在の経歴でどの求人があり、何が評価され、何が不足するかを個別に確認します。

社内SE転職ナビは、テスト経験を、利用部門の要求、ベンダー成果物の受入、移行、問い合わせ、運用改善へつなぐ求人を探す候補です。社内SEという職名だけで受入・品質を持てるとは限りません。内製と外注、受入基準、利用者対応、障害当番、入社90日の仕事を確認し、対象年齢・地域・面談期限にも合う場合だけ検討します。

TechClipsエージェントは、ITエンジニア経験を使い、自社サービス企業を含むQA・品質・開発の求人を比較したい人の候補です。公開求人や自社開発の案内を、自分への紹介件数や配属保証へ置き換えません。製品チームとの距離、公開後の品質改善、テストコード、レビュー、現在紹介可能な求人を面談で確かめます。

比較中の全社へ申し込む必要はありません。年齢、実務経験、勤務地、転職時期が対象に合い、求人紹介を実際に利用したい候補を二社まで選びます。同じ版の職務経歴書と七問を渡し、紹介数ではなく、求人を選んだ理由、評価された案件事実、不足条件、未確認事項、応募前の同意手順を比較します。合わない求人へ応募・承諾する必要はありません。

• 今のテスト経験で紹介可能な職種と、選定理由は何か
• 評価された品質判断と、不足する実務経験は何か
• 入社90日の工程・成果物・レビュー担当は誰か
• QA・自動化・開発・受入のどこを任されるか
• 職種変更・配属・案件終了後の条件は何か
• 企業ごとの応募前に本人確認を取るか
• 給与内訳・評価・業務と勤務地の変更範囲は何か

応募・内定・退職を分け、次に残る成果物で決める

面談後24時間以内に、紹介求人、選定理由、評価された経験、不足条件、未回答項目、次の連絡日を記録します。担当者が話しやすいかだけで決めず、現在のテスト経験を誇張せず理解し、次の責任へつながる求人を説明できたかを見ます。求人がゼロでも、対象外の理由が具体的なら市場確認の結果になります。

応募前には、企業名、職種、勤務地、給与レンジ、担当工程、送付する職務経歴書の版、推薦文を確認します。相談したことと企業へ応募したことは別です。重複応募を避け、本人の個別同意なしに情報を送らない手順を確かめます。応募後も面接で判明した差分を求人表へ追記してください。

内定時は、QAや開発という職名より、入社後の成果物を確認します。テスト観点、品質報告、テストコード、製品コード、受入基準のどれを持つか。誰がレビューし、何か月後に範囲を見直すか。口頭の「将来は開発もできる」を条件書と同じ確約として扱わず、不確実な項目として比較します。

給与は年収の最大値だけでなく、基本給、固定残業、賞与、手当、試用期間、評価日を現職と同じ表へ入れます。品質責任や開発範囲が増えても、長時間労働、頻繁な勤務地変更、待機条件が生活に合わない場合があります。求人票、面接回答、最終条件の差分を確認してから承諾します。

転職しない結論も失敗ではありません。現職でテスト設計、分析、自動化、実装補佐を始める担当者と期限が決まり、求人より早く証拠を作れるなら残る選択があります。一方、心身へ影響がある、ハラスメントや安全上の問題がある場合は、90日計画より休息、医療、社内外の相談窓口を優先してください。

• 面談: 選定理由・評価事実・不足・未回答を記録する
• 応募: 企業・求人・送付書類・推薦文へ個別に同意する
• 内定: 成果物・レビュー・見直し時期を書面で確かめる
• 条件: 給与内訳・働き方・変更範囲を現職と比べる
• 退職: 入社条件が揃ってから別の判断として決める

職務経歴書の変換例

「テストしかしていない」という自己評価を、入力資料、品質リスク、判断、成果物、開発との境界、未経験、次に増やす責任へ置き換えます。

行動前チェックリスト

• 直近三案件を実行・設計・分析・可視化・予防へ分けた
• テスト件数より、要求・リスク・判断・成果物を整理した
• 自分・設計者・開発者・品質責任者の担当を分けた
• QA・自動化・開発・社内SE・品質管理を比較した
• 自己学習と本番の開発・自動化実務を混ぜていない
• 顧客名・画面・データ・障害詳細を持ち出していない
• 90日で作る成果物・レビュー担当・期限を決めた
• 求人で入社90日の工程・成果物・配属決定者を聞く
• 職種変更の事例を自分への保証にしていない
• 給与・評価・案件終了後・変更範囲を書面で確認する
• 対象条件に合う二社までへ同じ経歴と7問を渡す
• 相談・応募・内定承諾・退職を別々に判断する