Team Geek ―Googleのギークたちはいかにしてチームを作るのかを読んだときのメモ。

0章 – まえがき

・エンジニアリングの重要な要素であるが、忘れがちな存在の「人間」に焦点を当てている。
・技術集団を率いる人間は、技術への深い愛と造詣が必要。

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

・リーナスもビル・ゲイツもチームとうまくやる才能があった。
・人は作業途中のコードは見せたがらず、完璧にしてから見せようとする。
　しかし、作業を隠すことで失敗のリスクが高くなる。すでに誰かが対応していたり、簡単なミスに気が付かなかったり、不要なものを作成している可能性がある。
　何度もコンパイルしながらプログラムするように、フィードバックされながら作業したほうがよい。
・チームで働くときのポイントはHRT。謙虚(Humility)・尊敬(Respect)・信頼(Trust)。尊敬は思いやり、その人を高く評価すること。信頼は正しいと信じ、仕事を任せること。
・世の中の関心は常に動く。専門家として新しいことを学ばないと置いていかれる。謙虚に常に学んでいかなければならない。
・弱さ(わからないこと)を見せることは信用を失うことではない。謙虚を見せて、他人の意見を信頼することで、その正直さと強さによって周りが尊敬してくれるようになる。

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

・文化はリーダーではなくチームメンバが作る。そのため強烈な個性をもった新人が現れると、彼の文化がチームに根付くことになる。それが健全な文化になることはとても少ない。
・エンジニアはコミュニケーションをできるだけ排除してコードを書こうとするが、コミュニケーションがないと自分が正しいコードを書いているという保証はない。
(チームと違う方向に進んでいるかもしれない)
・ミッションコミットメントは方向性と、制限されたスコープが必須。
・バグ管理ツールは優先度をつける必要がある。そうしないと、どうでもよいバグを修正して、重大なバグは放置される。
・コードコメントには「なに」は記載せず、「なぜ」を記載する。
・ソースコードは完成してからもさまざまな人によって変化を続けるため、作成者の名前を記載するべきではない。

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

・伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考える。(どうやって仕事を完了させるかはチームが考える)
・部下を子供として扱えば、部下は子供のように振る舞う。エンジニアを大人として扱うべし。
・マネジメントの仕事はチームの幸せと生産性を高めること。
・マネージャーとしていちばん大事なのは、執事や召使のようにチームに奉仕すること。HRTの雰囲気を出す必要がある。
・パフォーマンスが低い人は高い人の時間を奪う。結果としてパフォーマンスが高い人は流出し、どこにも行けない人たちチームに残る。
・パフォーマンスの低い人は早めに対策する必要がある。そのチームで仕事できなくても、違うチームだと役に立つ能力を持っているかもしれない。
　また向き合う場合は、目標と期日を設定して、毎週進捗確認をする必要がある。
・チームをマイクロマネジメントしなくなれば、メンバのほうがリーダーよりも仕事に詳しくなる。つまり、リーダーは合意形成や方向性の決定を支援することになり
　目標の達成方法はメンバが決定すべきこととなっていく。
・リーダーとしてチームを長期に渡って生産的にするには、チームの幸せを計測したほうがよい。
　1対1のミーティングの後に「何か必要なものある？」という質問をすると、そのメンバが生産的で幸せになるために必要なものを簡単に把握できる。

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

・相手にする価値のない人は無視がオススメ。リソースを食われてしまうため、言葉で言いくるめるよりも無視がよい。
・善人と悪人で分類して悪人を追い出すのではなく、問題ある振る舞いを追い出す必要がある。
・有害な振る舞いに対応する前に、短期的にチームの注意や集中を無駄にしても長期的にプロジェクトにメリットがあるか、衝突は有益な方法で解決できるかを考える。
・無能で十分説明されることに悪意を見出すな。よくわからない人を追放するのではなく、破壊的な振る舞いを受け入れず、HRTに対しての期待を明確にすることが仕事。
　(例えば、ある製品に欠陥が見つかった場合、製造した企業が無能であるか愚かであるということを示しているのであって
　消費者を困らせるために企業が悪意を持って欠陥を忍ばせたわけではない、という考え方のこと。)

6章 – ユーザも人間

・成功しているプロダクトは問題を限定して、それをうまく解決したもの。
　トースター(多くの食材を調理でき、ほぼすべての人が利用できる。ただしラジオ機能(余計な機能)はついていない。)のようなプロダクトを目指すこと。
・プロダクトのユーザが増えると、機能が増えることで複雑性が増す。しかしユーザの平均的な技術能力は低下するため、ユーザの不満が増えていく。
　開発者がユーザの声を聞けるような環境を用意しておくこと。またユーザはシンジられないかもしれないが、開発チームと関係を築きたいと考えている。