Team Geek Googleのギークたちはいかにしてチームを作るのか

Subversion開発など、多くのソフトウェア開発に関わり、Googleでプログラマを経てリーダーを務めるようになった2人の著者

Brian W. Fitzpatrick
Ben Collins-Sussman

FitzとBen により書かれた本だ。

技術よりも人間としての関わり方
リーダーの役割
チームとして働くとは
といった事に重きをおいて説明されている。

自分の中で共感できた、なるほどなと思ったところをいくつか抜粋。

HRTの精神

• 謙虚 Humility
  自分は全知全能ではない、絶対に正しいわけではない。常に自分を改善しよう。
• 尊敬 Respect
  相手を思いやり、その能力や功績を高く評価しよう。
• 信頼 Trust
  周りの人は優秀であり、正しい事をしてくれると信じて任せてみよう。

この３つを持ってチームとして働こうという大前提。

ミッションステートメント

ミッションステートメントを設けることで、
チームの意思決定の基準が定まる。
必要な作業、不要な作業。
ステートメントに沿って同じ判断に到達する事が出来るので、無駄な衝突を避ける事ができる。

やることとやらない事を明確にできる為、無駄な作業も生まれない。

今までこんなものを設定してきたプロジェクトを経験した事はなかった。

というよりは、各々が自分の中だけで勝手に定義しているだけが多い気がします。
個人ごとに考えが違う事は当然なので、最初に定義しておけば効率良さそうと思いました。

天才プログラマー

誰もが自分は天才だと思われたいところはあるが、実際問題自分たちは天才ではない。
たとえ、天才であったとしてもミスは犯すし完璧ではないものです。

一人で作業してはならない。
自分が作っているものが、正しいものなのか、早い段階で他の人に見てもらうようにしましょう。

プログラマーにありがちな、完璧主義なゆえに完成してから見せたい。
未完成のものを見られたら、何を言われるか不安だ。
細かいところまで見られてバカだと思われないかと思ってしまうかもしれないが、

前述したように、自分は天才でも完璧でもない。

隠す事の方がリスクは高くなり、
しょうもない問題でつまづいている可能性もある。

開発者なら、コードを書きつつ何回もコンパイルするのが普通だ。
全てのコードを書いてから、五万行のコードを初めてコンパイルするなんてバカな事はしないはず。

それと同じで、実装過程を隠す必要はない。

正しい批判と受け止め方

コードを批判されても、君自身を批判しているわけではない
自分の価値と自分の書いたコードとを結び付けない事が大事。

ジャグリングの改善点を指摘されて、自分の性格や価値観が否定されたと思うことはないだろう。

プログラミングはスキルであり練習により向上するものだ。

指摘する側も、個人の価値まで否定してはならない。
ここでもHRTの精神を忘れずに、相手を尊敬する事が大切だ。

ユーザーを意識する

ソフトウェアの複雑さは隠さなければならない。

オプションだらけにしてはならない。
複雑な問題を解決しているんだから、隠す必要はない？
そんなことはない、
簡単なものは簡単に、複雑なものはできるだけ簡単にし、ユーザーには簡単な事をしているように感じさせるようにするべきだ。

おしまい

同僚から紹介された本なので、さっと読んでみました。

200ページくらいなので、読みやすい本かと思います。
翻訳された本なので、多少読みにくいところはありましたが良い本だと思います。