Greenでフロントエンドエンジニアを採る｜技術と開発体制の見せ方

フロントエンドエンジニアの求人票を並べると、「React/TypeScriptでの開発経験」という一行がどの会社にも書かれています。技術スタックが似通っている職種なので、技術名だけでは会社ごとの違いが伝わりません。フロントエンドの候補者が求人で見極めようとしているのは、使う技術より、その技術を使って「どこまで決められる立場か」と「誰とどう作るか」です。 この記事では、Green（株式会社アトラエが運営する、IT・Web業界を中心とした中途採用の求人サイト）でフロントエンドエンジニアを採るときに、技術と開発体制をどう見せるかを整理します。

フロントエンドの候補者が求人で見ていること

フロントエンドの候補者が、求人票やスカウトで確かめていることは、おおむね次のとおりです。

• 画面の設計にどこまで関われるか：デザインが決まった画面を実装するだけか、画面の構成や使い勝手の検討から関われるか
• デザイナーとの関係：社内にデザイナーがいるか、どの段階で一緒に議論するか
• バックエンドとの分担：APIの設計に意見を言えるか、フロントエンド側でどこまでデータを扱うか
• 技術的な判断：ライブラリやフレームワークの選定、状態管理の設計を、チームで決められるか
• 品質への取り組み：テスト、表示速度、アクセシビリティにどの程度取り組んでいるか
• 既存のコードの状態：古い仕組みからの移行中か、新しく作るのか

フロントエンドは、デザイナー、バックエンド、プロダクトマネージャーなど、多くの職種とつながる仕事です。そのため、技術そのものより、まわりの職種との関係がどうなっているかで、仕事の中身が大きく変わります。

開発体制の見せ方

フロントエンドの求人票では、開発体制を次のように具体的に書きます。

1. チームの構成：フロントエンドエンジニアは何人か、デザイナーやバックエンドは同じチームか別のチームか
2. 仕事の流れ：企画からリリースまで、フロントエンドエンジニアがどの段階から関わるか
3. デザイナーとの協業：デザインのレビューに参加するか、実装しながらデザイナーと調整するか
4. APIとの関わり：バックエンドとAPIの設計を一緒に決めるか、決まったAPIを使うか
5. 技術選定の進め方：新しいライブラリを入れるときに、誰がどう決めるか
6. いま取り組んでいる改善：表示速度、テストの整備、古い仕組みからの移行など

「デザイナーと密に連携」のような抽象的な書き方より、「画面の設計段階からデザイナーと週に一度レビューをし、実装上の制約をその場で伝えている」のように、場面で書くと伝わります。

エージェントベストの見解

フロントエンドの採用で当社が相談を受けると、最初に「この求人のフロントエンドエンジニアは、画面の仕様を決める会議に出ていますか」と聞きます。出ている会社と出ていない会社では、求める人がまったく違うからです。仕様の議論から関わる会社は、使い勝手やプロダクトへの関心が強い人が合います。決まった仕様を実装する会社は、実装の質や速さを重視する人が合います。ところが求人票では、どちらの会社も「ユーザー目線を持った方」と書いていることが多く、候補者はその違いを読み取れません。仕様の会議への関わり方を一文で書くだけで、合う人からの応募が増え、合わない人の応募が減ります。求人票を書く前に、この一点を現場に確かめてください。

スカウトの書き方

フロントエンドの候補者にスカウトを送るときは、相手の経歴から「どんな画面を、誰と、どこまで作ってきたか」を拾います。

• 弱い書き出し：「Reactでのご経験を拝見しました」
• 直した書き出し：「管理画面のリニューアルで、デザイナーと画面構成から議論し、状態管理の設計を見直された経歴を拝見しました。当社でも、店舗向けの管理画面を使いやすく作り直す段階にあります」

ポートフォリオや公開しているコードがある候補者には、それを見たうえで具体的に触れると、読んだことが伝わります。ただし、見ていないものに触れるのは避けてください。

