オファー面談で映された組織図スライドを見て、Yさん(33歳・Webデザイナー経験9年)は「あれ」と思ったそうです。自分が応募したのは「デザインエンジニア」の求人なのに、その役職名が入っていたのは開発本部ではなく、デザイン室の箱の中でした。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、デザインエンジニアやUIエンジニアの相談で年収の話がかみ合わない原因は、スキルの高低よりも、その求人の人件費がどの職種の予算から出ているかにあることがほとんどです。今回は、実際の相談事例を交えながら、求人票とオファー面談で「どの枠で評価されているか」を見抜く基準をお伝えします。

今回は、次の内容に沿ってご紹介します。

  • デザインエンジニアの専用の年収統計がなく、「予算枠」で提示額が決まってしまう構造
  • デザイナー枠とフロントエンド枠で、提示額の根拠がどう変わるか(Yさんの事例)
  • 求人票の所属・応募要件・評価者から枠を読み取る手がかり
  • オファー面談で、どの職種グレードに載っているかを確認する質問
  • 枠を移したいときに、面接で何を主役に語るか
目次
  1. デザインエンジニアの年収に「専用の統計」がない理由
  2. 予算枠とは、人件費を出す部署の給与テーブルのこと
  3. 同じ求人で提示額が割れたYさんの事例
  4. 交渉は「額」ではなく「どのテーブルか」から
  5. 求人票で枠を見分ける5つの手がかり
  6. 同じ会社の別求人が、最大のヒントになる
  7. デザイナー枠とフロントエンド枠で何が変わるか
  8. 年収の水準は「調査」と「現場感覚」を分けて読む
  9. オファー面談で聞くべき質問
  10. グレード確認は、年収交渉の前に済ませる
  11. デザイナー枠が不利とは限らない場面
  12. 面接で何を主役に語るか
  13. ポートフォリオは「どちらの評価者に見せるか」で選ぶ
  14. 枠は後から動かせるのか
  15. よくある質問
  16. まとめ

デザインエンジニアの年収に「専用の統計」がない理由

「デザインエンジニア 年収」で調べると、Webデザイナーの平均年収かフロントエンドエンジニアの平均年収のどちらかに行き着きます。私が確認した範囲では、デザインエンジニアやUIエンジニアだけを切り出した年収統計は見当たりませんでした。

これは調査が足りないというより、職種として定義が揃っていないことが原因です。同じ「デザインエンジニア」でも、Figmaでデザインを作ってコードまで書くデザイナーを指す会社もあれば、デザインシステムを実装して保守するフロントエンドエンジニアを指す会社もあります。名前は同じでも、中身の比率が会社ごとに違うのです。

だから年収の相場を探すとき、「デザインエンジニアの平均はいくらか」という問い自体が成り立ちにくい。成り立つのは「この求人はどちらの給与テーブルに載っているか」という問いのほうです。

予算枠とは、人件費を出す部署の給与テーブルのこと

予算枠と書きましたが、難しい話ではありません。会社には職種ごとに給与テーブルやグレード表があり、採用ポジションの人件費はどこかの部署の予算から出ます。デザイン室の採用枠で入れば、デザイナーのテーブルで査定されます。開発本部の枠で入れば、エンジニアのテーブルです。

新しい職種ほど、この線引きが曖昧なまま求人が出ます。実装もできるデザイナーが欲しい会社と、デザインの感覚があるフロントエンドが欲しい会社が、同じ言葉で募集しているのが実態です。

民間の調査を見ると、二つのテーブルの出発点が違うことは確かです。dodaの「Webデザイナーの平均年収」によれば、2024年12月時点でWebデザイナーの平均年収は378万円(全職種の平均は426万円)で、年代別では20代が341万円、30代が407万円でした(出典:doda「Webデザイナーの平均年収」)。

一方、JAC Recruitmentが公開しているフロントエンジニアの年収データは、JAC経由の転職実績(2024年1〜12月)で、ボリュームゾーンが700万円前後、30代で520万〜600万円というものです(出典:JAC Recruitment「フロントエンジニアの年収」)。

ただし、この二つの数字を並べて「デザイナーはエンジニアより低い」と読むのは雑です。前者はWebデザイナー全体の平均、後者はJAC経由の転職実績で、集計の対象も方法も違います。ここで言いたいのは、二つのテーブルは出発点の水準そのものが違う前提で動いているということだけです。

同じ求人で提示額が割れたYさんの事例

