読者です 読者をやめる 読者になる 読者になる

valid,invalid

関心を持てる事柄について

採用活動のベストプラクティスを求めて「ソフトウェア開発者採用ガイド」を読む

Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており、今では自分が採用側として履歴書を読み、面接に参加し、コードレビューを行うようになった。

コードレビューについては以下を参照。

Quipper のエンジニア採用プロセス コードテスト編 - @kyanny's blog -

応募直後のレジュメを見て下す判断や、面接の時間内での行われる会話の内容や質問は基本的に各自に委ねられている。事前に得られた候補者の情報から面接前に「今の採用方針は○○だから、こういうところを今回は見てみよう」「この経験を掘り下げてみよう」程度の認識合わせをすることはあるが、とりわけシステマティックな進行に沿っているわけではない。

そういうわけでこれまで数十名の候補者のレジュメを見て十数人程度の候補者と会ってきたのだが、いずれの場でも未だ手探り感は拭いされていない。というのも、今まで採用活動に関心はあったものの本格的に関わったことはなく、自分なりのベストプラクティスのようなものが無いからだ。

そんな折にたまたま同僚から「ソフトウェア開発者採用ガイド」(Joel Spolsky, 2008年, 初版, 青木靖訳)を渡された。個別のテーゼはどこかで見たことあったりするものの通読したことは無く、まさに今の状況にマッチする内容なので読んでみた。

総評

2時間30分ほどで一読した*2

どうやって候補者の優秀さを見抜き、納得感のある判断を下していくか、そのための"コツ"を掴んでいく道筋は見えたように思う。自分から見れば本書のやり方は幾分システマティックすぎるのだが、体系だった手法で観察・判断するからこそブレずにすんでいるのだとわかる。読了後に正解が見つかったわけではないが、自分と本書の間での中庸を目指してみることで変化をもたらせるという確信はある。

本書のすべてに賛同することはなくても良い。ただ、本書の内容を共通の土俵として持ったうえで議論することには意義がある。採用に携わるチーム全員がその土俵に立つことで一段階 上の採用活動ができるのではないだろうか。

また、この本の前提として 2008年時点で Joel の経営する Fog Creek Software は少数精鋭型で社員100名以下の中小、かつアメリカ(N.Y.)のテック企業ということに留意する必要があるのだが、それが Quipper の現状*3とそう遠くないので楽しめた点も多くあった。おそらく大企業の新卒一括採用ではこの本の内容はほとんど機能しないし、逆に小さすぎれば採用活動にリソースを割くのは難しいからだ。

本書の主張

「採用すべき人物像は以下の3点を満たすかどうか、それだけを見ればよい」という至ってシンプルなもの。

  1. 頭が良い
  2. 物事を成し遂げる
  3. 嫌なやつでない

これらを見極めるためにどういった手法や質問が重要なのか、はたまたプログラマとはどういう人種でどういう環境を好むのか(=どういうオフィス環境を整備すべきなのか)といった各論が観点を変えつつ述べられている。

また、本書では候補者は3タイプに分類される。

  1. 無能な人: 彼らは一年中 職を探しているので求人サイトや紹介会社などを経由して市場によく出てくる。彼らは複数の職にやたらめったら応募する。応募者のほとんどがダメなのはこのため。履歴書が1000枚あれば970枚はこの人たち。

  2. しっかりした能力のある人: 充分な経歴や実力もありチームにも貢献できるが、数倍の生産力を持つスーパースターとは程遠い。安定した仕事を持ち、ほとんどのケースにおいてその状況に満足しているので、人生において市場に出るのは数回。履歴書が1000枚あれば30枚はこの人たち。

  3. すごく優れた人: 凡庸なプログラマの数倍の給料を払っても手に入れるべき人材。彼らは何かしらのプロジェクトに夢中になっていることが常で、転職時も知人経由で移動したりするので、市場に出てこない。履歴書が1000枚あればその中に1人いることもあるかもしれないが、まずいない。

「無能な人」とは随分キツイ言葉だが、 Joel が言うのは「ドットコムブーム時に現れた、HTML が『プログラミング』だと思っている人たち」だ。日頃からコードを書いているプログラマなら誰でも1分で解ける問題*4に時間がかかる、もしくは解くことが出来ない人たち。プログラマがこの種の人々を見破るのは容易いが、ひょっとしたらマネージャは騙されるかもしれない。大事なのはこうした候補者に時間を割きすぎないよう、ちょっとしたコーディングテストや履歴書の見方で工夫すること。1人を不合格にしてもその後ろに969人も控えているのだから。

難しいのは「しっかりした能力のある人」と「すごく優れた人」の峻別だ。実際にはその間にかなりの幅のグレーゾーンがあり、見分けることは困難だと思われている。だが、関わったプロジェクトの説明や経験から「成し遂げる人かどうか」を見極め、大きな設計に関する質問への回答から「技術的な素養があり、頭が良いかどうか」を見極め、それらの会話の合間から「嫌なやつでないか」がわかるし、これらを見極めるための面接は候補者ごとの比較をしやすくするため、システマティックに行われるべきだという。

