Wantedlyでフロントエンドエンジニアにスカウトを送る文面の考え方

Wantedlyでフロントエンドエンジニアにスカウトを送るとき、最初にぶつかるのは「自社と同じフレームワークで検索して送っているのに、返信が来ない。来ても、面談で『デザインは誰が決めるのか』『バックエンドも持つのか』を聞かれて止まる」という問題です。結論から言うと、フロントエンドエンジニアへのスカウトは、フレームワーク名の一致で相手を選ぶのではなく、先に自社のフロントエンドの担当範囲と最初に任せる画面を決め、「同じ種類の画面を、同じような使う人のために作っている人」を選び、その人が作った画面を読んだ一文から、自社の画面の場面で誘います。 この記事では、フロントエンドエンジニアがスカウトで見ているもの、送る前に決めること、誰に送るか、プロフィールと成果物の読み方、文面に書くこと、返信後の面談、社内の分担、やりがちな失敗を整理します。エンジニア全般のスカウトの考え方はエンジニアにスカウトを送る文面の考え方、文面の3段の型はエンジニア向けスカウト文面の型、募集記事はフロントエンドエンジニアを採る募集記事の書き方で書きました。

フロントエンドエンジニアがスカウトで見ているもの

「デザイナーとの分担」と「バックエンドとの境界」は、書かれていなければ面談で最初に聞かれます。

送る前に決めること｜担当範囲と、最初に任せる画面

送る前に、社内で二つを決めます。

• フロントエンドの担当範囲：デザインを誰が決めるか、実装者がどこまで変えられるか、バックエンドとの境界、一人目か何人目か。決め方はフロントエンドエンジニアを採る募集記事の書き方で書きました
• 最初に任せる画面：「最初の月は〇〇の画面の作り直しを任せ、△△がレビューする」を一つ。これが文面の2段目になり、送る相手を「その画面を作れる人」に絞れる

誰に送るか｜フレームワークの一致ではなく、画面の種類と使う人の重なり

フレームワークは入れ替わりが速く、いま一致していても次の移行で変わります。選ぶ基準は、「同じ種類の画面を、同じような使う人のために作っているか」です。

「何を直したか」が要点です。自社の最初に任せる画面が「古い画面の作り直し」なら、古い画面を移した経験を書いている人。「使いにくい管理画面の改善」なら、使う人の動きを見て直した経験を書いている人。フレームワーク名は「あればよい条件」に置きます。絞り方の基本はスカウト対象の絞り方で書きました。

公開している成果物の扱い

フロントエンドエンジニアは、作った画面や書いた記事を公開している人が、他の職種より多い傾向があります。あれば読み、文面で「〇〇の画面の△△の部分を見ました」と一文で触れます。ただし、公開していない人を外しません。会社の仕事で作った画面は公開できないことが多く、公開の有無は経験の有無ではありません。

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

相談で最も多い思い込みは、「フロントエンドは技術の入れ替わりが速いから、いま自社と同じフレームワークを使っている人でないと立ち上がらない」というものです。当社は3媒体すべての販売パートナーとしてWantedlyのスカウトを見ていますが、フロントエンドエンジニアが返信した文面を並べると、フレームワーク名が一致していたかどうかは、返信の有無とほとんど関係がありません。関係があるのは、「自分が作った画面を読んでくれたか」と、「デザインを誰が決めるか・バックエンドとの境界が文面で分かるか」の二つです。フレームワークが一致していても、相手がデザイナーと組んで作っている人で、自社がデザインも実装者に任せる会社なら、面談で「聞いていない」になります。当社が対象を組み直すとき、最初にやるのは、検索条件からフレームワーク名を外し、「どの画面を、誰のために作っている人か」で並べ直し、担当範囲を文面の最初のほうに入れることです。

文面に書くこと

文面の型（相手の一文→自社の開発の場面→話す場の案内）はエンジニア向けスカウト文面の型に書いたので、ここではフロントエンド特有の要点だけを書きます。

• 相手の一文は、画面で：「〇〇の画面を作られていると書かれていたのを読んで」「△△の画面の□□の部分を見ました」。フレームワーク名ではなく、画面と、その画面で何を大事にしていたか
• 担当範囲を、最初のほうで：「デザインは社内のデザイナーが決め、使いにくい点は実装側から提案して変えています」「画面と、データのやり取りの部分まで持ってもらいます」。隠さない
• 最初に任せる画面を、一文で：「最初の月は〇〇の画面の作り直しを任せ、△△がレビューします」。募集記事と同じ言葉
• いま決めようとしていることを、一つ：「古い画面を〇〇から△△に移す順番を、いま決めようとしています」。会社説明ではなく、画面の場面
• 話す場は、フロントエンドエンジニアと：「同じ職種の〇〇と、いま作り直している画面を見ながら話します。転職を決めていなくても構いません」

