「Team Geek」を読んだ

読みました。

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

チームで仕事をするときにはHRT（謙虚・尊敬・信頼）の文化を大事にしようという本。特にパフォーマンスの低い人やチームにとって有害な振る舞いな人に対処するときほどHRTが大切らしい。具体的に有害な振る舞いへの対処の例が書いてあってよかった。その他とくに面白かった点は、

• 早い段階で失敗をすることが大事
• 同期コミュニケーションの人数を減らし、非同期コミュニケーションの人数を増やすことがコミュニケーションの原則
• 技術的負債の解消など防御的な仕事はどれだけ大切でも全体の仕事量の1/2以下にする

以下読書メモ。

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

• ソフトウェア開発は、天才一人による仕事ではなく、チームスポーツ
  • 私たちは天才ではないし、仮に天才であってもミスをする
  • Linusの功績はLinuxのコンセプトを実証したことではなく、大勢のエンジニアをうまくリードして開発を進めたこと
• HRT（謙虚・尊敬・信頼）を大事にしよう
  • あらゆる人間関係の衝突はHRTの欠如によるもの
  • エゴをなくし謙虚に振る舞う
  • 攻撃的な非難でなく、尊敬を含んだ建設的な批判や謙虚な質問をする
  • 早い段階で失敗をする
  • 影響を受け、影響を与える

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

• チームの文化とは、チームが共有する経験・価値・目標のこと
• チームの文化の基礎を作るのは初期のメンバー
• 強固な文化を作ると「自己選択的」になる
  • 良いチームは良く、悪いチームは悪くなっていく
• コミュニケーションの原則は、同期コミュニケーションの人数を減らし、非同期コミュニケーションの人数を増やすこと
  • メーリスやチャットを活用して検索できる形でログを残す
  • ミーティングの人数を減らす。ミーティングでメールを読んでいる人は、ミーティングに参加しなくても良い人
• チームにとってミッションステートメントが重要。エンジニアチームのミッションステートメントであれば、「チームの方向性を定義して、プロダクトのスコープを制限する」だけで良い
  • ex) GWTのミッションは、開発者が既存のjavaツールを使ってajaxを構築できるようにすることで、ユーザーのウェブ体験を劇的に改善することである

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

• マネージャーになると自分の仕事を定量化するのが難しくなる。しかし、チームの成果を自分の手柄にする必要はない。チームの幸せと生産性がマネジメントの仕事
• パフォーマンスが低い人は無視せずに、成長させるかチームから退席させる。何れにしても、まずはHRTを前提とした一時的なマイクロマネジメントが必要になる。期限を設定して、達成して欲しい目標を決める。うまくいかなければ、場合によっては中止する
• マイクロマネジメントをやめる。リーダーはチームの合意形成や方向性の決定を支援することで、目標の達成方法はエンジニアが決定する
• エンジニアがリーダーに相談するのは、リーダーが問題を解決を求めているのではなく、エンジニア自身が問題解決するのを手伝って欲しいから。そのために問題の調査/整理を行う
• リーダーは障害を取り除くための答えを知る必要はなく、取り除ける人を知るだけで良い

4章 有害な人に対処する

• 有害な人ではなく、以下のような有害な振る舞いを排除する
  • 無駄な質問や間違った発言でチームの時間/エネルギーを消費する
  • 合意の決定を受け入れない、異なる視点の意見に耳を傾けない
  • 完璧主義
• 悪意を持って有害な振る舞いをする人間は無視する
• 悪意を持たずに有害な振る舞いをしてしまっている人間にはHRTを持って対応し、場合によっては退場してもらう
• 技術的に貢献できる人は交換可能だが、HRTの文化はかけがえのないもの

5章 組織的操作の技法

• 悪い習慣をやめることはできない。良い習慣と置き換えなければいけない
• マネージャーとの約束は小さくし、届けるものは大きくする。できないことを約束しない
• 技術的負債の解消などの防御的な仕事は評価されないので、どれだけ必要でも時間をかけすぎない
• 忙しい人にメールでお願いをするには「３つの箇条書きと行動要請」を利用する
  • 問題について説明する最大３つの箇条書きと１つだけの行動要請