シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。

エンジニアを選考する側になってしまった

»

 以前、、そして後編へと3回に分けての僕自身の職探しについてのコラムをを書いたが、実は最近、今度は僕がエンジニアを採用する側になってしまった。もちろん、僕は、経営者でもなく、マネージャでもない単なるエンジニアのリーダーなので、リーダーがスタッフを探すという立場だ。

 そのため、採用に関わる法的な側面、特にシンガポールならではの外国人を採用する場合のビザの話や、スタッフを人として見たときの判定の話はできない。しかし、過去に何度か、エンジニアの選考の仕事を経験した結果、僕なりに「確立」している使えるエンジニアを判定する方法を今回もとっているので、今回はそれについて書いてみる。ただし、自分自身が求職していて、同じ方法で自分自身が選考されていると感じたことはあまりないので、世間一般の方法とは違うのかもしれない。

 さて、まずはレジュメに目を通すことから始まる。僕自身が仕事を探したときの経験から分かってはいたが、実際に聞いて驚いた。私が今勤めている誰も名を知らない中小企業が、安っぽい募集広告をだして、それにレジュメを送って来る応募者が100人近くもいるということだ。レジュメは東南アジア全域から送られてくる。とても応募者全員と面接をするようなことはできず、書類選考を行う。

 レジュメを見るポイントだが、まず学歴。シンガポールの大学は別にして、それ以外の東南アジアの国の大学の場合、マスター卒であろうと、成績がどうであろうとそれは無視する。また、レジュメの職歴に書かれている、Javaの経験や.NETなどの技術の経験、金融関係とか医療関係などのドメインの経験は一応見るが、あまりそれに引きずられないように努力する。見るのは、1つ1つのプロジェクトの期間と、そのプロジェクトで応募者が果たした役割だ。

 ただし、役割として書かれている内容は自己申告なので、基本的に信じることができない。そのため、それを基に面接することを決めた場合は、面接で嘘を見破る努力をしなければならない。また、僕は、エンジニアが1人前に育つには長期のプロジェクトを一度は経験する必要があると思っているので、2年以上の長期のプロジェクトの経験がない候補者は落とす。つまり経験年数が長くとも、短いプロジェクトばかりの候補者は落とすことになる。

 さて、面接だが、レジュメの選考の基準でも書いたように、Javaの何かのフレームワークを知っているとか、デザインパターンを知っているとか、そういう知識の有無も少しは聞くが、これも、あまりその結果に引きずられないように努力する。基本的に、確認することは以下の3つだ。

(1) 未知の分野のエキスパートの説明を短期間で理解できるか?

 私の開発現場は基本的にアジャイルなので、開発要件は開発対象の分野での、その道のプロに直接聞いて把握していくことが必要になる。僕の経験だが、この能力はやはり、普通にいう「頭の良さ」、とかなり相関が高い気がする。学生時代の成績が良かった人。しかも、それほど努力せずに良い成績をとれた人。学生時代に先生の説明を1回聞くだけですんなりと理解できた人。そういう人が、文句なしだといえる。

 しかし、それに加えて、自分が理解できていないことが分かる人。そして、その理解できていないことを、要領よく言葉にして質問できる人。この辺りの能力は、多分、経験で身に付けられるものだと思う。

 話を聞きながら、自分の頭の中に論理のネットワークを作り、そのネットワークの中の矛盾に気付き、その矛盾の原因となる勘違いを突き止められる能力だ。多分、僕自身は後者のタイプのエンジニアだと思う。僕自身は、人の話を一度聞いただけで、なかなかすんなりと理解できない。質問を数多くして、理解するタイプだ。

 さて、短い面接でこの能力を測るのだが、方法は簡単だ。難しい要件を面接の会議室の白板を使って、僕自身が複雑な内容を実際に説明し、その後、それをどこまで理解しているかをチェックするためのテストを課す。

 今回、具体的に行っているのは、僕自身が昔日本の給与計算システムのアプリを開発したことがあるエキスパートなので、僕が日本の給与計算、一番分かりにくいのが社会保険料の算出の部分だが、その仕組みを説明している。理解していることを確認した後は、ERダイアグラムを書いてもらい、同時に設計能力の有無も確認している。シンガポールのエンジニアで日本の給与計算についての知識を持っている人は、まず皆無なので、公平に能力を確認できる。

 この方法だが、実際のアジャイルの現場で要件を聞く相手は、通常はITエンジニアではない。つまり、システム化するしないにかかわらず、自分が現在やっている業務を、システム化など一切考えずに説明してくるのが普通だ。しかし、私が説明するときはどうしてもシステム化を頭に思い浮かべながらの説明になるため、上のやり方は、厳密な意味のアジャイルでの要件把握のプロセスとは少しずれる。しかし、本当の能力との相関がかなり高い能力確認法だと思う。

(2) 未知のプラットフォームを使った開発を命じられて、短期間にそのプラットフォームの技術を習得して、開発できるか否か?

 レジュメを見て、応募者が経験したことのないプラットフォームを見付け、「そのプラットフォームを使った開発をやることになった。さてどうする?」を問う。僕にとって納得の行く回答が出てくれば合格だ。大抵の候補者は「Googleを使って検索して調べながら開発を行う」と回答してくる。スタッフレベルの開発者なら、そうやって技術を習得したとししても、及第点だ。

 しかし、「本を図書館で借りて週末や通勤時に読んで、未知のプラットフォームの知識を効率よく得ながら開発する」と回答する候補者なら、100点満点だ。120点の回答は、「レジュメには書いてないが、趣味でその技術を使った開発をやったことがあるので、問題ない」だが、そういう応募者には、まだ会ったことはない。また、「過去のプロジェクトで、同じ目にあったことがあり、このときはこう対処した」と、具体的な話ができても、最高だ。

(3) レジュメにうそがないか?

 プロジェクトの中の1つ2つをピックアップして、プロジェクトの役割に応じた苦労話などの具体的なエピソードを聞く。技術面や、開発対象のドメインについて聞くのもよいが、この場合付け焼き刃の理論武装をしていることもあるので難しい。また、プロジェクトが終わった後、2年も3年もたてば、細かい技術などは、忘れてしまっていることが普通だが、具体的なエピソードは簡単には忘れないので、このやり方が良い。

Comment(0)

コメント

コメントを投稿する