本書は「すごく優れた人」をいかに採用するかという題にフォーカスしている。ほとんどの企業においては「しっかりした能力のある人」を採用するのが当面の目的であることが多いと思うが、だからといって本書の内容が不要かというとそうではない。本書で述べる手法はグレーゾーンの中で候補者がどこに位置するのかを知る方法論でもあるからだ。"中の下"か"中の上"か判別しやすくなるのは採用活動において間違いなく有益だろう。

対象読者層

これは採用する側向け、特に面接に出席するプログラマもしくはプログラマ出身のマネージャが対象に書かれているようだが、人事・マネージャ・プログラマが読んでもまったく問題ないし、むしろ共通の土壌で話そうとするなら読むべきと思った。

さらに言えば候補者・応募者側にとっても読む価値がある。この本で述べるような採用手法を知っている・実践している会社は少なくともソフトウェア開発者に強い関心があると見定めることができるし、そうした会社に入るために必要なものがわかる。


各論

以下は全7章それぞれで印象に残ったことのメモだ。

第1章 ソフトウェアにおける高音域

  • 高音域を出せる歌手の才能は凡人の鍛錬では届かない。

平均的なプログラマが何人いてもスーパースターのような働きは出来ないことを比喩している。

  • ウォルマートは単価が安いことが価値だ。スーパーマーケットで売られる高級靴下は誰も買わない。
  • じゃあ最安価のプログラマを集めて最安値のソフトウェアを作れば売れるのか?
  • それは違う。ソフトウェアは食品や靴下と違って複製にコストがかからないので作成に関わるコストを薄く広げることができるからだ。1本あたりのコストをほとんど変えることなくクオリティを上げられる、逆に言うと、コストを下げるとクオリティが下がることになる。

「人月の神話」以降 誰もが知っている話のように見えるが、受託ソフトウェア開発業の大部分では未だに理解されていないように見える。

  • インターナルソフトウェアを作るのにロックスターは呼び込めない
  • 銀行のIT部門に本物のエンジニアは来ない
  • 遍く行き渡るソフトウェアほどコストを分散できるので、全国数万の ATM や社員に使われるだけのシステムではスーパースターの働き・コストは見合わない(正当性・妥当性がない)
  • たとえ見合うとしてもそのソフトウェアが彼らの興味を引くものである可能性は限りなく低い。

青い銀行を助けるようなスーパープログラマは今後も現れないという気持ちを新たにした。

第2章 優れた開発者を見つけるには

  • 優れた開発者を見つけるには、こちらから出向く、インターンシップを活用する、優れたコミュニティを作る
  • ブログ戦略の失敗

優れたフォーラム*5に優秀なプログラマが集まるからといって、そのプラットフォームを作るのは至難の業だ。

  • 社員推薦はダメ。非競合契約のリスク、プログラマは本当の友達を紹介しない

非競合契約はアメリカ固有の問題なのだろうか?日本でも起こりうるか軽くググッたがよくわからず。

若い社員の転職の自由を奪う非競争契約 - WSJ

競合他社への転職を禁止される……そんなのアリ?「競業避止義務契約」の有効性 - 業界の仕事について学ぶ - HR TALKS | Fashion HR

本当の友達を紹介すると万一の不採用時に関係にひびが入る、みたいなことが書いてあったがこれに関しては一概にそうとは言えないと思う。

  • 紹介ボーナスは破綻すると歴史が証明している

前者は経験ないので優秀な知り合いを呼びこむのに有向なのかわからないが、インセンティブの線引きが非常に難しいのでうまく機能させることにコストがかかるというのは想像できる。

  • 紹介だろうが同じフローで選考すべき

その通りだと思う。Quipper もそうしている。

第3章 開発者観察ガイド

前職では開発職にも関わらずメモリ4Gで Pentium 搭載の Windows XP を2013年まで使わされていたり、個人のデスクから離れて仕事をすることもできず、ましてや音楽を聴こうものなら説教モノ、当然リモート勤務もありえないという環境だったので、良い仕事ができるよう良い環境を用意することには本当に同意したい。

ただ、コストをかけすぎてもペイしない可能性は高いと思う。個室は…どうなんだろう。コスト面で相当厳しそうだが、それに見合うほど生産性が上がるんだろうか?

また、最近の求人でよく見る「最高の開発環境 / 最高の椅子で仕事しませんか!?」的な"環境推し"はどうかと思う。ぱっと目を引く要素としてアリかもしれないが環境だけで職場を選ぶような人に来て欲しいだろうか?

ちなみに最近入社した同僚が Kensington のトラックボールKinesis のキーボードを併用しているのを見たときに会社費用で購入してもらったと知った。そんな制度があったことを昨日まで知らなかった!

第4章 履歴書の順序付け

  • 履歴書の情報は少ない

本当にそう思う。

採用活動に本格的に関わったことはないと先に述べたが、前職では派遣社員の選定に参加することが時折あった。 派遣会社が用意した経歴書と標準的な履歴書をもとに選定するのだが、ほぼ年齢と経歴書に羅列された技術要素の経験年数で決まってしまっていた。

