Forkwellのスカウトテンプレートの作り方

Forkwellの文面は、書き始める前に一手挟みます。公式サイトが挙げている仕組みに「スカウトする理由をチェックボックスで明確化」があり、「エンジニアのプロフィールを見ながら文面作成できるUI」とセットで説明されているからです。なぜ送ったのかを先に選んでから本文を書く流れなので、文面はその理由を裏づける形になります。この記事では、候補者のプロフィールのどの欄を根拠にするかで三つの型に分け、例文つきで組み立てます。以下は2026年9月24日時点で公式サイトおよびヘルプセンターに記載されている内容に基づいており、運営は株式会社フォークウェルです。

根拠にできる六つの欄

候補者のプロフィールの構成は、ヘルプセンターの記事に詳しく書かれています。ダッシュボードは「経験・スキル」と「やりたいこと・未来」のタブに分かれ、次の六つの欄があります。表の右端は、それぞれの欄を文面でどう使うかです。

ヘルプセンターは候補者に、職歴の書き方としてチームの編成、チームの特徴・課題、使用した技術・バージョン、チームでの役割、チームの課題と自身が工夫したこと、成果（数値や表彰、誰に喜んでもらったか等）というテンプレートを示しています。丁寧に書いている候補者なら、どんな課題をどう解いたかまで読めるので、文面の根拠はここから取るのがいちばん効きます。記事や成果物の欄も、GitHubの登録やブログ・スライドのRSS連携でプロフィールに公開できると案内されており、公開されている記事に触れられれば、読んだことがそのまま伝わります。

型1｜経験技術のレベルを根拠にする

要件と経験技術が正面から重なる場合の型です。いちばん書きやすい反面、テンプレート感が出やすいので、レベルの話で終わらせず、その技術で何をしてもらうかまで書きます。例文では、経験技術の欄と職歴の一文を組み合わせて根拠にしています。

件名：Rails での API 設計のご経験について（決済基盤の刷新）

はじめまして。株式会社◯◯で採用を担当している△△と申します。プロフィールの経験技術で Ruby と Rails が Lv.3 になっていたことと、職歴に書かれていた「仕様変更が頻繁に発生するなかでの API 設計」という記述を拝見してご連絡しました。

弊社では決済まわりの基盤を来期に作り直す予定で、いま同じ悩みの真っ最中です。既存の仕様を壊さずに切り替える設計を、一緒に考えてくださる方を探しています。

求人票に現在の構成と、移行後に使う予定の技術を分けて書いています。まずはそちらをご覧いただいて、もし気になる点があればメッセージで質問いただくだけでも構いません。

最後の一文が効きます。機能一覧には、いいね！でマッチングした場合について面談は任意だと書かれており、チャットだけのやりとりが想定されています。面談を前提にしない返し方を残しておくと、返信の心理的な負担が下がります。

型2｜記事や成果物を根拠にする

公開されているアウトプットに触れる型です。読んでいないのに読んだふりをすると一発で見抜かれるので、具体的な内容に触れられる場合だけ使います。例文では、記事の書き出しに反応したことと、自社がいま同じ課題を抱えていることをつなげています。

件名：◯◯の記事を読みました（監視基盤の設計について）

はじめまして。株式会社◯◯の△△と申します。プロフィールから辿って、監視のアラート設計について書かれた記事を読みました。「鳴らしすぎると誰も見なくなる」という書き出しが、弊社の現状そのもので、思わず最後まで読んでしまいました。

弊社は今その状態を抜けたいと思っていて、SRE の立ち上げを進めています。記事に書かれていた考え方に近い方針で進めたいと考えています。

直近で転職をお考えでなくても構いません。いまどう運用されているかを伺えるだけでも、こちらとしてはありがたいです。

公式サイトは、候補者の声として「フォークウェルで受け取るスカウトはコピペ感がなく、ポートフォリオをしっかり見て送ってくれているという実感があります」という記述を掲げています。この型は、その実感を作る側の書き方です。記事の要約を書くのではなく、どの一文に反応したかを書くと、読んだことが伝わります。

型3｜「やりたい・目指したいこと」に応える

転職の緊急度が高くない相手に有効な型です。ヘルプセンターは候補者に、企業はこの欄を参考にして、会社のビジョンと同じ方向を目指せそうか、本人の希望を自分たちの会社で叶えられる可能性があるかを判断する、と説明しています。企業が見る前提で書かれている欄なので、触れられることを候補者も想定しています。

件名：「小さいチームで裁量を持ちたい」について

はじめまして。株式会社◯◯の△△と申します。プロフィールの「やりたいこと」に、小さいチームで設計から関わりたいと書かれていたのを拝見しました。

弊社の該当ポジションは、いま3名のチームです。設計の意思決定はチーム内で完結していて、稟議に回すのは予算が動くときだけです。裁量がある反面、相談相手が少ないという面もあります。良い面だけでなくそこも含めて、実際のところをお伝えできればと思います。

求人票に所属エンジニアを紐付けていますので、どんなメンバーがいるかも見ていただけます。

