この本について

著者： Brian W. Fitzpatrick, Ben Collins-Sussman
出版： オライリー・ジャパン（2013年）
原題： Team Geek: A Software Developer's Guide to Working Well with Others

「コードを書く技術」を扱った本は山ほどあります。では、「人とうまくやる技術」を扱った本は？　Googleのエンジニアである著者2人が、Subversionの開発や社内の経験をもとに書いた本書は、まさにその問いへの回答です。

全体のテーマ：HRT（ハート）

本書を貫くキーワードは HRT（発音は「ハート」）です。

原則	意味
Humility（謙虚）	世界の中心は自分ではない。常に自己改善を
Respect（尊敬）	相手を1人の人間として敬い、能力を認める
Trust（信頼）	他者は有能であり、正しいことをすると信じる

著者は断言します。「あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ」 と。

1章：天才プログラマの神話

1人でコードを抱え込む動機は「不安」です。未完成なものを見られたくない、アイデアを盗まれたくない――その心理が、実はリスクを高めます。

本書が指摘する「隠して開発する」デメリット：

設計ミスを早期に発見できない
車輪の再発明が起きやすい
バス係数（プロジェクトの知識を持つ人数）が低いまま

ソフトウェア開発はチームスポーツである。

リーナス・トーバルズも、マイケル・ジョーダンも、1人で成功したわけではない。彼らの真の功績は「チームをリードしたこと」だと著者は述べます。

実践HRT

エゴをなくす：自分の意見を主張しつつも、「集団のエゴ」を育てる
批判を学ぶ：「君は君の書いたコードではない」という意識を持つ
影響を受けやすくする：弱さを見せることが、長期的な信頼につながる

2章：素晴らしいチーム文化を作る

チーム文化はパン種（サワードウのスターター）のようなものです。最初の文化が強ければ、新来者が持ち込む悪影響に耐えられる。文化を守るのはチームリーダーではなく、チームメンバー全員の責任です。

成功する文化のコミュニケーションパターン

同期コミュニケーション（ミーティングなど）は最小化し、非同期コミュニケーション（メール・文書など）を充実させるのが基本原則です。

ミッションステートメント（いや、マジで）

「やること」だけでなく「やらないこと」を明文化することで、年単位の節約になります。
良いミッションステートメントの例（GWT）：

GWTのミッションは、開発者が既存のJavaツールを使ってAJAXを構築できるようにすることで、ユーザーのウェブ体験を劇的に改善することである。

方向性（何をするか）とスコープ制限（何をしないか）の両方が含まれているのがポイントです。

ミーティングのルール

絶対に必要な人だけを呼ぶ
アジェンダを事前に配布する
ゴールを達成したら時間前でも終了する
参加者は5人以下が理想
お昼休みや終業前に設定する（自然に終了させるため）

その他、コードレビュー・メーリングリスト・グループチャット・設計文書の整備が文化の強度を決めます。

3章：船にはキャプテンが必要

リーダーシップの本章は、「なんとなくリーダーになってしまったエンジニア」のために書かれています。

サーバントリーダーシップ

伝統的なマネージャーは「どうやって仕事を完了させるか」を考えます。
リーダーは「チームが仕事を完了させるための道を作る」のが役割です。

「管理したくなる衝動を抑えるんだ」 ― GoogleのエンジニアリングディレクターSteve Vinterの言葉

リーダーシップのアンチパターン

自分の言いなりになる人を採用する
パフォーマンスの低い人を無視する
人間的な問題を無視する
チームを子ども扱いする
採用で妥協する

リーダーシップパターン

エゴをなくす：ミスを認め、謝罪できるリーダーは尊敬される
禅マスターになる：常に平静を保ち、質問で相手が自分で考えられるよう支援する
触媒になる：合意形成を促し、障害を排除する。「適切な答えを知るより、適切な人を知るほうが価値がある」
正直になる：難しいフィードバックは「褒め言葉のサンドイッチ」を避け、事実ベースで伝える

人は植物

エンジニアはそれぞれ必要なものが違います。サボテン型（自律性重視）もいれば、アフリカスミレ型（細かなフィードバック重視）もいる。リーダーの仕事はモチベーションと方向性を、必要な分だけ与えることです。

ダニエル・ピンクの『モチベーション3.0』を引用しつつ、著者は内発的動機の3要素を紹介しています：

自律性：自分で考えて動ける裁量
熟達：新しいスキルを学び続ける機会
目的：自分の仕事が誰かの役に立っているという実感

4章：有害な人に対処する

「有害な人」という言葉は乱暴ですが、著者が排除したいのは人ではなく振る舞いです。

よく見られる有害な振る舞いのパターン：

他人の時間を尊重しない（読めばわかることを何度も質問する）
エゴ（合意の決定を受け入れられない）
権利の過剰主張（要求するが貢献しない）
完璧主義による停滞

対処法の原則：

感情的にならない：平静を保ち、技術的な議論に戻す
エサを与えない：トロルは無視が最善
優しく追い出す：誠実に接することで自然と距離ができることもある
長期的に考える：「短期的なメリットのために文化を妥協する必要はない」

5章・6章：組織操作とユーザー

5章では、大きな組織の中でチームが動くための政治的スキルを扱います。権限のない相手を動かすには、HRTを使いながら根回しや説得の技術が必要です。

6章では、チームが最終的に向き合うべき相手――ユーザーについて述べています。ユーザーへの敬意もHRTの延長線上にあります。

総評

本書が伝えたいことは一貫しています。

「コードはマシンとのやり取りではなく、人と人とのコミュニケーションである」

「天才1人でプロダクトを作る」という幻想を手放し、HRTを中心に置いたチームを作ることが、長期的に優れたソフトウェアを生む唯一の道だと著者は主張します。

技術的な議論ではなく、チームの設計と人間関係のアーキテクチャについて考えさせてくれる一冊です。設計やアーキテクチャに関心のあるエンジニアにとって、コード以外の「構造」を学ぶ良い機会になるかと思います。