フロントエンドエンジニアを辞めたい？LPやバナーまで頼まれる会社の見分け方

自社サービスの会社でフロントエンドエンジニアをしている人がいるとします（架空の例です）。デザイナーが 2 人から 1 人に減り、リリースの 3 日前に API のレスポンスの形が変わった。同じ週にデザイナーから余白と動きの差し戻しが十数件、iPhone の Safari だけ日付の選択が崩れる。そこへマーケティング部から、HTML が書けるのはフロントだけだからと、キャンペーンの LP とバナーの差し替えまで来る。デザインの遅れもバックエンドの変更も、最後に全部フロントに来る。これはフロントをやる限りずっとこうなのか、会社を変えれば違うのか。

フロントエンドの仕事に付いてくる部分と、会社の体制で変わる部分が重なっています。 デザイナーとの直しのやりとり、ブラウザや端末ごとの表示の違い、リリース前に作業が集まることは、フロントならどの会社に移っても残ります。会社で変わるのは、それをフロントの人が一人で抱えるかどうかです。デザイナーが何人いるか、LP やバナーまで頼まれるか、直前の変更を誰が止めるか、デザインの修正をどこで打ち切るか。

このうち LP やバナーまで頼まれるかは、求人票の業務内容に書いてあれば来ると見てよいでしょう。ただ、書いていなくても来ないとは限りません。修正の打ち切り方や評価はほとんど書かれていないので、あわせて面接で直近の出来事を聞いて確かめます。

直しのやりとりとリリース前の残業はどこでも残る。変わるのは一人で抱えるかどうか

フロントエンドは、デザインとバックエンドがそろった後、最後に手を動かす仕事です。厚生労働省の job tag の Web サービス開発の SE の説明でも、デザイナーが画面デザインを担当することが多く、決まった後に開発中のサイトに取り込む流れになっていて、「新サービスのリリース前など、残業が多くなる。」と書かれています（「システムエンジニア（Webサービス開発） - 職業詳細」、2026 年 10 月 9 日確認）。要件定義やバックエンドも含む SE の説明ですが、リリース前に作業が集まるのはフロントも同じです。

辞めたくなる場面と、会社を変えたら残るかどうかを並べます。

きつさ	場面	会社を変えたら
デザイナーとの直しのやりとり	実装を見せると、動きがなんとなく違うと返ってきて、余白や動きを直してまた見せる	残る。修正をどこで打ち切るかの取り決めや、余白や色の基準を共通の部品にしていれば、回数は減らせると当サイトは見ている
ブラウザ・端末ごとの表示の違い	手元の Chrome では合っているのに、iPhone の Safari だけ崩れる	残る。どの端末まで合わせるかは会社が決める
リリース前に作業が集まる	デザインの遅れや API の変更が最後にフロントに集まり、公開日は動かない	残る。残業がどこまで増えるかと、直前の変更を誰が止めるかは会社次第
細部が決まっていないデザイン	例外の時の表示や細かい動きが決まっておらず、実装しながら自分で決めるか、関係者に聞いて回る	残る。自分で決めてよい立場かどうかは会社で違う
デザイナーが少ない	デザイナーが減ってから、差し戻しが増えた	会社による
LP・バナーの制作や CMS の更新が来る	マークアップの担当がいないので、キャンペーンの LP やバナーの差し替えを頼まれる	会社による
成果が見えにくい	直した細部は誰も気づかず、評価では機能の数で話が進む	見えにくい仕事であることは変わらない。評価の基準と評価者は会社で違いうる

冒頭の例でいえば、リリース前の残業、Safari の崩れ、差し戻しのやりとりはフロントの仕事そのものです。それがここまで重くなったのは、デザイナーの減員、LP の依頼、3 日前の変更を止める人がいないことが重なったからです。この 3 つは、会社を選べば減らせます。

デザイナーが担っていた仕事の大きさについては、事業会社のフロントエンドエンジニアの声があります。UI デザイナーが辞め、代わりが来るまで本人がデザインも担うことになった。自分で画面をデザインする時に何を基準に余白を取ればよいか分からず、実装を見せるとプロダクトオーナーから「なんとなく違う」という感覚で意見が出ることがあった。そのうえで、プロダクトオーナーを含むメンバーを説得するやりとりの大部分を、少なくとも当時のチームではデザイナーが担っていたと気づいた、と書いています。

LP やバナーまで頼まれるかは、求人票の業務内容で分かる