冒頭のYさんの話に戻ります。Yさんは旅行系メディアを運営する事業会社でインハウスデザイナーを9年務め、現年収は480万円ほど。コーディングは自分でこなし、直近ではデザインシステムのコンポーネントをReactで実装する仕事もしていました。自社開発のSaaS企業の「デザインエンジニア」求人に応募し、実装の経験を評価されて最終面接まで進みます。

オファー面談で提示されたのは年収510万円でした。現年収からは30万円ほど上がっています。ただ、Yさんは別のエージェント経由で、同じ会社が出している「フロントエンドエンジニア」求人のレンジが600万円台からだったことをメモしていました。その場で聞いたところ、人事の答えは「デザインエンジニアはデザイン室の所属なので、デザイナーのグレードで評価しています」というものでした。

Yさんは私に相談に来て、こう言いました。「実装もやるのに、なぜ設計図を描く人と同じ物差しなんですか」。私の見立ては少し違いました。会社側に悪意があるわけではなく、デザイン室の予算で採った人材は、デザインの給与テーブルでしか査定できない仕組みだったのです。

交渉は「額」ではなく「どのテーブルか」から

私がYさんにお勧めしたのは、増額を求める前に、評価の枠そのものを確認することでした。Yさんは人事に「実装範囲が広いので、エンジニアのグレードで再評価してもらえないか」と書面で問い合わせます。返ってきた答えは、デザイン室所属の職種は全員デザイナーのグレード体系で運用しており、個別の例外はつくれない、というものでした。

結果として、Yさんはその会社を辞退します。別にフロントエンドエンジニア枠で「デザインシステム担当」を募集していた別のSaaS企業を受け直し、年収640万円で内定しました。もちろん、全員が同じように動けるわけではありません。Yさんは実装の比重が実際に高かったから通ったのであって、この例は再現性を保証するものではありません。

それでも、この事例から持ち帰ってほしい点は一つです。提示額の差は、本人の価値ではなく、載っているテーブルの差で説明がついてしまうことがある。そして、このテーブルは面談の場で聞かなければ見えません。

求人票で枠を見分ける5つの手がかり

オファー面談で初めて枠を知るのでは遅いので、求人票の段階である程度は推測できます。私が求人を読むときに見ているのは、次の5点です。

求人票で「枠」を推測する手がかり

  • 所属部署:デザイン室・クリエイティブ部門か、開発本部・プロダクト開発部か
  • 応募要件:Figma・ポートフォリオ(制作実績)が先頭か、React/TypeScript・テスト・CI経験が先頭か
  • 選考で出る課題:デザインのレビュー・UI設計の説明か、コーディング課題・コードレビューか
  • 面接官の肩書き:デザインリード・ヘッドオブデザインか、EM・テックリードか
  • 同社の別求人:同じ会社に「フロントエンドエンジニア」や「UIデザイナー」の求人が別にあるか

どれか一つで決まるわけではありません。ただ、所属部署と応募要件の先頭が同じ方向を向いていれば、その枠で評価される可能性はかなり高いと見ています。

同じ会社の別求人が、最大のヒントになる

5つのうち、私が一番役に立つと感じているのは最後の「同社の別求人」です。同じ会社が「フロントエンドエンジニア」の求人を出していれば、そこに書かれたレンジが、その会社のエンジニアテーブルの目安になります。「UIデザイナー」の求人があれば、デザイナーテーブルの目安になる。

そのうえで、手元の「デザインエンジニア」求人のレンジがどちらに近いかを見ます。レンジが明記されていない場合でも、応募要件の求めるレベル(「チームのコード品質に責任を持つ」「デザインシステムを設計する」など)が、どちらの別求人に近いかで当たりはつきます。

テックリードの求人でも似た話をしましたが、肩書きより中身で見るというのは、新しい職種ほど有効な原則です(関連:テックリード求人の年収レンジの見方)。

デザイナー枠とフロントエンド枠で何が変わるか

ここまでを整理すると、枠によって次のような違いが出ます。年収そのものだけでなく、評価の仕方や昇給の経路も違うので、一覧にしました。

比べる点デザイナー枠フロントエンドエンジニア枠
評価の軸画面・体験の品質、制作物の説明力コードの品質、保守性、開発速度への貢献
昇給の比較対象デザイナーの上位グレードエンジニアの上位グレード
給与の出発点民間データ上はやや低め民間データ上は高め
昇進の行き先デザインリード、アートディレクターテックリード、EM、スタッフ職