送り主は、フロントエンドのリーダーか、一緒に働くことになるデザイナーにする方法もあります。デザイナーとの協業を強みにしている会社なら、デザイナーの名前で送ると、開発体制がそのまま伝わります。

検索とターゲットの考え方

フロントエンドの候補者を探すときの考え方です。

• フレームワーク名だけで絞らない：ReactとVueなど、フレームワークが違っても、画面の設計や状態管理の考え方は共通している部分が多い
• 職種名の揺れに注意する：「Webエンジニア」「マークアップエンジニア」「UIエンジニア」など、フロントエンドの仕事を別の名前で書いている人がいる
• 関わってきた画面の種類を見る：一般向けのサービスか、業務向けの管理画面か。自社の画面に近い経験は、立ち上がりが早い
• デザインへの関わり方を見る：デザインから関わってきた人か、実装に集中してきた人か。自社の開発体制に合うほうを優先する

選考へのつなぎ方

フロントエンドの選考では、求人票で伝えた開発体制を、面接でも実際に感じてもらうことが大切です。

• 一次面接：現場のフロントエンドエンジニアが、過去に作った画面での判断（設計、状態管理、パフォーマンスの改善）を聞く。ポートフォリオがあれば、それを題材にする
• デザイナーとの面談：デザイナーとの協業を重視する会社は、選考のどこかでデザイナーと話す場を設けると、候補者が開発体制を実感できる
• 最終面接：プロダクトの方向性と、その中でフロントエンドに期待する役割を話す
• 課題を出す場合：既存の画面の改善点を話してもらう形など、短時間で取り組めるものにする

エージェントベストの見解

フロントエンドの採用を始める前に、当社が勧めている順番があります。求人票を書く前に、社内のデザイナーとフロントエンドのリーダーで「次に入る人に、何を任せたいか」を一度話してもらうことです。フロントエンドの採用では、デザイナーとエンジニアで期待がずれていることがよくあります。デザイナーは「デザインの意図を汲んで実装してくれる人」を、エンジニアは「設計や技術選定を任せられる人」を求めている、というようなずれです。このずれを残したまま求人票を書くと、両方の期待を詰め込んだ求人になり、どちらの期待にも合う人が見つからなくなります。媒体を選ぶ前、スカウトを送る前に、この話し合いを済ませておくと、その後の運用が大きく楽になります。

職種全体の媒体の選び方はフロントエンドエンジニアの採用媒体の選び方に、求人を職種ごとに分けるときの考え方はGreenで求人を複数出すときの分け方にまとめています。

まとめ

• フロントエンドの候補者は、技術名より「どこまで決められるか」と「誰とどう作るか」を見ている
• 開発体制は、チーム構成、仕事の流れ、デザイナーやバックエンドとの関わりを場面で書く
• 仕様の会議に出ているかどうかで、合う人が変わる。一文で書いておく
• スカウトでは「どんな画面を、誰と、どこまで作ってきたか」を拾い、送り主をデザイナーにする方法もある
• 求人票を書く前に、デザイナーとエンジニアで期待を揃えておく

よくある質問

フレームワークの経験は必須にすべきですか

自社のフレームワークの経験を必須にすると、対象が狭くなります。画面の設計や状態管理の考え方が共通していれば、別のフレームワークの経験でも立ち上がれることが多いため、歓迎の経験として書く方法も検討してください。

デザインも担当できるフロントエンドエンジニアを探しています

デザインと実装の両方を担当する人は、候補者の中でも限られます。両方を求める場合は、どちらに比重があるかを求人票で明確にし、求める範囲を具体的に書くと、合う人から応募が来やすくなります。

ポートフォリオの提出を求めてもよいですか

在職中の候補者は、業務で作ったものを公開できないことが多いです。提出は任意にし、ない場合は面接で過去の仕事の判断を話してもらう形にすると、応募のハードルが下がります。