求人票から分かるのは、ほかの仕事を兼ねるかどうかと、チームの体制の一部です。当サイトの掲載求人では、LP・バナー・メルマガの制作や CMS の更新などを仕事として書く会社が約 10% ありました。業務内容にこれらが並んでいれば、その会社でもフロントの人に LP やバナーの依頼が来ると考えてよい、というのが当サイトの見立てです。今の状況を変えたいなら、まずここを見ます。ただ、書いていない会社でも頼まれないとは限らないので、面接でも確かめます（下の 3 問目）。

ほかに求人票から分かるのは、次の 3 つです。

• デザイナーとの連携を仕事として書く会社は約 30%。デザイナーの人数は、多くの求人票に書かれていません
• デザインシステム・コンポーネント設計・Storybook の語がある会社は約 20%。ただし、これで分かるのは、そうした仕組みを使っていることまでです。余白や色の基準を誰が決め、誰が直すかは書かれていません。今の職場にも Storybook が入っているなら、なおさらそれだけでは違いになりません
• 技術選定に関わると書く会社は 25〜30%、パフォーマンスや表示速度の改善を仕事として書く会社は約 25%。画面を作る以外の仕事もフロントに任せる会社かどうかの手がかりになります。技術選定は、業務内容の欄にあるか、必須の条件の欄にあるかで意味が変わります

反対に、デザインの直しの進め方、納期や仕様変更の決め方、エンジニアの評価の仕組みを書いている会社は、どれも 5% 未満でした。数少ない例では、開発の方向性や納期をエンジニアが決めるので無理なスケジュールにならない、と書く求人があります。こうした書き方は会社自身の説明なので、書いてあっても面接で中身を確かめます。

面接では、直近のリリースで誰が何を決めたかを聞く

方針を聞くと、どの会社も良い面を話します。そこで方針ではなく、直近の出来事を聞きます。できればカジュアル面談で、同じチームのフロントの人にも同じ質問をしてください。採用担当とフロントの人で答えが食い違えば、そこを確かめ直す手がかりになります。聞くことは、大事な順に次の 4 つです。

1. 直近のリリースの直前に仕様やデザインが変わった時、延期するか機能を削るかは誰が決めましたか

• 危ない答え: 走りながら柔軟に作っている、そこはみんなで調整している、という答え。誰がいつ決めたかが出てきません
• 良い答え: 前回は実装の途中で余白の変更が入ったので、PM が判断してその部分を次のリリースに回した、という答え。誰が決め、どうなったかまで出てきます

続けて、そのリリースの前の週にフロントの人が何時ごろまで残っていたかを聞くと、リリース前の残業の重さが分かります。

2. 直近のリリースで、デザインが固まったのは実装を始める何日前でしたか。その後に来た直しは、どこで打ち切りましたか

何日前なら安全という目安は、この記事では示せません。見るのは日数より、固まった時点を答えられるかと、打ち切った人や決まりの名前が出るかです。実装と並行で詰めていく、という説明で終わるなら、直しのやりとりを打ち切る仕組みが無いと考えてよいと思います。

3. LP やバナー、キャンペーンの依頼は、どなたが受けていますか。前回の依頼は誰が作りましたか

タイトルの「LP やバナーまで頼まれる会社」かどうかは、ここで確かめます。危ないのは、手が空いている人がやる、フロントで分担している、といった受け手の決まっていない答えです。良いのは、制作の担当や外部の会社など、受け手の名前が出てくる答えです。

4. 前回の評価で、フロントの方はどんな仕事が評価されましたか。評価するのはエンジニアの方ですか

返ってきたのが機能の数だけなら、評価のされ方は今の会社と同じだと思ってよいでしょう。ブラウザの不具合の修正や差し戻しを減らした仕組みが理由として出てくれば、画面の見た目以外の仕事も評価に入っていると考えられます。

辞めるか、会社を変えるかの分かれ目

分かれ目は、直しのやりとりとリリース前の残業そのものが耐えられないのか、ほかの仕事が重ならなければ続けられるのかです。

リリース前に忙しいのは仕方ないと思えていて、しんどいのは LP の依頼やデザイナー不足が重なることや、評価で見た目の担当扱いされることなら、同じフロントのまま会社を変えることで軽くなる部分があります。

その場合、身につけた TypeScript の経験を捨てることにもなりません。当サイトの掲載求人では、TypeScript の語がある会社は約 55% でした。

デザイナー寄りやバックエンド寄りに職種をずらした時に不満が減るかは、比べた資料が手元に無く、この記事では示せません。ただ、当サイトの掲載求人では、バックエンドまで担当しうると書くフロントの求人を出す会社も約 10〜15% あり、フロントのまま範囲を少し広げる会社も選択肢に入ります。

