ソフトウェアエンジニアを採用する時に見るべき６つのポイント

何を期待されてるのかさっぱりわかりませんが、到着３週間で早速採用インタビューとかに使われてたりしています。英語がわからんっつーの。しかもMathのPhDの喋る内容なんて日本語で聞いてもわからないっていうのに。こちらから質問しておきながら半分以上は聞き流したりして何とかやってます。パーソナルなことは聞かないようにと言われていますが、人種も年齢も性別もごちゃまぜなのでほんとに気にならないというか気にしている場合ではない。「ジュニア」「シニア」ぐらいの分け方はありますがそれ以上でもそれ以下でもないし新卒中途とか年齢とか性別とか見てたころは一体何だったのだろうという。

そんなわけで今日は採用に関する６つのポイント。実は半分は人の受け売りです。

Passion
これはよく言われると思いますが、その職場や職種に熱意とか興味とかがない人はやっぱり駄目でしょうね。逆に他のものが足りなくても熱意があれば（特にソフトウェアなんかの場合）自分でどんどん覚えていくので十分補足する材料になり得ます。

Potential
人には伸びしろというのが必ずあるものですし今の時点で足りてなくても１年ぐらいで追いつくと思えば十分ペイするはずです。必ずしも年齢が若いとかそういうことではなくて、例えば大企業ですごく狭い領域を専門的にやってましたという人が小さい会社に来て広範囲の問題を相手にする場合、当然これまでの専門外は見ず知らずなわけですが自分の専門をきっちりやった上で柔軟性があれば伸びしろは十分にあるわけです。

Knowledge
当たり前と言えば当たり前ですが、自分が働く領域について知識があるかどうかは重要なファクターです。ソフトウェアエンジニアについて言えばこれまでやって来た領域に限らず広くソフトウェアエンジニアリングについて本を読めばわかることは多いですし、今同業の人たちでどんなことがホットなのか、業界のビジネストレンドがどうなっているのか、どういうプレイヤーがいるのかなど、アンテナの高さは働き始めてからの伸びに関わります。

Skill
Knowledgeと少し違うのはソフトウェアエンジニアの場合ちゃんとコードが書けるか、シェル動かすスピードはどうかとかそういうことになります。リンクリストとかスタックとか書かせればすぐわかります。SQLで相関サブクエリ＋集計とか出すと結構な人が脱落します。もうちょっと高度なものが必要な時にはダイナミックプログラミングとかもいいかもしれません（所用時間で終わらなくても大枠の理解が伝われば良し）。ある程度レベルや分野に分けて事前に問題集を作っておくといざというときにパッと出せて便利です。

Experience
KnowledgeやSkillと連動すると思いますが、これまでの経験は当然活かせる方がよいと思います。これの難しいところはレジュメ見てもわからないところで、「１０人プロジェクトのリーダ３年」という人はザラにいたわけですが、修羅場の切り抜け方、議論のまとめ方を知ってるか知らないかはよくよく話を聞いて判断することにしています。プロダクトがバグったときにどういう措置を採りますか？と聞いて「ログ見ます」しか答えられない人は、多分困ったときに頼りにならないと思ってます。

Getting Things Done
６つも挙げといてこれが書きたかっただけなんですが、一番大事なことはちゃんと任務を完遂できるかどうか。特にコードを書かなきゃならない場合、シノゴの行ってないでまずはコード書けと。書いて捨てろと。捨てたら同じことしないように３倍の早さで書き直せと。会社の方向性と体質にもよりますが、会社としてビジネスが絡む以上きれいごとだけでは済まされないわけで、それを理解できずにいつまでもグダグダやる人がいます。逆に何も考えずに目先のゴールだけ達成してコードの品質とか考えない人はソフトウェアの美学から採りたくないんですけれどもええ。

採用に関わるエンジニアの方も少なくないでしょうが、「何となく」話を聞いて終わり、というのは多いのではないでしょうか。自分もよくそこに陥りますので。自分なりの指針を持って採用に関わればブレないし少しは科学的にやれるような気がします。