Findyのスカウト文面の作り方｜返信が来る型と避けたい書き方

Findyのスカウト文面を考えるとき、ほかの媒体と同じ「件名と本文を一通で書く」発想のままだと、手が止まります。法人向けのページにあるとおり、Findyは興味のあるエンジニアへの「いいね」を通じてマッチングする仕組みだからです。文面は、いいねの時点で候補者に伝わる情報と、マッチした後に送る最初のメッセージの二段に分けて考えます。この記事では、候補者が自分で入れた情報から一文目を作る方法を中心に、例文と避けたい書き方を整理します。人物像ごとの例文集はFindyのスカウトテンプレートの作り方にあるので、ここでは文面を組み立てる手順に絞ります。

文面は二段に分けて考える

いいねを送る段階では、候補者は企業ページや求人票を見て、反応するかどうかを決めます。この段階で長い文章を読ませる場面は多くありません。だから一段目の「文面」は、実質的には企業ページと求人票です。ここに書いていないことは、いいねだけでは伝わりません。

二段目は、マッチした後の最初のメッセージです。相手はすでに少し興味を示しているので、ここで聞きたいのは「なぜ自分なのか」と「会うと何が分かるのか」の二つです。会社の紹介を最初から繰り返す必要はありません。一段目で伝えたことを前提に、相手に合わせた話を一つ足します。

いいねに添えられる内容や、候補者の画面での見え方は、プランや画面の仕様によって変わることがあります。法人向けページでは商談時にデモ検索ができると案内されているので、実際の画面で「候補者からはどう見えるか」を確かめてから文面を決めてください。

一文目の材料は、候補者が自分で入れた情報から取る

求職者向けのFindyでは、GitHub連携で開発言語ごとのスキルを見るスキル偏差値、職歴やプロジェクトから専門性を整理するキャリア分析、職歴と16の質問への回答から志向性や活躍しやすい環境を診断する価値発揮診断、経験やスキルから見た想定年収が案内されています。候補者が自分で入れた情報や、自分で受けた診断の結果は、一文目の材料になります。下の表は、材料ごとに書ける一文と、書かないほうがよい一文を並べたものです。

表の右側に共通するのは、相手の情報を「見た」とは言っているものの、何を見て、どう結びつけたのかが書かれていない点です。スキル偏差値の数字そのものを褒めても、相手は自分の仕事のどこが評価されたのか分かりません。左側のように、相手の経験と、自社でやってほしい仕事を一本の線でつなぎます。

例文：マッチ後の最初のメッセージ

バックエンドの中堅エンジニアに、決済まわりの作り直しを任せたい会社を想定した例です。会社名や数字は置き換えて使ってください。

興味を返していただき、ありがとうございます。○○社でバックエンドの採用を担当している△△です。

GitHubで公開されている、Goで書かれた非同期処理のライブラリを拝見しました。リトライの設計を細かく分けている点が、いま私たちが抱えている課題に近いと感じています。弊社では来年にかけて決済の処理基盤を作り直す予定で、その設計を一緒に考えてくださる方を探しています。

まずは30分ほど、現場のテックリードと話していただけないでしょうか。いまの構成と、作り直しで迷っている点をそのままお見せします。選考ではないので、ご質問だけでも構いません。

この例文は三つの部品でできています。一段落目は名乗るだけ、二段落目は「相手の何を見たか」と「自社の何につながるか」、三段落目は「会うと何が分かるか」と「誰が出てくるか」です。会社の紹介や福利厚生は書いていません。それは企業ページと求人票の役目です。

候補者の反応がどのような言葉で画面に表示されるかは仕様によって変わることがあるので、書き出しのお礼の一文は実際の画面に合わせてください。

二文目以降は「入社後の最初の三か月」を書く

一文目で相手の経験と仕事を結びつけたら、二文目以降は、入社した後に最初に何をするのかを具体的に書きます。エンジニアが知りたいのは「やりがいのある環境」ではなく、最初に触るコード、最初に話す相手、最初の三か月で求められる成果です。

書き方の目安は次のとおりです。

• 最初に担当するシステムや機能を、名前で書く
• 一緒に働くチームの人数と、レビューを誰がするかを書く
• 技術選定に関わる余地がどのくらいあるかを書く
• 決まっていないことは、決まっていないと書く

