IT人材採用のミスマッチはなぜ起きるか。求める人物像を言語化する手順

「募集しても応募が来ない」「来ても求める水準に届かない」。IT人材の採用で語られる悩みの多くは、市場の厳しさだけが原因ではありません。求める人物像が言語化されていないまま募集が始まっていることが、少なくない割合を占めます。この記事では、ミスマッチが起きる仕組みと、要件を具体化する手順を整理します。

ミスマッチが起きる3つの型

採用がうまくいかない状況は、原因によって3つに分けられます。打つ手がそれぞれ違います。

• 母集団が集まらない／そもそも応募が来ない。条件、認知、募集の出し方に原因がある
• 選考で見極められない／応募は来るが、判断できない。評価基準が曖昧、面接する側に技術判断ができる人がいない
• 入社後にずれが出る／採用はできたが、期待と実際が食い違う。要件の言語化が足りていない

企業側は1つ目の問題として認識しがちですが、実際には3つ目が根本にあることが多いという構図があります。求める姿が曖昧なまま募集を出すため、応募も集まらず、選考基準も定まらないという連鎖です。

「即戦力」という言葉が招くずれ

募集要件でよく見かける表現に、次のようなものがあります。

• 「即戦力となる方」
• 「コミュニケーション能力の高い方」
• 「主体的に動ける方」
• 「Javaでの開発経験3年以上」

いずれも一見具体的ですが、何を判断すればよいかが分かりません。

「即戦力」は、何を任せた翌日から成果を出してほしいのかによって、必要な経験が変わります。既存システムの改修なら、そのシステムの構造を読み解ける力が要ります。新規開発なら、技術選定の経験が要ります。同じ「即戦力」でも中身は別物です。

「Javaで3年」も同様です。3年のあいだ何をしていたかで、できることは大きく変わります。 詳細設計以降だけを担当していた3年と、要件定義から関わった3年は別の経験です。

年数ではなく、「何をした経験があるか」で書くと、応募する側も判断しやすくなります。

求める人物像を言語化する手順

順序を踏むと、要件は具体的になります。

• 1. 任せたい仕事を洗い出す／その人に任せたい仕事を、具体的な作業レベルで書き出す
• 2. 判断が必要な場面を特定する／作業のうち、経験がないと判断できない部分を特定する
• 3. 必要な経験に翻訳する／その判断ができるためには、どんな経験が必要かを考える
• 4. 既存メンバーと比較する／社内の誰と近い役割か、あるいはどこが違うかを整理する
• 5. 選考で確認する方法を決める／その経験の有無を、面接や課題でどう確かめるか

とくに5番目まで踏むことが重要です。「確認方法まで決まっていない要件は、実質的に要件になっていない」と考えたほうが確実です。

この作業は人事部門だけでは難しく、実際に一緒に働く現場の担当者を巻き込む必要があります。技術的な判断ができる人が選考に加わっていないと、見極めは成立しません。

必須と歓迎を分ける

要件を洗い出すと、必ず多くなります。そこで必須と歓迎を分けます。

判断の基準はひとつです。「これがなければ、入社後すぐに困るか」。困るなら必須、後から身につけられるなら歓迎です。

実務でよくある例を挙げます。

• 特定のフレームワークの経験 → 同種の経験があれば習得できることが多い。歓迎に回せる場合が多い
• 担当領域の業務知識 → 業界特有の商慣習がある場合、習得に時間がかかる。必須になりやすい
• 設計工程の経験 → 任せたい役割によって、必須か歓迎かが変わる
• チームでの開発経験 → レビューや合意形成が必要な現場では必須に近い

必須要件が多いほど、該当する人は急速に減ります。 5つの必須要件があれば、それぞれを満たす確率の掛け算になります。本当に必須なのかを問い直す価値があります。

それでも埋まらないときの選択肢

要件を整理しても、採用には時間がかかります。プロジェクトの開始時期が決まっている場合、待てないことがあります。

その場合の選択肢は3つです。

• 要件を下げて採用し、育成する／時間はかかるが、長期的には組織の力になる
• 外部人材で当面を補う／専門性が高く一時的に必要な領域では現実的
• 役割を分割する／1人ですべてを求めず、必要な部分だけを複数人で分担する

3つ目は見落とされがちですが有効です。「設計から実装まで一人で」という要件を、設計は経験豊富な外部人材、実装は社内メンバー、と分ければ、それぞれの確保は現実的になります。

要件の言語化は、この判断のためにも役立ちます。何が必須で何が任意かが分かっていれば、分割の仕方も見えてきます。