フロントエンドエンジニアを辞めたい。別の会社でも技術と調整は残りうる、兼務は求人票、分担は面接

最近、フロントエンドエンジニアを辞めたいと思った場面を3〜5個、今の職場の人数・回数・仕事の割合と一緒に書いてください。会社を移っても技術を学ぶ必要と他職種との調整は残りうる一方、兼務は求人票、実際の分担は面接で確かめます。 厚生労働省 job tag の「システムエンジニア（Webサービス開発） - 職業詳細」は、Webサービス開発のSEについて、開発技術は日進月歩で、情報を集めて技術を磨く積極性が求められると説明しています（2026年9月30日確認）。これは要件定義やバックエンドも含む職業説明で、フロントエンドだけの説明ではありません。

例にするのは、BtoB SaaSの画面実装、デザインシステム、アクセシビリティ改善を担う架空の人です。

フロントエンドエンジニアを辞めたい場面を3〜5個、今の職場の値と一緒に書く

板挟み、修正が終わらない、仕事が広がりすぎた、評価されない。そのままでは応募先との違いを比べられません。最近つらかった場面を3〜5個選び、いつ、誰と、何が起きたかを書きます。次に、人数、回数、期間、仕事の割合、決めた人を添えます。

例の人について、後で求人票と面接に持っていける形にすると、次のようになります。すべて架空の値です。

辞めたい場面	今の職場の値	比べる単位	確認先
デザイン確定後も修正が往復する	デザイナーは1人。直近3か月の公開4回で、実装開始後の差し戻しは計11回。実装前レビューは0回。差し戻しはデザイナーが判断	人数、公開回数、差し戻し回数、実装前レビュー、判断者	チケット、デザインレビュー履歴
バックエンドのAPIを待ち、公開前に実装が詰まる	バックエンドは社内。直近4回の公開のうち2回は、API仕様の確定が画面実装の開始後。変更はPMが判断	社内・外注、仕様が固まった時点、公開回数、判断者	API仕様、チケット、公開計画
LPやバナー更新まで頼まれる	直近3か月は画面実装65%、デザインシステム20%、LP・バナー15%	期間、仕事の割合	チケット、予定表
技術学習が業務外に残る	直近1か月は業務外に6時間。書籍費は会社負担	月の時間、費用	予定表、経費精算
技術選定に関われない	直近2回の変更はテックリードが決定し、本人の参加は0回	変更回数、参加した段階、決めた人	設計記録、会議履歴
画面の品質が評価に入らない	評価4項目のうち、表示速度・アクセシビリティ・テストは0項目。評価者はEM	項目数、評価者	評価票、面談記録
公開前の残業が増える	平常月25時間、直近の公開前50時間	平常月と公開前の実残業	勤怠、公開計画

「公開前の残業が増える」は、平常月と公開前の月を分けます。週や日でしか記録がなければ、月へ推定せず、公開前の週の日数と一日ごとの勤務時間をそのまま使います。給与欄の固定残業時間ではなく、勤怠に残る実際の時間を使います。「デザイン確定後も修正が往復する」は、実装前レビューの有無、実装開始後の差し戻し回数、デザインシステムや共通コンポーネントの有無にします。

三つの側を決めてから、場面を振り分ける

表へ置く前に、三つの側を決めます。

• 続けても残る側: フロントエンドを続けるなら、別の会社でもゼロになるとは見込みにくい仕事や難しさです。技術を学び続ける必要や、デザイナー・バックエンド等と調整して画面を実装する場面が入ります。
• 会社で変わりうる側: 担当する仕事の割合、使う技術、制度、実残業のように、同じ単位の値を会社や配属先で比べられる側です。値を求人票で読めなければ面接で聞きます。会社を移れば必ず軽くなるという意味ではありません。
• 今は分からない側: 実際の分担、判断者、修正の打ち切り方、評価、人間関係のように、一つの値だけでは比べられない側です。面接で直近の進め方を聞いて置き直し、入社後を予測できないものはこの側に残します。

面接で聞くかどうかではなく、同じ単位の値で比べられるか、進め方や判断の実例が必要かで二つの側を分けます。

一つの場面に二つの原因があれば、二行に分けます。技術を学ぶ必要と、業務外だけで学ぶ時間は別です。公開前に仕事が増えることと、残業が平常月25時間から公開前50時間になることも別です。画面が動いて当たり前に見られやすいことと、会社の評価項目に画面の品質が入らないことも分けます。

例の人の場面を原因ごとに分けると、次のようになります。