最後の一点は軽く見られがちですが、効き目があります。作り直しの方針がまだ固まっていないなら、そう書いたほうが、設計から関わりたい人には魅力に映ります。決まっていないことを決まっているように書くと、面談で話が食い違い、現場のエンジニアの時間が無駄になります。

エラベルの見解

担当する側から見ると、Findyの文面は「書く時間」より「読む時間」で難しさが変わります。相手のGitHubや職歴を読み、自社の仕事のどこにつながるかを一文にするには、技術の話がある程度分かることが前提になります。採用担当や代行の担当者が技術に詳しくない場合でも、現場のエンジニアに「この人のどこを見ればよいか」を三つだけ聞いておけば、読む場所が決まり、一件あたりの時間が安定します。逆に、読む場所を決めずに件数だけ求めると、テンプレートに名前を差し込むだけの文面になります。依頼する前に、担当者が「何を読んで一文を作るのか」を言葉で説明できるかを確かめてください。

避けたい書き方

返信が来ない文面には、いくつかの共通点があります。どれも書き手は善意で書いていますが、エンジニアから見ると「自分のことを見ていない」というサインに映ります。

• スキル偏差値や想定年収の数字に触れて持ち上げる
• 技術スタックを全部並べ、どれを使う仕事なのかが分からない
• 「急成長」「裁量が大きい」など、どの会社にも当てはまる言葉で魅力を語る
• カジュアル面談に誰が出るのかを書かない
• 一通目で選考の日程を聞く

二つ目は特に多い失敗です。求人票に書いた技術を文面でもう一度並べても、相手にとっての情報は増えません。文面では、相手の経験と重なる一つか二つの技術に絞って、それを何に使うのかを書きます。

現場のエンジニアに一度読んでもらう手順

文面ができたら、送る前に現場のエンジニアに一度読んでもらいます。見てもらうのは文章のうまさではなく、技術の話が正しいかと、書いた仕事の中身が実態と合っているかの二点です。採用担当が書いた文面には、「マイクロサービス化を推進中」のように、現場から見ると言い過ぎに当たる表現が混ざることがあります。

毎回見てもらうと現場の負担が大きくなるので、最初の数通だけ見てもらい、直された箇所を言い換えの一覧にして残します。一覧があれば、代行の担当者も同じ直しを繰り返さずに済みます。

エラベルの見解

外に出してよいのは、いいねの送信と、型に沿った最初のメッセージまでです。どの技術の話を入口にするか、入社後の三か月に何を任せるかは、社内で決めて渡してください。ここまで代行に決めさせると、文面はそれらしく整っても、面談で現場のエンジニアが「その話は聞いていない」となり、候補者の信頼を失います。エラベルでは担当者を選んで依頼できるので、技術の話を読み解ける経験のある人を選び、社内で決めた入口の話を正しく文面にしてもらう、という分担がしやすくなります。

まとめ

• Findyはいいねを通じてマッチングする仕組みで、文面は「いいねの時点で伝わる情報」と「マッチ後の最初のメッセージ」の二段で考える
• 一文目は、スキル偏差値やキャリア分析、志向性など、候補者が自分で入れた情報と自社の仕事を結びつけて書く
• 二文目以降は、入社後の最初の三か月に何をするかを具体的に書き、決まっていないことは決まっていないと書く
• 数字で持ち上げる、技術を全部並べる、誰が面談に出るか書かない、の三つは避ける
• 最初の数通は現場のエンジニアに読んでもらい、直しを言い換えの一覧にして残す

よくある質問

Q. いいねを送るときにも長い文章を書くべきですか？

いいねの段階では、候補者は企業ページや求人票を見て反応を決めることが多いので、伝えたいことはまずそこに書きます。いいねに添えられる内容や見え方はプランや画面の仕様で変わることがあるため、商談のデモで実際の画面を確かめてから決めてください。

Q. スキル偏差値が高いことを伝えるのは逆効果ですか？

数字を褒めるだけでは、相手は自分の仕事のどこが評価されたのか分かりません。どの言語の、どの経験を、自社のどの仕事に活かしてほしいのかまで書けば、数字に触れる必要はなくなります。

Q. 例文をそのまま使ってもよいですか？

型として使うのは構いませんが、二段落目の「相手の何を見たか」は一通ごとに書き換えてください。ここを差し替えずに送ると、ほかの媒体の一斉送信と同じに見えます。