自社が使っている技術は、正確に、理由と一緒に一文で書く場合だけです。相手の技術を評価しません。

返信後の面談｜画面を見せ合う

フロントエンドの面談は、画面を見せ合うと話が進みます。

面談には、フロントエンドエンジニアと、デザイナーがいるならデザイナーが出ます。デザイナーが出ると、「分担」が言葉でなく実際に伝わります。一人目の募集なら、レビューする人が出ます。面談の設計はカジュアル面談の設計で書きました。

選考に進むとき、画面を作る課題を出すなら、面談のときに「課題がある」「どのくらいの時間がかかるか」を先に伝えます。後から出すと、「聞いていない」になります。伝え方はカジュアル面談から選考に進むときの伝え方で書きました。

社内の分担

一人目のフロントエンドエンジニアを採るスカウトでは、「読んで一文を書く人」が社内にいません。その場合は、いま画面を作っている人（バックエンドのエンジニアや、外部の制作会社）に相手のプロフィールを見てもらい、「一人目で、設計は〇〇と相談して決める」と正直に文面に書きます。

運用代行や代理店が支えられるのは、対象の並べ直しの基準づくり、型、避ける言葉のチェック、募集記事との整合の確認までで、担当範囲の決定、相手の画面を読んだ一文、技術の言葉の確認、面談は社内が担います。代理店の代行の範囲は代理店に運用まで頼めるかで書きました。

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

自社で持つべきなのは、「相手の画面を読んで一文を書くこと」までです。当社がWantedlyのフロントエンド向けスカウトを支えるとき、型、対象の基準、避ける言葉、募集記事との整合は当社が出せます。ただし、相手が公開している画面を見て「△△の部分が、うちの〇〇の画面と近い」と言えるのは、画面を作っている人だけです。当社がその一文を作れば、フロントエンドエンジニアには「画面を見ていない人が書いた」と一目で分かります。ここを外に出すと、文面は「〇〇のご経験を活かして」に戻り、返信は来ません。当社が最初にお願いするのは、社内のフロントエンドエンジニア（いなければ、いま画面を作っている人）に、相手の画面を見て一文を言ってもらうことです。その一文があれば、当社は型に組み込み、担当範囲と最初に任せる画面を揃えて、送れる形にします。

やりがちな失敗

最も多いのは、最初の「フレームワーク名の一致で選ぶ」です。

まとめ

• フロントエンドエンジニアは、誰から来たか・自分のどの画面を読んだか・デザイナーとの分担・バックエンドとの境界を、文面の段階で見ている
• 送る前に、担当範囲（デザインを誰が決めるか・どこまで変えられるか・境界）と、最初に任せる画面を決める
• 誰に送るかは、フレームワークの一致ではなく、作っている画面の種類と使う人の重なりで。「何を直したか」を読む。公開している成果物はあれば読み、無くても外さない
• 文面には、相手の画面を読んだ一文、担当範囲、最初に任せる画面、いま決めようとしていることを。相手の技術を評価しない
• 面談は画面を見せ合う。フロントエンドエンジニアとデザイナーが出る。課題を出すなら先に伝える

よくある質問

自社と同じフレームワークを使っている人が、検索でほとんど出ません

フレームワークで絞る必要はありません。「同じ種類の画面を、同じような使う人のために作っている人」で選び、文面に「使っている技術は違いますが、〇〇の画面の作り方が近いと思い」と書きます。

デザイナーがいません。文面にそう書くと、来なくなりませんか

隠すほうが、面談で「聞いていない」で離れます。「デザイナーはいない。いまは〇〇が画面の案を作り、フロントエンドエンジニアが使いやすさの観点で変えている。デザインの判断に関わりたい人と話したい」と書けば、それを前提に読む人だけが返信します。数は減りますが、面談で離れる人がいなくなります。

フロントエンド向けのスカウトの対象の絞り込みは、御社に相談できますか

できます。当社は、対象の並べ直しの基準づくり、文面の型、避ける言葉のチェック、募集記事との整合の確認を支えられます。相手の画面を読んだ一文、技術の言葉の確認、面談は、社内のフロントエンドエンジニアが担ってください。当社はOfferBox・Wantedly・ワンキャリアの販売パートナーとして、Wantedlyのスカウト運用を支えています。3媒体の全体像は3媒体の違いと選び方にまとめています。