30歳からのプログラミング

30歳無職から独学でプログラミングを開始した人間の記録。

『優れた技術者の集まる会社にする方法 ソフトウェア開発者採用ガイド』を読んだ

前回読んだ『Joel on Software』の Joel Spolsky が、ソフトウェア開発者の採用について論じた一冊。
自身が優秀な開発者であり経営者でもある Joel が、多くのソフトウェア開発者が採用に対して何となく感じていることを平易な文章で明快に説明していく。

詳しく調べてはいないが、本書の内容も基本的に Joel on Software で公開されている記事をまとめたものだと思う。
例えば「第 2 章 優れた開発者を見つけるには」は、以下の記事を翻訳したものになっている。

エッセイ集なので採用業務について体系立てて論じているわけではないが、それゆえに非常に読みやすい。しかし内容は薄くない。
「分かってはいるが実践は困難」「この基準を満たす開発者がどれだけいるんだ」と思いたくなる内容もあるが、主張している内容はいずれも真っ当なものばかり。
Joel 自身が本書の内容を実践しており、その結果 Stack Overflow や Trello など日本でも知られているサービスが複数生まれているため、とにかく説得力がある。
ソフトウェア開発者が読んでも面白いが、開発者にとっては常識であったり感覚的に理解しているような事柄について丁寧に論じているので、非開発者が読むとより大きな示唆を得られるかもしれない。

本書の内容を自分なりに要約すると、以下のようになる。

ソフトウェアの機能や品質がそのまま競争力になるような事業の場合、優れたソフトウェア開発者を採用できるかが事業の成否を左右する。
優れた開発者でなければ作れないものがある。凡庸な人間をいくら集めても優れた人材の代替にはならないし、そういう人たちに膨大な時間を与えたところで結果は同じ。
そのため、候補者が本当に優れた開発者なのかを注意深く慎重に見極めなければならない。
そして優れた開発者は引く手数多なので、基本的に採用市場には出てこないし、出会えたとしても自社に来てくれるかは分からない。彼らはいくつも選択肢を持っているのだから。
さらに、幸運にも優れた開発者が入社してくれたところで、彼らをうんざりさせるような政治や彼らを軽んじるようなマネージメントを繰り返していれば、彼らの能力を活かすことはできないし、いずれは去っていくだろう。
このように、優れた開発者を雇って事業を成功させるためには、いくつものハードルを越えなければならない。

候補者と企業、どちらも同じ課題を抱えており、それぞれに「強者」と「弱者」が生まれているんだろうなと、本書を読んで感じた。
お互いに「誰でもいい」わけではなく、だからこそ、たくさんの選択肢を持つ「強者」と、苦しくなる一方の「弱者」が生まれてしまう。
市況の変化によってトレンドは変わるが、基本的な構造は変わらない。

例えば本書には「一括送信の履歴書は死にものぐるいの徴候に思える」という表現が出てくる。
志望動機が薄くて汎用的な内容の履歴書を提出されると、本当にこの仕事をしたいと思っているのか疑わしくなってしまう、という話なのだが、これは企業側にも言える。
パーソナライズされておらず誰にでも言えるような内容のスカウトメールを一括送信しているようでは、候補者からよい印象を持たれる可能性は低い。「死にものぐるい」と映るだろう。
そして「死にものぐるい」が採用市場で高く評価されることはない。魅力があり「強者」である企業や候補者は多くの選択肢を持っており、そんなことしないからだ。

どうやって自分を知ってもらうか、自分を見てもらうか、にも同じことが言える。
採用広報の重要性と難しさが本書で出てくる。どんなに魅力を持った企業であっても、それを上手く発信していかないと目に留めてもらえないのが現実で、まず知ってもらうということのハードルが高い。
そして候補者も同じ状況にある。たくさんの応募の中から、どうやって自分を見つけてもらうのか、どうやって面接を受けるチャンスを掴むのか。

面接には多くのリソースを必要とするので、希望する人全てと面接するのは企業にとって現実的ではない。
他の業務との兼ね合いもあるので、自然と効率性を求めることになる。そのため、フィルタリングが行わる。
本書では履歴書と電話面接によるフィルタリングを紹介しているが、履歴書によるフィルタリングでは、「(人によっては)何年も前の過去の話」がそれなりに大きなウェイトを占めている。
詳しくは実際に読んでもらいたいが、選考プロセスが厳しい大学や企業に入ったことがあるか、大学の成績はよいか、大学対抗プログラミングコンテンストに出場したことはあるか、など。これらによって、どの候補者と優先的に面接するかを決めている。

高校を中退しており無名文系私大卒の私にとっては、かなり厳しい内容だ。経歴だけでなくアクティビティについても同様で、若い頃を引きこもりとして無為に過ごしたため、セキュリティ・キャンプに参加したこともなければ、未踏ジュニアに応募したこともない。
そして残念ながら、過去の経歴で判断するのはそれなりに妥当だろうなとは思う。情報工学を修めているかでソフトウェア開発者の履歴書を選別するのは、別に間違ってはいないと思う。

とはいえ、それらがフィルタリング条件として最適というわけではなく、企業と候補者の双方に機会損失が生まれているのも事実だと思う。
履歴書から読み取れる情報は少なく、書類上の評価が高くても能力が低い候補者はいるし、その逆のケースもあると、本書にも書かれている。
企業にとっても候補者にとっても、出会いたい相手に出会うのは難しいのが現状と言える。今はまだ何のアイディアもないが、もっと上手い仕組みを作れるとよいなとは思っている。