求人票の側では、所属エンジニアの紐付け、動画・スライドの埋め込み、エンジニアに特化した魅力タグが使えます。文面で長く説明するより、求人票のどこを見てほしいかを指すほうが短く済みます。三つの型は、使える相手と外れやすい場面が違うので、次の表のように使い分けます。

エラベルの見解

表の比率は、私たちが実務で使っている配分の目安です。型2は根拠が強い反面、アウトプットを公開している候補者にしか使えず、型3は相手の書き込みが薄いと空振りします。結局、全体の結果を決めるのは、型1をどれだけ手抜きせずに書けるかです。「Lv.3のご経験を拝見し」だけで済ませると、ほかの媒体のテンプレートと変わらなくなりますが、職歴欄に書かれた課題と工夫に一行触れるだけで、読まれ方が変わります。担当者を選ぶときも、型2の華やかな例文より、型1の一行に何を書くかを見せてもらうと、この媒体での力量が分かります。

いいね！に添える一言と、避ける書き方

スカウトと並ぶもう一つの経路がいいね！です。ヘルプセンターは、企業がプロフィールを見て「いいね！」と思った点とともに興味を伝える機能だと説明しており、いいね！にも一言が付きます。相手はまだ返信を決めておらず、「直接やりとりを開始する」を押すかどうかを判断している段階なので、スカウト本文とは役割が違います。次の表は、三つの場面で相手がどういう状態にあり、何を書くかを並べたものです。

いいね！の一言は、たとえば「監視まわりの記事と、直近の職歴にあった移行プロジェクトを拝見しました。弊社もいま同じ移行の途中です。」で十分です。プロフィールが薄い相手には、いいね！と一緒に「ポートフォリオのここがもっと知りたい！」を届け、候補者が更新して「更新を通知する」を押すと送信元企業に通知が届く仕組みを使えます。当て推量でスカウトを書くより、更新を待ってから書くほうが根拠が厚くなります。

避ける書き方もはっきりしています。公式サイトは「エンジニアには毎日大量のスカウトメールが届きますが、文面が似通ってくると読まれなくなり、スパムメールと変わらない扱いになります」と書き、スパム化させない仕組みを設けているとしています。求人票の要約を貼ること、年収レンジから書き始めること、根拠なしに「カジュアルにお話ししませんか」とだけ書くこと、同じ文面を条件だけ変えて配ることは、この前提に反します。候補者の側には特定企業にプロフィールを閲覧できないようにする機能もあるので、雑な文面は約59,000人という母集団そのものを減らします。

エラベルの見解

例文を三つ出しましたが、そのまま使うことは勧めません。この媒体の候補者は、コピペかどうかを見分ける目を持っています。使ってほしいのは文そのものではなく、根拠に3割、自社の状況に3割、会い方の提案に2割、返しやすくする一言に2割という構成の比率です。この配分を守れば文章の巧拙はあまり効かず、逆に自社の状況を書かずに相手を褒めるだけの文面は、どれだけ丁寧でも返信になりにくいと考えています。条件の組み方はForkwellの検索条件の組み方、送る順番はForkwellのスカウト運用設計にまとめています。

まとめ

• Forkwellでは「スカウトする理由」を先に選んでから本文を書く。文面はその理由を裏づける形にする
• 根拠はプロフィールの六つの欄から取る。いちばん効くのは、職歴欄に書かれた課題と工夫
• 経験技術・記事や成果物・やりたいことの三つの型を、相手のプロフィールの厚さで使い分ける
• いいね！の一言は一文で足り、情報が薄い相手には「ここがもっと知りたい！」で更新を待つ
• 求人票の要約や同じ文面の使い回しは、スパム化させない仕組みの前提に反し、母集団そのものを減らす

よくある質問

Q. 例文をそのまま自社の文面に使ってもよいですか

そのまま使うことはお勧めしません。候補者は、ポートフォリオを見て送られたかどうかを見分けます。構成の比率（根拠・自社の状況・会い方の提案・返しやすくする一言）だけを借りて、中身は相手の職歴と自社の事実で埋めてください。

Q. いいね！とスカウトは、どちらを先に送るべきですか

相手のプロフィールが薄い場合や、興味の有無を先に確かめたい場合は、いいね！が向いています。いいね！の一言は短くてよく、やりとりが始まってから詳しい話を送ります。職歴や記事から十分な根拠が取れる相手なら、最初からスカウトを書いても構いません。

Q. 文面はどのくらいの長さが適切ですか

公式に文字数の目安は示されていません。技術スタックやメンバーの情報は求人票に載せられるので、文面は根拠と自社の状況、会い方の提案に絞ると短くまとまります。例文のように三段落程度に収め、詳しい説明は求人票のどこを見てほしいかを指す形にするのが扱いやすいです。

※料金・通数・機能の条件は変わります。掲載した内容は2026年9月24日時点で公式サイトおよびヘルプセンターに記載されているものであり、実際の条件は運営にご確認ください。