分けた場面	最初に置く側	そう置く根拠	次に確かめる値
技術を学び続ける必要がある	続けても残る側	複数の評判記事が挙げ、Webサービス開発のSEについてはjob tagにも記述がある	学ぶ技術
技術学習が業務外に残る	会社で変わりうる側	学習支援の制度・費用と業務内外の時間を同じ単位で比べられるため	業務内外の時間、費用
LP・バナーが仕事の15%を占める	会社で変わりうる側	LP等を仕事に書く会社があり、担当の有無は求人票から手がかりを得られるため	仕事の割合、依頼元
直近2回の技術選定に参加できなかった	会社で変わりうる側	技術選定への関わりを仕事として書く求人があるため	参加する段階、決める人、直近の変更例
実装開始後にデザインが11回差し戻された	今は分からない側	修正の進め方を求人票に書く会社は少なく、語の有無から実際の回数を読めないため	実装前レビュー、差し戻し回数、決める人
API仕様の確定が実装開始後になった	今は分からない側	API連携の記載だけでは、仕様が固まる時点や遅れた際の決め方を読めないため	社内・外注、確定時点、変更を決める人
画面が動いて当たり前に見られやすい	続けても残る側	環境による差とする記事もあるが、評判記事の一部が職種側の見えにくさとして挙げるため	見えにくいと感じた場面
画面品質が評価4項目に入らない	今は分からない側	項目数だけでなく、誰が何をどう評価したかという実例が必要なため	評価項目、評価者、直近の評価例
平常月25時間、公開前50時間の実残業になる	会社で変わりうる側	実残業は会社や配属先ごとに同じ単位で比べられるため	平常時と公開前の実残業

続けても残る側に置いた場面が一番つらいなら、会社比較をいったん止め、続けたい仕事と手放したい仕事を書き分けます。技術を学ぶ必要そのものではなく、移行の速さや業務外の時間がつらいなら、その部分は会社で変わりうる側へ分け直せます。必要そのものを手放したいなら別の職種も候補にします。会社で変わりうる側と今は分からない側は、求人票と面接へ進めます。

ほかによくある場面の早見表

例の人にない場面は、次の表で最初の置き場所を決めます。同じ悩みでも、仕事として起きる場面と、回数・分担・決め方を分けます。

場面	最初に置く側	根拠の出どころ	次に確かめる値
デザイナー・バックエンド・PMと調整して画面を実装する	続けても残る側	複数の評判記事。Webサービス開発ではjob tagもチームでの画面検討を説明	調整する相手と内容
デザインが固まらないまま実装し、確認を回り続ける	今は分からない側	評判記事が、判断を自分で下すか確認して回るかはプロジェクトによると説明	確定時点、判断者、レビュー回数
ブラウザ・端末差を直す	続けても残る側	複数の評判記事がフロントエンドの細部修正として挙げる	対応する画面の種類
対応ブラウザ・端末が広く、修正の終わりを決められない	今は分からない側	求人票に語があっても実際の対応範囲と打ち切り方は読めない	対応範囲、許容差、決める人
外注バックエンドのAPI遅れが画面実装にしわ寄せされる	今は分からない側	API・I/F調整の記載から社内外の分担や確定時点は読めない	社内・外注、仕様確定日、遅延時の変更
デザインやバックエンドまで兼務する	会社で変わりうる側	評判記事が会社による兼務として挙げ、求人票にも担当の記載が出る	任意か必須か、仕事の割合
LP・バナー・CMSの制作や運用も持つ	会社で変わりうる側	評判記事が会社差として挙げ、求人票にも仕事名が出る	依頼元、仕事の割合、専任者
Webサービス開発で公開前に仕事が増える	続けても残る側	job tagがWebサービス開発のリリース前の残業を説明	山が来る時期と仕事
上司や同僚との関係がつらい	今は分からない側	求人票と面接で入社後の関係を予測できない	今の職場の出来事を整理し、会社比較には使わない

デザイン自体を作る仕事が中心で、その分担を見直したい場合は、Webデザイナーを続けるときの見分け方で扱っています。

続けても残りうる部分は、根拠の範囲を分けて読む

フロントエンドの仕事についての解説や体験談では、技術の入れ替わり、デザイナー・バックエンド・ディレクターとの調整、ピクセル単位やブラウザ差の修正、上流の遅れや仕様変更のしわ寄せ、動いて当たり前に見られやすいことが、つらさとしてよく挙がります。これらは割合を調べた結果ではなく、辞めたい場面を洗い出す候補です。