「給与の出発点」の行は、先ほどのdodaとJACのデータから読み取れる水準の違いを書いたもので、この表の数字が確定した相場というわけではありません。

年収の水準は「調査」と「現場感覚」を分けて読む

ここで正直に線引きをしておきます。dodaやJACの数字は調査として確認できますが、「デザインエンジニアの提示レンジが◯万円」という調査は私が確認できませんでした。以下は調査ではなく、私が現場で見ている求人傾向です。

デザイナー枠のデザインエンジニア求人は、同じ年代のWebデザイナーの上位層に近いレンジで出ることが多く、実装ができる分だけ上乗せされる、という程度の印象です。フロントエンドエンジニア枠のデザインエンジニア求人は、フロントエンドエンジニアのレンジにそのまま乗ることが多い、というのが私の印象です。

結論として、平均年収の数字を探すより、手元の求人がどちらのテーブルに載っているかを確認するほうが、金額の見通しは早く立つと私は考えています。

オファー面談で聞くべき質問

求人票で見当をつけたら、面接の後半かオファー面談で、枠を直接確認します。聞き方次第で、角が立つこともなければ、情報が取れないこともありません。

枠を確認するための質問

  • 「このポジションは、どの職種のグレード体系で評価されますか」
  • 「昇給や昇格の比較対象は、デザイナーのメンバーですか、エンジニアのメンバーですか」
  • 「評価面談で私を見る方は、デザインリードですか、エンジニアリングマネージャーですか」
  • 「同じ職種名で入社された方は、現在どちらの部署に所属していますか」

一つ目で給与テーブルを、二つ目で昇給の経路を、三つ目で評価者を確認します。四つ目の「すでに入社している人」の所属は、嘘をつきにくい事実なので、実態が一番出やすい質問です。

グレード確認は、年収交渉の前に済ませる

グレードや号俸そのものの確認方法は、別の記事で詳しく書いています(関連:オファー面談でグレードと号俸を確認する質問)。デザインエンジニアの場合は、それ以前に「どの職種のグレードか」を一段前に確認する点だけが違います。

交渉の順番は、まず枠、次にグレード、最後に金額です。枠が違えば同じ金額を求めても通る土台が違うので、金額の交渉から入ると、会社の側は「デザイナーの給与テーブルの上限」を理由に断るだけで済んでしまいます。

ポイント: 提示額の交渉の前に、「どの職種の給与テーブルで評価されているか」を確認する。ここを聞かずに金額だけ求めると、テーブルの上限という一言で終わる。

レンジが公開されている求人の見方については、別の記事でも触れています(関連:求人票の年収レンジと提示額のずれの見方)。

デザイナー枠が不利とは限らない場面

ここまで読むと「フロントエンド枠のほうが得」という話に見えるかもしれませんが、そうとは言い切れません。年収の絶対額だけで枠を選ぶと、数年後に困る人も見てきました。

たとえば、デザイナー枠はデザインリードやアートディレクターへ進む道が明確で、チーム全体のUXの判断を任されやすい環境です。実装もできるデザイナーは社内で希少なので、組織のなかで裁量が大きく、年収が上がらなくても任される仕事の幅が広がります。デザインの意思決定に関わりたい人にとっては、フロント枠より向いている会社もあります。

反対にフロントエンド枠では、評価の中心がコードの品質と開発の速度になります。デザインへの関心が強い人が入ると、画面の細部を詰めても評価に反映されず、プルリクエストの数やテストの網羅で見られる、というズレが起きることがあります。

私が相談で伝えているのは、年収の額と、将来どちらのキャリアの階段を登りたいかを、二つ並べて決めるということです。額が低めに出ても、登りたい階段がデザイン側にあるなら、その枠は合理的な選択になります。逆に、額を理由に枠を選んだのに、評価の軸が自分の強みと合わないと、半年後に再び転職を考えることになりかねません。

面接で何を主役に語るか

枠は会社が決めるものですが、面接での語り方は、どちらの枠で評価されやすいかに影響します。私が支援してきた感覚では、ここは出身によって落とし穴が違います。

デザイナー出身の方は、実装経験を「少しコードも書けます」と控えめに語りがちです。控えめに語ると、会社は迷わずデザイナー枠で評価します。実装の範囲を、担当したコンポーネントの数・使ったフレームワーク・レビューを受けた経験といった具体で語ると、エンジニア側の評価者にも伝わります。

逆にエンジニア出身の方は、デザインの話を「センスはないですが」と引いて語りがちです。ただ、デザイン側の評価者が見たいのは作品の巧拙より、デザインの意図をどう実装に落としたかという判断の説明です。こちらも具体的に話せるほうが、評価の枠が広がります。

