公開: 2026/5/19|更新: 2026/6/30
Findyエンジニア採用完全ガイド|スキル偏差値活用から返信率90%超まで
Findy企業向けの登録から求人設計・いいね運用・スカウト返信率最大化まで実践解説
Findyエンジニア採用完全ガイド|スキル偏差値活用から返信率90%超まで
Findyのスキル偏差値とは、GitHubのパブリックリポジトリ活動を独自アルゴリズムで数値化した相対スコアだ。偏差値60以上が上位10〜15%に相当し、採用担当者が候補者の技術力を可視化するための補助指標として活用できる。ただし「高偏差値しかいいねしない」運用は優秀な候補者を見落とす。筆者が採用支援の実務で培ったFindyの正しい活用法を、登録から運用改善まで体系的に解説する。
「Findyでいいねを送り続けているのに、いいかもが全然返ってこない」——Findy運用を始めたばかりの採用担当者からよく聞く悩みだ。Findyは「いいね型マッチング」という独自の仕組みを採用しており、正しく運用すれば返信率80〜90%超の事例も出ている。一方で他媒体と同じ感覚で使うと「いいねは消費しているのに採用が進まない」という状態に陥る。
このページでわかること
Findyの「いいね型マッチング」の仕組みと他媒体との根本的な違い
スキル偏差値・GitHubスコアの正しい読み方と絶対に避けるべき落とし穴
「いいかも」率を劇的に上げる企業ページ・求人票の設計方法
いいね優先度の設計と職種別コメントの実例
90日活用ロードマップとKPI設計・月次改善サイクル
Findyの料金目安とROI算定の考え方
TL;DR(要点まとめ)
いいね型マッチング:エンジニアが「いいかも」を返した後にメッセージを送る仕組みで返信率の土台が根本的に高い
勝負は企業ページ:技術スタック・開発体制・課題感を具体的に書かないと「いいかも」はもらえない
偏差値は参考値:大企業・受託出身は低偏差値でも実力あり。職務経歴と合わせて総合判断する
CSを週次で活用:専任サポートを採用改善パートナーとして使い倒す
Web系・モダン技術に強い。シニア・転職顕在層はBizReachなどと組み合わせて補完する
1. Findyとは何か|他媒体との根本的な違い
Findyはファインディ株式会社が運営するエンジニア特化型の転職・採用プラットフォームだ。登録エンジニア数は26万人超、導入企業4,000社超(ファインディ社公式)。単なるスカウト媒体ではなく、GitHubの活動データでエンジニアのスキルを可視化できる点が最大の特徴だ。
【データで見るエンジニア採用市場とFindyの位置づけ】
エンジニアの求人倍率は10.68倍(doda「転職求人倍率レポート」2025年12月時点、IT・通信エンジニア系職種)で全職種平均(約2倍前後)を大きく上回り、採用難度は構造的に高い
国内のIT人材不足は2030年に最大約79万人と試算(経済産業省「IT人材需給に関する調査」2019年)
Findyの累計登録エンジニアは26万人超、導入企業は4,000社超(ファインディ株式会社公式、2025年時点)。GitHub活動を起点にした「いいね型マッチング」でWeb系・モダン技術層に強い
母集団が構造的に枯渇している市場では、「多くの候補者に当たる」より「関心を示した候補者と確実に会話を始める」設計が効く。Findyの仕組みはこの構造に適合している。
「いいね型マッチング」の仕組み
一般的なスカウト型媒体(BizReach・Green等)は「企業がスカウトを送信→エンジニアが返信を判断」という一方通行の構造だ。Findyは「いいね」を送ると→エンジニアが「いいかも」を返した後にメッセージを送れる仕組みになっている。エンジニアが能動的に関心を示してから会話が始まるため、返信率の土台が根本的に違う。採用担当者が意識すべきは「返信率」より「いいかも率」(いいねに対していいかもが返ってくる割合)だ。
媒体 | 返信率の傾向 | 特徴 |
Findy | マッチング後は80〜90%超の事例も | いいかも後の会話率が高い |
BizReach | 低め(開封率が下がりやすい) | 転職顕在層が多い |
Green | 10〜20%程度 | IT/Web全般、量的母集団に強い |
Forkwell | 20〜30%程度 | Web系シニア、技術力重視層 |
Findyに多い層:Web系・モダン技術(Go/TypeScript/Python等)、20〜35歳の若手〜ミドル、GitHubやQiitaでアウトプットしている層、スタートアップ・SaaS志向のエンジニア。Findyで薄い層:40代以上のシニア、組み込み・レガシー技術専門家、転職顕在層(→媒体ミックスで補完)。
初期登録から稼働まで
企業の初期登録は公式サイトから問い合わせ→担当営業との初回ミーティング→アカウント開設という流れだ。開設後にやることは3つある。①企業ページの充実(技術スタック・チーム構成・課題感の記入)、②求人票の作成(具体的な技術要件・開発環境の記載)、③CS担当者との初回Syncで採用ターゲットの設計。この3つが揃う前にいいねを送り始めると、いいかも率が低い状態で消費してしまうため注意が必要だ。
2. スキル偏差値の読み方と候補者の見極め
Findyの「スキル偏差値」はGitHubのパブリックリポジトリ活動(コミット数・OSSコントリビューション・スター数・言語別使用頻度等)を独自アルゴリズムで解析した相対スコアだ。採用担当者向けに、実務での読み方を整理する。
偏差値 | 相対水準 | 実務感覚 |
70以上 | 上位約2% | OSS貢献・人気リポジトリ作者クラス |
65〜70 | 上位5〜10% | 業務外でも積極的に開発。技術ブログ・登壇実績あり |
60〜65 | 上位10〜15% | 業務でしっかり開発。実務3〜5年の実力者が多い |
55〜60 | 上位15〜30% | 標準的な経験。スキルは面接で要確認 |
55未満 | 下位70% | GitHubアウトプット少ない。スキルがないわけではない |
偏差値の落とし穴と正しい補正方法
スキル偏差値が測れるのは「GitHubのパブリック活動」のみだ。業務コードが非公開の大企業・受託開発出身のエンジニアは実力があっても偏差値が低くなる。筆者の経験では、偏差値50台でも実務能力の高いエンジニアに出会う機会は多く、偏差値基準で足切りして優秀な候補者を逃すケースを繰り返しみてきた。
低偏差値でもいいねを送るべきケース:
大企業・受託出身(業務コードが非公開)
自社技術スタックと一致する実務経験がある
直近プロジェクトが自社課題に親和性がある
Qiita・Zenn・技術ブログのアウトプットが豊富
言語別スキル偏差値の特性
Findyでは言語別に偏差値を確認できる。言語によって「GitHubでの可視性」が異なるため、同じ偏差値でも実質的な技術力の解釈が変わる。
言語 | 偏差値の信頼性 | 注意点 |
Python/JavaScript/TypeScript | 高め | OSSエコシステムが成熟。公開リポジトリが多い |
Go/Rust | 比較的高め | モダン技術はGitHub活動が活発な層が多い |
Java/C#/.NET | 低め | エンタープライズ開発は業務コードが非公開 |
C/C++ | 低め | 組み込み・ゲーム開発は非公開が多い |
PHP | 中程度 | Webサービス系は公開リポジトリあり |
スキル偏差値を使った絞り込み設定の実践
Findy管理画面では言語別偏差値・使用技術・就業形態希望などで候補者を絞り込める。実務での推奨設定:
技術スタックフィルター優先:偏差値より使用言語・フレームワークで絞る(GoとKubernetesを使っているエンジニアなど)
転職意向度フィルター:「積極的に転職活動中」→「良い条件があれば」の順に優先
偏差値は下限のみ設定:「偏差値55以上」など緩めの下限を設けつつ、個別の職務経歴を確認する
地域フィルター:リモート可の場合は全国に広げると母集団が一気に増える
3. 企業ページと求人票の設計
「いいかも」率はほぼ企業ページで決まる
Findyでは、エンジニアが「いいね」通知を受け取った後に企業ページを見て判断する。スカウトメール型の媒体と違い、文面より先に企業ページの質が問われる。充実したページと空虚なページの差は、採用担当者が書いた「会社の魅力」より、エンジニア自身が書いた「技術的な実態」があるかどうかだ。
エンジニアが「いいかも」を押す企業ページの5要素を満たすためには、キャリアページ全体の構成もあわせて最適化することが重要だ。
技術スタックの具体的な記載:「GoとNext.js、EKS+Argo CD」のように具体的に
開発チームの構成と文化:エンジニア人数・職種構成・コードレビュー文化
直面している技術的課題:何が難しくやりがいがあるか
現場エンジニアの顔が見える情報:エンジニアのコメントやブログへのリンク
成長できる環境の証拠:カンファレンス参加支援・OSS貢献推奨など
企業ページ改善チェックリスト
企業ページのセルフチェックリストを以下に示す。筆者が採用支援の現場でよく使っているものだ。
チェック項目 | 良い例 | 悪い例 |
技術スタック | 「Go 1.22, React 18, AWS EKS, ArgoCD」と具体的に列挙 | 「クラウドネイティブな環境」と曖昧に表現 |
開発体制 | 「エンジニア12名、スクラム、2週間スプリント」 | 「チームワークを大切にする」 |
技術的課題 | 「マイクロサービス分割中でトレーシング設計が課題」 | 「やりがいのある仕事」 |
現場の声 | エンジニアのコメント・テックブログのリンク | 採用担当者の目線だけで書いた紹介文 |
リモート情報 | 「週3日以上リモート可、コアタイムなしフレックス」 | 「柔軟な働き方」 |
求人票で書くべき:具体的な技術スタックとバージョン、コードレビュー文化、技術的な裁量度(「設計判断に関われる」等)、学習支援の具体策、リモート・出社条件の詳細。
求人票で避けるべき:「最先端技術」「モダンな環境」など実態のない形容詞、「スキルより人物重視」(本当か疑われる)、「チームワークを大切にする」だけの説明。
カスタマーサクセスを最大限活用する
Findyには専任のCS担当が付く。求人票のレビュー・候補者選定・スカウト戦略の相談ができる。月1回の報告にとどめるより週次Syncを依頼し、採用戦略を一緒に考えるパートナーとして活用すると成果が早く出る。具体的には「今週いいかも率が低かった求人のフィードバック」「競合他社の求人設計事例の共有」などをCSと話す場にするとよい。
4. 「いいね」の設計と送り方のコツ
いいね優先度の考え方
Findyでは1日のいいね送付数に上限があるため、優先度設計が重要だ。優先度設計を有効にするには、事前のスカウト候補者検索で狙ったエンジニア層を正確に特定することが必須だ。筆者が推奨する優先度設計は次の通りだ。
優先度 | 対象 | 理由 |
最高 | 転職積極層×自社技術スタックが一致する候補者 | 最も受諾確率が高い |
高 | 転職積極層×偏差値60以上 | スタック一致確認後にいいね |
中 | 良い条件があれば×スタック一致 | 中長期パイプライン構築 |
低 | 様子見層×一般スペック | 費用対効果が低い |
いいねコメントのパーソナライズ
Findyのいいねには「なぜいいねしたか」の一言コメントを添えられる。これをパーソナライズすることで「いいかも」率が2〜3倍変わることもある。
悪い例(定型文): 「ご経歴を拝見し、ぜひ一度お話できればと思いいいねをしました。ご検討をよろしくお願いします。」
良い例(バックエンドエンジニア向け): 「GoでgRPCサービスを設計されている点が、自社のマイクロサービス移行プロジェクトにぴったりだと感じました。同じく Go×k8s×ArgoCD の環境で開発しており、アーキテクチャの話を聞いていただけると嬉しいです。」
良い例(フロントエンジニア向け): 「Next.js × Storybookの組み合わせで設計されているのを拝見しました。弊社でも同じくNext.js 14でのApp Router移行を進めており、デザインシステム構築の経験者をまさに探していたところです。」
良い例(インフラ・SRE向け): 「Prometheusを使ったオブザーバビリティ基盤を構築されているのが気になりました。弊社では現在SRE組織の立ち上げ期で、Alert設計からランブック整備まで一緒に取り組んでいただける方を探しています。」
コメントの素材はGitHub・Qiita・職務経歴から見つける。手間はかかるが、いいかも率の改善として確実に回収できる投資だ。
いいかも後のメッセージ設計
「いいかも」が来たら:カジュアルなトーンで(「まず15分だけお話を」)、候補者のGitHub/Qiitaへの個別言及を入れ、「カジュアル面談(選考なし)でOKです」と明示する。「いいかも」時点でエンジニアは「ちょっと興味がある」程度なので、過剰な売り込みは逆効果だ。返信スピードも重要で、いいかもが来たら当日中にメッセージを返すことを習慣にする。
5. KPI設計と運用改善
主要KPIと目標水準
KPI | 目標水準(参考) | 低い場合の改善ポイント |
いいね→いいかも率 | 20〜35% | 企業ページ・求人票の質 |
いいかも→面談設定率 | 60〜80% | 最初のメッセージの質・返信スピード |
面談→エントリー率 | 30〜50% | カジュアル面談設計・魅力訴求 |
エントリー→内定率 | 30〜50% | 選考基準と候補者のマッチ度 |
内定→承諾率 | 60〜80% | オファー設計・クロージング力 |
いいかも率が20%未満なら企業ページ・求人票の改善が先決。面談設定率が低ければ最初のメッセージか返信スピードの問題。月次レビューはKPI確認→求人票改善→候補者傾向分析→CSとのSyncの流れで回す。
90日活用ロードマップ
Findy導入後に成果を出すまでの典型的なロードマップを示す。筆者が採用支援で伴走した企業の多くで、この流れに沿って運用を軌道に乗せてきた。
Day 1〜14:基盤整備
企業ページをエンジニアに読んでもらい修正(技術スタックの正確化・現場の声追加)
求人票を2〜3件作成、CS担当者にレビューを依頼
いいねコメントのテンプレートを職種別に3パターン作成
Day 15〜45:テスト運用
毎日上限いっぱいまでいいねを送付
いいかも率を週次でモニタリング(20%を下回る場合は企業ページ見直し)
カジュアル面談を週2〜3件実施し、フィードバックを求人票に反映
Day 46〜90:改善・安定化
いいかも率の高い求人パターンを特定し、横展開
CS担当者と月次レビューを実施(改善ポイントの優先度付け)
補完媒体との役割分担を確定(Findy:若手〜ミドル、BizReach:シニア・転職顕在層など)
月次PDCAサイクルの運用方法
毎月末に以下の4ステップでPDCAを回す。数値だけでなく「どの候補者との面談が特に良かったか」という定性的な振り返りも重要だ。
数値確認:いいかも率・面談設定率・エントリー数のトレンドを確認
ボトルネック特定:最もKPIが低いファネルを特定
仮説設定と改善施策の実行:ページ文言修正・コメントパターン変更など
CSとのSync:改善内容を共有し、フィードバックをもらう
6. 他媒体との使い分けと媒体ミックス
Findyは強力な媒体だが、単独で全ての採用ニーズをカバーできるわけではない。採用戦略として最も効果的なのは、Findyをメイン媒体としながら、ターゲット別に補完媒体を組み合わせる「媒体ミックス」設計だ。
媒体 | 強い層 | Findyとの使い分け |
BizReach | 転職顕在層・ハイクラス | ミドルシニア・転職積極層の補完 |
Green | IT/Web全般・若手〜中堅 | 量的な母集団の補完 |
Forkwell | Web系シニア・技術力重視 | シニア層・スペシャリスト補完 |
LAPRAS | GitHub/Qiita活動が多い層 | Findyと被る層だが重複して当たる |
Wantedly | カルチャーフィット重視・若手 | 会社の雰囲気を伝える場として |
Findyをメインにすると効果的な企業の条件:モダン技術スタック(Go/TypeScript/Python等)の採用、技術ブログ・OSS・登壇などアピールできる開発実績がある、スタートアップ・SaaS企業で技術環境の魅力を語れる。
逆に、Findyだけでは難しいケースもある。40代以上のシニア採用、特定の業界知識が必要な採用(金融・医療系システム等)、急いで採用したい場合(Findyの候補者は潜在層が多く時間軸が長い)は、BizReachの採用戦略との組み合わせが有効だ。
スカウトサービスの選定方法についてはエンジニア採用プラットフォーム選定ガイドも参照してほしい。
7. よくある失敗パターンと対策
実際の運用で頻繁に見る失敗とその対策を整理した。
失敗パターン | 対策 |
偏差値60以上にしかいいねを送らない | 大企業・受託出身は低偏差値でも実力あり。職務経歴と合わせて判断する |
企業ページを作りっぱなしにする | 四半期1回以上、技術スタック・チーム構成を更新する |
いいかもへの返信が遅い | 通知をオンにし、いいかもが来たら当日中にメッセージを送る |
数打ちいいねを送る | いいね前にポジション要件との一致を必ず確認する |
CSをほぼ使っていない | 週次Syncを依頼し運用改善パートナーとして活用する |
いいねコメントが定型文のまま | 候補者のGitHub・Qiita・経歴を見て個別に書く |
一つの求人に全集中する | 複数ポジションで求人を作り、候補者に合うポジションにいいねを分散 |
競合比較をせずに運用する | CSに「同規模の同業他社はどう設計しているか」を定期的に聞く |
8. Findyの料金と費用感
Findyの料金は公式サイトでは非公開(要問い合わせ)だが、実務で得た感覚として参考情報を共有する。
一般的に初期費用+月額費用型のサブスクリプションプランと、採用成功報酬型プランの2つが用意されている。サブスクリプション型は毎月定額でいいねを送り放題(上限あり)、成功報酬型は採用1名につきフィー支払いという構造だ。コスト感としては他の大手スカウト媒体(BizReach・Green等)と同水準かやや低め、という声が多い。
ROI計算の視点では、月額コストをいいかも率・面談転換率・採用単価で割って評価するとよい。たとえば月額50万円のプランで月3名採用できれば、1名あたりの採用コストは約17万円。エージェント経由の採用(年収の30〜35%フィー)と比較すると、スカウト媒体の費用対効果は高くなりやすい。
ただし、運用工数(いいね送付・コメント作成・面談調整等)のコストも含めてトータルで評価することが重要だ。専任の採用担当者が週10〜15時間をFindy運用に使うなら、その人件費も計算に入れる。
FAQ(よくある質問)
Q1. Findyの登録からいいねを送り始めるまでどのくらいかかりますか?
初回面談・アカウント開設・企業ページ整備を含めると、最短2〜3週間。企業ページの充実度が成果に直結するため、急いで「まずいいねを送りたい」気持ちを抑えて、企業ページ整備を先に完了させることを推奨する。
Q2. Findyの料金体系はどうなっていますか?
公式サイトでの料金は非公開(要問い合わせ)。初期費用+月額費用プランと採用成功報酬型プランがある。コスト感は他媒体と同水準かやや低めという声が多い。詳細は営業担当者に確認することを勧める。
Q3. GitHub非公開でスキル偏差値がない候補者はどう判断しますか?
職務経歴・スキルシートのみで判断する。GitHub非公開でも有力な候補者は多い。大企業・受託出身で業務コードが公開できない状況は珍しくないため、偏差値がなくても書類内容が良ければ積極的にいいねを送る。
Q4. 「いいかも」が全然来ない場合、何から改善すればいいですか?
企業ページと求人票の見直しが先決。技術スタックが具体的か、エンジニアが「働くイメージがわくか」を確認し、改善しない場合はCS担当者に相談する。多くの場合、企業ページの「技術課題の記述」が曖昧なことが原因だ。
Q5. Findyはフロントエンドエンジニア採用に向いていますか?
非常に向いている。TypeScript・React・Next.jsを持つエンジニアの密度が高く、言語別スキル偏差値で絞り込みが可能だ。特にNext.js App RouterやTurbopackなどモダンな技術に詳しい層が集まりやすい。
Q6. いいかもから内定承諾まで平均どのくらいかかりますか?
転職潜在層が多く2〜3ヶ月が目安。BizReachより時間軸が長いため、パイプラインを常時複数保ち長期的な採用計画に組み込むことを推奨する。「今すぐ採用したい」という状況でFindy単独に頼るのは難しい。
Q7. Findy Freelanceとの違いは何ですか?
「Findy」は正社員採用、「Findy Freelance」はフリーランス・業務委託の紹介サービス。「業務委託で実績確認→正社員登用」のステップも活用事例として存在する。
Q8. 非Web系企業でも使えますか?
使えるが、ミスマッチに注意が必要だ。Findyはスタートアップ・Web系志向のエンジニアが多いため、レガシー技術・オンプレ環境中心の企業は候補者の関心を引きにくい傾向がある。組み込み・インフラ・エンタープライズ系の採用には補完媒体を検討する。
Q9. Findyでシニアエンジニアを採用できますか?
できるが難易度は高め。Findyは20〜35歳の若手〜ミドル層に強く、40代以上のシニアは母集団が薄い。シニア採用には BizReach・Findy People(ヘッドハンティングサービス)・リファラルを併用することを推奨する。
Q10. 採用担当者1人でFindy運用は可能ですか?
可能だが、週10〜15時間は確保したい。いいね送付・コメント作成・面談調整・CSとのSync・KPI確認を考えると、採用担当者1人が複数媒体を同時並行で運用する場合はどこかを削ることになる。Findyを最優先する時期と他媒体を優先する時期を分けて運用するのが現実的だ。
まとめ:Findyで採用を動かすための次のアクション
Findyは正しく運用すれば返信率・採用の質ともに高い成果を出せる媒体だ。「登録して終わり」ではなく継続的な運用改善が成果を左右する。
今日からできる改善アクション:
企業ページをエンジニアに読んでもらいフィードバックをもらう
いいねコメントの定型文を廃止し、候補者のGitHubやQiitaに言及した一言を添える
CS担当者との週次Syncを依頼し、KPI確認と改善ポイントを習慣的に話し合う
カジュアル面談にテックリードやEMを巻き込む
Findyがカバーしにくい層のための補完媒体をセットで設計する
スカウト全体の戦略を見直したい場合はエンジニアスカウト運用のPDCA最適化ガイドもあわせてご覧いただきたい。
エンジニア採用の打ち手、
エンジニアと一緒に整理しませんか?
techcellarは、採用に詳しいエンジニア自身が貴社の採用チームに伴走するサービスです。 スカウト文面の改善、技術面接の設計、ペルソナ設計、媒体選定まで、実務目線でアドバイスします。
- ✓相談は無料・所要30分
- ✓会社規模・フェーズに合わせた提案
- ✓エンジニアが直接対応
お問い合わせフォームへ遷移します
現役エンジニアでありながら、スタートアップのエンジニア採用支援を行う。採用コンサル営業として採用を売る側の経験と、エンジニアとして採用される側の経験を併せ持つ。13以上のダイレクトスカウトサービスの運用経験をもとに、AI×採用の実践ノウハウを発信。
採用のお悩み、
エンジニアに相談
しませんか?