このうち公的な職業情報で補えるのは、Webサービス開発と重なる範囲です。厚生労働省 job tag の「システムエンジニア（Webサービス開発） - 職業詳細」は、デザイナーと画面を検討し、試作された画面を確認し、デザイン決定後に開発中のサイトへ取り込む流れを説明しています。スマートフォンからも共通に使える画面や機能を設計・開発に盛り込むこと、技術が日進月歩で情報収集と技術の習得が求められること、新サービスのリリース前には残業が多くなることも記載しています（2026年9月30日確認）。

job tagにフロントエンドエンジニアという職業はありません。このページは要件定義・設計・バックエンドも含むWebサービス開発のSEの説明で、受託・制作会社のフロントエンドを説明したものでもありません。そのため、Webサービスの画面開発をする人について、デザイン決定後の取り込み、スマホを含む画面開発、技術の習得、リリース前の山が残りうると考える補助にだけ使います。

残りうるのは仕事や場面であって、つらさの大きさまで同じとは限りません。デザインが実装前にどこまで固まるか、API仕様がいつ決まるか、対応ブラウザ・端末、公開前に何時間残業するか、画面品質をどう評価するかは、応募先で別に確かめます。

求人を1件開き、兼務・使う技術・品質の記載を読む

最初に書いた場面のうち、会社で変わりうる側か今は分からない側に置いたものを一つ選び、フロントエンドの求人を1件開きます。欄の名前だけで探すと見落とします。仕事内容の欄が空でも、担当や技術が応募条件、会社・事業の紹介、PRポイント、福利厚生のその他に書かれている場合があります。求人票の全文から、次の語を探します。

• 兼務と分担: バックエンド、サーバーサイド、フルスタック、デザイン、LP、バナー、CMS、コーポレートサイト、API開発、API連携、I/F、要件、デザイナー、PM、ディレクター
• 画面を作る仕組み: デザインシステム、コンポーネント、Storybook、レビュー
• 技術と選定: TypeScript、React、Next.js、Vue、Nuxt、jQuery、技術選定、リプレイス、書籍、カンファレンス
• 品質: ブラウザ、レスポンシブ、マルチデバイス、アクセシビリティ、表示速度、パフォーマンス、テスト、E2E
• 働く時間と評価: 残業、時間外、固定残業、想定年収、年収例、評価、等級、昇給

題名がWebエンジニアやフロントエンドでも、仕事内容にモバイルアプリ、バックエンド、PMなどが混じることがあります。応募先を比べるときは、入社直後にWebの画面実装を主に担当すると読めるかを確かめ、仕事の割合が分からなければ面接へ回します。Webの画面実装を担当するかも分からなければ、その求人との比較はいったん止めます。

技術や品質の語が仕事内容にあれば、入社後の仕事を読む手がかりです。応募条件にしかなければ、採用時に求める経験として読みます。会社・事業の紹介にしかない技術選定は、事業部や会社全体の説明として読み、募集する人が参加する仕事とは決めません。たとえばアクセシビリティ経験が応募条件にあっても、入社後に改善を担当することや、会社が指標を持つことまでは決めません。Figmaも使う道具の手がかりであり、デザイナーとフロントエンドの分担を示す語にはしません。

APIも、周りの動詞まで読みます。APIをGoで開発する、設計・実装するという記載はバックエンド兼務の候補です。APIを利用する、連携する、I/F仕様を調整するという記載は画面側との連携であり、バックエンドを開発する仕事とは数えません。どちらも仕事の割合と、社内・外注の分担は面接へ回します。

以下の割合は、2026年9月30日時点で当サイトPREVIOに掲載中の求人から、職種にフロントエンドエンジニアを含むもののうち、題名にフロント、front、マークアップ、コーダー、UIエンジニアがあるか、題名にReact、Vue、Next.js、Nuxt、Angularがあり、サーバー側の言語やフルスタックを含まない求人を、勤務地で絞らず全件集計した結果です。EM、PM、テクニカルディレクター、QA、モバイルなどが題名にある求人は除きました。割合は題名・仕事内容・勤務時間・休日・勤務地・リモート・フレックス・給与・福利厚生・PR・募集背景・賞与の各欄で数え、応募条件欄は含めていません。ただし、仕事内容の欄に書かれた応募条件の文は含みます。会社単位で、その会社の対象求人のどれか1件に書いてあれば書く会社、どの求人にも書いていなければ書いていない会社とし、割合は5%単位に丸めています。業界区分はIT・ソフトウェア全般とインターネットの会社が大半で、SIer・SES・受託開発などは約15%です。この約15%は集計対象の偏りを示す数字で、区分ごとの違いを判断する数字ではありません。