『Joel on Software』を読んだ

Microsoft での勤務経験を持ち Stack Overflow の創業者でもある Joel Spolsky によるエッセイ集。

Joel は自身が運営するウェブサイト Joel on Software で多数の記事を公開しており、その一部を掲載したのが本書。

ひとつひとつの章がかなり短い(長いものでも 20 ページくらい、短いものだと 4 ページほど)ので気軽に読めるし、各章は独立しているので興味のある部分だけ読むこともできる。

技術そのものについて解説している技術書ではなく、ソフトウェア開発やソフトウェア産業についての著者の考えが書かれており、 Paul Graham の『ハッカーと画家』にテイストが近いかもしれない。
無料で公開されているエッセイ集をまとめたもの、というのも『ハッカーと画家』に似ている。

本書に収録されているのは 2000 年から 2004 年に書かれた記事なので、さすがに古さを感じるものもある。
未来予測のような内容も含まれるので、現在の視点から「答え合わせ」してみるのも面白いかもしれない。

以下、特に面白かった章の要約。

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

    • 候補者は、明らかに水準に到達していない人、何とも言えない人、スーパースターの 3 種類いる
      • 何とも言えない人とスーパースターを区別して前者を採用しないことが重要
    • 特定のタスクを非常によくこなせるとしても、他のチームではあまり上手くいかないような候補者も不採用
      • 変化の速い世界なので、どのようなタスクでもこなせる人間が必要
    • 分からない、境界線上だ、というケースは全て不採用
      • どっちつかずの候補者はすべて機械的に不採用にする
    • なぜなら、まずい候補者を採用するよりは、いい候補者を落とすほうがずっとマシだから
    • 優れた候補者を見つけるのがいかに難しく感じられても、基準を下げてはいけない
    • 採用するべきなのは、頭がよくて物事を成し遂げる人
    • 頭のよさを見分けるために、候補者の頭のよさを示せるような状況を作ることが重要
      • 自分の話ばかりして候補者に話す時間を与えない面接官はダメ
      • 頭のよさを「たくさんの事実を知っていること」だと思ってクイズショーを展開する面接官もダメ
    • ソフトウェアチームが採用するべきなのは、特定のスキルセットを持っている人ではなく、資質を持っている人
      • スキルセットはすぐ陳腐化するのだから、どんな新技術でも学べる人を雇ったほうがいい
    • その人を知るための一番の方法は、その人に話をさせること
      • そのために自由回答式の質問と問題を与える
    • 面接する候補者の情報はできるだけ入れないようにする
      • どうしてもバイアスが掛かってしまうから
  • 第 24 章 あなたが絶対すべきでないこと PART I

    • プログラムをスクラッチで書き直すのは、最悪の戦略的誤り
    • プログラマが既存のコードを捨てたいと思いがちなのは、プログラムは書くより読むほうが難しいため
    • しかし、古いコードは様々な面で新しいコードよりも利点がある
      • 古いコードは既に動いている
      • 古いコードは歴史のなかでテストされている
        • 多くのバグが見つかり、それが修正されている
        • 実世界のなかで何週間も使われたからこそバグが見つかった
    • コードを捨てることは積み重ねられたバグフィックスを捨てることを意味する
  • 第 26 章 漏れのある抽象化の法則

    • 抽象化とは、複雑なことが行われている中身を隠して単純化すること
    • 抽象化によって、中身の詳細を知らなくても利用できるようになる
    • 例えば TCP は IP の上に構築されているが、抽象化によって IP のことを意識することなく TCP を利用できる
    • しかし TCP より下層の部分で何か問題が発生すると、 TCP は機能しなくなる
      • 何からの理由で IP パケットが全く届かなくなったり、ネットワークケーブルが切断されてしまったり
    • このような状態を Joel は「漏れのある抽象化」と呼んでいる
    • 自明ではない抽象化はすべて、多かれ少なかれ漏れがある
    • 普段は上手くいっていても、時折漏れ出してきて、問題が発生する
      • メモリの仕組みを知らなくても問題なくコードを書けるかもしれないが、知っていないことで、ものすごくパフォーマンスに問題のあるコードを書いてしまうかもしれない
        • コンピュータの仕組みを完全に抽象化することはできず、このように漏れ出してくることがある
      • SQL のクエリでも似たようなことが起こり得る
    • 抽象化によって隠されている「下層」について知らないと、抽象化に失敗して下層が漏れ出してきたときに対応できない
  • 第 33 章 ビッグマック 対 裸のシェフ

    • 物事を上手くやるためには才能が必要
    • だが才能をスケールさせるのは困難
    • そこで、才能ある者がルールを作り、凡庸な人間がそれに従うというやり方で、スケールさせようとする
    • しかしその結果として得られる成果物の品質は低い
      • 一定であり安定しているかもしれないが、低い
    • ルールや手順は、平時においては上手く機能するかもしれない
      • だが状況の変化に対応できない
      • ルールを作った才能ある人達なら、対応できるだろう。だがルールに従うしかできない人間では、対応できない。対応できるだけの能力がないからこそ、ルールを必要としそれに従っているわけだから。
    • これが、企業の勃興と衰退が繰り返される理由
      • 硬直化し時代に対応できない大企業を、若い才能が追い抜く。しかし才能はスケールしない。そこで才能ある者がルールを作り、凡庸な人間にそれに従わせる。最初は上手くいくが、状況変化に対応できず勢いを失っていく。
    • この過ちを犯さないためには、優秀な人間を雇うことに執着しなければならない