「ソフトウェア開発者採用ガイド」を読んだ

Posted on 2016-08-21 , Tags: Hiring, Book Review

現在働いている会社1は現在社員13人であり、だれでも採用に関わる機会が多い。
採用活動についていくつか調べている中で、“採用活動のベストプラクティスを求めて「ソフトウェア開発者採用ガイド」を読む”に影響されて、「ソフトウェア開発者採用ガイド」を読んだので感じたことなどを書きとめておく。

全体について

この本の概要は上のブログによくまとまっているので、ここでは省く。
「ジョエルテスト」はよく知られていると思うが、この本全体も一度は読んでおくとためになることは多いように感じた。

印象に残った点

ここからは印象に残った点をあげていく。

スーパースターを採用する必要性

特に印象に残った点としては、前提として「スーパースター」となるようなプログラマがいかに大切なのかを結構なページ数を割いて説明していたところだ。
この論点の根拠として、「スーパースター」は平凡なプログラマの5倍ほどの仕事をこなせることがある、というのを学生の統計データをつかって説明していた。しかし、そもそも学生の場合 Rebuild.fm #154 Aftershowでkazuhoさんが言っていたように、中学生からプログラミングをやっている人と大学から始めた人、というのでレベルがだいぶ異なる気もするが、これはこのまま仕事としてプログラマをやっている人にも適用できるものなのだろうか、ということは疑問に感じた。尤も、平凡なプログラマの5倍の成果をだせる人がいる、という説は自分自身プログラマの端くれとしてこれまでやってきた経験からも全く違和感がないことではある。
また、本でも述べられているが、「スーパースター」が本当に必要なのか？という疑問については、実際にどのような案件を担当するのかにもよるので、この本の主張を全て鵜呑みにする必要はないように思う。

いい人を見つけるにはこちらから出向くしかない

いい人はそもそもマーケットに出まわる可能性が低い、とのこと。
これはその通りかなと思った。入口あけてまっているだけではいい人がくる確率は少ないだろう。

社員による推薦は有効か？

上のブログでもふれられているが、著者は社員による推薦はあてにできない、としている。
もし不採用になったときに友情にヒビがはいることを懸念して本当の友人はつれてこない、特にインセンティブがある場合は見境なしにつれてくる、などが問題点としてあげられている。
自分の感覚としては、有効にはたらく場面も多そうだが、確かにこれも特に優れた方法ではないのだろう。

履歴書の読み方

著者は履歴書でいい人かどうかを判断するかは至難の業であり、基本的には明らかによくない人の判断に使うべきだ、という主張だった。これも納得できる。
また、本では例えばRubyをつかったシステム開発者を雇いたい場合、Rubyの入門書を読んだだけの人よりはSmallTalkとPythonのエキスパートを雇うべき、という事例をあげている。これもその通りで、関連する分野に習熟していれば、知らない技術でもある程度目星をつけて調べることができるので速い。プログラマは暗唱するのが仕事ではないので、知らない技術タームは調べればよいだけで、似たような概念、基礎になる概念を知っているほうが大事だ。

採用する側もアピールしなければならない

最後に、本を通して述べられていたことだが、いい人に来てもらうには採用する側も、よい環境2、よいチームで働けそうだ、という魅力を感じてもらえるように努力しなければならない。気高いゴールを設定したり、ある種の帰属意識をもてるようなチームを作る必要がある。
また、面接時にもできるだけいい印象をもって帰ってもらうことで、その人自身が最終的に不採用になったとしても、後で技術者間での話題としてあげたくなったり、メリットが増えるようだ。

この本がどの程度活かせそうか

上でも述べた通り、この本では「スーパースター」をどう雇うか、というのが主目的である。
この目的を読んだ時「スーパースター」が必要ないプロジェクトもあるだろう、と考えたし、実際著者もそのように述べているが、一点、自分の想定と少し異なる点があった。自分は「スーパースター」としてぼんやり「技術がとても得意な人」というイメージでいたが、著者は「頭が良く」「物事を成し遂げられる」人という2点をあげている。
これは、「頭が良い」だけでは延々と最適なものを追求してしまう可能性があり、「物事を成し遂げられる」だけではただ手を動かして何かよくわからないものができあがってしまう、ということのようだ。「頭がよいか」と「物事を成し遂げられるか」の2軸4象限で人を分類し、どちらも満たす人のみ雇いたい、ということだと解釈した。
即ち、当初自分がイメージした、ただ「技術がとても得意な人」はただ「頭が良い」人に近く、それとは別に、コミュニケーションが適切にとれるかどうか、現実的なスケジュールを考えてタスクを落しこめるか、など最終的に成果をだせるかどうかも著者は重要と考えているようだ。これは全くその通りで、その意味で、この本は自分の最初の印象よりは汎用的なのだと思う。
もちろん、この本が全てではないが、具体的にとりくめそうなところからやっていこうと思う。

  1. 過去の記事に現在の会社については書いた。↩︎

  2. https://twitter.com/naoya_ito/status/758815716413808640 のようなネタがあるほど、よい開発環境がメリットになる(むしろ最近ではある程度最低条件である)ことが多い。↩︎