反対に、直しのやりとりとリリース前の残業そのものが耐えられないなら、会社を変えても同じ場面に戻ります。その場合は、会社より職種を考え直すほうが先です。

今の会社に残る道もある

デザイナーが手一杯なら、PM か上長に、範囲を絞って頼みます。たとえば、リリース前の 1 週間はデザインの変更を受けない、LP の依頼は上長を通す、くらいです。頼みが通ったかどうかより、頼んだ後に実際に何か変わったかを見て判断します。区切りは、次のリリースを 1 回終えて、同じように直前に作業が集まったら動く、くらいが自然です。

差し戻しは、自分でも減らせることがあります。直近のリリースの差し戻しを、Figma に指定があったのに実装がずれていたものと、どこにも指定が無かったものに分けてみると、原因が見えます。後者が多ければ、人数より基準が無いことの問題です。そうなら、余白や読み込み中の表示など、指定が無い時の決まりを自分で案にして、デザイナーには可否だけを短時間で確認してもらい、Storybook の共通部品に入れておきます。次のリリースで差し戻しがどう変わったかを数えておけば、評価面談でも転職の面接でも、画面を作る以外に自分で進めた仕事として話せます。

求人を見て、カジュアル面談で直近のリリースの話を聞くところまでは、辞めると決める前に在職中にできます。

よくある質問

転職すれば年収は上がりますか？

LP の依頼やデザイナー不足が減ることと、年収が上がることは別の話です。同じ年齢・経験年数の人と比べた今の年収の水準は、別の記事「フロントエンドエンジニアの年収は低い？　同じ年齢・経験年数の開発者の平均年収と比べる」で扱っています。

職務経歴書で「見た目を作っていた人」に見えない書き方はありますか？

起きた出来事より、自分が何を判断し、その結果どうなったかを書きます。たとえば、リリース 3 日前の API の変更に対応して予定どおりリリースした、iOS の Safari だけで起きる日付選択の不具合を特定して直した、という書き方です。差し戻しの件数を書くより、差し戻しを減らすために作った仕組みがあれば、そちらを書きます。

業務で技術選定をしたことがなくても、技術選定を書く求人に応募していいですか？

通るかどうかは会社によります。まず、技術選定が「業務内容」にあるか「必須の条件」にあるかを見てください。業務内容にあるなら入ってから関わる仕事、必須の条件にあるなら経験を求めている、という書き方の違いです。社内でフレームワークの移行などが進んでいるなら、その中で何を担当したかが話の材料になります。

Storybook やデザインシステムがある会社なら、直しのやりとりは減りますか？

語があるだけでは言えません。今の職場に Storybook があっても差し戻しが多いなら、なおさらです。減るのは、余白や色の基準を共通の部品として持ち、それを誰が決めて直すかが決まっている会社です。それは求人票にはほとんど書かれていないので、面接で直近のリリースの修正をどこで打ち切ったかを聞いて確かめます。

この記事の数字と声について

• 当サイトの数字は、2026 年 9 月 30 日時点で当サイト PREVIO に掲載していたフロントエンドエンジニアの求人のうち、求人のタイトルからフロントエンドの仕事と分かるものを、会社単位で数えました。「書く会社」は、その区分に当たる求人を 1 件以上出している会社です。仕事内容などの本文に語や記述があるかを機械で拾い（応募資格の欄は数えていません。本文中の応募条件の文は入っています）、一部は人の目で確かめて直した結果で、割合は 5% 単位に丸めています。技術選定の語は、求める人物像の文で当たったものも含みます。日本のフロントエンドの求人全体の数字ではありません。書いていないことは、無いことを意味しません
• job tag の説明は「システムエンジニア（Webサービス開発）」のもので、要件定義やバックエンドも含む SE の説明です。job tag にフロントエンドエンジニアだけの職業はありません
• デザイナーが辞めた後に自分でデザインを担ったフロントの人の話と、開発の方向性や納期をエンジニアが決めると書く求人の例は、個人の声と会社自身の説明として紹介しています
• 業務内容に LP・バナー・CMS があれば同じ仕事が回ってくると読むこと、技術選定やパフォーマンス改善の記述を、画面を作る以外の仕事も任せる会社の手がかりとすること、修正の打ち切りの取り決めや共通の部品で直しの回数を減らせるとすること、面接の答えの見分け方、TypeScript の語がある会社の割合から TypeScript の経験が無駄にならないとすることは、当サイトの見立てです
• 社内での頼み方、待つ期間の区切り方、差し戻しを分けて決まりを作る手順、職務経歴書の書き方、転職の準備の進め方は、当サイトの助言です