Team Geek 〜コミュニティの問題

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

SubversionのBen Collins-Sussmanと、Data Liberation FrontのBrian Fitzpatrickの共著。

本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。
（ミッションステートメント、より）

本書の内容は上述の「ミッション・ステートメント」の通りで、プログラマが配慮するべき人間関係問題についての解説。リーダーやマネージャーには必須だが、そうでない人もきちんとこれらの能力を身につけておくことで、無駄を低減することができる。そうすれば、もっと多くの時間を技術のために費やせるというわけだ。

そして、一番重要なことは

コラボレーションの涅槃に到達するには、ソーシャルスキルの「三本柱」を身につける必要がある。この三本柱は、人間関係を円滑にするだけでなく、健全な対話とコラボレーションの基盤となるものだ。

謙虚（Humility）
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
尊敬（Respect）
一緒に働く人のことを心から思いやろう。相手を1 人の人間として扱い、その能力や功績を高く評価しよう。
信頼（Trust）
自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。(無能な人に仕事を任せて炎上したことのある人には難しいだろう。)

この3 つを合わせて「HRT」と呼びたい。読み方は「ハート」だ。痛みを軽減するものだから、苦痛の「hurt」ではなく、心の「heart」である。ぼくたちの主張は、この三本柱で成り立っている。

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。
(p.15)

に尽きる。残りの部分は、このHRT原則が様々な場面でどのように現れ、どのように対処すべきかという説明。

だから、本書から何を学ぶかは人それぞれだと思う。厚い本ではないので、ざっと目を通しておくと良いと思う。
なので以下は自分用メモ。

無能で十分説明されることに悪意を見出すな
(p.116)

防御的な仕事によって、プロダクトの保守性・安定性・信頼性は高まる。だが、政治的な信頼性を獲得することはできない。防御的な仕事ばかりしていては、プロダクトが動いていないと思われる。古いことわざの言葉遊びをすると「認知した者勝ち†」だ。
　ぼくたちは、技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3〜1/2 をかけないというルールを作っている。それ以上は政治的自殺行為につながるからだ。
(p.136)

「すべてやっているけど、一向に改善されないし、うまくいかない」と文句を言ってくる人がいる。そういうときはどうすればいいのだろうか？ 答えは単純だ。君ができることはもう残されていない。あとは被害者にならないように、そこから逃げ出そう。
(p.145)

マーケティングの人に先を越されてはいけない。
(p.153)

怠惰の罠には気を付けよう。怠惰は作業の自動化につながるので、プログラマの美徳だと言う人もいる。しかし、怠惰のせいでユーザーを不便にするコードを書いてしまう可能性もある。ユーザーにとって使いやすいソフトウェアは、プログラマにとって作るのが面倒なこともある。コードを書く側の都合ではなく、ユーザーに集中しよう。コードを書くのが大変になったとしても、愚痴を言わずにやるべきだ。
怠惰の古典的な例は、ユーザーに多くのオプションを与えることだ。
(p.164)