公開: 2026/5/19|更新: 2026/9/5
Findyエンジニア採用完全ガイド|スキル偏差値活用から返信率90%超まで
Findy企業向けの登録から求人設計・いいね運用・スカウト返信率最大化まで実践解説
Findyエンジニア採用完全ガイド|スキル偏差値活用から返信率90%超まで
Findyのスキル偏差値とは、GitHubのパブリックリポジトリ活動を独自アルゴリズムで解析し、登録エンジニア内での相対的な技術力を言語別に数値化した指標だ。企業側は週次上限のある「いいね」でアプローチし、エンジニアが「いいかも」を返すとメッセージが送れる。プレミアムプランでは「いいかも」を待たずに直接スカウトを送る「プレミアムスカウト」も使える。ただし「高偏差値しかいいねしない」運用は優秀な候補者を見落とす。筆者が採用支援の実務で培ったFindyの正しい活用法を、登録から運用改善まで体系的に解説する。
「Findyでいいねを送り続けているのに、いいかもが全然返ってこない」——Findy運用を始めたばかりの採用担当者からよく聞く悩みだ。Findyは「いいね型マッチング」という独自の仕組みを採用しており、正しく運用すれば返信率80〜90%超の事例も出ている。一方で他媒体と同じ感覚で使うと「いいねは消費しているのに採用が進まない」という状態に陥る。
このページでわかること
「いいね型マッチング」の仕組みと他媒体との違い
スキル偏差値の算出方法(公式の考え方)と正しい読み方
「いいかも」率を上げる企業ページ・求人票の設計
いいねの週次上限とプレミアムスカウトの使い分け
90日ロードマップとKPI設計、料金体系(ベーシック/プレミアム)
TL;DR(要点まとめ)
いいね型マッチング:エンジニアが「いいかも」を返した後にメッセージを送る仕組みで返信率の土台が根本的に高い
勝負は企業ページ:技術スタック・開発体制・課題感を具体的に書かないと「いいかも」はもらえない
偏差値は参考値:言語別・直近1年の公開活動ベースの相対値。大企業・受託出身は低偏差値でも実力あり。職務経歴と合わせて総合判断する
いいねは週次上限あり・プレミアムスカウトは本命用:上限枠は技術スタック一致の候補者に配分し、直接送れるプレミアムスカウトは「必ず会いたい」候補者に絞る
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代以上のシニア、組み込み・レガシー技術専門家、転職顕在層(→媒体ミックスで補完)。
初期登録から稼働まで
企業の初期登録は公式サイトから問い合わせ→担当営業との初回ミーティング→アカウント開設という流れだ。開設後にやることは、①企業ページの充実(技術スタック・チーム構成・課題感)、②求人票の作成(具体的な技術要件・開発環境)、③CS担当者との初回Syncで採用ターゲットの設計、の3つ。揃う前にいいねを送り始めると、いいかも率が低い状態で枠を消費してしまう。
2. スキル偏差値の読み方と候補者の見極め
Findyのスキル偏差値は「参考指標として使えば強力、足切り基準にすると危険」というのが実務での結論だ。GitHubのパブリックリポジトリ活動(コミット数・OSSコントリビューション・スター数・言語別使用頻度等)を独自アルゴリズムで解析した相対スコアであり、候補者理解の入口として使うのが正しい。採用担当者向けに、実務での読み方を整理する。
スキル偏差値の算出方法と更新の仕組み(公式の考え方)
スキル偏差値は、エンジニアがFindyにGitHubアカウントを連携した時点で解析され、その後のGitHub活動に応じて変動する。算出対象はあくまでパブリックリポジトリの活動のみで、プライベートリポジトリや業務コードは反映されない。この前提を理解していないと、候補者の実力を大きく読み違える。
ファインディ社の公開情報および解説記事で共通して説明されている算出の枠組みは次の通りだ(詳細なアルゴリズムは非公開。数値の目安は時期により変動する)。
評価軸は「量・質・影響度」の3系統:コミット数や変更行数などの「コードの量」、設計の複雑さや可読性・READMEの充実度などの「コードの質」、Star数・Fork数・OSSへの貢献などの「他者への影響度」を総合してスコア化する
言語ごとに別モデルで評価される:Python・JavaScript・TypeScript・Go・Ruby・PHPといった主要言語ごとに最適化されたモデルで算出され、言語別偏差値として表示される。総合値より言語別の値を自社スタックと突き合わせる方が実務的だ
解析対象は直近の公開活動:解析対象は直近1年程度の公開リポジトリとされ、過去に活発でも最近の活動が止まっていれば数値は下がる。2024年にはアルゴリズムが大きく更新されており、同じ候補者でも時期で値が変わりうる
相対評価である:偏差値なので登録エンジニア全体の中での相対位置を示す。母集団の変化によっても数値は動く
偏差値 | 相対水準の目安 | 実務感覚 |
70以上 | 言語により上位約8〜13% | OSS貢献・人気リポジトリ作者クラス |
65〜70 | 上位15〜20%前後 | 業務外でも積極的に開発。技術ブログ・登壇実績あり |
60〜65 | 言語により上位25〜30% | 業務でしっかり開発。実務3〜5年の実力者が多い |
55〜60 | 中位 | 標準的な経験。スキルは面接で要確認 |
55未満 | 下位 | GitHubアウトプット少ない。スキルがないわけではない |
上位何%に当たるかは言語で差がある。公開されている目安では、Goの偏差値60は上位30%前後、Pythonの偏差値60は上位25%前後、偏差値70になるとGo・TypeScriptで上位12〜13%、Pythonで上位8%程度とされる。「偏差値60=上位10%」のような固定イメージで足切りすると、母集団の3割近くを機械的に捨てることになる。
偏差値の落とし穴と正しい補正方法
スキル偏差値が測れるのは「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の成果は企業ページの質でほぼ決まる。いいねを受け取ったエンジニアが最初に見るのは文面ではなく企業ページであり、ここに技術的な実態が書かれていなければ「いいかも」は返ってこない。
「いいかも」率はほぼ企業ページで決まる
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のいいね運用は「量より優先度設計」で成果が決まる。いいねには送付数の上限があるため、誰に・どの順番で・どんなコメントを添えて送るかの設計が、いいかも率を左右する最大の変数になる。
いいねの週次上限とプレミアムスカウトの違い
Findyの企業側アプローチは「いいね」と「プレミアムスカウト」の2種類で、性質がまったく異なる。いいねは相互マッチング(いいかも)が成立して初めてメッセージを送れる仕組みで、送付数には週35件程度の上限が設けられているとされる。一方プレミアムスカウトは、プレミアムプランで利用できる「いいかもを待たずに直接メッセージを届けられる」スカウトだ。
種類 | 送れる条件 | 届き方 | 向いている用途 |
いいね | 全プランで利用可。週次上限あり | 候補者が「いいかも」を返すとメッセージ交換が開始 | 技術スタック一致層への幅広いアプローチ |
プレミアムスカウト | プレミアムプランで利用可 | マッチング不要で候補者に直接届く | 「必ず会いたい」本命候補者への本気度の高い打診 |
プランの違いも押さえておきたい。公開されている解説によると、ベーシックプランは相互マッチング後のみスカウト送信が可能で、アプローチ対象にも偏差値帯の制限がある。プレミアムプランは全登録エンジニアが対象で直接スカウトが可能な代わりに、求人票の下限年収に条件(600万円以上とされる)が設けられている。条件は変更されうるため、契約前に営業担当へ最新の内容を確認してほしい。
実務での使い分けは次の3点に集約される。
いいねは「上限枠の配分」で勝負する:週次上限があるため、技術スタックが一致する候補者へ優先的に配分してパイプラインを作る。スタック不一致の候補者に数打ちで送るのが最も損な使い方だ
プレミアムスカウトは「この人に必ず会いたい」候補者に限定する:直接届く分、候補者は「なぜ自分に」を厳しく見る。定型文ではなく、経歴・GitHub活動への具体的な言及を必ず添える
消費ペースを管理する:週初に枠を使い切らず、新規登録エンジニアが流入するタイミングにも送れるよう残枠を確保する
筆者が運用支援で見てきた失敗は、プレミアムスカウトを「通常いいねの延長」として序盤に使い切ってしまうパターンだ。希少な枠は本命候補者のために温存し、コメントの質で確実に回収する運用が効く。
いいね優先度の考え方
Findyではいいねの送付数に週次の上限があるため、優先度設計が重要だ。優先度設計を有効にするには、事前のスカウト候補者検索で狙ったエンジニア層を正確に特定することが必須だ。筆者が推奨する優先度設計は次の通りだ。
優先度 | 対象 | 理由 |
最高 | 転職積極層×自社技術スタックが一致する候補者 | 最も受諾確率が高い |
高 | 転職積極層×偏差値60以上 | スタック一致確認後にいいね |
中 | 良い条件があれば×スタック一致 | 中長期パイプライン構築 |
低 | 様子見層×一般スペック | 費用対効果が低い |
いいねコメントのパーソナライズ
Findyのいいねには「なぜいいねしたか」の一言コメントを添えられる。これをパーソナライズすることで「いいかも」率が2〜3倍変わることもある。
悪い例(定型文): 「ご経歴を拝見し、ぜひ一度お話できればと思いいいねをしました。ご検討をよろしくお願いします。」
良い例(バックエンドエンジニア向け): 「GoでgRPCサービスを設計されている点が、自社のマイクロサービス移行プロジェクトにぴったりだと感じました。同じく Go×k8s×ArgoCD の環境で開発しており、アーキテクチャの話を聞いていただけると嬉しいです。」
良い例(フロントエンジニア向け): 「Next.js × Storybookの組み合わせで設計されているのを拝見しました。弊社でも同じくNext.js 14でのApp Router移行を進めており、デザインシステム構築の経験者をまさに探していたところです。」
コメントの素材はGitHub・Qiita・職務経歴から見つける。手間はかかるが、いいかも率の改善として確実に回収できる投資だ。パーソナライズ作業を効率化したい場合は、AIを活用したスカウト自動化・個別最適化の手法も参考になる。
いいかも後のメッセージ設計
「いいかも」が来たら:カジュアルなトーンで(「まず15分だけお話を」)、候補者のGitHub/Qiitaへの個別言及を入れ、「カジュアル面談(選考なし)でOKです」と明示する。「いいかも」時点でエンジニアは「ちょっと興味がある」程度なので、過剰な売り込みは逆効果だ。いいかもが来たら当日中に返信することを習慣にする。
5. KPI設計と運用改善
Findy運用の改善は「いいかも率」を起点にファネル全体をKPI管理することで初めて回り始める。感覚での運用を続けると、どこがボトルネックかわからないまま、いいねだけを消費することになる。
主要KPIと目標水準
KPI | 目標水準(参考) | 低い場合の改善ポイント |
いいね→いいかも率 | 20〜35% | 企業ページ・求人票の質 |
いいかも→面談設定率 | 60〜80% | 最初のメッセージの質・返信スピード |
面談→エントリー率 | 30〜50% | カジュアル面談設計・魅力訴求 |
エントリー→内定率 | 30〜50% | 選考基準と候補者のマッチ度 |
内定→承諾率 | 60〜80% | オファー設計・クロージング力 |
いいかも率が20%未満なら企業ページ・求人票の改善が先決。面談設定率が低ければ最初のメッセージか返信スピードの問題だ。
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・経歴を見て個別に書く |
一つの求人に全集中する | 複数ポジションで求人を作り、候補者に合うポジションにいいねを分散 |
8. Findyの料金と費用感(ベーシック/プレミアム)
Findyの料金は公式サイトでは非公開(要問い合わせ)だが、構造は「基本利用料+成功報酬」の組み合わせだ。基本利用料は契約期間(6ヶ月/12ヶ月)で決まり、採用が決まった時点で理論年収に対する成功報酬が別途発生する。
公開されている解説記事で示されている参考値を整理すると次の通りだ(税別・掲載時点の情報。最新の料金は営業担当に確認してほしい)。
プラン | 基本利用料の目安 | 成功報酬の目安 | 主な違い |
ベーシック | 6ヶ月36万円/12ヶ月54万円 | 理論年収の30% | いいね→いいかも成立後にスカウト可。対象偏差値帯に制限 |
プレミアム | 6ヶ月60万円/12ヶ月90万円 | 理論年収の35% | 全登録エンジニアに直接スカウト(プレミアムスカウト)可。求人の下限年収600万円以上が条件 |
コスト感としては他の大手スカウト媒体(BizReach・Green等)と同水準かやや低め、という声が多い。成功報酬型の人材紹介(年収の30〜35%が相場)と比べると、基本利用料は上乗せになるが、複数名採用するほど1名あたりのコストは下がる構造だ。
ROI計算の視点では、基本利用料と成功報酬の合計を採用人数で割り、いいかも率・面談転換率とあわせて評価するとよい。たとえば12ヶ月のベーシックプラン(54万円)で年収600万円のエンジニアを2名採用した場合、成功報酬360万円と合わせて総額414万円、1名あたり約207万円。同条件を人材紹介(フィー35%)で採用すると1名420万円になるため、運用工数を差し引いてもスカウト媒体側の費用対効果が高くなりやすい。
ただし、運用工数(いいね送付・コメント作成・面談調整等)の人件費も含めてトータルで評価することが重要だ。社内で運用リソースを確保できない場合は、媒体運用ごと外部に委託する選択肢もある。費用感と選び方はエンジニア採用代行(RPO)の費用相場と失敗しない選び方で解説している。
FAQ(よくある質問)
Q1. Findyの登録からいいねを送り始めるまでどのくらいかかりますか?
初回面談・アカウント開設・企業ページ整備を含めると、最短2〜3週間。企業ページの充実度が成果に直結するため、いいね送付より先に企業ページ整備を完了させることを推奨する。
Q2. Findyの料金体系はどうなっていますか?
公式サイトでの料金は非公開(要問い合わせ)だが、「基本利用料+成功報酬」の構造で、ベーシックとプレミアムの2プランがある。公開されている参考値ではベーシックが6ヶ月36万円・成功報酬30%、プレミアムが6ヶ月60万円・成功報酬35%(いずれも税別)とされる。コスト感は他媒体と同水準かやや低めという声が多い。詳細は営業担当者に確認することを勧める。
Q3. GitHub非公開でスキル偏差値がない候補者はどう判断しますか?
職務経歴・スキルシートのみで判断する。GitHub非公開でも有力な候補者は多い。大企業・受託出身で業務コードが公開できない状況は珍しくないため、偏差値がなくても書類内容が良ければ積極的にいいねを送る。
Q4. 「いいかも」が全然来ない場合、何から改善すればいいですか?
企業ページと求人票の見直しが先決。技術スタックが具体的か、エンジニアが「働くイメージがわくか」を確認し、改善しない場合はCS担当者に相談する。多くの場合、企業ページの「技術課題の記述」が曖昧なことが原因だ。
Q5. Findyはフロントエンドエンジニア採用に向いていますか?
非常に向いている。TypeScript・React・Next.jsを持つエンジニアの密度が高く、言語別スキル偏差値で絞り込みが可能だ。
Q6. いいかもから内定承諾まで平均どのくらいかかりますか?
転職潜在層が多く2〜3ヶ月が目安。BizReachより時間軸が長いため、パイプラインを常時複数保ち長期的な採用計画に組み込むことを推奨する。
Q7. Findy Freelanceとの違いは何ですか?
「Findy」は正社員採用、「Findy Freelance」はフリーランス・業務委託の紹介サービス。「業務委託で実績確認→正社員登用」のステップも活用事例として存在する。
Q8. 非Web系企業でも使えますか?
使えるが、Findyはスタートアップ・Web系志向のエンジニアが多いため、レガシー技術・オンプレ環境中心の企業は候補者の関心を引きにくい。組み込み・エンタープライズ系の採用には補完媒体を検討する。
Q9. Findyでシニアエンジニアを採用できますか?
できるが難易度は高め。40代以上のシニアは母集団が薄いため、BizReach・Findy People(ヘッドハンティングサービス)・リファラルを併用することを推奨する。
Q10. 採用担当者1人でFindy運用は可能ですか?
可能だが、週10〜15時間は確保したい。複数媒体を同時並行で運用する場合はどこかを削ることになるため、Findyを最優先する時期と他媒体を優先する時期を分けて運用するのが現実的だ。
Q11. スキル偏差値は候補者側の活動でどう変わりますか?
直近の公開活動に応じて変動する相対スコアのため、OSS貢献や個人開発を続ければ上がり、活動が止まれば下がりうる。採用側は「いいねを送った時点の偏差値」より「直近どんなリポジトリで何をしているか」を見る方が、現在のスキルと関心を正確に捉えられる。
Q12. プレミアムスカウトは通常のいいねとどう使い分けるべきですか?
プレミアムスカウトは「いいかも」の成立を待たずに候補者へ直接メッセージを届けられるスカウトで、プレミアムプランで利用できる。相互マッチングが前提のいいねと違い候補者に必ず届く分、「なぜ自分に来たのか」を厳しく見られるため、技術スタック・転職意向・経歴の3条件が揃った「この人に必ず会いたい」候補者にのみ使い、経歴やGitHub活動に具体的に言及したコメントを添える。通常いいねとの差別化ができない定型文で送るのは希少枠の浪費になる。
Q13. いいねは週に何件まで送れますか?
公開されている解説では、企業からのいいねは週35件程度が上限とされている(プランや時期で変動する可能性があるため契約時に確認してほしい)。上限があるからこそ、送る前に技術スタックとの一致・転職意向を確認し、枠を「スタック一致×転職積極層」に優先配分する運用が成果を左右する。
Q14. ベーシックプランとプレミアムプランはどちらを選ぶべきですか?
年収600万円以上のポジションで、いいかもを待たずに本命候補者へ直接アプローチしたい場合はプレミアムが向く。一方、若手〜ミドル層を幅広く集めたい、まずFindyの候補者層と自社の相性を確かめたい場合はベーシックから始めて十分だ。ベーシックはアプローチ対象の偏差値帯に制限があるとされるため、シニア・ハイスキル層を狙う採用ではプレミアムを検討する。
まとめ:Findyで採用を動かすための次のアクション
Findyは正しく運用すれば返信率・採用の質ともに高い成果を出せる媒体だ。「登録して終わり」ではなく継続的な運用改善が成果を左右する。
今日からできる改善アクション:
企業ページをエンジニアに読んでもらいフィードバックをもらう
いいねコメントの定型文を廃止し、候補者のGitHubやQiitaに言及した一言を添える
CS担当者との週次Syncを依頼し、KPI確認と改善ポイントを習慣的に話し合う
カジュアル面談にテックリードやEMを巻き込む
Findyがカバーしにくい層のための補完媒体をセットで設計する
スカウト全体の戦略を見直したい場合はエンジニアスカウト運用のPDCA最適化ガイドもあわせてご覧いただきたい。
エンジニア採用の打ち手、
エンジニアと一緒に整理しませんか?
techcellarは、採用に詳しいエンジニア自身が貴社の採用チームに伴走するサービスです。 スカウト文面の改善、技術面接の設計、ペルソナ設計、媒体選定まで、実務目線でアドバイスします。
- ✓相談は無料・所要30分
- ✓会社規模・フェーズに合わせた提案
- ✓エンジニアが直接対応
現役エンジニアでありながら、スタートアップのエンジニア採用支援を行う。採用コンサル営業として採用を売る側の経験と、エンジニアとして採用される側の経験を併せ持つ。13以上のダイレクトスカウトサービスの運用経験をもとに、AI×採用の実践ノウハウを発信。
エンジニア採用のお悩み、エンジニアに相談してみませんか?
採用に詳しいエンジニアが貴社の採用チームを強化します
採用のお悩み、
エンジニアに相談
しませんか?