AI・DX人材が採れない本当の理由
— 採用要件を言語化する5つのステップ

1. 「いい人が来ない」の根本原因は、要件の解像度にある

採用がうまくいかないとき、多くの企業はまず「媒体を変える」「エージェントを増やす」「年収レンジを上げる」という集客側の打ち手から考えます。しかし、私が上場企業子会社の代表として毎月数百名の応募と向き合った経験からも、その後さまざまな企業の採用を支援してきた経験からも、うまくいかない採用の根本原因は集客ではなく、「誰を採るか」が正確に定義されていないことにあるケースが大半です。

要件が曖昧なまま採用活動を進めると、問題は選考プロセスの全工程に波及します。

• 求人票が刺さらない。誰にでも当てはまる言葉で書かれた求人は、誰の心にも刺さらず、転職サイトの一覧で埋もれます。
• 紹介会社が動けない。エージェントは要件が曖昧な求人に候補者を当てられないため、「とりあえず経歴が近い人」を送ることになり、ミスマッチが繰り返されます。
• 面接の判断がぶれる。評価基準がないため、面接官ごとに見るポイントが異なり、「なんとなく良い／悪い」という印象で合否が決まります。
• 入社後にギャップが出る。期待役割が言語化されていないため、入社した本人も受け入れる現場も「思っていたのと違う」状態になり、早期離職につながります。

つまり、要件定義は採用活動の一工程ではなく、求人票・母集団形成・選考・定着のすべての品質を決める土台です。ここの解像度を上げずに集客側だけ強化するのは、穴の空いたバケツに水を注ぎ足す行為に近いと言えます。

2. なぜAI・DX人材の要件定義は特別に難しいのか

要件定義の重要性はどの職種にも当てはまりますが、AI・DX領域では難易度が一段上がります。理由は3つあります。

理由1：職種名と実態が一致していない

「AIエンジニア」という同じ肩書きでも、機械学習モデルを研究開発する人、生成AIのAPIを使って業務アプリケーションを作る人、データ基盤を整備する人では、スキルセットがまったく異なります。DX人材も同様で、「DX推進担当」の実態は、企画寄り・技術寄り・現場変革寄りと企業によってバラバラです。職種名で募集すると、自社が必要とする人と違う人が集まるのがこの領域の特徴です。

理由2：技術の進化が速く、スキル要件がすぐ古くなる

生成AIの登場以降、「AIを使ったシステム開発」に必要なスキルは大きく変わりました。数年前の常識で「機械学習の博士号」「Kaggleの実績」などを必須要件にすると、実際には生成AIのAPI活用で解ける課題なのに、採用の難易度と人件費だけが跳ね上がります。「今の自社の課題に、どのレベルの技術が必要か」の見極めが要件定義の核心になります。

理由3：技術理解と事業理解の両方が要る

要件を定義するには、「事業のどこに課題があるか」（事業理解）と「それを解くのにどんな技術・経験が必要か」（技術理解）の両方が必要です。事業側だけで書くと「AIで何かやってくれる人」という曖昧な要件になり、技術側だけで書くと「うちの事業には過剰な」スペック表になります。両者を翻訳できる人が社内にいないことが、AI・DX採用が難しい構造的な理由です。

3. 応募が来ない求人票の3つの典型パターン

要件定義の甘さは、求人票に正直に現れます。採用のご相談で拝見する求人票の課題は、およそ次の3パターンに集約されます。

3つに共通するのは、「この人に入社後何をしてもらい、何ができたら成功なのか」を発注側が決めきれていないことです。求人票の書き方のテクニックでは解決できず、その手前の要件定義に立ち返る必要があります。

4. 採用要件を言語化する5つのステップ

では、要件はどの順番で言語化すればよいのか。私たちが採用支援の現場で使っている手順を5つのステップに整理します。ポイントは、人物像やスキルからではなく、事業課題から始めることです。

ステップ1：事業課題を特定する — 「なぜ今、このポジションが必要か」

最初に言語化すべきは人ではなく課題です。「売上の頭打ちをデジタルチャネルで打開したい」「属人化した業務がボトルネックで受注を増やせない」など、そのポジションが解決すべき事業課題を1〜2文で書きます。ここが書けない場合、実はまだ採用のタイミングではない（外部委託や業務改善で足りる）可能性も含めて検討すべきです。

ステップ2：期待役割と成功基準を決める — 「1年後に何ができていたら成功か」

課題が決まったら、「入社後1年でこの状態を作ってほしい」という期待役割を定義します。あわせて、半年後・1年後の成功基準（何がどうなっていたら活躍と言えるか）を数字や状態で書きます。これは入社後の目標設定・評価にそのまま使えるため、定着率にも直結します。

