Team Geakを読んだ。
Team Geek - Googleのエンジニアたちはいかにしてチームを作るのか
を読んだ。
内容をざっと把握するなら、以下の投稿参照。客観的にうまくまとまっている。
『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』まとめ - Qiita
この本で一貫して主張されているのは、謙虚、尊敬、信頼のHRTを重んじろということだった。というと、かなり当たり前にように聞こえるが（実際当たり前でもあるが）、この本の根底には、昨今の規模の開発では個人プレイをあまり重視を重視すべきでないということがあるように感じる。
冒頭にある天才の神話が興味深く、ドキリとするエンジニアは多いのではないだろうか。
最高のギークファンタジーがあればこんな感じだ。最初に素晴らしいコンセプトを思いつく。そして、バットケイブに数週間～数か月こもり、アイデアを完ぺきな形で実装する。それから、そのソフトウェアを「大放出」する。誰もが君の天才っぷりに衝撃を受ける。同僚たちは君の頭のよさに感服する。誰もが君のソフトウェアを使うようになる。自然と富と名声が集まってくる。
これはエンジニアを目指す人間なら、あてはまる願望ではないかと思う。幼少からコンピュータや勉強が好きな子どもたちというのは、得てして人とのコミュニケーションが苦手であったり、軽視しがちだったりするものだ。また、自尊心が高い傾向があるかもしれない。そういった人たちにとっては、個人プレイによって得ることのできる富や名声は非常に抑えがたい衝動だ。
自分の好きなようにやればいいじゃん。そう思っているかもしれない。
それが違うんだ。ここでは君が間違っている。その間違いこそが大きな問題だ。
オープンコミュニティであれ、企業内の仕事であれ、ソフトウェアエンジニアリングにコミュニケーションやコラボレーションが必須であるのはもはや歴然たる事実である。世にでている「プロジェクトマネジメント」や「ソフトウェアエンジニアリング」と名のつく教科書は、だいたい人同士のコミュニケーションをどう定量的に扱うかについての議論に多くの紙面を割いている。ソフトウェア開発における最大の課題はコミュニケーションそのものなのだ。
多くの天才をかかえるGoogleがそのような考えを持っていることに多少の驚きを感じつつ、また共感を覚えた本だった。
- -
ところで、最近こういったチーム運用の本を読むと、採用の話が頻繁に出てくる。いかに能力が高い人材を確保するかに多くの紙面を割いているし、この本でも同じ文化をもつ人材をどう採用するかの記述があった。新卒一括採用をしている企業ではあまり馴染みはなく、採用した集団の中央値がより大きくなるよう、また、最小値がある一定以下にならないように採用しているように思う。これは、採用後に配属をきめるという風習に起因していると考えられる。どこへ配属しても文句の出ない人材を採用する必要があるためだ。極端にコミュニケーション能力を欠いていてもだめだし、極端に礼儀がなっていなくても不採用だ。すべてが平均か、それ以上であればいい。逆に、例えば数理モデルに相当精通していて、たとえ担当部署がそれを必要としていても、あまり魅力的ではない。
Googleの採用方法は当初は奇抜さにフォーカスがあたっており、当時としてはその過剰ともいえる福利厚生や労働環境の厚遇が注目されていた。しかし、最近日
本であっても、スタートアップ等では、エンジニアは財産と考え、出来る限り厚遇するという企業はもはや珍しくなくなっている。
一方日本古来の企業や多重請負い構造をとる企業は、内部のエンジニアは人月をとるための人材でしかない。現場で日々強く感じることだが、彼らはプログラマというより、もはやコーダに近いのではないかとおもう。
彼らの技術力の高さというのは生産性が高いということなのであるが、これは、単に行数が多くかけるということであったりする。一見すると悪くないし、取引先や上司にも定量的に説明しやすい。だが、本当に優秀なコードというものは行数は少ないものになるはずだし、もはや行数ではなにも語れないであろう。一時間に多くの行数
がかけるからといって、必ずしも生産性が高いとはいいがたいし、ましてや技術力の高さを測るバロメータとしては明らかに不適切であろう。
採用の話では、採用後の教育のコストなどを考えた場合に、優秀な人材を逃すより、下手な人材を誤って入社させたほうがコストが大きく、リスクになるということが議論される。似たような話はJoel on Software日本語版記事でもあった。一旦採用した人材を教育し解雇するとなると非常にコストが高くつくためだ。日本の社会構造だと、更に解雇しづらい環境になるわけで、すると、より現場にあった人材を厳しく試験したうえで入社させるべきなんでないかと思った。
