総合ITエンジニアの採用選考、どうしてる？
ITエンジニアの採用を成功させるためには、自社のニーズに合いそうなエンジニアに応募してもらった上で、お互いにマッチするかをうまく見極めて決断する必要がある。応募を得るために有効な基本原則は、前回の記事「ITエンジニア採用に欠かせない原則とは」で紹介した。
次の課題は、応募してくれたITエンジニアをどのように選考するかだ。そこで今回は前・中・後編にわたって、ITエンジニアの採用選考についての著者の考えを、10年以上経営者兼エンジニアとして採用に関わってきた実体験を踏まえて述べていきたい。前編では、採用選考の仕組みを構成する要素を分析した上で、エンジニアが採用選考へ参加することや評価項目を定めることの重要性について解説する。
採用選考、どうしてる？
みなさんの会社では、どのように採用選考を行っているだろうか。まずは採用選考のやり方を構成する要素について考えてみよう。例えば、次のような観点が思い浮かぶのではないだろうか。
- 誰が選考に参加しているか？
- 誰がどのように採否を決定しているか？
- 応募から採用に至るまでのフローはどうなっているか？
- 評価する項目や、項目ごとの重要度は定義されているか？
- 採用候補者のスキルや人柄を正確に見極められているか？
そもそも採用選考のゴールは、採用候補者を評価して、採用するかどうかを決定することである。評価する人と決定する人は、同じである場合もあれば、異なる場合もあるだろう。また、それぞれ1人で行うとは限らず、複数人で行うかもしれない。
いずれにしても、評価者が評価を行い、決定者がその評価結果を踏まえて決める形が基本だろう。
このとき、評価者にとって課題となるのは、次の2点ではないだろうか。
評価者の課題
- 何について評価するのか？
- 評価したい要素について、どういう方法で見極めるのか？
また、決定者の課題としては次の2点が考えられる。
決定者の課題
- 評価結果をどう解釈するか？
- 何をもって採否を決定するか？
次に、これらの課題を解決するために何が必要となるか、その要素と枠組みを考えてみよう。
評価に必要な要素と枠組み
1. 何について評価するのか？
評価者にとっての1つめの疑問「何について評価するのか？」を解決するためには、それを具体的に定義した評価項目が必要である。
評価項目については後で詳しく触れるが、例えば「自力でWebアプリケーションを作った経験がある」とか「適切な言葉遣いで話せる」といった項目のことを指す。
このような項目が定められておらず、採用に参加する人がなんとなく判断して評価する場合もあるかもしれない。しかし、著者の経験では、評価項目の定義はぜひとも用意したほうがよい。その理由は、後で詳しく述べる。
それでは、評価項目は何を基準に作ることになるのだろうか？ 当然、より上位の方針からブレークダウンすることになる。すなわち「会社が社員全般に対して求めること」や「その採用の目的に適うかどうか」といった観点から決めることになるだろう。そこで、評価項目の上位に「社員全般に求めること」と「採用の目的」という2つの要素を置こう。
2. 評価したい要素について、どういう方法で見極めるのか？
評価者にとっての2つめの疑問「評価したい要素について、どういう方法で見極めればよいのか？」に対しては、評価項目に対応した見極めの方法論やテクニックが必要となる。「面接でコードを書いてもらう」などはよく知られたテクニックだ。見極めの方法論については、主に後編（次々回）で取り上げたい。
ところで、候補者の資質の見極めは、誰が評価を行うかでも変わってくる。例えば、エンジニアが参加していない面接で、その場でコードを書いてもらって評価するのは難しいだろう。したがって、「誰が評価するか」という要素を、見極めのテクニックの上流に置きたい。
「評価項目」と「誰が評価するか」の関係を考えて見ると、誰が評価するのがよいかは、評価項目次第であることがわかる。そこで「誰が評価するか」という要素は「評価項目」と「見極めのテクニック」の間に足すことにする。
以上で、評価についての要素を整理することができた。
採否の決定に必要な要素と枠組み
評価についての要素を整理できたので、次は、採否の決定についての要素を整理していこう。
1. 評価結果をどう解釈するか？
評価者による評価結果については、注意すべき点がある。それは、評価結果には評価者の主観によるバイアスがかかってしまうということだ。そのため、決定者は評価結果の信頼度を判断する必要が生じる。また、評価項目も採用の目的に対して完璧とは限らない。評価項目の偏りや不備のために、評価結果が適切でないと感じる場合もあるだろう。
このように、個人差や評価項目の不備を踏まえた上で、評価結果をどう解釈するかという課題が、今回の1ページで挙げた決定者の課題の1つめ「評価結果をどう解釈するか？」である。決定者の解釈の自由度が大きすぎると、評価者の評価が無意味になる危険もあるため、どのような調整を許容するかの指針を定めておきたい。
2. 何をもって採否を決定するか？
2つめの課題「何をもって決定するのか？」に対して答えを出すためには、採否決定の基準を作成する必要がある。採否決定の基準とは、評価項目に対して行われた評価がどういう結果なら採用するのかという決まりのことだ。
以上、評価者による評価から決定者による採否の決定までに挙げてきた採用選考の要素をまとめると、次図のとおりとなる。
本記事（前・中・後編）では、ITエンジニアの採用選考を考えるためのステップを、この図を使いながら解説していく[1]。
注
[1]: この図自体は、ITエンジニアに限らず、採用全般に対して適用可能であると思う。
現場のエンジニアが選考に参加することが望ましい
まずは、採用選考の要素の図の中ほどにある「誰が選考するか」に着目したい。これについて、ほぼ間違いなく有効だと思われるのが、ITエンジニアの採用選考にはできるだけITエンジニアに参加してもらうことである。
一口にITエンジニアといっても、エンジニア経験があるが今は現役ではない人、採用後に働いてもらう環境とは技術・チームが異なるエンジニアなどさまざまだ。なるべく、採用した人が働くことになる現場のエンジニアに参加してもらおう。
自社にエンジニアがいない場合、パートナー企業のエンジニアに協力してもらうという手もある。エンジニア参加ゼロで選考するよりはよいだろう[2]。
ところで、なぜ現場のエンジニアに参加してもらうことが重要なのか。それには次のような理由があるからだ。
現場のエンジニアに参加してもらうことが重要である理由
- エンジニアとしての適性、現在のスキル、向いている仕事の領域、予想される成長速度などを一番的確に判断できるのはエンジニアである（コラムを参照）
- 一緒に働けそうかどうかを高い精度で評価できるのは、一緒に働くことを具体的にイメージできる立場の人である
- 採用後に、その採用に伴う各種の協力をエンジニアから得やすくなる
ただ、これらの理由を目にしても、エンジニアに採用選考に参加してもらうことにためらいを感じる方がいるかもしれない。
エンジニアに選考に参加してもらうことに二の足を踏む理由の一つに「エンジニアの貴重な時間を採用に使いたくない。エンジニアでなくともある程度見極めができる自信がある」という考え方がある。これについては、マッチしない人材が来た後にエンジニアの時間が無駄になる度合いを考慮すれば、エンジニアに採用に協力してもらうことは相対的にコストパフォーマンスが良い、ということを述べておきたい。もちろん、書類選考や1次面接など、前段の採用フローで候補者を絞り込み、エンジニアの負担を減らす工夫も大切だ。
別のケースとして「採否についてエンジニアの意見を否定できなくなるのが怖い」「エンジニアが選んだ社員が増えることで、自社の雰囲気や運営に影響が出ることが不安」といった気持ちが潜んでいることも考えられる。もしもそのような気持ちが多少あるとすれば、この点は、本連載の基本的なテーマの1つである「エンジニアとスタッフのしあわせな協力体制をどう築けるか」ということに関わりが深い。これについては、中編以降でまた触れていきたいと思う。
ところで、ここまでエンジニアに採用選考に参加してもらうことを強く推奨してきたが、それでは「現場のエンジニアに採用選考に参加してもらいさえすれば採用はうまくいく」のだろうか――残念ながら、答えはNOである。ITエンジニアに採用選考に参加してもらうことは、あくまでも上手な選考の最初の入り口にすぎない。他にもたくさんの気をつけたいポイントがあるので、順に解説していこう。
コラム「エンジニア同士でなければ見えてこないもの」
著者は、以前勤めていた職場で、スタッフ部門の地位ある社員がエンジニアを面接する様子を観察したことがある。その様子をまとめるとこうだ。
面接官が重視していたこと
- キーとなる技術用語を知っているか（簡単なテストが行われた）
- 本人の熱意
- ビジネスマンとしての常識や責任感
- 面接官本人の持論の「演説」を熱心に聞いてくれるか
面接官が確認しなかった（できなかった）こと
- 論理性・緻密さ・客観的な態度（技術者として基本的に重要な要素である）
- 技術を頭で知っているだけなく実際にどの程度使えるのか
- エンジニアとしてのチームプレイ力
結果的に、エンジニアへの適性やスキルレベルは評価できておらず、社員としての好感度や一般的なアピール力ばかりを評価してしまっていた。
これは一例に過ぎないが、エンジニアという職種の詳細を知らないということは、その種の、本来見極めるべき部分の見落としや、評価の偏りを招きやすいのではないかと思う。
注
[2]: 実際にそのようなニーズはあり、弊社もたまに協力することがある。
評価項目を策定しないとエンジニア採用の精度は高まらない
現場のITエンジニアに採用選考に参加してもらうか否かにかかわらず、候補者が会社として採用したい人材像にマッチするかを見極めるための確認事項、すなわち「評価項目」を定義しておいたほうがよい。評価項目を定義することは、逆説的な言い方をすれば、他の項目については評価を行わないでよいということを決めることでもある。そのため、評価項目を定義するということは、評価を行う領域を絞り込むことでもある。
もしも、採用選考に関わる人々の間で、具体的な評価項目についての共通認識がない場合、何が起きるだろうか？ 例えば、ある日突然、現場のITエンジニアが上司から「採用面接に参加した上で、自由な意見を聞かせてくれ」と言われたら？ あるいは「エンジニアの視点で技術力を見極めてくれ」と言われたものの、指示してきた本人のイメージする “技術力”が曖昧な場合には？
評価項目が定まっていない、ないし、評価者に伝わっていないという状況は、候補者を全方位から評価することを評価者に求めることに似ている。
ここでは、評価や見極めを採用面接によって行うとしよう。採用面接の時間は限られている。そのため、現実には全方位で評価することはできない。評価項目を示さないということは、評価するエリアの選択の仕方を、評価者の個人的な視野と判断に委ねるということである。
ITエンジニアに採用選考を依頼する場合、このようなやり方では、評価するポイントが次のような点に偏ってしまいがちだ。
- 自分の良しとするITエンジニア像に近いか。将来近づけそうか
- 即戦力で頼りになるか
- 一緒に働くことに興味や関心を持てるか
- 自分に似ているか[3]
しかし、会社として本当に評価してもらいたい項目は、次のようになるはずだろう。
一般的な領域
- ① 候補者の価値観は、会社の価値観とマッチしているか
- ② 候補者には、会社が社員に広く求める資質やスキルがあるか
専門的な領域
- ③ 採用の目的に照らして、適切な準備期間ののちに戦力として活躍できる資質・スキルがあるか
このように、個人が思い思いに判断する評価領域と、会社が本来評価してほしい領域にはズレがあり、個人に任せるやり方では、会社にとって理想的な採用選考を実現することは難しい。このズレは色々な問題を引き起こし得るが、特に次に挙げる2つの問題を生じやすく、注意が必要だ。
- 一般的な領域に対する評価が個人ごとにばらつき、精度が低くなる
- 専門的な領域について、採用の目的に照らして合理的ではないレベルで特定の評価項目を重視してしまい、結果的に甘すぎる／厳しすぎる評価をしてしまう
1.については、例えば服装や言葉遣いに対する評価は、評価者の個人的な関心で大きくブレることが多い。服装や言葉遣いを評価するかどうかを任せきりにすると、細かく見る人もいればまったく見ない人もいるという状況になる。また、会社の価値観への適合度合いなども、意識的に評価する人もいるが、まったく気にしない人もいる。
2.については、「どのくらいの期間でキャッチアップできればよい」とか、「ある領域ができればある領域はできなくてもよい」といった情報が伝わっていないと、チームメンバーとしてのスタンダードな資質・スキルと比べるなどした結果、必要以上に厳しく評価してしまう可能性がある。また、たまたま採用に関わったエンジニアが重視するポイントが必要以上に選考結果に強く反映されて、結果的に甘すぎる／厳しすぎる評価になる危険性がある。
こうした問題をできるだけ回避するため、評価項目はある程度明示しておきたい。
それでは、評価項目はどう作ればよいだろうか？ 次回の中編では、前述の「会社が本当に評価してもらいたい項目」①～③について、それぞれどのように採用選考の評価項目を作ることができるかを解説する。また、評価項目や採否の決定基準において、「一般的な領域」と「専門的な領域」のどちらをどれだけ重視するか、その判断の難しさを解説するとともに、その対処方法を考えていきたい。
注
[3]: 個人差はあるが、面接を行うエンジニアが、自分に似たタイプのエンジニアに好感を持ちやすい傾向を経験的に感じている。例えば、好奇心旺盛なエンジニアは好奇心を、勉強の得意なエンジニアは勉強力を、OSS開発に熱心なエンジニアはOSS開発への関わり方を、マネージメントが得意なエンジニアはマネージメント適性を重視するといった傾向を感じる。