エンジニアの採用はチームの文化で決める

エンジニアの採用では、だいたいこんなイメージになるのではないか。

  1. 事前に業務経歴書を読む
  2. 面談で、持っている技術スキルを尋ねる
  3. 一番辛かった経験談などを尋ねる

1番目は参考になったことがほとんどない。なぜなら、エントリしてくるエンジニアの業務経歴書には、業種と適用技術しか書かれていないからだ。○○業界のプロジェクトで△△技術を使った、的な書きっぷり。

2番目は1番目では技量がわからないから尋ねることになるわけだが、上っ面だけで質問をする採用側もよく見かける。そんな質問でどのくらい技量が把握できるのだろう。

3番目なんてほとんど意味がない。例えば、修羅場やデスマの経験を聞いてどうするのだろう。修羅場やデスマ前提なプロジェクトマネジメント をやっているのだと採用側から漏らしているようなものだ。

中途採用なら即戦力を必要としている。であれば、即戦力で配置するポジションはどこなのだろう。アーキテクトのような技量を必要とするのだろうか。リーダのロールを任せたいのだろうか。であれば、アーキテクトに必要とされる資質に関する質問をした方が良いのではないだろうか。さらに、過去の事例のシステムデザインを持ち出して、自分ならどうするか所見を言ってもらうのが良いのではないだろうか。

ここまでは採用する側の欲しい技術的な資質を持っているかどうかだけを尋ねている。

では、採用したい組織の部門、チームに入って一緒に働けるかどうかはどうやって見極めるのだろう。採用候補者のエンジニアはそのエンジニアのキャリアとして経験を持っているのと同様に、採用したらjoinするチームにはこれまで培ってきたチームの家風、文化が育っている。採用後、エンジニアが新たな文化を持ち込むかもしれないが、それはベースに既存の文化に混入してくるのである。

要は、候補者がチームの文化に馴染めるかどうかを見極めなければならない。

チームは、候補者に対して、チームで持っているスキル、スキルレベルを伝える他に、文化として形作られた意思決定のスタイルを伝えなければならない。

少ない情報でも早く判断する、ある程度仕様を決められればとにかく作ってみる、全員でレビューしてから作る、などである。

採用で優先するのは、この文化に馴染めるかどうかが最優先事項だ。技術は資質を持ち合わせているなら、後から教育すればいい。

そう考えると、採用は変わってくると思わないだろうか。

 

世界で闘うプログラミング力を鍛える150問 ~トップIT企業のプログラマになるための本~

世界で闘うプログラミング力を鍛える150問 ~トップIT企業のプログラマになるための本~