2007 - 2010年 不動産情報管理システム Java Seasar2 による web アプリの構築に上級 SE として参加 みたいな文面でわかることは何だろう?

  • 以下の加点要素で順序付けして、会うべき人に先に会おう
    • プログラムへの情熱
    • 選んでいること
    • 頭が良いこと
    • 英語ができること
    • 選ばれてること
    • 本格的
    • 多様性

これは日本の定型化されたレジュメでは難しいと思う。そのため、履歴書以外のアウトプット、ブログや GitHub アカウント、カンファレンスの登壇経験などを判断材料にすることはある。

  • 特定のテクノロジーの経験不問

自分たちが使っているテクノロジーの経験があれば非常にスムーズに入ることができるかもしれないが、技術的多様性が増す可能性は低くなる。 非常に専門的なテクノロジーを取り扱うのでない限り、この観点は大事だと思う。

第5章 電話でのふるいわけ

  • 電話面接の勧め。外見に左右されず、発言のみを審議する

これはアメリカの N.Y. に位置し、遠距離から応募がある Fog Creek Software ならではの工夫でもある。Quipper も同様で日本国内遠方からの応募、国を超えての応募はよくあるし、その場合は Skype 等での面接も対応している。また、採用プロセスの後半に CTO / CEO 面接があるのだが、彼らは英国の居住しつつも世界中を飛び回っていることが多いので、これも Skype で行われることが多い。

  • この面接で以下の3点を見抜く
    1. 職歴、自身のことについて表現(成し遂げる人かどうか、情熱はあるか
    2. 技術的な面(大きな範囲の設計
    3. 逆面接(会社に関する質問

これは電話でも電話でなくても同じ内容だった。

第6章 採用面接ゲリラガイド

  • プログラマの面接をプログラマがすり抜けるのは簡単だし、世慣れたマネージャが採用の全権を握っているような会社では優れたプログラマは居ない
  • 必ず6人と合わせる、このうちの5人は同僚となる人

Quipper だと必ずしもこの数を満たさないが、同僚となる同職種の人間が面接に出席するべきなのはその通りだ。

  • 私のチーム以外でなら採用してもいいよ、というのは不採用
  • 短期的な痛みの解決で人を雇うと長期的につらい
  • ボーダーラインはNOと言え
  • 不安や懸念が残る人がまずいプログラマであった場合に解雇するのは難しく、人柄はいいやつだったりするからだ
  • 違法な質問を避ける
  • 結婚しているか子供がいるかも聞く必要なし(単身者を優遇するように誤解されるかもしれない)

このあたりはアンチパターン集だ。 違法な質問に関する取り締まりはアメリカの方が厳しいようだが、日本にも職業安定法に以下の情報を収集してはいけないという規定が存在する。

  1. 人種、民族、社会的身分、門地、本籍、出生地その他社会的差別の原因となるおそれのある事項
  2. 思想及び信条
  3. 労働組合への加入状況

気をつけたい。

  • 結果は候補者に即フィードバック、15分以内にメール
  • 時が経つと記憶は薄れるし迷うぐらいなら採用しない

これはあまり正しいとは思えない。

複数名で参加した面接の後に各自の判断(採用 / 不採用)と所感をディスカッションする時間を設けることでより冷静かつ合理的な判断が可能になると考えるからだ。

また、採用枠・定員が決まっている場合は複数の候補者と面談した後に相対評価で決まることもあるだろう。優れた人に合格通知した翌日にすごく優れた人が現れた場合はどうするか?予算を超えてでも採用する、という選択肢もありうる。だがこれは合否判断よりも上位の問題になるので慎重を期すべきと思う。

第7章 最適でないチームを直す

この章は第1~6章までと違ってマネジメントの話が中心で、毛色が違った。

  • 主要な3つのマネジメント法があるが簡単な2つは機能不全、難しい1つは機能する
  • 指揮統制法
    • 軍隊みたいなやりかたはほんの一部の領域でしかうまくいかない
  • 入門経済学法
    • 外発的動機づけはダメ
    • 効用はドルで測れないということを理解してない
    • メトリクスのための最適化は目的と一致しない
  • 一体化法
    • 組織のゴールを共有することで内発的動機づけが行われる
    • ただしあらゆる社会的コミュニケーション能力を駆使する必要がある

付録 ジョエルテスト

ソフトウェア開発チームのクオリティを判断する12の質問。 これについてはまた別の記事で書いてみたい。


*1:web developer 職への応募であれば現職の web developeriOS developer 職への応募であれば iOS developer

*2:気になった箇所をメモしたり、論理の飛躍や突飛な表現があると前段との繋がりを見失って数ページ戻ったりしてしまうので、自分は本を読むのが遅いほう

*3:2016年7月時点で社員数は百数十名、本社は英国。Wantedly 参照:

*4:解き方が瞬時に浮かぶ、という意味。「配列の全ての値の合計を計算する関数を書け。」みたいな

*5:Joel on Software が引き合いに出されている