採用計画の立て方｜「去年と同じ」で始めて失敗する企業の3つの共通点
はじめに —— 「去年と同じ」で始める採用計画が失敗する理由
多くの企業の採用計画は、こう始まります。
「去年は何人採ったから、今年も同じくらいで」
この進め方には、3つの構造的な問題があります。
問題1: 事業環境は去年と同じではない
事業の成長フェーズが変われば、必要な人材の質も量も変わります。去年は「即戦力」が必要だったかもしれませんが、今年は「将来のリーダー候補」かもしれない。去年は営業を増やすフェーズだったが、今年はプロダクト強化のフェーズかもしれない。
去年の計画をコピーするということは、去年の事業環境を前提にした計画で今年を戦うということです。
問題2: 「何人」は決まっても「どんな人」が決まらない
「エンジニア3人」「営業5人」——人数は決まっても、具体的にどんな人材が必要かが曖昧なまま動き出す。結果として、求人票は過去のコピペ、評価基準は面接官の感覚頼みになります。
採用計画とは「何人採るか」ではなく、「どんな人を、いつまでに、どのチャネルで、どう見極めて採るか」の設計です。
問題3: 計画を立てても振り返らない
計画を立てたら満足して、あとは目の前の応募者対応に追われる。半期が終わっても「計画通りだったか」を検証しない。次の計画もまた感覚で立てる——このサイクルでは、採用の質は永遠に改善しません。
この記事では、これらの問題を構造的に解決する採用計画の立て方を解説します。
採用計画の5ステップ
Step 1: 事業計画から採用ニーズを導出する
↓
Step 2: ポジションごとの要件を構造化する
↓
Step 3: チャネル戦略を設計する
↓
Step 4: 選考プロセスとスケジュールを設計する
↓
Step 5: KPIを設定し、PDCAを回す仕組みを作る
Step 1: 事業計画から採用ニーズを導出する
採用計画は、事業計画から逆算して立てます。「何人必要か」ではなく、**「事業目標を達成するために、いつまでに、どの機能が必要か」**を起点にします。
逆算の問い
| 問い | 導出されるもの |
|---|---|
| 今期の事業目標は何か？ | 必要な機能・ケイパビリティの特定 |
| 目標達成に、現在のチームで何が足りないか？ | 採用すべきポジションの特定 |
| 足りない機能は、既存メンバーの育成で補えるか？ | 採用 vs 育成の判断 |
| いつまでにその機能が必要か？ | 採用スケジュールの逆算 |
| その機能がないと、事業にどの程度の影響があるか？ | ポジションの優先順位 |
ポジション優先度マトリクス
複数のポジションがある場合、以下の2軸で優先順位をつけます。
| 事業インパクト大 | 事業インパクト小 | |
|---|---|---|
| 充足の緊急性高 | 最優先で動く | 計画的に進める |
| 充足の緊急性低 | 早めに候補者プール構築 | 次の四半期以降 |
よくある失敗: すべてのポジションを「最優先」にしてしまう。リソースが分散し、結局どのポジションも中途半端になる。
正しい判断: 最優先ポジションは最大3つまでに絞る。残りは優先度を下げ、リソースを集中させる。
Step 2: ポジションごとの要件を構造化する
「エンジニア3人採用」で止めず、各ポジションの要件を構造化します。
要件定義テンプレート
各ポジションについて、以下を埋めます。
ポジション名: ________
配属先: ________
採用人数: ________
入社希望時期: ________
## なぜこの採用が必要か（背景）
[事業目標との接続。「なぜ今この人が必要か」]
## 入社後6ヶ月で期待する成果
[具体的なアウトプット。「3人」ではなく「何ができる状態になるか」]
## Must要件（これがないと不採用）
| # | 要件 | 判断基準 |
|---|------|--------|
| 1 | | |
| 2 | | |
## Want要件（あれば加点）
| # | 要件 | 重み |
|---|------|:----:|
| 1 | | |
| 2 | | |
## NG要件（即不採用）
| # | 要件 | 理由 |
|---|------|------|
| 1 | | |
## コンピテンシー（行動特性）
| # | コンピテンシー | Must/Want | 確認方法 |
|---|-------------|:---------:|--------|
| 1 | | | 書類 or 面接 |
| 2 | | | |
## 想定年収レンジ
下限: ________ 上限: ________
## 採用チャネル（優先順）
1.
2.
3.
このテンプレートを埋めるだけで、「なんとなく3人」から「根拠のある採用計画」に変わります。
ポイント: 「入社後6ヶ月で期待する成果」が最も重要。ここが具体的であれば、Must/Want要件もコンピテンシーも自然に導出できます。逆にここが曖昧だと、すべてが曖昧になります。
Step 3: チャネル戦略を設計する
各ポジションに対して、どのチャネルで候補者を集めるかを設計します。
チャネル別の特性マトリクス
| チャネル | 候補者の質 | 量 | コスト | リードタイム | 向いているケース |
|---|---|---|---|---|---|
| 人材紹介（エージェント） | 高 | 少 | 高 | 中 | ハイクラス・即戦力 |
| スカウト（ダイレクトリクルーティング） | 高 | 中 | 中 | 長 | 特定スキル・転職潜在層 |
| 求人媒体 | 中 | 多 | 中 | 短 | ボリューム採用 |
| リファラル（社員紹介） | 高 | 少 | 低 | 長 | カルチャーフィット重視 |
| 自社HP / 採用サイト | 中 | 少 | 低 | 長 | ブランド認知済みの層 |
| SNS / Founder-Led | 中 | 中 | 低 | 長 | スタートアップ・技術者 |
| 採用代行（RPO） | 中〜高 | 多 | 中〜高 | 短 | リソース不足時・立ち上げ期 |
チャネル選定の3つのルール
| ルール | 理由 |
|---|---|
| 1つのポジションに2〜3チャネルを組み合わせる | 1つに依存するとリスクが高い |
| ポジションの特性に合わせて主力チャネルを変える | エンジニアとセールスでは有効なチャネルが違う |
| チャネルごとのKPIを設定する | 「どのチャネルが効いているか」を測れるようにする |
ポジション×チャネルの設計例
| ポジション | 主力チャネル | サブチャネル | 理由 |
|---|---|---|---|
| バックエンドエンジニア（Go） | スカウト | リファラル、自社HP | 転職潜在層にアプローチ。Go人材は転職市場に少ない |
| 法人営業 | 求人媒体 | 人材紹介 | ボリュームが必要。エージェント経由も確保 |
| VP of Engineering | 人材紹介 | スカウト | ハイクラスは紹介が確実。スカウトで潜在層も狙う |
| カスタマーサクセス | 求人媒体 | スカウト | 新しい職種なので、キャリアチェンジ層も対象 |
Step 4: 選考プロセスとスケジュールを設計する
選考プロセスの標準設計
各ポジションの選考フローを設計します。ポイントは、各フェーズで「何を確認するか」を事前に決めることです。
| フェーズ | 所要日数目安 | 何を確認するか | 担当 |
|---|---|---|---|
| 書類選考 | 2日以内 | Must要件の充足、コンピテンシーの推定 | 採用担当 (or AI) |
| 一次面接 | 書類通過から5日以内 | 専門性、課題解決力、協働力 | 現場マネージャー |
| 二次面接 | 一次から5日以内 | リーダーシップ、カルチャーフィット | 部長 / VP |
| 最終面接 | 二次から3日以内 | キャリア志向、経営との適合 | 経営者 |
| オファー | 最終から2日以内 | 条件提示・意思確認 | 採用担当 |
ここで重要なのは「所要日数目安」の設定です。目安がないと、いつの間にか書類選考に1週間、面接調整に2週間かかり、トータルで1ヶ月以上。候補者は他社に先を越されます。
スケジュールの逆算設計
入社希望時期から逆算して、各フェーズのデッドラインを決めます。
入社希望日: 10月1日
↑
オファー承諾: 8月中旬（退職交渉期間1.5ヶ月）
↑
最終面接: 8月上旬
↑
二次面接: 7月下旬
↑
一次面接: 7月中旬
↑
書類選考: 7月上旬
↑
母集団形成: 5月〜6月（スカウト・媒体掲載開始）
↑
要件定義・チャネル設計: 4月〜5月
多くの企業は「母集団形成」の開始が遅すぎます。10月入社が必要なら、遅くとも5月にはスカウトや媒体掲載を始める必要がある。「人が足りないと気づいてから動く」のでは遅いのです。
Step 5: KPIを設定し、PDCAを回す仕組みを作る
採用計画を「立てて終わり」にしないための仕組みです。
採用KPIの設計
| KPI | 計測の意味 | 目安 |
|---|---|---|
| 応募数 | 母集団の量は足りているか | ポジションあたり月20件以上 |
| 書類通過率 | スクリーニング基準は適切か | 20〜40%が適正 |
| 面接通過率 | 面接の見極めは機能しているか | 一次50%、二次60%、最終80%程度 |
| 内定承諾率 | オファーの魅力は十分か | 70%以上を目指す |
| 選考リードタイム | 候補者を逃していないか | 応募→内定まで3週間以内 |
| チャネル別CPA | どのチャネルが費用対効果が高いか | チャネルごとに比較 |
| 採用単価 | 1人あたりの採用コストは適正か | 職種・レベルに応じて判断 |
PDCAの実行サイクル
| 頻度 | やること | 所要時間 |
|---|---|---|
| 毎週 | パイプラインの確認（各ポジションの応募数・選考状況） | 15分 |
| 隔週 | KPIの推移確認。目標とのギャップがあれば原因分析 | 30分 |
| 月次 | チャネル別の効果検証。効いていないチャネルの見直し | 1時間 |
| 四半期 | 採用計画全体の振り返り。次四半期の計画修正 | 2時間 |
最も大事なのは「毎週15分」のパイプライン確認です。ここで早期に異変を検知できれば、手遅れになる前に打ち手を変えられます。
「計画倒れ」を防ぐ3つのチェックポイント
チェック1: 計画と現実のギャップが見えているか
| ギャップの種類 | 確認方法 | 対策 |
|---|---|---|
| 応募が足りない | 月次の応募数推移を確認 | チャネル追加、求人票改善、スカウト量増加 |
| 質が合わない | 書類通過率が低すぎる or 高すぎる | 低すぎ→求人票の訴求見直し。高すぎ→基準が甘い可能性 |
| 面接で落ちすぎる | 面接通過率が異常に低い | 書類選考の基準と面接基準の乖離を確認 |
| 内定辞退が多い | 内定承諾率を追跡 | オファー条件の見直し、選考スピードの改善、候補者体験の改善 |
| スケジュール遅延 | 各フェーズの実績日数を計測 | ボトルネックの特定（日程調整？意思決定？） |
チェック2: 「言い訳」が構造化されているか
採用が予定通りに進まないとき、よく出る「言い訳」があります。これらを事前に構造化しておくことで、問題発生時に冷静に対処できます。
| よくある言い訳 | 本当の原因（可能性） | 対策 |
|---|---|---|
| 「良い人が来ない」 | 求人票が市場に響いていない / チャネルが合っていない | 求人票のレビュー、チャネルの見直し |
| 「忙しくて面接できない」 | 面接官の負荷管理ができていない | 面接負荷の分散、面接官の増員 |
| 「条件が合わなくて辞退された」 | 市場相場とのギャップ | 報酬データの再調査、非金銭的価値の訴求強化 |
| 「スキル要件を満たす人がいない」 | Must要件が厳しすぎる | Must/Wantの再分類。本当にMustか再検討 |
| 「採用は人事の仕事でしょ」 | 現場の巻き込みが不十分 | 採用計画策定段階から現場を参加させる |
チェック3: 計画を「育てる」仕組みがあるか
完璧な計画を最初から作る必要はありません。重要なのは、計画を実行しながら改善するサイクルを持つことです。
計画を立てる（仮説）
↓
実行する（検証）
↓
データを見る（KPI確認）
↓
計画を修正する（改善）
↓
次の計画に反映する（学習）
このサイクルが回っていれば、最初の計画が完璧でなくても問題ありません。四半期ごとに精度が上がっていきます。
職種別: 採用計画のカスタマイズポイント
エンジニア採用
| ポイント | 理由 |
|---|---|
| リードタイムを長めに取る | 優秀なエンジニアは転職潜在層が多い。関係構築に時間がかかる |
| スカウトを主力チャネルにする | 求人媒体だけでは質の高い候補者に届かない |
| Must要件を最小限にする | 「Go経験3年」をMustにすると、TypeScript出身の優秀人材を逃す |
| 技術ブランディングを並行する | テックブログ、OSS、勉強会登壇で認知を作る |
営業採用
| ポイント | 理由 |
|---|---|
| 書類選考の基準を明確にする | 「会ってみないと分からない」で全員面接すると面接官が圧迫される |
| 短いリードタイムを設計する | 営業は転職市場の流動性が高い。3週間以内に決着をつける |
| チャネルは求人媒体＋エージェント | ボリュームと質のバランス |
| 入社後のオンボーディング計画も含める | 早期離職を防ぐために、採用計画にオンボーディングも組み込む |
マネージャー採用
| ポイント | 理由 |
|---|---|
| コンピテンシー重視で選考する | スキルより行動特性が成果を左右する |
| リファラルとエージェントが主力 | マネージャー層は転職市場に出にくい |
| 現場との合意形成を先にする | 「どんなリーダーが必要か」を現場と経営で合意しないと、選考がブレる |
| 内定後のフォローを手厚く | マネージャー層は他社からのオファーも多い |
採用計画テンプレート: すぐ使えるフォーマット
全体計画サマリ
## 採用計画 FY2026 — [部署名]
### 事業背景
[なぜ今これだけの採用が必要か。事業計画との接続]
### 採用目標サマリ
| ポジション | 人数 | 入社時期 | 優先度 | 主力チャネル | 想定年収 |
|-----------|:----:|:-------:|:------:|:-----------:|:-------:|
| | | | | | |
### 全体スケジュール
| 月 | アクション |
|:--:|----------|
| 4月 | 要件定義完了、チャネル選定 |
| 5月 | 母集団形成開始（スカウト・媒体掲載） |
| 6月 | 選考開始 |
| 7月 | 内定出し開始 |
| 8月 | 退職交渉期間 |
| 9月 | オンボーディング準備 |
| 10月 | 入社 |
### KPI設定
| KPI | 目標値 | 計測頻度 |
|-----|:------:|:-------:|
| 応募数/月 | | 毎週 |
| 書類通過率 | | 隔週 |
| 面接通過率 | | 隔週 |
| 内定承諾率 | | 月次 |
| 選考リードタイム | | 月次 |
ポジション別計画
## ポジション別採用計画
### [ポジション名]
- 人数: __名
- 入社時期: ____年__月
- 優先度: 最優先 / 高 / 中
#### 背景
[このポジションが必要な理由]
#### 期待する成果（入社6ヶ月後）
[具体的なアウトプット]
#### Must/Want要件
| 層 | 要件 | 判断基準 |
|:---:|------|--------|
| Must | | |
| Want | | |
| NG | | |
#### チャネル戦略
| チャネル | 優先度 | 月間目標 |
|---------|:------:|:-------:|
| | | |
#### 選考フロー
| フェーズ | 担当 | 確認事項 | 目標日数 |
|---------|------|---------|:-------:|
| 書類選考 | | | 2日 |
| 一次面接 | | | 5日 |
| 二次面接 | | | 5日 |
| 最終面接 | | | 3日 |
| オファー | | | 2日 |
まとめ —— 「去年と同じ」から「事業から逆算」へ
採用計画は「何人採るか」を決めることではありません。「事業目標を達成するために、どんな人を、いつまでに、どう見つけ、どう見極めるか」の設計です。
| やるべきこと | 効果 |
|---|---|
| 事業計画から採用ニーズを逆算する | 「なぜこの採用が必要か」が明確になる |
| ポジションごとにMust/Want/NGを構造化する | 「どんな人か」が具体的になり、選考基準がブレない |
| チャネル戦略をポジション別に設計する | 「良い人が来ない」を構造的に解決できる |
| 選考プロセスに日数目安を設定する | 候補者を逃さないスピード感が生まれる |
| KPIを設定しPDCAを回す | 計画が「育つ」仕組みになる |
まずは、次の四半期の採用計画を1ポジションだけ、このフレームワークで立ててみてください。 「去年と同じ」から「事業から逆算」に変えるだけで、採用の質は構造的に変わります。
Tasonalは、採用計画で定義した要件を書類選考AI・日程調整AI・AIスカウトで実行する採用AIプラットフォームです。計画で決めた「どんな人か」をAIが評価基準に落とし込み、選考プロセス全体を構造化。計画→実行→振り返りのサイクルが、データに基づいて回り始めます。
