IT業界の常識をそのまま鵜呑みにして行動していると幸せになれない、そう気づいたのはいつのことだったでしょうか。
そのひとつが、外部からプロジェクトメンバーを募るときのやり方です。
自社で要員を確保できない場合、派遣会社や同業のシステム会社に人の手配をお願いすることがあります。
・仕事の概要（業務内容、OS、DB、言語）
・期間（○月○日から○ヶ月）
・応募人数（○名）
という内容でお願いすると、先方の営業が、自社や知り合いの会社のSEの職務経歴書を送ってきます。
そして、発注側が気に入れば「採用面接」になるという手順です。
この採用面接ですが、名の通り、面接だけのことが多いようです。
つまり、これまでの業務経験について質問し、その応対能力を見て判断するのです。
しかし、これが企業の入社試験であれば、どうでしょう？
筆記の能力診断テストが課されたりして、1対1の簡単な面接だけで、あっという間に採用したりはしないはずです。
たとえ、明日からプロジェクトが走り出そうとしていて、技術者が一人も決まっていないという状況だとしてもこういった安易な方法を採るべきではありません。
まず、プログラミング技術者を採用しようとしているのであればとにかく、簡単なコードを書かせることが先決でしょう。
簡単なアルゴリズムや、数十行のコーディングで実現できる（慣れたプログラマであれば5分くらいで書き終えてしまうような）問題を出すのが良いでしょう。
それは基本的なアルゴリズムの問題であり、たとえどんなに緊張して本領が発揮できなかったとしても、間違えたり、スペルミスをすることは問題外です。
テストをすることは、発注側にとって応募者がコーディングにどのくらいの時間をかけるかを確認することができるというメリットもあるのです。
「巧遅は拙速に如かず」
どんなに教科書通りの素晴らしいコードを書いたからといって、普通の人が5分で書き終えるものを、5分待ってから書き出し、書き終えるのに10分かかるようでは、採用してはいけないのです。
また、コードを書かせることで、会話だけでは気付かない面も見えてくるはずです。
採用面接で1時間、どんなに真剣に質問を考えたとしても技術者の能力を見抜くのは難しいものです。
確かに、一緒にいて楽しい人や、気の合う仲間を採用するという意識も多少は必要なのかもしれません。
しかし、技術者を助っ人として雇うのであれば、気のいい仲間ではなく、結果を時間内で出してくれる人を求めるべきではないでしょうか。
決して、コードを書かせるテストをはずしてはいけません。
Vol.00187