updated_at: 2026/4/16
ひとり人事のエンジニア採用完全ガイド|少人数で成果を出す仕組み化
ひとり人事・少人数チームがエンジニア採用を成功させる優先順位と仕組み化の実践手法を解説
ひとり人事のエンジニア採用完全ガイド|少人数で成果を出す仕組み化の全手法
「採用も労務も評価制度も、全部ひとりで回している」「エンジニア採用をやらなきゃいけないのに、技術のことが分からない」「求人を出しても応募ゼロ、スカウトを送る時間もない」
スタートアップやベンチャー企業で「ひとり人事」としてエンジニア採用を任されている方なら、一度はこの状態に陥ったことがあるはずです。
経済産業省の「IT人材需給に関する調査」(2019年公表)では、2030年には最大約79万人のIT人材が不足すると試算されています。大手企業でさえエンジニア採用に苦戦する中、限られたリソースのひとり人事が正面から戦っても勝ち目はありません。
しかし、やり方を変えれば話は別です。筆者は人材業界で採用を「売る側」として13以上のダイレクトスカウトサービスに携わり、現在はエンジニアとして「採用される側」の視点も持っています。この両面の経験から断言できるのは、ひとり人事でもエンジニア採用は成功できるということ。ただし、そのためには「何をやるか」以上に「何をやらないか」の判断が重要です。
このガイドでは、ひとり人事がエンジニア採用で成果を出すための優先順位の付け方、仕組み化の具体手法、そして外部リソースの活用法を体系的にまとめました。
このページでわかること
ひとり人事がエンジニア採用で直面する5つの構造的課題
限られた時間で成果を最大化するタスク優先順位マトリクス
技術知識がなくてもエンジニアに刺さる求人・スカウトの作り方
現場エンジニアを巻き込む「スクラム採用」の始め方
採用業務の仕組み化・自動化で工数を半減させる方法
外部リソース(RPO・採用代行・AI)の使いどころと選び方
TL;DR(要点まとめ)
ひとり人事の最大の敵は「全部やろうとすること」。まず採用チャネルを2つに絞り、PDCAを回す
技術が分からなくても、エンジニアと「30分の壁打ち」を週1回やるだけで求人とスカウトの質が変わる
採用プロセスの80%はテンプレ化・自動化できる。属人化を排除して「仕組み」で回す
現場エンジニアを面接官ではなく「採用の共犯者」として巻き込む設計が鍵
自分でやるべきことと外部に任せるべきことの線引きが、ひとり人事の生命線
1. ひとり人事がエンジニア採用で直面する5つの構造的課題
1-1. 時間の絶対量が足りない
ひとり人事は採用だけをやっているわけではありません。労務管理、勤怠処理、評価制度の運用、社内イベントの企画、入退社手続き——日々の業務に追われる中で、採用活動に割ける時間は多くの場合、業務全体の30〜40%程度です。
エンジニア採用は特に手間がかかります。スカウト文面のカスタマイズ、技術要件の整理、カジュアル面談の調整、面接後のフィードバック——1ポジションの採用でも月に数十時間は必要です。複数ポジションを同時に動かすなら、時間がいくらあっても足りません。
1-2. 技術知識のギャップ
エンジニア採用で最もつまずきやすいのが、技術に関する知識不足です。「Reactができる人がほしい」と現場に言われても、ReactとVue.jsの違いが分からなければ、候補者のスキルを正しく評価することも、刺さるスカウト文面を書くことも難しい。
ただし、これは「プログラミングを学べ」という話ではありません。必要なのは技術を評価する力ではなく、技術者と対話する力です。ここを間違えると、無駄な学習に時間を費やして本来の採用業務が回らなくなります。技術リテラシーの効率的な身につけ方は「非エンジニア人事の技術リテラシー入門|採用力を高める実践ガイド」で詳しく解説しています。
1-3. 採用ブランド力の弱さ
従業員50人以下のスタートアップの場合、候補者の多くはそもそも会社名を知りません。大手企業やメガベンチャーと比べてスカウトの開封率・返信率が低くなるのは、ある意味で当然です。
ひとり人事はブランディングの専任担当もいないため、採用広報に時間を割く余裕もない。この悪循環が「応募が来ない→スカウトに頼る→返信が来ない→疲弊する」というパターンを生みます。
1-4. 意思決定の属人化
採用基準の設定、年収レンジの決定、オファー条件の調整——通常であれば採用チーム内で議論するこれらの判断を、ひとり人事は経営者と1対1で行わなければなりません。
経営者がエンジニアのバックグラウンドを持たない場合、「なぜこの年収が必要なのか」「なぜこの候補者を採るべきなのか」の説明コストが大きくなります。データに基づく説明ができなければ、感覚的な判断に流されがちです。
1-5. 採用ノウハウの蓄積が難しい
チームであれば、誰かが成功した手法を共有し、失敗から学び合うことができます。しかしひとり人事は、すべてを自分ひとりで試行錯誤しなければなりません。
「前任者が突然辞めて引き継ぎがない」「そもそも前任者がいない」というケースも多く、ゼロからのスタートを余儀なくされることも珍しくありません。
2. ひとり人事のタスク優先順位マトリクス
限られた時間で成果を最大化するには、やらないことを決めるのが最重要です。以下のマトリクスで、エンジニア採用のタスクを4象限に分類しましょう。
最優先(自分でやる・今すぐ)
採用要件の整理: 現場エンジニアとの要件定義(Must / Nice to have の切り分け)
スカウト送信: ターゲット候補者へのパーソナライズメッセージ
カジュアル面談: 候補者との初回接点。企業の魅力を直接伝えられる唯一の場
オファー面談: 条件提示と入社意思決定のサポート
重要だが急がない(仕組み化して効率化)
求人票の作成・更新: テンプレートを作り、現場エンジニアの言葉を反映
面接日程の調整: カレンダーツール連携で自動化
候補者への進捗連絡: メールテンプレ + ATS の自動通知
採用データの集計: ダッシュボードを一度作れば自動更新
効果はあるが工数大(外部に委託)
スカウト候補者のリストアップ: RPOや採用代行に任せる
技術ブログ・採用広報コンテンツの制作: 現場エンジニアに書いてもらう or 外注
エージェントとのリレーション管理: 定型化して週1回のミーティングに集約
採用イベントの企画・運営: コミュニティ連携や外部イベントへの相乗り
後回しでOK(やめるか大幅に簡略化)
すべての媒体への同時掲載: 2媒体に絞って深く運用する
独自の採用サイト構築: まずはWantedlyやnotionページで十分
凝った選考課題の設計: 初期は既存のコーディングテストサービスを活用
大規模な採用イベント開催: ROIが読めないうちは参加側に回る
3. 技術が分からなくてもエンジニアに刺さる求人・スカウトを作る方法
3-1. 「30分壁打ち」で技術翻訳力を鍛える
週に1回、30分だけ現場エンジニアと話す時間を確保してください。話す内容は以下の3つです。
今週のチームの課題は何か?: 「Kubernetesの移行が遅れている」「フロントのパフォーマンス改善が必要」など、生の課題を聞く
どんな人が来たらうれしいか?: 「Goが書ける人」ではなく「マイクロサービスの設計経験がある人」のように、スキル名ではなく経験ベースで聞く
最近チームで面白かったことは?: 「新しいCI/CDパイプラインを構築した」「技術負債の返済プロジェクトが始まった」など、求人やスカウトのネタになる素材を集める
この壁打ちを4回やれば(つまり1ヶ月で合計2時間)、求人票やスカウト文面に書ける技術的なエピソードが十分にたまります。
3-2. 求人票は「エンジニアの言葉」で書く
ひとり人事が陥りがちなのが、人事目線の抽象的な表現で求人票を書いてしまうことです。
NG例:
最先端の技術を駆使して、革新的なプロダクトを開発するメンバーを募集します。裁量が大きく、やりがいのある環境です。
OK例:
React + TypeScriptのSPAをNext.jsに移行中。初期設計から関われるため、アーキテクチャの選定にも意見を出せます。チームは4人で、PRレビューは全員で回しています。
ポイントは具体性。使っている技術スタック、チームの人数、直近のプロジェクト内容、意思決定のプロセスなど、エンジニアが「この環境で働いたらどうなるか」をイメージできる情報を入れます。
書き上げた求人票は必ず現場エンジニアにレビューしてもらいましょう。「この表現は実態と違う」「この技術名は正確にはこう書く」など、数分のレビューで精度が格段に上がります。求人票の具体的な書き方は「エンジニアが応募したくなる求人票(JD)の書き方完全ガイド」で詳しく解説しています。
3-3. スカウト文面の「型」を作る
ひとり人事がスカウトに割ける時間は限られています。全文をゼロから書くのではなく、**カスタマイズすべき箇所を3つに絞った「型」**を用意しましょう。
カスタマイズすべき3要素:
なぜあなたに送ったのか(パーソナライズ理由): 候補者のプロフィール・経歴から1つ具体的なポイントを拾う
その経験がうちでどう活きるか(接続ポイント): 候補者の経験と自社の課題・プロジェクトを結びつける
今のフェーズだからこそ得られる経験(限定性): 「シリーズAの今だからこそ、0→1の設計に携われる」のような時間軸のある訴求
残りの会社紹介や応募方法の部分はテンプレートで問題ありません。3要素のカスタマイズに1通あたり5〜10分かければ、十分にパーソナライズされたスカウトになります。スカウト文面の具体的な書き方やテンプレートについては「エンジニア向けスカウトメールの書き方と返信率を上げる例文集」も参考にしてください。
3-4. スカウト媒体別のプロフィール読み解き方
技術知識がなくても、候補者プロフィールの「見るべきポイント」を押さえれば、的確なスカウトが送れます。
BizReachの場合: 職務経歴書の「プロジェクト概要」に注目。どんな規模のシステムを、どんな役割で、どんな技術を使って開発したかが書かれています。特に「チーム規模」と「担当領域」を見ると、マネジメント志向かスペシャリスト志向かが推測できます。
Forkwellの場合: 「スキル」のタグと自己評価レベルを確認。自信のあるスキルほど高い評価がつけられている傾向があります。また「興味のある分野」も重要な手がかりです。今の仕事と違う分野に興味を持っている場合、転職意向が高い可能性があります。
Greenの場合: 「ポートフォリオ」や「自己紹介」の文章量に注目。詳しく書いている候補者は転職に積極的な場合が多い。「将来やりたいこと」の記述があれば、そこに自社のプロジェクトを接続させるスカウトが効果的です。
Wantedlyの場合: 「この先やりたいこと」と「できること」の組み合わせを見ます。Wantedlyユーザーは条件面よりもミッションや環境への共感を重視する傾向があるため、年収よりも「何を作っているか」「どんなチームか」を訴求したスカウトが刺さります。
3-5. 技術用語の「地雷」を避ける
スカウト文面や求人票で技術用語を間違えると、エンジニアからの信頼を一瞬で失います。よくあるミスを押さえておきましょう。
JavaとJavaScriptは全く別の言語: 名前は似ていますが、用途も文法も全く異なります。混同するとエンジニアの間で「分かっていない会社」という烙印を押されます
バージョンを適当に書かない: 「React経験者歓迎」は問題ありませんが、「React 15経験者歓迎」のように古いバージョンを指定すると「技術負債がひどい環境なのかな」と思われます。バージョンを書くなら現場に確認してください
略語の正式名称を確認する: AWS、GCP、CI/CDなど、正式名称と略語の対応を間違えないように。不安なら略語を使わず正式名称で書く方が安全です
迷ったら現場エンジニアに確認する——これが鉄則です。知ったかぶりより「教えてください」と聞ける人事の方が、エンジニアからの信頼は厚くなります。
4. 現場エンジニアを「採用の共犯者」にする巻き込み設計
ひとり人事が最も頼るべき社内リソースは、現場のエンジニアです。ただし、「面接に出てください」と丸投げしても協力は得られません。エンジニアを採用の共犯者として巻き込む設計が必要です。この考え方は「スクラム採用でエンジニア採用を加速|現場を巻き込む実践ガイド」でも詳しく解説しています。
4-1. 巻き込みのステップ
Step 1: 課題を共有する
「エンジニアが採れないと、あなたの業務負荷は減りません」——この事実をデータで示します。現在の採用状況(応募数、面接通過率、内定承諾率)をダッシュボードにして、チームSlackに週次で共有するだけで意識は変わります。
Step 2: 最小工数のタスクから依頼する
いきなり面接をお願いするのではなく、負荷の小さいタスクから始めましょう。
求人票のレビュー(10分)
カジュアル面談への同席(30分)
候補者のGitHubプロフィールの簡易チェック(5分)
技術ブログの短い記事を1本書く(1時間)
Step 3: 成功体験を作る
エンジニアが関わった採用が成功したら、必ずフィードバックしましょう。「あなたがカジュアル面談に出てくれたおかげで、候補者の志望度が上がりました」と具体的に伝えます。採用は人事だけの仕事ではなく、チーム全体の成果であるという認識を育てます。
4-2. エンジニアに頼むべきタスクと頼んではいけないタスク
頼むべき:
技術要件の定義と優先度付け
技術面接・コーディング面接の実施
カジュアル面談での技術的な質疑応答
採用広報コンテンツ(テックブログ、登壇資料)の作成
頼んではいけない:
日程調整やメール連絡などのオペレーション業務
採用媒体の管理・候補者のステータス更新
エージェントとのやり取り
年収交渉やオファー条件の設計
原則は「エンジニアにしかできないことだけエンジニアに頼む」。オペレーションは人事が巻き取り、エンジニアの時間は技術的判断に集中させましょう。
4-3. 巻き込みに失敗するパターンと対策
パターン1: 「忙しいから無理」と断られる
対策: いきなり「面接をお願いします」はNG。まずは「5分で求人票をチェックしてもらえませんか?」から始める。小さな依頼を積み重ね、採用に関わることの意義を体感してもらう。
パターン2: 面接はしてくれるが評価がバラバラ
対策: 面接前に評価シートと評価基準を共有する。「技術力」「設計力」「チームワーク」など軸を明確にし、5段階で評価してもらう形式にすると、エンジニアごとの評価のブレが減る。面接後は10分でいいので口頭でのデブリーフィングを行い、認識のズレを早期に修正する。
パターン3: エンジニアが面接で「自社の魅力」を語れない
対策: カジュアル面談で伝えるべきポイントを3つに絞った「トーキングポイントカード」を用意する。技術スタック、開発プロセス、直近のプロジェクトの3点だけ整理しておけば、エンジニアも話しやすい。人事が同席して進行をリードし、技術的な深掘りの部分だけエンジニアに振るスタイルもおすすめ。
4-4. エンジニアの採用協力を評価に組み込む
採用活動への貢献を人事評価に反映する仕組みを作ると、エンジニアの協力が持続します。例えば以下のような項目を評価シートに追加できます。
面接への参加回数(四半期で3回以上など)
リファラル候補の紹介件数
テックブログの執筆本数
採用イベントへの登壇
ただし、数値ノルマにするのではなく「チームへの貢献」の一要素として位置づけるのがポイントです。採用は全員の仕事であるという文化を醸成するのが目的であり、義務感で動いてもらっても質の高い採用にはつながりません。
5. 採用チャネルの選択と集中——2つに絞る勇気
5-1. ひとり人事が選ぶべきチャネルの考え方
使える時間が限られている以上、採用チャネルを広げすぎるのは逆効果です。多くの場合、2つのチャネルを深く運用する方が、5つのチャネルを浅く使うよりも成果が出ます。
チャネル選定の基準は以下の3つです。
ターゲットエンジニアがいるか: 職種・レベル・志向性に合った候補者がそのプラットフォームを使っているか
運用工数は現実的か: ひとり人事が週に割ける時間内で回せるか
PDCAを回せるか: データが取れて、改善サイクルを回せるか
5-2. フェーズ別おすすめチャネル組み合わせ
シード〜シリーズA(採用実績が少ない段階):
Wantedly(ストーリーで企業の想いを伝えやすい) + リファラル(創業メンバーのネットワーク活用)
理由: 知名度がない段階では、条件面ではなく「ミッション」や「人」で勝負する。リファラルは採用コストが低く、カルチャーフィットの精度も高い
シリーズA〜B(組織拡大期):
BizReach または Forkwell(スカウト型で攻めの採用) + 自社採用ページ(応募の受け皿)
理由: スカウト型媒体でターゲットを絞ったアプローチが可能。自社ページは一度作れば長期間機能する
シリーズB以降(採用チーム構築期):
複数スカウト媒体の運用 + 人材紹介エージェント(ハイレイヤー採用向け)
理由: この段階では採用チームが2名以上になっているはず。チャネルを増やして母集団を拡大する
5-3. 各チャネルの週次運用スケジュール例
ひとり人事が週10時間をエンジニア採用に使える場合のスケジュールです。
月曜(2h): スカウト候補者のリストアップ + スカウト文面作成
火曜(1.5h): スカウト送信(10〜15通)
水曜(2h): カジュアル面談・面接(2枠)
木曜(1.5h): エンジニアとの30分壁打ち + 求人票更新
金曜(1h): 週次データ集計 + 翌週のアクション整理
空き時間: 候補者対応(返信・日程調整)はスマホで随時処理
週10時間でも、型を決めてルーティン化すれば十分に回ります。
5-4. チャネル運用で陥りがちな失敗と回避策
失敗1: 媒体を増やしすぎて全部中途半端になる
3つ以上の媒体を同時に運用し始めると、各媒体への投入時間が分散し、どの媒体でも成果が出ない状態に陥ります。特にスカウト型媒体は、プロフィール閲覧→スカウト送信→返信対応→面談調整という一連のフローに時間がかかるため、1媒体あたり週3〜4時間は必要です。ひとり人事で週10時間の場合、スカウト媒体は1つが限界と心得ましょう。
失敗2: 返信が来ないからと媒体を変える
スカウトの返信率は最初の1ヶ月で判断しないでください。文面のABテスト、送信対象の見直し、送信タイミングの変更など、少なくとも3ヶ月は同じ媒体でPDCAを回してから判断するのが適切です。媒体を変えても、運用方法が同じなら結果も同じです。
失敗3: リファラルを「待ち」の姿勢で運用する
「紹介してくれたら報酬を出します」と制度だけ作って放置しても、リファラルは動きません。月に一度、全体ミーティングの最後に「今こんなポジションを募集しています。心当たりがある方は声をかけてください」と30秒だけ告知するだけで紹介率は変わります。さらに効果的なのは、経営者やCTOが自ら「こういう人を探しているので、紹介してほしい」とSlackで発信すること。トップの行動が組織の行動を変えます。
6. 採用業務の仕組み化・自動化で工数を半減させる
ひとり人事にとって仕組み化は生存戦略です。「自分がいなくても回る」状態を作ることで、本来注力すべき候補者とのコミュニケーションに時間を使えるようになります。
6-1. ATS(採用管理システム)の導入
まだスプレッドシートで候補者を管理している場合、ATSの導入を強くおすすめします。特にひとり人事に向いているのは以下の特徴を持つATSです。
初期設定が簡単で、導入に1週間以上かからない
媒体連携が豊富で、複数チャネルの候補者を一元管理できる
自動リマインド・ステータス変更通知がある
面接評価シートを候補者ごとに紐づけられる
ATSを使うだけで、日程調整メール、選考ステータスの管理、面接官への通知といった定型業務が自動化されます。具体的なATS選定基準については「エンジニア採用に最適なATS(採用管理システム)の選び方と運用ガイド」を参照してください。
6-2. テンプレートライブラリの構築
以下のテンプレートを事前に用意しておくと、日々のオペレーションが格段に速くなります。
スカウト文面テンプレート: 職種別に3パターン(バックエンド / フロントエンド / インフラ)
カジュアル面談の案内メール: 日程候補の提示 + 会社紹介資料のリンク
面接後のお礼メール: 選考通過 / 不通過 / 保留の3パターン
オファーレターのドラフト: 年収・ポジション・入社日の穴埋め式
内定後フォローメール: プレボーディング施策の案内
面接評価シート: 技術力・コミュニケーション・カルチャーフィットの3軸
週次レポートテンプレート: 経営者への報告用(応募数・面接数・内定数のサマリー)
6-3. 生成AIの活用ポイント
2026年現在、生成AIは採用業務の強力なアシスタントになります。ただし、使いどころを間違えると逆効果です。
生成AIが得意なタスク:
スカウト文面のドラフト作成(候補者情報を入力して下書きを生成)
求人票のたたき台作成(技術要件を箇条書きで渡して文章化)
面接質問リストの作成(職種・レベルに応じた質問案の生成)
候補者への返信メールのドラフト
採用データの分析・レポートの要約
人間がやるべきタスク:
スカウト文面の最終チェック(AIが作った文面をそのまま送ると、誰にでも当てはまる無個性な文章になりがち)
候補者との直接対話(カジュアル面談・面接は人間同士の信頼構築の場)
採用判断(合否の意思決定は人間の責任)
年収やオファー条件の設計(事業計画との整合性は人間が判断する)
生成AIは「ゼロから作る時間」を削減するツールとして使い、最終的な品質管理は人間が行う——この線引きを明確にしましょう。
6-4. Slack・チャットツールの活用
採用に関する情報共有を、メールではなくSlackの専用チャンネルで行うことをおすすめします。
#hiring-engineer: エンジニア採用の進捗共有・相談チャンネル
#hiring-referral: リファラル候補の紹介・相談チャンネル
面接後の評価コメントもSlackのスレッドに集約すれば、後から振り返る際に便利です。経営者や現場エンジニアが「今、採用がどうなっているか」をリアルタイムで把握できる状態を作ることで、採用への当事者意識も高まります。
7. 外部リソースの使いどころと選び方
ひとり人事が「全部自分でやる」のは構造的に無理があります。外部リソースを戦略的に活用することで、自分の時間を高付加価値な業務に集中させましょう。
7-1. RPO(採用代行)
向いているケース:
複数ポジションを同時に採用する必要がある
スカウト送信のボリュームを確保したい
採用オペレーションを丸ごと任せたい
費用感: 一般的に月額30〜80万円程度が相場です(対応範囲により変動)。成果報酬型の場合、採用1名あたり年収の15〜25%程度が目安です。
選定のポイント:
エンジニア採用の実績があるか(IT業界に特化しているか)
コミュニケーションのレスポンスが速いか
データに基づいた改善提案をしてくれるか
自社の採用チームが育つ支援をしてくれるか(丸投げにならない設計か)
7-2. 人材紹介エージェント
向いているケース:
年収700万円以上のシニアエンジニアを採用したい
CTO・VPoEなどのハイレイヤーポジション
急いで1名確保する必要がある
費用感: 理論年収の30〜35%が一般的な手数料率です。年収700万円のエンジニアなら210〜245万円。
ひとり人事がエージェントと上手く付き合うコツ:
取引エージェントは3社以内に絞る(多すぎると管理コストが増える)
週1回の定例ミーティングで進捗を確認する
「こんな人がほしい」ではなく「こんなプロジェクトを一緒にやる人」で伝える
不採用の場合は理由を具体的にフィードバックする(次の紹介精度が上がる)
7-3. スカウト代行・AIスカウト
向いているケース:
スカウト送信の工数を削減したい
ターゲット候補者のリストアップを効率化したい
返信率の改善ノウハウがほしい
スカウト代行サービスでは、候補者のリストアップからスカウト文面の作成・送信までを代行してもらえます。AIを活用したスカウトサービスも増えており、候補者のプロフィールを分析してパーソナライズされた文面を自動生成する仕組みもあります。
ひとり人事の場合、スカウトの「量」を外部に任せ、カジュアル面談以降の「質」の部分に自分の時間を集中させるのが効果的です。RPOの詳しい選び方は「エンジニア採用代行(RPO)とは?失敗しない選び方と成功事例を徹底解説」で解説しています。
7-4. 外部リソース活用の判断フレームワーク
外部に任せるかどうかは、以下の3つの問いで判断できます。
自分がやることで候補者体験が向上するか? → Yesなら自分でやる
仕組み化すれば自分でなくてもできるか? → Yesならツールか外部委託
専門知識が必要か? → Yesで自分にないなら外部の専門家に依頼
8. ひとり人事の「採用力」を育てるナレッジ蓄積術
8-1. 採用振り返りノートを書く
毎週金曜日に15分だけ、以下の3項目を書き出しましょう。
今週うまくいったこと: どのスカウトに返信があった?どの面談で手応えがあった?
今週うまくいかなかったこと: なぜ不採用にした?なぜ辞退された?
来週試すこと: スカウト文面のABテスト、面談の進め方の変更など
これを3ヶ月続けると、自社のエンジニア採用における「勝ちパターン」と「負けパターン」が見えてきます。引き継ぎ資料としても機能するため、将来的に採用チームを拡大する際にも役立ちます。
8-2. データで語る習慣をつける
経営者に「エンジニア採用がうまくいっていません」と言っても、何も変わりません。代わりに以下のデータを週次で報告しましょう。
ファネル数値: スカウト送信数 → 返信数 → カジュアル面談数 → 面接数 → 内定数 → 承諾数
チャネル別コンバージョン率: どの媒体からの候補者が最も内定承諾まで至っているか
リードタイム: 初回接触から内定承諾までの平均日数
辞退理由の集計: どのフェーズで、どんな理由で離脱しているか
データがあれば、「スカウトの返信率が5%なので、送信数を倍にするか、文面を改善するか、媒体を変えるか」という建設的な議論ができます。「何となくうまくいかない」から「ここがボトルネック」に変わるだけで、経営者の理解と協力も得やすくなります。
8-3. 社外の人事コミュニティに参加する
ひとり人事の最大のリスクは、情報の孤立です。社内に相談相手がいない分、社外に知見を求めることが重要です。
HERPHR: HERPが運営する人事コミュニティ。エンジニア採用のノウハウ共有が活発
採用担当者向け勉強会: 各種媒体が定期開催しているセミナーや勉強会
X(旧Twitter)の採用担当者クラスタ: #人事 #採用 のハッシュタグで情報収集
他社のひとり人事と情報交換することで、自社では思いつかなかった手法やツールに出会えることがあります。
8-4. 採用要件定義書のフォーマット化
ポジションが変わっても使い回せる採用要件定義書のテンプレートを作っておくと、新しいポジションの立ち上げが格段に速くなります。以下の項目を網羅したフォーマットを用意しましょう。
ポジション名と配属チーム: 候補者が「自分がどこに入るのか」を理解できる粒度で
採用の背景: 増員か欠員補充か、事業戦略上のどんな課題を解決するための採用か
Must要件とNice to have要件: 技術スキル・経験年数・マネジメント経験などを明確に分離
想定年収レンジ: 下限と上限を明示(経営者と事前に合意済みであること)
選考フロー: カジュアル面談→技術面接→最終面接→オファーなど、各ステップと担当者
採用目標時期: いつまでに入社してほしいか(逆算で選考スケジュールを組む)
競合情報: 同じターゲットを採りに行っている企業とその訴求ポイント
このフォーマットを現場エンジニアと一緒に埋めることで、採用要件の認識齟齬を防ぎ、選考途中での基準のブレも抑制できます。
8-5. 不採用・辞退のデータを資産にする
不採用にした候補者や、辞退された候補者のデータは、次の採用を成功させるための貴重な資産です。以下の情報を記録しておきましょう。
不採用理由: 「技術力が基準に達していなかった」「カルチャーフィットに懸念があった」など具体的に
辞退理由: 「年収条件が合わなかった」「他社に決めた(どの企業か)」「選考スピードが遅かった」など
タレントプール候補: 今回はタイミングが合わなかったが、将来的に声をかけたい候補者
辞退理由を3ヶ月分まとめて分析すると、自社の採用における弱点が浮かび上がります。年収で負けているのか、選考スピードで負けているのか、企業の魅力の伝え方に問題があるのか——データがあれば改善の優先順位が明確になります。
9. ひとり人事の次のステップ——採用チームを作る
ひとり人事はいつまでもひとりでいる必要はありません。採用実績を積み重ね、事業が成長してきたら、採用チームの構築を経営者に提案しましょう。
9-1. 採用チーム拡大のタイミング
以下のいずれかに該当したら、2人目の採用メンバーを迎える検討を始めるべきです。
同時に3ポジション以上のエンジニア採用を進めている
スカウトの送信数が月50通を超えている
面接が週5回以上入っている
採用以外の人事業務(労務・評価)に支障が出ている
候補者への返信が24時間以内にできなくなっている
9-2. 2人目は何を担当させるか
2人目の採用メンバーには、オペレーション業務を任せるのが効果的です。
面接日程の調整
候補者へのステータス連絡
採用媒体の管理・データ入力
エージェントとの定例連絡
こうすることで、ひとり人事だった自分は戦略・コミュニケーションに集中できます。
採用戦略の立案と経営者との議論
カジュアル面談・オファー面談
現場エンジニアとの連携
採用ブランディングの企画
9-3. 引き継ぎ可能な状態を常に作っておく
ひとり人事が突然離脱した場合でも採用が止まらないように、以下のドキュメントを常に最新化しておくことをおすすめします。
採用フロー図: 応募から入社までの全ステップと各ステップの担当者・所要日数
媒体アカウント一覧: ログイン情報、契約状況、更新日
エージェント連絡先リスト: 担当者名、連絡先、過去の紹介実績
テンプレート集: スカウト文面、メール、評価シートなどの保管場所
採用振り返りノート: 過去の成功・失敗パターンの記録
これらを社内のナレッジベース(Notionなど)にまとめておけば、2人目が入った際の立ち上がりも速くなりますし、自分が休暇を取る際も安心です。
10. ひとり人事が陥りやすい5つの罠と対処法
罠1: 完璧な候補者を探し続ける
「バックエンドもフロントエンドもできて、インフラも分かって、マネジメント経験もある人」——こんな人材は存在しません。Must要件を3つ以内に絞り、それ以外はNice to haveとして割り切る。完璧な人を探す時間で、「今のチームに足りないスキルを補える人」に絞って動いた方が結果は出ます。
罠2: 経営者の「こんな人がいい」に振り回される
経営者が面接のたびに「もっとこういう人がいい」と要件を変える——これはひとり人事がよく直面する問題です。対策は、採用要件を文書化して経営者と合意しておくこと。口頭での要件変更は記録に残らず、後で「そんなことは言っていない」となりがちです。要件変更があった場合は「承知しました。ただし要件を変えると、ターゲット層が変わるため、これまでの候補者は対象外になります。よろしいですか?」と影響範囲を明示しましょう。
罠3: 候補者への返信が遅れる
ひとり人事は忙しさのあまり、候補者への返信が48時間以上かかることがあります。しかし、返信の遅さは候補者体験を大きく損ないます。特にエンジニアは複数社と同時に選考を進めていることが多く、返信が遅い企業は選択肢から外されがちです。
対策は2つ。(1)返信テンプレートを用意して「とりあえず24時間以内に一次返信」する習慣をつける。(2)面接日程の調整はカレンダーツール(Calendlyなど)を使い、候補者に空き時間を直接選んでもらう仕組みにする。
罠4: 採用を「人事の仕事」だと思い込む
「採用は人事の仕事」と自分を追い込むと、すべてを抱え込んで燃え尽きます。採用はチーム全体の課題であり、人事はその推進役にすぎません。現場エンジニア、経営者、時にはデザイナーやPMも巻き込んで「全員採用」の体制を作ることが、ひとり人事が生き残るための最重要戦略です。
罠5: 数字を追わずに「感覚」で動く
「今月は何となくうまくいかなかった」「あの候補者はいい人だった気がする」——感覚ベースの運用は再現性がありません。前述の通り、最低限のファネル数値(送信数・返信数・面談数・面接数・内定数・承諾数)を毎週記録するだけで、自分の採用活動を客観視できるようになります。数字は嘘をつきません。
FAQ(よくある質問)
Q1. エンジニアの技術レベルをどうやって判断すればいいですか?
技術レベルの判断は現場エンジニアに任せましょう。ひとり人事の役割は、候補者のコミュニケーション力・カルチャーフィット・キャリア志向の見極めです。技術面接は現場エンジニアが担当し、人事面接では「なぜ転職するのか」「何を実現したいのか」「チームでどう働くか」を深掘りする——この役割分担が最も効率的です。
Q2. エンジニア採用の予算をどう確保すればいいですか?
まず「採用しない場合のコスト」を数値化しましょう。エンジニアが1名足りないことによる開発遅延、外注費の増加、既存メンバーの残業代——これらを試算し、「採用コスト < 採用しないコスト」であることを経営者に示します。採用予算は一般的に年間売上の5〜15%が目安ですが、スタートアップでは投資フェーズとして高めに設定するケースも多いです。
Q3. スカウトの返信率が低いのですが、どう改善すればいいですか?
まず現状の返信率を正確に計測してください。その上で、3つのレバーで改善を試みます。(1)ターゲットの精度を上げる(要件の Must / Nice を見直す)、(2)文面のパーソナライズ度を上げる(3要素カスタマイズの徹底)、(3)送信タイミングを変える(一般的に平日の午前中や昼休みの時間帯が開封率が高い傾向にあります)。1つずつ変数を変えてABテストし、効果を検証しましょう。
Q4. カジュアル面談と面接の違いは何ですか?
カジュアル面談は「選考」ではなく「情報交換」の場です。合否判定はせず、候補者に会社の情報を伝え、候補者の話を聞く双方向のコミュニケーションです。面接は選考プロセスの一部で、評価基準に基づいて候補者を見極めます。ひとり人事はカジュアル面談を「会社のファンを作る場」として活用し、技術面接は現場エンジニアに任せる設計がおすすめです。
Q5. 採用代行(RPO)と人材紹介エージェントはどう使い分けますか?
採用代行は「プロセスを任せる」、エージェントは「候補者を紹介してもらう」が基本的な違いです。ひとり人事で採用オペレーションの工数が足りない場合はRPO、特定のハイレイヤーポジションをピンポイントで埋めたい場合はエージェントが向いています。両方を使う場合は、RPOに日常のオペレーションを任せつつ、CTOクラスの採用だけエージェントを使うという組み合わせが効果的です。
Q6. リファラル採用を活性化するにはどうすればいいですか?
リファラルは「制度を作るだけ」では動きません。まず経営者やCTOが率先して自分のネットワークから紹介する姿勢を見せること。次に、紹介のハードルを下げること——「採用に至らなくても、まずはカジュアルに話してみませんか?」と伝えるだけで紹介しやすくなります。紹介してくれたメンバーへの感謝は忘れずに。金銭的なインセンティブより「紹介してくれてありがとう」のひと言の方が、次の紹介につながります。
Q7. ひとり人事でも採用ブランディングはできますか?
できます。大規模な施策は不要です。まずは「現場エンジニアに月1本の短いテックブログを書いてもらう」「カジュアル面談で使う会社紹介スライドを整備する」の2つから始めましょう。Wantedlyのストーリー機能やnoteなど、無料で使えるプラットフォームを活用すれば、コストをかけずに発信できます。重要なのは頻度と継続性。月1回でも定期的に発信し続けることが、中長期的な採用ブランド構築につながります。
まとめ——ひとり人事のエンジニア採用は「捨てる勇気」で決まる
ひとり人事のエンジニア採用で最も大切なのは、全部をやろうとしないことです。
採用チャネルは2つに絞る
現場エンジニアを巻き込み、技術的判断は任せる
定型業務は仕組み化・自動化する
自分でやるべきことと外部に任せるべきことの線引きを明確にする
データで語り、感覚に頼らない
限られたリソースでも、やるべきことに集中すれば成果は出ます。
エンジニア採用のスカウト運用やAI活用でお困りの方は、techcellarのサービスページをご覧ください。ダイレクトスカウト13サービス以上の運用実績と、エンジニア×AIの視点から、ひとり人事の採用活動をサポートします。
採用のお悩み、
エンジニアに相談
しませんか?