【書籍】ソフトウェア 開発者 採用ガイド - まとめも
メルカリでEngineerの採用や育成をしている@_tweeeety_です
この記事は、
「ソフトウェア 開発者 採用ガイド(Joel on Hiring)」
という書籍の自分まとめです。
先日、以下のようなnoteも書いたのでよかったらご参考まで。
1. 書籍の概要
Joel SpolskyというMicrosoftで働かれていたソフトウェアエンジニアの方が書かれたエンジニア採用に関する著書です。
ジョエル・スポルスキ（Joel Spolsky、1965年 - ）は、アメリカ合衆国のソフトウェアエンジニアで著作家である。ソフトウェア開発について論じたブログであるJoel on Softwareの著者として知られている。1991年から1994年にかけて、Microsoft Excelチームのプログラムマネージャとして活躍し、その後Fog Creek Softwareを創業した。
ref: wiki
エンジニアの採用についておおまかに
・ 優れた開発者を見つける
・ 開発者の見分け方
・ 履歴書について
・ phone screeningについて
・ 面接について
と記載されています。
驚いたのは、記載されたのが2008年なのですが、
2019年に読んで「日本の採用はこれに近づいている気がする」と思った事です。
アメリカでは今日の採用が当たり前のように行われていたことが伺えます。
2. 書籍の目次
amazonからの引用です。
・ 第1章 ソフトウェアにおける高音域
・ 第2章 優れた開発者を見つけるには
・ 第3章 開発者観察ガイド
・ 第4章 履歴書の順序付け
・ 第5章 電話でのふるい分け
・ 第6章 採用面接ゲリラガイド
・ 第7章 最適でないチームを直す
・ 付録 ジョエルテスト
3. 単語で表すこの書籍
あくまでも所感ですが、この本を読んだ感想を3つの単語で表します。
・ すぐれた開発者
・ 見決めわめ方
・ エッセンス
4. 書籍まとめ
4.1 ソフトウェアにおける高音域
Fog Creekでは、
「自分たちが働きたいソフトウェア会社を作る」
ということを目的にしている。
これを成し遂げるプランは次の4つに集約される
最高の仕事環境
↓
最高のプログラマ
↓
最高のソフトウェア
↓
収益!
プログラマのコストをケチるなら、お粗末なソフトウェアを作ることになり、それでいてたいした節約にはならない
1人の際立ったプログラマを5人の凡庸なプログラマで置き換える意味はない。
「遅れたプロジェクトに人を投入するとさらに遅れる」というブルックスの法則のためだ。
チームを可能な限り小さくすることには付加的な利点がある。
また、少数の優れたプログラマの代わりにたくさんの凡庸なプログラマを用意しても優れたプログラマの作り出すものが彼らには決して作れない。
「平均的な」開発者がすごいソフトウェアを作り出す高音域に達することは決してないのだ。
だからソフトウェア開発者であれば最も満足できるキャリアは本物のソフトウェア会社である。
4.2 すぐれたソフトウェア開発者を見つけるには
優れたソフトウェア開発者は、マーケットに出てこない
ソフトウェア開発者を分類すると
無能な人々 >>> しっかりした能力の人 >> 優れた人
となる。
「優れた人々はマーケットには現れない」:
・ 優れたソフトウェア開発者は、その全職歴を通して、平均4回くらいしか職に応募しない
・ 基本的に働きたいところで働くので、彼らが履歴書を送ったり、たくさんの職に応募することはない
・ 無能な人々は、同じように少なかったとしても、何千という職に応募する
・ しっかりした能力の人は、優れた人よりは多いが、無能な人よりは少ない
・ 結果的に、1000通の履歴書のうち30通ほどが検討に値する
そもそも彼らを手に入れることはできるのだろうか
採用を、
「履歴書を集め、より分ける」
という手順で考えるのではなく、
「勝者を突き止め、接してくるようにし向ける」
という手順で考える必要がある
基本的な方法:
1. こちらから出向く
2. インターンシップ
3. 自分のコミュニティを作る
1. こちらから出向く
・ 雇いたいと思う人がいる場所を考える
・ 足を運ぶ
・ 良い人をみつけたら全力の口説きモード
をおこなう
ただし、大きく汎用的な求人サイトでの広告は避ける。
最初のふるい分けを通るものすらいない
2. インターンシップ
求人マーケットに現れない優れた人をつかみ取る良い方法は、
彼らが求人マーケットなどというものがあることに気づく前に手に入れてしまうこと。
つまり大学にいるときに。
本当に優れたプログラマはしばしばプログラミングを10際のときにはじめる。
法律や医学と違い、大学2,3年で非常に優れたプログラマになっている。
良い大学に行っている若者は、大学にやってくる会社からだけでも良い職の選択肢は十分にあり、大学に来ない会社にわざわざ応募しない。
どのようにやっているか:
・ このプロセスを9月にはじめる
・ 200ほどのコンピュータサイエンス学科に手紙を出す
・ 見つけたコンピュータサイエンス専攻の学生一人ひとりに個人的な手紙を出す
・ インターンシップを知らせ、応募することを個人的に勧める
・ たくさん応募がきたらインターン採用枠1人につき、10人くらいに絞り込み電話面接する
・ 面接を通った2,3人をニューヨークに呼んで直接面接する
・ 実地の時点で採用したい率は非常に高いのでアトラクトモード
・ 送迎リムジン、クールなホテル、会社のお土産や直前インターンのドキュメンタリーを用意する
・ 面接後は、ニューヨークを知ってもらうための滞在も用意する
・ 通るのが1人だったとしてもその通った人が良い印象を持つことが本当に重要
・ 通らなかった人も、いかした会社だと思いながら大学に戻り、どんなに良かったかを友達に話し、聞いた人がまた受けたくなる
・ この時点で正社員として雇いたいかを判断している。だから本物の仕事を与える。
・ インターン中は、特別課外活動や見学旅行も毎週行っている
なんにせよ、本当に雇いたいと思う人について、待つことに意味はない。
卒業後のフルタイムの仕事を早い段階で提示する。
すごく良い条件で。
彼らが大学に戻って友達と情報交換するときに、誰よりも初任給が高い事を知るようにしたいのだ。
これは、面接しか行っていない会社より、より多くの情報を持っている、
良い情報を持っているからこそ、多くの額を喜んで支払える。
アメリカにおいて、この業界のインターンシップには給料が支払われる。
その給料はかなり良い。
週750ドルの給料、住居、昼食、地下鉄のフリーパスを支給している。
フルタイムの社員を1人得るためには、2人のインターンを雇う必要があると計算している。
さらに、高校生をどうにか雇えないかとさえ考えている。
次世代の優れたプログラマとコネクションを築くために。
それがたとえ6年のパイプラインになろうとも。
3. 自分のコミュニティを作る
すぐれた開発者たちの大きなコミュニティを、あなたの会社の周りにどうにかして作り上げること。
ただし、これはかなり難しい
社員による推薦について
優れたソフトウェア開発者をみつけるためのよくあるアドバイスは
会社にいる開発者に聞け
というもの。
しかし、地雷も埋まっていて、新規採用のソースとしては最も弱いと考えている。
ひとつの大きなリスクとして、非競合契約がある。
・ 強制力があると思わなかった
・ 契約書を読む習慣がなかった
・ すでに提示を受け入れ、仕事の初日に初めて契約書を見た
などで気づかなかったとしても強制力があり、しばしば行使されている。
もうひとつのリスクとしては、
採用プロセスで何らかの選考を行っているなら、本当の友達を紹介しない可能性があることだ。
それで不採用になったら友人関係にヒビが入るから。
4.3. 開発者観察ガイド
彼らが職場で好むこと、嫌うことが何なのか、最高の開発者に選ばれるためには何が必要なのか。
個室
・ 個室のほうがステータスが高い
・ キュービクルやその他の共有スペースは落ち着かない
ワークスペースの物質的側面
・ ディスプレイ
・ アーロンチェア
開発者のおもちゃ
・ 最高のコンピュータ
・ 2台の大きなディスプレイ
・ 必要な書籍が自由に買える制度
開発者の社会生活
・ 組織の中でプログラマはどのように扱われているのか？
・ 同僚はどんな人たちか？
・ 独立性と自律性
・ 政治がないこと
何の仕事をしているのか？
・ 開発者を引きつける一番良い方法
- 彼らに興味深いことをさせること
- イルマおばさんに会ったときに説明できるくらいシンプル、ないしは有名なこと
- 多くの開発者は、自分の働く会社の社会的な価値を気にかける
・ 成績上位の新人社員にプロジェクトを選ばせる
・ 必要もなくクールな新技術を使う
- ビジネスの中心的なアプリでなくても良い
- 内部的に使われるツールなど
- 新しいアプリでエキサイティングな新しい言語で書かせる
会社と一体化できるか？
・ 自分の仕事に意味を見出したい
・ 若いプログラマはイデオロギーのある会社に惹かれる
・ 自分の会社の理想主義的な側面を見出し、候補者が間違いなくそれに目を止めるようにする
・ あなたの会社が何を表明しており、どう受け取られているかを考える必要がある
4.4 履歴書の順序付け
履歴書から候補者について多くのことを読み取るのは難しい
そこで3点をポリシーにしている
・ 求人広告を選別的に行い、履歴書の山のノイズを減らす
・ 履歴書はふるい分けして面接しなければならない人の数を減らすだけ
・ 面接する順番を決める。客観的なシステムで点数をつけ構成で一貫的になるようにする
履歴書の順位付けの基準
・ 情熱を持っていること
- 余暇の時間に課外活動やOSSの貢献を行っている
- プログラミングが好きであり、新しいテクノロジーの探求にエネルギーを使っている
・ 選んでいること
- FogCreekが自分の働きたい場所だという一貫した説明を聞きたい
- 添え状を書くのに時間を使っているという事実は、自信をもっており何千通の会社に応募している事がない
- こういう候補者は採用を伝えたときに、おそらく受け入れる可能性が高い
・ 英語ができること
- 自分のアイデアについて明確にコミュニケートできる
- コンパイラとしかうまくコミュニケートできないプログラマっより実効性が高い
- ドキュメンテーション、レビュー、会議などで必要
- 履歴書が整然としているかも重要
- 整然としていないのは、秩序立てて整理できていない、一般にだらしない
・ 頭がよいこと
- 高いGPA、高い標準テストスコア、TopCoderなど
・ 選ばれていること
- 過去に非常に選別的なプロセスを通り抜けた証拠
- 応募者の30%未満しか受け入れてない大学、難関採用プロセスの会社で働いてたなど
・ 本格的であること
- 履歴書はプログラマを判定する方法としてはとても貧弱
- 難しいテクノロジーは上のほうへ上がる傾向にある
・ 多様性をもたらすこと
- 十分に違ったバックグラウンドを持つ人々を特に求めている
- 例えば、エンタープライズでの経験はインターネットチームに有用な多様性をもたらす
- バックグラウンドの多様性は、チームが異なった解放を見出だせる可能性が高くなる
これらは採用の基準ではない。
大きな履歴書の山を並べ直すための客観的で公正な方法というだけのことである。
このテストで点数が低いが優秀な人や、点数が高いがへぼなプログラマーもいる。
履歴書が貧弱なら、もっと関門を追加する事はできないか？
リクルーターが感じる誘惑のひとつに、
応募プロセスに余分な関門を追加する
というものがある。
応募数を減らす点では機能するが、応募の質を改善するという点ではうまくいかない。
良いプログラマも追い払ってしまうことになる。
特定のテクノロジーの経験を求めないこと
最高のプログラマーにとって、リクルーターに対して頭にくるところは、
彼らがキーワードやバズワードに病的に執着していること
SmalltalkとPythonの深い経験をもつがRubyを聞いたこともない人は、
Rubyの本を一度読んだ事がある人よりも成功する見込みがずっと高い。
4.5. 電話でのふるい分け
電話でのふるい分けには、通常の実地の面接と違った利点がある。
・ 安上がりなこと
・ 1時間未満で履歴書の上では実に素晴らしいと思う人の半分を削る事ができる
・ それがよりフェアに行える
電話での面接は3つのパートからなっている
1. 候補者に職歴、自身について説明してもらう
2. 技術的な質問をする
3. 私のことを質問させる
1. 候補者に職歴、自身について説明してもらう
そうする意図は、彼らをくつろがせ、気分を楽にして緊張を取り除き、彼らに自分を表現したいような仕方で表現させることだ。
この段階では、候補者が問題解決者、物事を成し遂げるタイプの人であることを示すものを探す。
また、情熱も探す。
このパートでは、2つの方面に掘り下げる
テクノロジー:
これこれのプロジェクトをやったという場合、以下の点について詳しく質問する
・ 彼らが使ったテクノロジー
・ それをどう使ったのか
・ 彼らが具体的に果たした役割
自分でなにをやっているかわかってない人、話を作っている人、役割を誇張している人を見破れる。
政治:
履歴書にある過去に勤めた会社には常に物語がある。それを詳しく掘り下げる。
・ 過去に困難な問題にどう対処してきたかという物語
・ 抵抗に直面しても物事を成し遂げてきたような人
・ 体制に挑戦し、反対を乗り越え、何かを実現したような人
2. 技術的な質問をする
理想的な質問は、
・ 候補者が使った経験があってどういうものなのかは知っているが
・ 自分で実装したことはありそうにないようなもの
目的としているのは、必ずしも最良の答えを見つけ出す事ではない。
3. 私のことを質問させる
この時点では、すでにその人が実地に勧めるかを判断している
だから、このパートでは自分のほうが面接をされ、
候補者はFogCrreekを売り込まれるという形を取る。
面接プロセスは、候補者が私達のところで働きたいと思うかを判断する場でもある。
ただし、質問によっては、
webサイトを5分も調べればわかるような下調べさえ面接前にしていないと、
頭の良さや物事を成し遂げる能力に対する信用を失う。
4.6. 採用面接ゲリラガイド
ソフトウェアプロジェクトにとって一番重要なのは人なんだと
リップサービスはするけれど、それについて何ができるかとなると誰にもよくわからない。
良いプログラマを手に入れたければ、最初に正しくやらなければならないのは適格なプログラマを雇うという事だ。
人を雇うとき、上級スタッフが候補者を落とすのは認めてもいいと思うが、
下級スタッフの1人が気に入らなかったというだけで誰かを落とそうとは思わない。
面接では、3種類の人たちを見分けることになる。
・ 極端な無知な人
・ なにかに貢献できそうに見える人
・ スーパースターな人
「なにかに貢献できそうに見える人」は、迷ったら不採用だ。
短期的な痛みの解決と引き換えに、ずっと長く続く痛みを抱え込むことになる。
「いいかもしれないけど、わからない」とは決して言わないこと。
もしわからないならそれは不採用を意味する。
どっちつかずのものはすべて機械的に「ノー」に置き換えても差し支えない。
それは
良い候補者を落とすほうが、まずい候補者を採用するよりもずっとまし
だからだ。
まずい候補者は：
・ たくさんのお金と労力がかかる
- 彼らのバグを直すために他の人の時間が奪われる
・ 解雇するには何ヶ月もかかり悪魔のように難しい可能性がある
・ まずい社員は良い社員のやる気をくじく
・ プログラマとしてまずくとも人間として本当にいいやつの場合がある
- あなたは彼らを解雇するのは忍びない、または、みながうんざりする可能性がある
ひとたび誰かを面接するとなったら、
ドアの外には900人の候補者が列をなしているというフリをする。
基準を下げてはいけない。
誰を採用すべきかをどうやって判断するか
判断は2点しかない
1. 頭がよく
2. 物事を成し遂げる
頭がよく、成し遂げない人は以下のような人がいる
・ 博士号をもっていて大企業で働いている
・ スケジュールどおりに出荷するよりアカデミックなことに重きをおく
・ 頭は良いが役に立たない
頭は悪いが物事を成し遂げる人は以下のような人がいる
・ 考えなしに馬鹿なことをやり誰か他の人がその後始末をする羽目になる
・ 優れた人の時間を奪う
面接で頭の良さをは以下のポイントで見出す
・ 何度も繰り返し説明せずに済む
・ 候補者がいかに頭が良いかを示せる状況を作る
悪い面接者
・ 自慢屋
- 候補者に「ええ、そうですね」と言うくらいの時間しかなくなる
・ クイズショー
- 頭が良い=「たくさんの事実を知っている」だと思いこんでいる
- 雑学問題をひたすら出し続ける
- 15秒もあればネットで調べられるものは意味がない
特定のスキルセットではなく、資質を持った人を雇いたいものなのだ。
仕事に持ち込むどんなスキルセットも2年もすれば技術的に古くなってしまうだろう。
一般に、ある人について最も多くのことを知ることができる方法は、
その人に話をさせることだ。
自由回答形式の質問と問題を与える。
面接前に用意するプラン
面接の前に面接で使うプランを用意すると良い
1. イントロダクション
2. 候補者の最近のプロジェクト
3. 簡単なプログラミングの質問
4. ポインタ/再帰の質問
5. 答えに満足しているか？
6. 質問は？
1. イントロダクション
これは候補者をリラックスさせるためのものだ。
・ フライトはどうだったか
・ 自分は誰で面接がどう進むか
2. 候補者の最近のプロジェクト
最近のプロジェクトについての質問をする
自由回答形式の質問をし、耳を傾け、相手が詰まっているときは
「それについてもう少し聞かせて」と言う
自由回答形式で探すもの
・ 情熱
- プロジェクトに対して情熱的
- 情熱的に否定的であるというのも良い兆候
- それについて話しているときに面接中という事を忘れることもあるくらい
・ 物事をよく説明しようと気を使う
- 普通の人が理解できるように説明できない候補者は落とす
- 「ちょっと練習だと思って祖母にわかるように説明してもらえないかな？」と聞く
・ リーダシップの兆候
- チームで行った成果なら「あなたは何をしたの？」と聞く
- 物事を成し遂げるか知る唯一の方法は、過去に物事を成し遂げたか見ること
3. 簡単なプログラミングの質問
仕事をしているプログラマであれば1分くらいで解けるはずの問題を出す。
みんな問題を解くことは解くが、特のにかかる時間に大きな差がある。
基本的なコンセプトが考えるまでもないというくらい簡単に思えるのでなければ、
大きなコンセプトを把握することが難しい。
4. ポインタ/再帰の質問
面接の形式が、
表面的には候補者がただホワイトボードにコードを書くだけというものであっても、
ここでの本当の目的は、そのコードについて会話をすること
・ なんでそんなふうにしたの？
・ そのアルゴリズムの特性はどういうもの？
・ 何か忘れてない？
・ バグがどこにあるかわかる？
これは、難しすぎる問題でも構わない。
候補者が手をつけられるチャンスがありさえすれば良い。
進めながら小さなヒントや足がかりは喜んで出す。
ただし、ヒントはgoogleで見つけられるような雑学問題の答えだ。
5. 答えに満足しているか？
ほんとんどの場合、一発で書いたコードにはバグがある。
プログラマは誰でもミスをする。
そのこと自体に悪いことはなにもない。
ただ、それを見つけられる必要がある。
そのため、追加で以下のようなことを質問してみる
・ 「そのコードで満足している？」
・ 「OK、じゃあバグはどこにあるかな？」
極稀に、最初からバグがまったくないコードを書く候補者もいるが、
「このコードにはバグがあるよ」と言ってみる。
コードを注意深く見直し、コードの正しさを厳格に示し、
礼儀正しいながらも毅然とおしてコードは完璧だと断言するかを見ることもできる。
6. 質問は？
この時点では、どんな質問をされようが気にかけない。
すでに心を決めている場合が多い。
候補者に対して、会社と仕事を売り込むのに使っている。
良い候補者でもまずい候補者であっても、会社のことを好きになり、良い印象を持って帰って欲しいと思う。
面接のあと
候補者について決断を下すのに最適な時間は、面接が終わった3分後。
時が経つほど記憶は薄れていく。
面接者には、面接のあと即座にフィードバックを返すよう求めている。
また、これの納期は15分後としている。
決断するのに困難を感じるなら簡単な方法は不採用にすればいい。
確信が持てない人は単に雇わないこと。
どうすれば最高の人を雇えるのか
諦めないこと。
優れた人は平均的な人よりはるかに価値がある。
プログラミングにおいては3-10倍の生産性が、たった20-30%の余分なコストで手に入れられる。
4.7. 最適でないチームを直す
あなたは、チームメンバーが次の3つのどれかを把握する必要がある
1. 優れた開発者
2. 改善すべき点のある開発者
3. 望みのない開発者
新しいマネージャになった人がこれをやるための一番手っ取り早い方法は、同僚の評価を聞くことだ。
匿名を約束した上で、この3つのどれに当てはまるかをそれぞれ聞く。
働きの悪い者の解雇は必ずしもモラルを損なわない
マネージャが働きの悪い者を取り除くことを恐れるのは、それによってチームのモラルが下がるのを懸念するためだ。
チームリーダの究極的なゴールはチームのパフォーマンスを引き上げることだ。
パフォーマンスの改善
マネージャは、具体的で、現実的で、達成可能なゴールを設定し、彼らがどこへ向かうべきかを理解するのを助ける必要がある。
これはマネジメントのコーチングの側面だ。
マネジメント法
何かを率いようとするときに直面する主たる問題は、
みんなを同じ方向に進ませなくちゃいけないということだ。
これは実際には「他の人を思ったとおりに動かす」ということを体裁良く言っているにすぎない。
この場合のアプローチ方法が3つある。
・ 指揮統制法
・ 入門経済学法
・ 一体化法
マネジメントの本当の秘訣は、達成しようとしているゴールにみんなを一体化させることで、一体化法が向いている。
そのためにとても満足している方法は食事を一緒にすることだ。
家族のように感じられる結束したチームを作ることが必要とされる。
それによって同僚に対する誠実さと責任をみんなが持つようになる。
おわりに
リファラルというと、なんとなく「声をかける採用でしょ。知ってる」となりがちです。
しかし、実際のところ、かなりの労力が必要だという事が本書を読むとわかります。
最後に、本書で印象に残った言葉を綴っておわりにします
「これからの採用はお金をかけずに、汗をかく」
Enjoy Hiring!!
補足
このまとめについての補足です。
・ 202001時点のまとめです
・ あくまでも僕自信が参考になったポイントです
・ 汎用的なポイントとはズレる可能性があります
いいなと思ったら応援しよう！
