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

著者 : Brian W. Fitzpatrick Ben Collins-Sussman 角征典

• オライリージャパン (2013年7月20日発売)

感想・レビュー・書評

[別府さんの感想 · 2022年8月31日]

【書誌情報】
原題：Team Geek: A Software Developer's Guide to Working Well with Others
著者：Fitzpatrick, Brian W
著者：Collins-Sussman, Ben
訳者：角 征典
発行：オライリー・ジャパン
発売：オーム社
TOPICS：Business/Essay
発行日：2013年07月
PRINT LENGTH：228
ISBN：978-4-87311-630-3

複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しません。全員が最終目標に向かって協力することが重要であり、チームの協力はプロジェクト成功のカギとなります。本書は、Subversionをはじめ、たくさんのフリーソフトウェア開発に関わり、その後Googleでプログラマを経てリーダーを務めるようになった著者が、「エンジニアが他人とうまくやる」コツを紹介するものです。「チームを作る三本柱」や「チーム文化のつくり方」から「有害な人への対処法」までエンジニアの社会性について、楽しい逸話とともに解説します。
[https://www.oreilly.co.jp/books/9784873116303/]
[https://www.ohmsha.co.jp/book/9784873116303/]

【目次】
目次
推薦の言葉
日本語版まえがき
ミッションステートメント
謝辞
はじめに

1章　天才プログラマの神話
1.1　コードを隠して
1.2　天才の神話
1.3　隠したらダメになる
1.4　チームがすべて
1.5　三本柱
1.6　実践 HR T
1.6.1　エゴをなくす
1.7　批判の配分と対応を学ぶ
1.7.1　早い段階で失敗・学習・反復する
1.7.2　学習のための時間を残す
1.7.3　忍耐を学ぶ
1.7.4　影響を受けやすくする
1.8　次のステップ

2章　素晴しいチーム文化を作る
2.1　文化とは何か
2.2　なぜ気にかける必要があるのか？
2.3　文化と人々
2.4　成功する文化のコミュニケーションパターン
2.5　ハイレベルの同期
2.5.1　ミッションステートメント（いや、マジで）
2.5.2　効率的なミーティング
2.5.3　「地理的障害」のあるチームで働く
2.5.4　設計文書
2.6　日常的な議論
2.6.1　メーリングリスト
2.6.2　オンラインチャット
2.7　課題管理ツールを使う
2.8　エンジニアリングとしてのコミュニケーション
2.8.1　コードコメント
2.8.2　ソースコードに名前を書く（別名：「Authorタグ」問題）
2.8.3　すべてのコミットにコードレビュー
2.8.4　リアルなテストとリリースプロセス
2.9　すべてはコードに通ず

3章　船にはキャプテンが必要
3.1　自然は真空を嫌う
3.2　@Deprecatedマネージャー
3.2.1　「リーダー」は新しい「マネージャー」
3.2.2　1つだけ怖いのは ……まあ、全部だ
3.3　サーバントリーダー
3.4　アンチパターン
3.4.1　アンチパターン：自分の言いなりになる人を採用する
3.4.2　アンチパターン：パフォーマンスの低い人を無視する
3.4.3　アンチパターン：人間の問題を無視する
3.4.4　アンチパターン：みんなの友達になる
3.4.5　アンチパターン：採用を妥協する
3.4.6　アンチパターン：チームを子どもとして扱う
3.5　リーダーシップパターン
3.5.1　エゴをなくす
3.5.2　禅マスターになる
3.5.3　触媒になる
3.5.4　先生やメンターになる
3.5.5　目標を明確にする
3.5.6　正直になる
3.5.7　幸せを追い求める
3.5.8　その他のヒントやトリック
3.6　人は植物
3.7　内発的動機と外発的動機
3.8　最後に

4章　有害な人に対処する
4.1　「有害」の定義
4.2　チームを強化する
4.3　脅威を特定する
4.3.1　他人の時間を尊重しない
4.3.2　エゴ
4.3.3　権利を与えすぎる
4.3.4　未熟なコミュニケーションと複雑なコミュニケーション
4.3.5　パラノイア
4.3.6　完ぺき主義
4.4　有害な人を追い出す
4.4.1　完ぺき主義者には別の方向性を示す
4.4.2　生命体にエサを与えない
4.4.3　感情的にならない
4.4.4　不機嫌の真実を探せ
4.4.5　優しく追い出す
4.4.6　諦めるときを知る
4.4.7　長期的に考える
4.5　最後に

5章　組織的操作の技法
5.1　善玉、悪玉、戦略漢
5.2　理想：チームがうまく機能している会社
5.2.1　理想的なマネージャー
5.3　現実：環境が成功の邪魔になっているとき
5.3.1　悪いマネージャー
5.3.2　オフィスの政治家
5.3.3　悪い組織
5.4　組織を操作する
5.4.1　許可を求めるより寛容を求めるほうが簡単
5.4.2　道がないなら道を作る
5.4.3　上司の管理方法を学ぶ
5.4.4　運と親切の経済
5.4.5　安全なポジションまで昇進する
5.4.6　強力な友達を探す
5.4.7　忙しい経営者に（メールで）お願いする方法
5.5　プラン B：逃げる
5.6　希望は残されている

6章　ユーザーも人間
6.1　一般認識を管理する
6.1.1　第一印象に注目する
6.1.2　小さく約束して、大きく届ける
6.1.3　業界のアナリストと付き合う
6.2　君のソフトウェアはどれだけ使いやすいだろうか？
6.2.1　観客を選ぶ
6.2.2　ハードルを下げる
6.2.3　ユーザーではなく利用を計測する
6.2.4　速度重要
6.2.5　いろいろ手を出さない
6.2.6　怠けない
6.2.7　複雑さを隠す
6.3　ユーザーとの関係を管理する
6.3.1　見下さない
6.3.2　我慢する
6.3.3　信頼と喜びを作る
6.4　ユーザーのことを忘れない

付録 1　エピローグ
最後に
付録 2　あわせて読みたい
訳者あとがき
索引

[yoikaさんの感想 · 2022年4月30日]

「エンジニアリングは簡単だ。人間は難しい。」
という一文にとても共感しました。

プロダクト開発でコミュニケーションで苦労することが多く、
本書のHRTという考え方はとても参考になりました。

とくに相手の考えに対しての自分の意見の仕方として
「相手が間違っているのではなく、自分が理解できないことを強調し
自分の疑問として謙虚に質問をする。」
は、衝突や争いを避けられるのではないかと思い、
今後取り入れていきたい考え方の一つでした。

プロダクトやサービスの開発を行う上で
チームとして行動する際に抑えておきたい考え方が
たくさんあるのでチームで開発をする人にはおすすめの1冊だと思います。

[峯田 洋輔さんの感想 · 2022年2月17日]

チームで成果を出すためのtipsに近い本。
特に自分にとって大切だなと思ったのは下記

・早い段階から成果を見せることで、つまづきを回避したりアイデアを検査したりできるようになる
・失敗の学習をするには失敗を文書化すること
　何を学んだかと何を変更するかを記述する
→運用とのバランスで、失敗のみの蓄積はどうか？
・ミッションステートメントには、方向性とスコープ（手段など）を含めることで、やらないことを決められる
→戦略の本にもよく書いてある
・ポジ→ネガ→ポジのサンドイッチでのフィードバックはダメ
→本当に伝えたいメッセージを聞いてくれないから
・完璧主義の人の影響
ちゃんと設計されるまで動けないとチーム全体が遅い
→理論重視しすぎる点と通じるから気をつける
・誰が正しい間違ってるではなく、結論に辿り着くことかが大切。損切りして進まないといけないタイミングはある
・わかりやすく依頼を伝えるには3つの箇条書き+行動要請

そして最後に、大前提で、謙虚、信頼、尊敬だけは絶対に忘れるな。
これがあることで、本質的なことに時間を割くことができると。

[nabehiro3さんの感想 · 2022年1月28日]

Google の中の人が書いたソフトウェア開発のチームついての本。
「ソフトウェア開発はチームスポーツである」
と序盤にうたっているがまさにその通りだと思う。彼らは優れたコラボレーションには HRT, 謙虚(Humility)、尊敬(Respect)、信頼(Trust) を身につける必要があると言っている。

この本の中にはソフトウェア開発に従事してる身として、心に響くメッセージが多かったし、
これまで漠然と思って事が言語化されていた。
「建設的な批判は、エンジニアチームの成長や発展には欠かせない」というメッセージは、今携わってるプロジェクトがそのような雰囲気であったら様々な事が円滑に進んだだろうな、と思わされました。

効率的なミーティングの章は、ミーティングを開く立場の人ぜひ読んで欲しい内容。

ソフトウェア開発に携わる人は皆本書を読めば、きっとこの世界はより良くなると思う！

[tkhrsnさんの感想 · 2022年1月23日]

翻訳技術書特有の、アメリカンジョークのノリが鼻につくってのはあるけど…（実際巻末の訳者後書きも翻訳が大変だった模様）

技術者がチームリーダーになるにあたって最初に知るべき心構えが適切な分量で記載されているように思った。

通常、優秀なエンジニア程、優秀なチームリーダーと真逆の特性を持っているので（プログラマーの三大美徳参照）、
エンジニアがリーダー（本書はマネージャーという言葉を嫌っている）になる時
おそらく他の職種よりも過酷な思考の転換を迫られる。

それを考えると、確かにこの部分にフォーカスした本書のようなガイドはとても重要かもしれない。

最初と最後ちょっと退屈だったけど良著。

[むらけんさんの感想 · 2022年1月16日]

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

GoogleのエンジニアであるBrian W. Fitzpatrick氏とBen Collins-Sussman氏の著書になります。
チームでソフトウェア開発をするときに大事なことを実際の経験に基づいて述べています。ソフトウェアエンジニアだけでなく、社会人として読んでおいて損はない良書です。


【本書で学べること・考えること】
- ソフトウェア開発はチームスポーツ
- 最も大事なことは、謙虚(Humility)、尊敬(Respect)、信頼(Trust)の「HRT」である
- なぜチームで働くのか
- チーム文化を作る
- リーダーのあり方
- 有害な振る舞いへの対処法
- 組織との付き合い方
- ユーザーを大事にすることが超重要
- とにかく動くソフトを見せることの重要性


読んでみての感想です。

チームメンバー全員で読んで、想いを共有したいです。
このスタート点から始めれば、より良いチームになれると思います。

ソフトウェア開発において、動くソフトを届けることが最重要であり、役割は違えどその目的のために貢献することが求められることを再認識しました。

この本を一言でまとめると「HRT」になります。

[うどんさんの感想 · 2021年10月18日]

エンジニアチームの運営ってこういうことだよね、という事項が多く書かれており大変参考になる。
度々読み返している。

[けーさんの感想 · 2021年10月2日]

読み直し。当時はコードを書くプログラマの立場だったけれど、マネジメントもやる立場になって読むとまた得るものがあるな。人月の神話よりも良いかもしれない。

[naichilabさんの感想 · 2021年9月24日]

よい組織をつくるために必要なHRTについて色々な体験談を通して分かりやすく説明されている。
有害な人（行動）の排除の仕方とかも具体的に書いてあり、自分の組織に当て嵌めながら読むとなかなか面白かった。

どれも納得いくものだったが、言うは易く行うは難しだなぁと感じた。少しずつ普段の行動に取り入れていきたい。

[まーぼさんの感想 · 2021年4月17日]

1章 天才プログラマの神話
・早い段階で高速に何度も失敗せよ
・HRT:Humility(謙虚),Respect(尊敬),Trust(信頼)
⇐あらゆる人間関係の衝突はHRTの欠如によるもの


3章 船にはキャプテンが必要だ
・ミスをした際は謝る
←自分でそれを認めなくても、チームは自分のミスに気付いてる
←失敗した時に謝罪出来るリーダーは尊敬される
・メンバーが質問するのは答えを教えて欲しいのではなく,問題解決するのを手伝って欲しいだけ
→そのために相手に答えではなく質問すればよい
⚠️リーダー:障害を取り除く答えを知る必要はなく,取り除ける人を知るだけで良い。多くの場合、適切な答えを知るよりも、適切な人を知る方が価値がある
・チームに安心感を与え,失敗しても良いことを知らせる
・人を幸せで生産的に出来るのは、内発的動機を高めること
←内発的動機:自律性,熟達,目的3つが必要

5章 組織的操作の技法
・期待値を1%でも上回る
・攻撃的な防御的な仕事を考える:防御的な仕事(負債整理)などは評価されずらいので、政治的自殺行為に繋がるため、時間をかけすぎない
・メッセージの伝え方:3行の箇条書きと1つの要望