ステップ3：役割をスキル・経験要件に翻訳する

期待役割を実現するために必要なスキル・経験を洗い出します。このとき必ず「必須（これがないと役割を果たせない）」と「歓迎（あれば立ち上がりが速い）」を分けます。必須は3〜5個に絞るのが原則です。10個並んだ必須要件は、実質的に要件を決めていないのと同じです。技術要件の妥当性判断が社内で難しい場合は、この工程だけ外部の技術がわかる人にレビューしてもらうだけでも精度が大きく変わります。

ステップ4：組織文脈と人物像を言語化する

スキルが合っていても、働き方や意思決定のスタイルが合わなければ定着しません。「経営直下でスピード重視」「現場との調整が多い」「整った環境ではなく仕組みを作る側」など、自社の組織文脈を正直に書き、そこで活きる人物像・つまずく人物像を言語化します。ここを美化すると、入社後ギャップによる早期離職として必ず返ってきます。

ステップ5：評価基準と面接スコアカードに落とす

最後に、ステップ1〜4を面接で確認できる形に変換します。要件ごとに「どの面接で・誰が・どんな質問で・何を確認するか」を決めた面接スコアカードを作ります。これにより、面接官による評価のバラつきが抑えられ、「なんとなく良かった」ではなく要件に基づいた合否判断ができるようになります。

5ステップの適用例 — 「DX推進担当が欲しい」を言語化してみる

抽象的な依頼が5つのステップでどう変わるか、実際の支援でよくある例で見てみます。最初の依頼はこうでした——「うちもDXを進めたいので、DXに強い人を採用したい」。このままでは求人票も書けず、エージェントも動けません。ステップに沿って対話を進めると、次のように具体化されていきます。

• ステップ1（事業課題）：受注が増えているのに、見積作成と請求処理が手作業のため月末に残業が集中し、営業が事務作業に時間を取られている。
• ステップ2（期待役割）：入社1年で、見積〜請求の業務フローを再設計し、ツール導入によって営業1人あたりの事務時間を半減させる。
• ステップ3（スキル要件）：必須は「業務フローの改善・標準化を主導した経験」と「業務システムやSaaSの導入経験」の2つ。生成AIの活用経験は歓迎に回す。
• ステップ4（組織文脈）：現場は変化に慎重なベテランが多い。技術力より「現場に入り込んで信頼を作れるか」が定着の鍵になる、と正直に書く。
• ステップ5（評価基準）：一次面接では過去の業務改善の実例を深掘りし、「抵抗があった現場をどう巻き込んだか」を全候補者に共通の質問として確認する。

ここまで言語化されると、求人票のタイトルも「DX推進担当」ではなく「営業事務の業務改革リード（見積〜請求プロセスの再設計）」のような、実態が伝わる表現に変わります。誰を探しているのかが明確になれば、候補者にもエージェントにも刺さり方がまったく違ってきます。

5. 職種別の要件定義例 — AIエンジニア・DX推進・PM

5つのステップを、代表的な3職種に当てはめた例を示します。自社の状況に合わせて書き換える叩き台としてご活用ください。

6. 要件定義チェックリスト（10項目）

作成した要件定義の品質を、以下の10項目で自己診断してください。8個以上にチェックがつけば、求人票の作成・エージェントへの依頼に進める水準です。

特に重要なのは10番です。要件が経営と現場で共有されていないと、選考の途中で「やっぱりこういう人がいい」と基準が動き、候補者・エージェント双方の信頼を失います。要件定義書は、社内の採用関係者全員の合意文書として機能させてください。

7. 自社でやるか、外部と組むか

ここまでの手順は、自社だけでも実行できます。ただし、次のいずれかに当てはまる場合は、外部の専門家と組むことを検討する価値があります。

• 技術要件の妥当性を判断できる人が社内にいない（ステップ3で精度が出ない）
• 採用担当のリソースが足りず、要件定義に時間を割けない（結果として曖昧なまま走ってしまう）
• 過去に採用したが早期離職が続いており、原因を客観的に分析したい

外部と組む形には、要件定義や選考設計を含めて採用プロセス全体を支援する採用代行（RPO）と、候補者の紹介を受ける人材紹介があります。両者の違いと使い分けは、「採用代行（RPO）と人材紹介の違いと使い分け」で詳しく解説しています。

いずれの形を取るにせよ、本記事の5つのステップ、特にステップ1〜2（事業課題と期待役割）は自社でしか決められません。ここさえ言語化できていれば、外部パートナーの力を最大限に引き出せます。逆にここを丸投げすると、どんな支援会社と組んでも成果は出ません。まずは自社の「なぜ採るのか」を言葉にすることから始めてください。

よくある質問