集計した欄で探した内容	書く会社	求人票で読めること	面接へ回すこと
バックエンドまで担当しうる	約10〜15%	任意・将来を含む担当の記載	入社直後の必須範囲、仕事の割合
LP・バナー・CMS等の制作・運用	約10%	周辺の仕事がある手がかり	依頼元、仕事の割合、専任者
デザイナーとの連携	約30%	連携を仕事として書いていること	人数、デザインが固まる時点、判断者
デザインシステム・コンポーネント設計等	約20%	仕組みや仕事名の記載	実際に使う割合、実装前レビュー
技術選定	約25〜30%	選定に関わる仕事の記載	誰が決めるか、直近の変更例
書籍・カンファレンス等の学習支援	約40%	費用・制度の手がかり	利用実績、業務内外の学習時間
ブラウザ・レスポンシブ・マルチデバイス	約10%	語が出ること。仕事内容の欄に書かれた応募条件の文を含む	対応するブラウザ・端末、打ち切り方
パフォーマンス・表示速度	約25%	仕事としての改善を含む記載	指標、目標値、評価への入り方
エンジニア向けの評価の仕組み	5%未満	評価への言及	評価項目、評価者、直近の評価例

デザインまで担当する会社の割合は、この集計からは出せません。題名にデザイナーとフロントエンドが並ぶ求人はありますが、本文でデザインまで持つかは数えられていないためです。仕事内容にデザインがあれば担当候補として読み、比重を面接で聞きます。

修正、納期、仕様変更の決め方を書く会社は5%未満です。書いていない会社に決め方がないとは限らないため、求人票で比べず、面接で直近の例を聞きます。

TypeScriptの語は約55%、jQueryの語は約10%の会社で出ます。どちらも技術スタックなどに語が出る割合で、実際に使う時間や移行予定は分かりません。jQueryがあるだけでレガシーな会社とは決めず、併用する技術と、どの画面にどのくらい残るかを聞きます。コードレビューは約20%の会社で語が出ますが、語の有無から実施方法までは分かりません。

求人票の一つの欄が空でも、全文に同じ内容がないかを見てから、確認できない項目として残します。題名と仕事内容、応募条件、待遇の記載が食い違う場合は、都合のよい方を選ばず、両方を面接で示します。

実際の分担・決め方・実績を、今の職場と同じ単位で聞く

求人票を読み終えたら、確認できない項目を面接の質問にします。多いですか、整っていますか、連携は円滑ですか、では答える人の基準と比べることになります。今の職場と同じ対象・期間・単位を入れます。

比べる場面	今の職場の値	求人票で見る記載	面接で聞く質問
デザインの修正往復	3か月の公開4回、差し戻し11回、実装前レビュー0回	デザイナーとの連携、デザインシステム、レビュー	直近3か月の公開では、実装前のデザインレビューは何回あり、実装開始後の差し戻しは何回でしたか。デザインと実装の違いを許容するかは誰が決めましたか
API遅れのしわ寄せ	バックエンドは社内。4回中2回は実装開始後にAPI仕様が確定	API・I/F仕様、要件調整、バックエンドとの連携	バックエンドは社内と外注のどちらですか。直近の公開ではAPI仕様は画面実装の何日前に固まり、遅れたときは仕様・公開日・人員のどれを誰が変えましたか
LP等の兼務	3か月で画面実装65%、デザインシステム20%、LP・バナー15%	LP、バナー、CMS、兼務	直近3か月の画面実装、バックエンド、デザイン、LP等はそれぞれ何割でしたか。兼務は必須ですか、希望者だけですか
技術選定に関われない	直近2回の変更はテックリードが決定し、本人の参加は0回	技術選定、リプレイス、アーキテクチャ	直近2回の技術変更では、候補を誰が出し、誰が決め、配属予定者はどの段階から参加しましたか
技術学習が業務外に残る	1か月で業務外6時間、書籍費は会社負担	書籍、カンファレンス、研修	配属予定チームでは、技術学習に使える業務内の時間をどう確保していますか。直近1か月の利用例と費用補助を教えてください
公開前の残業	平常月25時間、直近の公開前50時間	実残業の数字、その対象と期間	配属予定チームの直近の平常月と公開前の月の実残業は何時間でしたか。公開前は何人で、何が増えましたか
画面品質の評価	評価4項目のうち表示速度・アクセシビリティ・テストは0	評価、等級、昇給、品質指標	直近の評価では、表示速度・アクセシビリティ・テストを何で測り、誰が評価しましたか。評価項目のうち何項目ですか

