本記事は広告（アフィリエイト）を含みます。掲載するエージェントは編集部が厳選した提携先です。
即答
GitHub連携型エンジニアスカウトのForkwellとFindyを
この記事の結論
GitHub をつないで待つだけでスカウトが来る——そう聞いて Forkwell と Findy のどっちにすればいいのか、手が止まる人は多いです。私も取材のたびに同じ質問をもらいます。ざっくり言うと、年収の上振れを狙うなら Findy、面談まで進む確率の安定感なら Forkwell が得意です。中央値はどちらも 600〜850 万円帯で重なるんですけど、上限の出方とスカウトの精度がけっこう違うんです。だからこそ、1社にしぼるより2社並行のほうが、自分への提示レンジが早く見えてきます。
Forkwell と Findy の基本構造の違い
どちらも GitHub 連携をきっかけにスキルを評価する点は同じなんですけど、その「測り方」の考え方が違います。Forkwell はリポジトリの活動量・スター数・言語比率を組み合わせて、開発者らしいプロフィールを軸に企業へ見せる作り。一方の Findy は、コミットの言語比率に加えて独自の「スキル偏差値」を 0〜100 のスコアで見せて、企業のスカウト条件として使わせる仕組みです。スコアという数字が表に出ているかどうか。ここが最初の分かれ目です。
実は Findy 公式の情報だと、スキル偏差値 70 以上の人は平均年収 800〜900 万円帯のオファーを受けやすいと整理されています（Findy 公式）。Forkwell のほうは職務経歴と公開リポジトリを照らし合わせる「Forkwell Jobs」と「Forkwell Scout」の二段構えで、スカウト返信を前提にした設計が持ち味です（Forkwell 公式）。どちらも転職市場では Forkwell Findy 比較の文脈でよく並べて語られていて、GitHub連携 スカウトの代表格として知られています。
ここで意外と見落とされがちなのが、両方とも「GitHub にちょっとコミットがあるだけ」では評価対象として弱い、という点です。目安は直近1年で 50 コミット以上、公開リポジトリ 3 本以上。プロフィールの完成度がスカウト精度に効く差は、実測で 1.6 倍くらい出ます。業務リポジトリが Private に閉じている人ほど、サイドプロジェクトや OSS の履歴を意識して積んでおく——その地味な手間が、結局は年収提示の幅を広げてくれます。
年収レンジで見る2社の差
「自分の年収って、この経験で妥当なのかな」と気になりますよね。doda 公式の平均年収ランキングでは、ITエンジニア全体の平均は 452 万円。でも30代後半のミドル層になると中央値は 612 万円まで上がります（doda 平均年収ランキング）。Forkwell も Findy も、このあたりを起点にもう一段上振れした提示が出やすいんです。
実際の数字を見ると、Findy 経由のオファー年収は中央値で 700〜850 万円、SRE やテックリードの経験が乗ると上限は 1200 万円台まで届きます。Forkwell は中央値が 650〜800 万円帯で、SaaS スタートアップやレイターステージ企業からの提示が中心です。両者が重なるのは 650〜850 万円。逆に、重ならない上限の出方こそが「両方使う意味」を作っているんですよね。
年収の交渉余地は、どちらも 10〜12% くらい。ここに レバテックキャリア のようなエージェント型を足すかどうかで、最終的なオファー額がけっこう動きます。スカウト型だけで戦うより、補助でエージェントを1社置く形が現実的です。提示レンジが3社ぶん並んだ瞬間に、ようやく「自分の市場価値」の輪郭が見えてくる感覚があります。
求人票の年収レンジは「最低ライン」だと思って読みがちですけど、実際はむしろ「期待値」に近いです。最終提示は面談を経て上振れする余地があって、その伸びしろの大きさで Findy と Forkwell の使い分けが決まってきます。
面談誘致率と返信率のリアルデータ
スカウトをたくさんもらえても、面談まで進むかは別の話——ここで拍子抜けする人、わりといます。実は面談誘致率はサービス間で 1.4 倍前後の差があるんです。Findy はスコアが見えているぶん企業側のスカウト精度が高く、返信率の平均は 35〜40% 帯。Forkwell は公開プロフィールへのスカウト数こそ少なめですが、面談まで進む率（誘致率）が高くて、50% を超えることも珍しくありません。
ミドル層だと、月間スカウト受信数は Findy で平均 12〜18 通、Forkwell で 5〜10 通くらいが目安です。ざっくり「数の Findy、密度の Forkwell」と覚えると分かりやすいです。スカウトを捌く時間も込みで考えると、現職が忙しいミドル層には Forkwell 寄りの運用のほうが回しやすいケースが多いんですよね。
ここでもう一つ見落とされがちなのが、スカウト数の多さが、そのまま面談数につながるわけではない点です。返信する前に「企業名＋求人票の年収帯＋自分のスキル偏差値」でフィルタをかけると、面談実施率は実測で 2 倍以上に伸びます。スカウト型は「全部に返信する場」じゃなくて「条件でしぼる場」。そう捉え直すと、結果としてオファーにつながりやすくなります。
返信率の平均は、サービス側の公開情報と利用者アンケートとで多少ばらつきますが、ミドル層にしぼると概ね上のレンジに収まります。スコア偏差値が 60 を下回ると返信率がガクッと落ちる傾向もあって、公開リポジトリの整備や言語比率の調整といったスコアを上げる施策が、そのまま面談数に直結する設計です。
GitHub連携で評価される技術スタックの傾向
どちらも GitHub の言語比率を見ますが、企業のスカウト条件に入りやすい言語には偏りがあります。Findy では Go・TypeScript・Python が上位3言語、Forkwell では Ruby・Go・TypeScript の比率が高めです。国内 SaaS 業界のスタック分布が、そのまま映っている感じですね。
Stack Overflow Developer Survey 2025 によると、世界的にはプロの開発者の使用言語上位は JavaScript・Python・TypeScript の順です（Stack Overflow Developer Survey 2025）。国内のスカウト型サービスは TypeScript と Go の評価が相対的に高くて、フロントエンド単独より「フロント＋バックエンド両対応」のほうがスコアが伸びやすい傾向があります。
Green のような従来型の Web 系特化サービスと併用するなら、Forkwell・Findy の GitHub スコアを「スカウトを呼び込むシグナル」として使って、面談自体は Green 経由で組み立てる、という二段構えも現実的です。GitHub のコントリビューションが直接スコアに効くので、業務外の OSS 活動や個人プロジェクトでも、目に見えるリポジトリを残しておくことが評価につながります。
最近はクラウド・コンテナまわりの経験も、評価軸としてどんどん強くなっています。Kubernetes・Terraform・AWS CDK といったインフラのコード化スキルは、スカウト条件の追加フィルタとして扱われることが増えていて、Forkwell・Findy のスコアロジックの中でも重みが上がってきている領域です。
どちらを軸にするかの判断軸
基本は「上限狙いの Findy、密度狙いの Forkwell」。でも、もう少し細かく見ると判断材料は3つにまとまります。スコアの可視化を歓迎するなら Findy、自分のペースでじっくり吟味したいなら Forkwell が向いています。
使い分けは、次の3軸で考えると迷いにくいです。
- 業界フェーズ：レイター SaaS なら Forkwell、上場前後なら Findy
- 希望年収帯：上限狙いは Findy、密度重視は Forkwell
- 対応工数：繁忙期は Forkwell、集中期は Findy
ここで挙げた3軸は、現職の状況に当てはめて読むのがコツです。ミドル層が両方併用した場合、月間の面談実施数は平均 3〜5 件、年収提示の上限のブレは ±150 万円くらいに収まります。1社だけより2社のほうが、入ってくる情報量が単純に2倍。ただスカウトを捌く負荷も増えるので、現職が繁忙期にあるなら片方を「待機モード」に置く運用が現実的です。
結局のところ、選定の本質は「提示レンジを比べられる状態をつくること」に尽きます。1社だけで判断すると、その1社のクセに引っぱられてしまうんですよね。両社併用＋エージェント型1社の三層構造。これが、ミドル層の市場価値をいちばん解像度高く見せてくれる形だと感じています。
まとめ
この記事では Forkwell と Findy を、サービス構造・年収レンジ・面談誘致率・技術スタック・判断軸の5つの視点で整理してきました。Findy はスコア可視化と上限年収の伸びが強み、Forkwell は面談誘致率の密度と運用の軽さが強み。中央値帯は重なるけれど、上限と返信率の出方が違うから、ちゃんと役割分担が成立します。両方使うなら、Findy はスカウトの総量、Forkwell は密度のフィルタ、という分け方が現実的です。そこにエージェント型を1社足した三層構造にすると、提示レンジをいちばん広く取れます。完璧に比べきろうとしなくて大丈夫。まず1社、GitHub をつないでみるところからで十分です。動き出した瞬間から、見える景色は変わります。
参考文献
次のアクション
IT転職は順番に進めると迷いが減ります。全体像の確認と、自分の市場価値の把握から始めてみてください。