エンジニアの転職理由 例文18選｜SES・SIerの不満（還元率・工程・評価）を面接用に言い換える型と、エージェント面談での話し分け【2026年10月版】
// TL;DR
- 転職理由の本音は「賃金」「会社の将来」「仕事内容」「評価」がほぼ横並び。厚労省の令和7年調査（2026年9月公表）では、自己都合で辞めた人の離職理由の上位3つが25.5%・25.2%・24.7%と僅差だった。本音がネガティブなのは普通で、隠すより「どう組み立てるか」で決まる。
- 型は「①事実 → ②自分が取った行動 → ③応募先で実現したいこと」の3文。不満は①に事実として1文だけ置き、②で「文句を言うだけの人ではない」ことを、③で志望動機につなぐ。
- SES・SIerの「還元率」「工程」「評価」は、それぞれ「報酬の決まり方」「担当範囲」「評価する人との距離」という構造の話に置き換えると、前職の悪口にならない。
- エージェント面談では本音と優先順位を話してよい。ただし面談内容は推薦文の材料になるので、事実と数字で話す。
目次
01本音の転職理由はこう分布している（2025〜2026年のデータ）
例文に入る前に、面接官が「よくある本音」として何を想定しているかを押さえておく。2つの調査がある。
1つ目は厚生労働省の「令和7年転職者実態調査」。2025年10月1日時点で、5人以上の事業所で働く転職者7,310人の回答を集計したもので、2026年9月25日に公表された。5年ごとの調査なので、前回は令和2年（2020年）になる。
上位5つが22〜26%に固まっていて、「これが1位」と言えるほどの差はない。前回の令和2年と比べて伸び幅が大きいのは「能力・実績が正当に評価されない」（15.3%→18.9%）で、「賃金が低かった」（23.8%→25.5%）、「会社の将来に不安」（23.3%→25.2%）も増えている。
2つ目はdodaの「転職理由ランキング2025」（2024年7月〜2025年6月に転職した人が対象、35項目から複数回答）。1位は5年連続で「給与が低い・昇給が見込めない」（36.6%）、2位は「労働時間に不満」（26.3%）。3位の「個人の成果で評価されない」は前回18位・10.9%から22.8%に上がった。調べ方の違う2つの調査で、どちらも「評価」への不満が増えている。
つまり、面接官から見れば「年収」「評価」「将来性」「仕事内容」を理由にする候補者は珍しくない。不満があること自体は減点にならない。差がつくのは、それを採用側の関心とつなげられるかどうかだ。
採用側は転職理由から何を読んでいるか
同じ厚労省調査の事業所側の集計では、「専門的・技術的な仕事」で転職者を採用した理由（3つまで複数回答）のトップは「経験を活かし即戦力になるから」64.1%、次いで「専門知識・能力があるから」51.2%だった。賃金を決めるときに考慮した要素も、情報通信業では「これまでの経験・能力・知識」が81.3%で全産業のなかで最も高い。
エンジニア採用で面接官が転職理由を聞くのは、主にこの3点を確かめるためだ。
- 再現性：同じ不満がうちでも起きないか（起きるなら早期離職になる）
- 課題への向き合い方：不満に対して自分で何か手を打った人か
- 志望動機との整合：辞める理由と、うちを選ぶ理由が一本の線でつながっているか
以下の例文は、どれもこの3点に答える形で組んでいる。
02面接で通る転職理由の型：3文と「深掘り2段目」
- ①事実：現職で何が起きているかを、感情語を使わずに1文で言う。「〜が不満で」ではなく「〜という体制です」「〜の割合が◯割です」。
- ②行動：その状況に対して自分が何をしたか。異動の希望を出した、社内勉強会を立ち上げた、評価面談で根拠を示して交渉した、など。ここが無いと「環境のせいにする人」に見える。
- ③実現：②をやっても現職の構造上できないこと、それが応募先ではできること。ここがそのまま志望動機の頭になる。
長さは、面接で口頭で話すなら1分以内（300字前後）が目安。最初は短く言い切り、面接官に深掘りさせるほうが会話になる。
深掘り2段目まで用意する
エンジニアの面接では、転職理由に対してほぼ確実に「それは現職で解決できなかったんですか？」「具体的にはどのくらい？」と返ってくる。例文ごとに、この2段目の質問と返し方を付けている。2段目で詰まると、1段目の答えがどれだけ整っていても「作った答え」に見える。
03本音→言い換えの対応表
本音の不満を、そのまま言うとどう聞こえるか、どの軸に置き換えれば構造の話になるかを先に一覧にする。
| 本音 | そのまま言うと | 置き換える軸 | ③でつなげる先 |
|---|---|---|---|
| 還元率が低い・単価が見えない | お金だけの人 | 報酬の決まり方（単価・評価・給与の連動） | 成果が評価と年収に反映される制度 |
| テスト・保守しかやらせてもらえない | 能力不足を環境のせいにしている | 担当工程の範囲と、その工程が決まる仕組み（商流） | 設計〜運用まで一貫して担当できる体制 |
| 上司が現場を見ていない | 上司の悪口 | 評価する人と、仕事を見ている人の距離 | 同じチームの人が評価する仕組み |
| 案件を選べない | わがまま | 技術スタックの選択権がどこにあるか | 応募先の技術スタックで深めたい領域 |
| 年功序列で給料が上がらない | 待遇への不満 | 評価基準（年次か、役割か、成果か） | 等級・評価基準の公開、役割に応じた報酬 |
| 残業・オンコールがきつい | 楽をしたい | 運用負荷の構造（属人化・自動化の度合い） | SRE・自動化に投資している組織 |
| 会社が傾いている | 逃げ | 事業の方向性と自分の専門の不一致 | 応募先の事業で自分の専門が使われる場所 |
| 人間関係が合わない | 協調性がない | 意思決定の進め方・レビュー文化 | 応募先の開発プロセス（レビュー・設計ドキュメント） |
ポイントは、「人」ではなく「仕組み」を主語にすること。仕組みの話なら、応募先の仕組みと比べられる。人の話は比べようがなく、聞く側は「うちでも誰かと合わなくなるのでは」としか考えられない。
04例文：SES・客先常駐から（6例）
SESからの転職理由で詰まりやすいのは、本音の大半が「会社の仕組み」への不満なのに、そのまま言うと前職批判に聞こえる点だ。公正取引委員会の2022年の調査では、ソフトウェア業の事業者の25.9%が「中抜き」事業者の存在を感じたことがあると答え、最終下請に限ると33.5%だった。構造の問題として広く知られているので、感情ではなく構造として説明すれば十分通じる。自分の現場がどの程度当てはまるかの判定はSES・客先常駐の転職サインを「還元率・工程・指揮命令」で判定する記事で扱っている。
例1：還元率・単価が見えない（年収を上げたい）
SES / 本音：還元率が低い、単価を教えてもらえない口頭 約50秒
-還元率が低くて、いくら頑張っても給料が上がらないので辞めたいです。
+現職では客先常駐で3年間、決済系システムの詳細設計と実装を担当しています。給与は等級表で決まっていて、参画先からの評価や担当範囲が広がったことが報酬に反映される仕組みがありません。評価面談では、担当範囲が実装から詳細設計まで広がったことを資料にまとめて伝え、等級の見直しを依頼しましたが、制度上は年次での昇給のみという回答でした。御社は役割と成果を基準にした等級制度を公開されており、担当範囲を広げた分がきちんと評価される環境で、設計まで含めて責任を持ちたいと考えて応募しました。
深掘り：「結局、年収が目的ですか？」→「年収は判断材料の1つです。それより、何をすれば評価されるかが分かる環境で働きたい、というのが大きいです。現職では基準が年次なので、伸ばすべき方向が自分で決められませんでした」
「還元率」という言葉は使わない。還元率は会社によって定義が違い（社会保険の会社負担分を含めるかどうか等）、面接官に通じても「お金の話をする人」という印象が先に立つ。「報酬の決まり方」と言えば、評価制度の話として聞いてもらえる。
例2：テスト・保守工程から抜けられない
SES / 本音：ずっとテスト要員、設計をやらせてもらえない口頭 約45秒
-テストばかりでスキルが身につかないので、もっと上流をやりたいです。
+現職では2年半、二次請けの立場で結合テストと運用保守を担当しています。テストの過程で仕様の矛盾を見つけることが多く、設計側に改善案を出すために、担当外ですが設計書のレビューにも参加させてもらうようになりました。ただ、商流上、設計工程は元請けの範囲と決まっていて、自社として設計から受ける案件がほぼありません。テストで品質問題が起きる原因を設計段階から潰したいと考えており、自社サービスとして設計から運用まで一つのチームで持っている御社で、その経験を活かしたいと考えています。
深掘り：「設計の経験はほぼ無いということですよね？」→「業務として設計書を書いた経験はありません。レビューで指摘した内容が採用された件数は記録していて（例：◯件）、指摘の観点はテストの不具合傾向から作っています。実務での設計は御社で学ぶ部分が大きいと理解しています」
例3：評価する人が現場を見ていない
SES / 本音：自社の上司は一度も現場に来ない、評価が適当口頭 約40秒
-上司が現場を全く見ていなくて、評価がいい加減なんです。
+現職は常駐先で日々の指示と成果確認が行われる一方、評価は自社の上司が年2回の面談で行う形です。常駐先の方からいただいた評価コメントを毎回まとめて提出していますが、評価に使う情報がそれだけになるため、どこを伸ばすべきかのフィードバックを受けにくい状況です。一緒に開発しているメンバーやリードからコードレビューや1on1で直接フィードバックをもらえる環境で、改善のサイクルを速く回したいと考えています。
深掘り：「上司と話し合ったりは？」→「面談の前に常駐先での成果をまとめて共有するようにしています。上司も理解はしてくれていますが、仕組みとして現場を見る機会が無いので、個人の努力では埋まりませんでした」
例4：案件・技術スタックを選べない
SES / 本音：案件ガチャ。やりたい技術と関係ない現場ばかり口頭 約45秒
-案件が選べず、やりたい技術ができないからです。
+これまで4年間で3つの現場を経験し、Java、PHP、COBOLの改修と、言語も業務領域も案件ごとに変わってきました。どの現場でも早く立ち上がることは得意になりましたが、1つの領域を深く掘る前に次の案件に移るため、専門と呼べるものが作れていないと感じています。業務外では2年ほどGoとAWSで個人開発を続けており、今後はバックエンドとインフラの両方が分かるエンジニアとして専門性を積みたいと考えています。御社のサービスはGoとAWSで構成されていて、自分が伸ばしたい方向と一致しているので応募しました。
深掘り：「うちでも配属は選べないことがありますよ」→「承知しています。配属先で求められる技術が変わることは問題ありません。現職との違いは、1つのプロダクトに長く関われる点で、そこを重視しています」
例5：待機・稼働が不安定
SES / 本音：案件が切れて待機、給料も減らされた口頭 約35秒
-案件が無くて待機させられて、会社の将来が不安になりました。
+今年、参画していた案件が終了し、次の案件が決まるまで2か月の待機期間がありました。その間に社内ツールの改修とAWSの資格取得に取り組みましたが、自分のキャリアが案件の有無に左右される働き方を見直したいと考えるようになりました。自社のプロダクトを長期的に育てる立場で、継続的に改善に関わりたいと考えています。
深掘り：「待機中は何をしていましたか？」→ここは具体的に。期間・取り組み・成果物（資格名、改修した機能、書いた記事など）を答えられるようにしておく。
例6：多重下請で意思決定から遠い
SES / 本音：三次請けで、何のために作ってるか分からない口頭 約45秒
-下請けの下請けで、言われたものを作るだけなのがつまらないです。
+現在は三次請けの立場で、要件は元請けと二次請けを経由して届きます。仕様の背景を確認したいときも数日かかることが多く、ユーザーの使い方を踏まえた提案がしにくい状況です。改善案をまとめて二次請け経由で提出し、実際に画面の入力項目の削減が採用されたこともありましたが、ユーザーの反応を見て次の改善につなげる、というところまでは関われません。エンドユーザーとの距離が近い自社開発の環境で、作ったものの使われ方を見ながら改善したいと考えています。
深掘り：「ユーザーと近い開発で何をしたいですか？」→応募先のプロダクトを実際に触り、気になった点を1つ具体的に言えるようにしておく。ここで逆質問にもつなげられる（面接段階別の逆質問24問も参照）。
05例文：SIerから（5例）
SIerからの転職は「上流しかやっていない」「下流しかやっていない」のどちらでも理由が作れる。共通して大事なのは、応募先で手を動かす覚悟があるのか、マネジメントを続けたいのかを曖昧にしないこと。Web系企業への移り方そのものはSIerからWeb系への転職の記事にまとめている。
例7：管理業務が中心でコードを書けない
SIer / 本音：Excelとベンダーコントロールばかりで技術が死ぬ口頭 約50秒
-Excelでの進捗管理ばかりで、エンジニアとして成長できないので。
+現職では入社6年目で、要件定義と協力会社の進捗管理を担当しています。顧客の業務を理解して要件に落とす力はつきましたが、実装は協力会社が担うため、技術的な判断の根拠を自分で検証できないことに課題を感じてきました。2年前から業務外でTypeScriptとReactを使った開発を続け、社内の工数集計ツールを作って部署内で使ってもらっています。要件定義の経験を活かしつつ、自分で実装まで責任を持つ立場に移りたいと考え、職種としてもバックエンドエンジニアとして応募しています。
深掘り：「年収は下がるかもしれませんが？」→下がる可能性を受け入れるかどうか、下限はいくらかを事前に決めておく。「◯万円までは許容できます。数年で取り戻すために◯◯を伸ばしたい」まで言えると説得力が出る。
例8：技術選定ができない（決まった構成しか使えない）
SIer / 本音：古い技術しか使わせてもらえない口頭 約40秒
-会社が古い技術しか使わないので、市場価値が下がるのが怖いです。
+現職では顧客ごとに標準の構成が決まっていて、技術選定は案件開始前に営業と顧客の間でほぼ決まります。インフラ更改の案件でコンテナ化の検証を提案し、PoCまでは実施しましたが、保守体制の都合で採用には至りませんでした。技術選定の理由を自分たちで議論して決め、その結果に責任を持つ開発に関わりたいと考えています。
深掘り：「新しい技術を使いたいだけでは？」→「新しいかどうかより、選んだ理由をチームで説明できることを重視しています。PoCのときも、運用負荷の比較表を作って提案しました」
例9：年功序列で成果が年収に反映されない
SIer / 本音：成果を出しても同期と年収が同じ口頭 約40秒
-頑張っても頑張らなくても給料が同じなのが嫌で。
+現職の評価は年次ごとの等級がベースで、プロジェクトでの成果は賞与で一部反映される仕組みです。昨年は炎上案件の立て直しでリーダーを務め、予定より早く安定稼働させましたが、等級は年次どおりでした。役割の大きさに応じて等級が上がる制度で、より大きな範囲を任されることを目標にしたいと考えています。
深掘り：「立て直しで具体的に何をしましたか？」→ここは実績の話として深く準備する。転職理由の深掘りが自己PRに変わる瞬間で、最も点が取れる場所。
例10：プロジェクト単位で人が入れ替わり、育たない
SIer / 本音：納品したら終わり。運用の知見が貯まらない口頭 約40秒
-作って終わりの仕事に飽きました。
+現職では受託開発で、納品後の運用は顧客か別チームに引き継ぐ形です。リリース後にどんな障害が起き、どう改善されたかを知る機会が少なく、設計の良し悪しを自分で確かめられないことに課題を感じています。運用まで同じチームで持ち、障害対応やモニタリングの結果を次の設計に返せる環境で働きたいと考えています。
深掘り：「オンコールもありますが大丈夫ですか？」→嫌なら正直に条件を確認する。ここで「大丈夫です」と流すと入社後のミスマッチになる。
例11：会社の事業方針と自分の専門が合わなくなった
SIer / 本音：会社がクラウドに舵を切らず先行きが不安口頭 約35秒
-会社の将来性がないと思ったからです。
+現職はオンプレミス環境の構築・保守が主力事業で、中期計画でもその方針が続く見込みです。私はここ3年、案件の中でAWSへの移行検証を担当し、クラウドの設計を専門にしたいと考えるようになりました。会社の方向性と自分が伸ばしたい専門が分かれてきたため、クラウドを前提にサービスを設計している御社で経験を積みたいと考えています。
深掘り：「社内でクラウドの部署を作る提案は？」→提案した事実があれば具体的に。無ければ「部署として新設する計画は無いと確認しました」のように、確認した事実を言う。
06例文：自社開発・Web系から（5例）
自社開発からの転職は、SES・SIerのような「構造上の問題」で説明しにくい。そのぶん面接官は「同じことがうちでも起きないか」をより強く見る。応募先の制度や体制を事前に調べ、違いを具体的に示す必要がある。
例12：評価基準が不透明
自社開発 / 本音：評価がマネージャーの好き嫌い口頭 約40秒
-評価が上司の主観で決まるのが納得できません。
+現職では評価基準が明文化されておらず、半期ごとの目標も口頭で決まります。チームで評価基準の言語化を提案し、エンジニアのグレード定義のたたき台を作りましたが、全社の制度改定の予定がなく採用されませんでした。評価基準が公開されている御社で、何をすれば次の段階に進めるかを明確にしたうえで成長したいと考えています。
深掘り：「うちの評価制度のどこがいいと思いましたか？」→応募先が公開している等級定義・評価資料・テックブログを読んだうえで、具体的な項目名を挙げる。
例13：技術的負債に投資しない
自社開発 / 本音：機能追加ばかりで負債が放置。もう限界口頭 約45秒
-レガシーなコードばかりで、リファクタリングをさせてもらえません。
+現職のプロダクトは創業期のモノリスのままで、開発の大半が新機能の追加に割り当てられています。障害の原因になっている箇所のリファクタリング計画を作り、障害件数と対応工数のデータを付けて提案しましたが、事業優先度の判断で着手は見送りになりました。事業の判断として理解はしていますが、私は品質と開発速度を両立させる設計に関わりたいと考えており、技術的負債の返済をロードマップに組み込んでいる御社に魅力を感じています。
深掘り：「うちも負債はありますよ」→「負債があること自体は前提だと考えています。返済の判断をデータで議論できるかどうかを重視しています」
例14：事業縮小・組織変更
自社開発 / 本音：担当プロダクトがクローズ、やる気が無くなった口頭 約35秒
-担当していたサービスが終わってしまい、居づらくなったので。
+担当していたサービスが今年3月にクローズし、私は社内システムの保守チームに異動になりました。BtoCサービスの改善で培った、ユーザーの行動データから仮説を立てて検証する経験は、今の部署では活かす場面が少ないため、同じくBtoCでデータを見ながら改善を回している御社で、その経験を続けたいと考えています。
深掘り：「異動先で活躍する道は？」→「保守チームでも監視の自動化などに取り組んでいます。ただ、自分の強みが最も活きるのはユーザーに近い改善だと考えています」
例15：残業・オンコールの負荷が高い
自社開発 / 本音：夜中に呼ばれすぎて体がもたない口頭 約40秒
-残業とオンコールが多すぎて疲れました。
+現職ではインフラを3名で担当していて、障害対応の手順が特定のメンバーに依存しているため、深夜の呼び出しが月に数回あります。手順書の整備とアラートの見直しを進め、誤検知のアラートは半分以下に減らしましたが、人員の増加予定がなく、属人化の解消に時間を割けない状態が続いています。運用の自動化に投資しているチームで、仕組みで負荷を下げる仕事に専念したいと考えています。
深掘り：「うちもオンコールはあります」→「オンコール自体は問題ありません。輪番の人数と、障害後の振り返りで改善が回る仕組みがあるかを伺いたいです」と、条件の確認に変える。
例16：尊敬できる人・学べる人がいない
自社開発 / 本音：社内で一番詳しいのが自分になってしまった口頭 約35秒
-周りのレベルが低くて、学ぶことがありません。
+現職では入社3年目でバックエンドのリードを任されています。設計判断を自分で下す経験は積めましたが、レビューで自分より深い視点の指摘を受ける機会が少なくなってきました。社外の勉強会で知見を補っていますが、日々の開発の中で、より経験のあるエンジニアと設計を議論できる環境に身を置きたいと考えています。
深掘り：「周りを育てる道は？」→「チーム内の勉強会は自分が主催しています。それと並行して、自分が学ぶ側に立てる環境も必要だと考えました」。周りを下げる言い方は一言も入れない。
07例文：短期離職・職種チェンジ（2例）
例17：入社1年未満での転職
短期離職 / 本音：求人票と全然違った口頭 約40秒
-求人票ではWeb開発と書いてあったのに、実際はヘルプデスクだったので。
+入社時はWebアプリケーションの開発ポジションとして内定をいただきましたが、入社後の配属で社内ヘルプデスクの担当になり、開発への異動時期も未定と説明を受けました。上長と2回面談して開発業務への配置を相談しましたが、当面は難しいという回答でした。短期間での転職になることは重く受け止めていて、今回は配属と業務内容を面接の段階で具体的に確認したうえで、長く腰を据えられる会社を選びたいと考えています。
深掘り：「なぜ入社前に確認しなかったんですか？」→言い訳をせず「確認が不十分でした」と認め、今回どう確認しているかを具体的に言う。ここで反省の言葉が出ないと、同じことを繰り返す人だと判断される。
例18：インフラ運用からSREへ（職種チェンジ）
職種チェンジ / 本音：運用の手作業から抜けたい口頭 約45秒
-手作業の運用ばかりで将来が不安なので、SREになりたいです。
+現職ではサーバー運用を4年担当しています。定型作業のうち、ログのローテーションとアカウント発行をシェルスクリプトとAnsibleで自動化し、月の作業時間を大きく減らしました。この経験から、運用をコードで改善する仕事を専門にしたいと考えるようになりました。現職の運用チームは手順書ベースの運用が前提で、自動化は個人の取り組みにとどまっています。SLOを置いて信頼性を設計している御社で、運用の経験を活かしながらSREとして専門性を高めたいと考えています。
深掘り：「コーディング経験はどのくらい？」→書いたスクリプトの規模・言語・レビューの有無を正直に。不足は学習計画で補う（技術面接やコーディングテストがある場合はコーディングテスト対策の記事も参照）。
例文はそのまま使わない
上の例文の数字（年数・件数・期間）は説明用の仮のもの。面接官は2段目・3段目で必ず具体を聞くので、自分の事実に置き換えて、深掘りされても崩れない状態にしてから使う。「◯件」「◯割」のように数字が入る場所を空けてあるので、そこを自分の数字で埋めるのが最初の作業になる。
08面接とエージェント面談の話し分け
転職エージェントを使う場合、転職理由を話す相手は2人いる。応募先の面接官と、エージェントのキャリアアドバイザーだ。目的が違うので、話す内容の重心も変える。
| エージェント面談 | 企業の面接 | |
|---|---|---|
| 相手の目的 | 紹介する求人を絞る・推薦文を書く | 採用するかを判断する |
| 本音の扱い | 話してよい。条件の線引きに必要 | 事実として1文に圧縮する |
| 年収の話 | 現年収・希望・下限を数字で伝える | 聞かれたら答える。転職理由の主軸にしない |
| 重心 | ①事実と、譲れない条件・優先順位 | ②行動と③応募先で実現したいこと |
| 注意点 | 話した内容は推薦文や企業への申し送りの材料になる | エージェント経由の情報と矛盾させない |
エージェント面談での言い方（例）
エージェント面談 / SESから・年収と工程の両方が不満本音＋優先順位
+正直に言うと、一番大きいのは年収です。現年収は420万円で、単価に対してどの程度還元されているかは開示されていません。ただ年収だけなら現職で交渉する余地もあったので、それより、テスト工程から設計に進めない構造を変えたいというのが転職の理由です。優先順位は、1. 設計から関われること、2. 年収450万円以上、3. 客先常駐でないこと、の順です。3は、自社内開発であれば常駐でも検討します。
こう話しておけば、アドバイザーは求人を絞り込める。推薦文に書かれても困る内容は入っていない。逆に「上司がひどくて」「とにかく辞めたい」とだけ話すと、アドバイザーは条件で求人を絞れず、推薦文にも書きようがない。
初回面談でほかに何を聞かれるか、答えにくい質問への対処はエージェントの初回面談で聞かれることの記事にまとめている。エージェント経由の転職が向く人・向かない人の判断は転職エージェントは「やめとけ」か検証した記事を参照。
転職理由の整理から相談するなら、エンジニア向けの転職エージェント
本音と優先順位を話して求人を絞り込み、応募先ごとに転職理由の伝え方を一緒に調整できる。面談・登録は無料。
09書類・一次面接・最終面接で矛盾させない
転職理由は1回話して終わりではない。職務経歴書、エージェントの推薦文、一次面接（現場のエンジニア）、最終面接（役員・事業責任者）と、少なくとも3〜4回は別の人が同じ話を聞く。言い回しが変わるのは問題ないが、中身（事実・行動・実現したいこと）は変えない。
職務経歴書・履歴書には短く書く
履歴書の退職理由欄は、自己都合なら「一身上の都合により退職」で問題ない。職務経歴書に転職理由を書く欄を設ける場合は、3文の型の③を中心に2〜3行に縮める。
職務経歴書 / 例2（テスト工程）の書類版2〜3行
+結合テストと運用保守で得た不具合の傾向分析の経験を、設計段階での品質向上に活かしたいと考え、設計から運用まで一貫して担当できる環境を志望しています。
書類全体の組み立てはエンジニアの職務経歴書の書き方の記事を参照。
面接の段階で比重を変える
| 段階 | 主な面接官 | 比重を置く部分 |
|---|---|---|
| 一次・技術面接 | 現場のエンジニア・EM | ②行動の技術的な中身（何をどう改善したか、なぜその判断をしたか） |
| 二次 | 部長・EM | ①事実の構造（なぜ現職では解決できないか）と、チームで働くイメージ |
| 最終 | 役員・事業責任者 | ③応募先の事業で何を実現したいか、長く働く理由 |
また、最終面接の前後でリファレンスチェックを実施する企業もある。前職の上司や同僚に話を聞かれたとき、面接で話した転職理由と食い違うと信頼を損なう。誰に頼むか、どこまで話を合わせておくかはリファレンスチェック対策の記事で扱っている。
10NGパターンと提出前チェックリスト
よくあるNGパターン
- 人が主語：「上司が」「同僚が」「営業が」で始まる理由は、どう言い換えても批判に聞こえる。仕組み（評価制度、体制、商流）を主語にする。
- 行動が抜けている：「〜できないので辞めたい」で終わる。②が無いと、うちでも少し不満があれば辞める人だと判断される。
- 志望動機とつながらない：転職理由は「評価制度」なのに、志望動機は「御社のサービスが好き」。どちらも本当でも、別々の話に聞こえる。③で同じ軸につなぐ。
- 条件だけ：「年収」「リモート」「残業」だけで終わる。条件は大事だが、それだけだと「もっと条件のいい会社があれば移る人」に見える。条件を求める背景（何をしたいからその条件が必要か）を足す。
- 応募先で解決しない理由：「客先常駐が嫌」と言いながら常駐ありの会社に応募する、「残業が嫌」と言いながら繁忙期のある受託に応募する。応募先の働き方を事前に確認する。
提出前チェックリスト
- 1文目に感情語（不満、嫌、つらい、ひどい）が入っていない
- 主語が「人」ではなく「仕組み・体制・制度」になっている
- 現職で自分が取った行動が1つ以上、具体的に入っている
- 年数・件数・割合など、事実を示す数字が最低1つ入っている
- 応募先のどの制度・体制・事業と対応しているかを言える
- 「現職で解決できなかったのか？」への答えを用意している
- 応募先でも同じ不満が起きない根拠を、求人票か面接で確認した
- エージェントに話した内容・職務経歴書の内容と矛盾していない
- 口頭で1分以内に話せる
よくある質問
エンジニアの転職理由で「スキルアップ」は弱いですか？
「スキルアップしたい」だけだと弱い。何のスキルを、なぜ現職では伸ばせず、応募先ならなぜ伸ばせるのかまで言えれば十分な理由になる。dodaの2025年調査でも、男性の転職理由2位は「スキルアップしたい」（24.1%）だった。珍しくないぶん、具体性で差がつく。例4（技術スタック）や例2（工程）の形で、伸ばしたい領域と応募先の技術を対応させると伝わりやすい。
年収アップが本当の転職理由なら、正直に言っていいですか？
言ってよいが、主軸にしないほうがいい。厚労省の令和7年調査でも、自己都合で辞めた人の離職理由の1位は「賃金が低かった」（25.5%）で、面接官にとっても珍しい理由ではない。ただ年収だけを理由にすると「もっと高い会社があれば移る」と受け取られる。例1・例9のように「何をすれば評価されるか」「役割と報酬が連動しているか」という評価制度の話に置き換えると、年収の話を含めながら通りやすくなる。希望年収そのものはエージェント経由で伝えるか、面接で聞かれたときに数字で答える。
SESから転職するとき、「SESが嫌だった」と言ってもいいですか？
業態そのものを否定する言い方は避ける。応募先がSESを使っていたり、取引先にSES企業があったりすることも多い。「SESが嫌」ではなく「担当工程が商流で決まる」「評価する人と現場が離れている」と、構造の中の具体的な点を挙げ、それが応募先ではどう違うかにつなげる。例1〜例6が参考になる。
転職理由と志望動機はどう分けて話せばいいですか？
転職理由は「なぜ今の会社を出るのか」、志望動機は「なぜこの会社なのか」。ただし面接官は両方を一本の線で聞いているので、転職理由の最後（3文の型の③）を志望動機の最初につなげる。例えば転職理由が「評価が年次ベース」なら、志望動機は「役割に応じた等級制度があり、◯◯の役割を目指せる」から始める。
転職理由がネガティブなものしか思いつきません。
それが普通だ。まず本音を全部書き出し、それぞれについて「その状況に自分は何をしたか」を書く。行動が書けたものが、面接で使える転職理由の候補になる。何もしていない不満は、面接の前に現職で1つ手を打っておく（評価面談で伝える、異動希望を出す）と、それ自体が②の材料になる。
参考・出典
- 厚生労働省「令和7年転職者実態調査の概況」（2026年9月25日公表）表4・表11ほか https://www.mhlw.go.jp/toukei/list/6-18c-r07.html ／ PDF https://www.mhlw.go.jp/toukei/list/dl/6-18c-r07-gaikyo.pdf
- doda「転職理由ランキング【最新版】」（2024年7月〜2025年6月の転職者対象） https://doda.jp/guide/reason/
- 公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書」（2022年6月29日） https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_software.html
福朗
フリーランスAIエンジニア。AIパイプライン開発と技術キャリアについて発信しています。