学習支援の記載は、費用や制度の手がかりです。業務内に学ぶ時間があるとは読まず、会社が確保する時間と利用例を聞きます。デザインやAPIの連携も、連携という語だけでは人数、確定時点、判断者が分かりません。直近の公開一件に絞ると、抽象的な体制説明ではなく実際の進め方を聞けます。新規プロダクトで公開実績がなければ直近の開発区切りを、受託で配属先が未定なら同じ職種の人が入った直近案件を対象に聞き直します。

求人票の残業時間が全社・部門・配属先のどれかを、先に確かめます。残業時間を書く会社は約20%で、多くは全社・部門の平均です。書く会社の中で20時間以下は最大値で約80%、最小値で約90%、30時間以上はそれぞれ約10%、約5%でした。この数字はフロントエンド全体の残業水準ではありません。

固定残業時間や年収例・想定年収の計算に使う時間は、実際の残業時間ではありません。裁量労働制も、制度名だけでは実際の勤務時間を比べられません。月の実績がなければ、直近の公開前の週について、一日の勤務時間と日数を今の記録と同じ単位で聞きます。

この見分け方で分からないこと

求人票の集計は、当サイトに掲載中の求人の構成を示したものです。対象は題名だけで決め、題名にフロント等がある求人か、題名にReact・Vue等があり、サーバー側の言語やフルスタックを含まない求人を数えています。会社単位の数え方では、対象求人を複数出す会社ほど、どれか1件が書く会社に入りやすくなります。制作会社かどうかは数えていません。

求人票に語があることは、実施率、仕事の比重、現場での使い方を示しません。反対に、書いていない会社にその仕事や制度がないとも言えません。技術名から移行予定は読めず、デザイナーの語がないことからデザイナー不在とも読めません。自社サービスの会社へ移れば、仕様変更のしわ寄せや細部修正から解放されるとも言えません。

job tagから分かるのは、Webサービス開発のSEについて仕事の流れに含まれうる範囲までです。フロントエンドだけの負担の大きさ、受託・制作会社の分担、修正回数までは分かりません。

面接で直近の実例を聞いても、入社後に同じ人数、分担、技術、評価、残業が続くとは限りません。上司や同僚との関係も予測できません。会社を移れば全部解けるとも、フロントエンドを辞めるしかないとも、一律には判定できません。

よくある質問

フロントエンドエンジニアはなぜきつい、つらいと言われるのですか？

技術の入れ替わり、デザイナー・バックエンド・ディレクターとの調整、細部修正、上流の遅れや仕様変更のしわ寄せ、デザインやバックエンド等の兼務、成果の見えにくさが理由としてよく挙がります。ただし、技術を学び続ける必要や調整する場面と、会社ごとの担当範囲・実残業は同じではありません。評価項目は今は分からない側へ置き、場面を三つの側へ分けて確かめます。

フロントエンドエンジニアを辞めたいとき、会社を変えれば楽になりますか？

一律には言えません。バックエンドやLP等の兼務、使う技術、学習支援、実残業は会社で変わりうる一方、技術を学び続ける必要や他職種との調整には残りうる部分があります。デザインやAPI仕様が固まる時点、修正の打ち切り方、評価は求人票だけで決めず、面接で直近の実例を聞きます。

自社サービスの会社なら、修正やしわ寄せは減りますか？

事業の形だけでは判断できません。job tagはWebサービス開発のSEについてリリース前の残業を説明していますが、修正の往復が減るとは示していません。求人票だけで修正・納期・仕様変更の決め方を読もうとせず、直近の公開でデザインとAPI仕様が固まった時点、変更を決めた人、公開前の実残業を聞きます。

jQueryと書かれた求人は避けたほうがよいですか？

jQueryの語だけでは決められません。技術スタックにReact等と併記する会社もあり、語の有無から使う比重や移行予定は分かりません。どの画面に残り、直近では何を置き換え、次の変更を誰が決めるかを聞きます。

フロントエンドエンジニアは評価されにくいなら、辞めたほうがよいですか？

一律には言えません。動いて当たり前に見られやすい面は評判記事の一部が挙げ、環境による差とする記事もあります。評価項目と評価者は今は分からない側です。表示速度、アクセシビリティ、テストを何で測り、直近の評価で誰がどう扱ったかを聞いてから比べます。

一つの場面を選び、求人票を読んで面接質問にする

最初に書いた3〜5場面のうち、会社で変わりうる側か今は分からない側から、一番変えたい場面を一つ選んでください。フロントエンドの求人を1件開き、全文から兼務・使う技術・品質の語を探します。空欄や食い違いが残ったら、今の職場と同じ対象・期間・単位を入れた面接質問を一つ作ります。