ポートフォリオは「どちらの評価者に見せるか」で選ぶ

ポートフォリオの載せ方も、枠に合わせて変えます。デザイナー枠を狙うなら、画面設計の意図や改善前後の比較を前に出します。フロント枠を狙うなら、コードの構成・テスト・READMEに書いた判断の理由が評価されます。フロントエンドのポートフォリオに何を載せるかは、別の記事で具体例を挙げているので、参考にしてください(関連:フロントエンドエンジニアのポートフォリオに何を作るか)。

両方に出す場合は、1本の作品を二つの見せ方で用意するのが現実的です。一つの資料で両方の評価者を満足させようとすると、どちらにも刺さらないものになりやすいからです。

枠は後から動かせるのか

入社してから枠を移せるのかという相談も、よく受けます。結論から言うと、会社によります。私が見ている範囲では、職種転換の制度が明文化されている会社は多くありません。口頭の「状況を見て」という約束は、ほとんど残らないのが実態です。

動かしやすいのは、入社時点で評価の枠と昇格の条件を書面にしておけた場合です。特に「半年後にエンジニアのグレードで再評価する」のような条件は、口頭の約束ではなく、雇用条件通知書や評価制度の資料に載せてもらうほうが確実です。

もう一つ、フロントエンドからデザインエンジニアに移る場合も同じ構造があります。フロントエンドエンジニアとして実務を積んでから、デザインシステム担当やUI専任のポジションに移ると、エンジニアのテーブルを保ったままデザインに近い仕事ができます。実装力が土台にある人は、枠をエンジニア側に置いておくほうが、年収は守りやすいと私は見ています。フロントの転向期間と年収の話は、別の記事で書きました(関連:jQueryからモダンフロントへの転向にかかる期間)。

ちなみに、フルスタックの名目で入ってフロント専任になる話のように、業務の中身と看板がずれる問題は別軸で起きます(関連:フルスタック求人でフロント専任になる問題)。今回扱っているのは業務の範囲ではなく、給与テーブルのずれです。両方が重なる求人もあるので、注意してください。

よくある質問

UIエンジニアとデザインエンジニアは同じ職種ですか。 会社によって違います。UIエンジニアは「UI実装に強いフロントエンドエンジニア」を指すことが多く、デザインエンジニアは「デザインと実装の橋渡しをする人」を指すことが多いという傾向はあります。ただ、この傾向は定義が揃っているわけではないので、肩書きではなく、所属部署と応募要件で確認してください。

デザイナーからデザインエンジニアに移ると、年収は下がりますか。 下がるとは限りません。実装の比重が高く、エンジニア枠で評価されれば、むしろ上がる場合があります。反対に、デザイナー枠のまま実装の仕事も増えると、年収は上がらず業務だけ増えるケースがあります。枠の確認が先です。

デザインエンジニアの求人は少ないですか。 肩書きとして明示された求人は、フロントエンドエンジニアやUIデザイナーに比べて数は多くありません。ただ、「デザインシステム担当」「UI実装」「フロントエンド(デザイン連携)」のような別の名前で、実質同じ仕事の求人が出ていることがあります。肩書きだけで絞らず、仕事内容で探すほうが見落としません。

ポートフォリオはデザインとコードのどちらを載せればいいですか。 狙う枠で決めます。デザイナー枠ならデザインの意図と改善の経緯、フロントエンド枠ならコードの構成と判断の理由を前に出します。両方を狙うなら、同じ作品を二つの見せ方で用意するのが現実的です。

まとめ

デザインエンジニア(UIエンジニア)の年収は、専用の統計がないために「平均はいくら」と探しても答えが出ません。ここまで書いてきたのは、同じ肩書きの求人でも、人件費がデザイナー枠から出ているかフロントエンドエンジニア枠から出ているかで、提示額の前提が変わるという構造でした。Yさんの事例のように、本人の実力ではなく載っているテーブルで額が決まってしまうことがあります。

求人票では所属部署・応募要件・同社の別求人を見て、面接では「どの職種のグレードで評価されるか」を金額の前に確認する。それだけで、提示額に納得できるかどうかの判断材料はかなり揃います。

私が一番伝えたかったのは、金額の交渉より前に、自分がどちらの枠で評価されているかを確認することのほうが先だということです。新しい職種ほど、肩書きは会社ごとに意味が違います。確認すること自体を、遠慮しないでください。