はじめに
本書籍の主張は、ＨＲＴ「謙虚（Humility）」,「尊敬（Respect）」,「信頼（Trust）」 です。Googleのソフトウェア工学本でも触れられていました。
ポイント
ソフトウェアの開発はチームスポートであり、技術的要素と同じだけ人的要素が影響する。
１章 天才プログラマの神話
- 隠したらダメになる。
- 早い段階で、高速に、何度も、失敗せよ。
- エンジニアには、コードに集中できるまとまった時間が必要だ。だが、それ以上にチームとの高帯域かつ高速な接続が必要。
- ３本柱HRT 「謙虚（Humility）」、「尊敬（Respect）」、「信頼（Trust）」
- あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。
- 早い段階で失敗・学習・反復する。失敗を文書化する。「ポストモーテム」
- 悪いところを見せれば、それだけ強い人だと思われる。矛盾していると思うかもしれないが、違う。間違いや能力不足を認めることは、長期的に立場を向上させるのである。
２章 素晴らしいチーム文化を作る
- 文化に合わない人を面談で排除する。
- 優秀なエンジニアは優秀なチームリーダを求める。アホなリーダは優秀なエンジニアの扱いが下手。偉そうに命令する。
- 優秀なミッションステートメントは、プロジェクトが目指さないことにも触れている。
３章 船にはキャプテンが必要
- 組立ラインの労働者は何年働いたとしても、数日間の研修を受けた労働者と交換可能だ。
- マネージャーになりたくない理由の１つ。・・・
- サーバントリーダ
- アンチパターン
- 自分の言いなりになる人を採用すること。
- パフォーマンスの低い人を無視すること。パフォーマンスの低い人をチームに残すことは、その人のためにもならない。
- 人間の問題を無視すること。
- みんなの友だちになること。友人関係と混同してはいけない。友人にならないとしても、昼食を一緒に食べよう。
- 採用を妥協すること。採用にコストはかかる。
- チームを子供扱いすること。
- リーダシップパターン
４章 有害な人に対処する
- 好ましくない振る舞いをする人は、それが悪いことだと気づいていない。あるいは、そおもそも気にしていない。無知や無関心は悪意よりもタチが悪い。つまりはHRTが欠けている。
- 他人の時間を尊重しない。自分の思考を垂れ流す人。
- 議論を蒸し返す人。文書を読もうという意思がない人。
- 完璧主義。
- 優しく追い出す。
５章 組織的操作の技法
- オフィスの政治家には、近づかない。
- 最悪の組織は、封建制度のような指揮統制型の構造をしている。
- 自分のアイディアが自分以外の人の口から出てくるのを耳にするのは苦痛かもしれない。でも、それがアイディアを広める唯一の方法だったりする。
- 忙しい経営者にメールでお願いする方法。短いメールのほうが返事をもらえる確率が高い。３つの箇条書きと、１つだけの行動要請を含める。
６章 ユーザも人間
- エンジニアリング文化は「事実」に満ちあふれている。マーケティングの人はウソばかりついている。ぼくたちはウソをつきたくない。
- Googleは、プロダクトの機能を事前に予告しない。だから、非現実的な期日に間に合わせるために
をすることもない。ソフトウェアは、実際に準備されて利用できるようになってから、リリースされる。
- ユーザに集中すれば、他のことはすべてついてくる。
- 顧客を選ぶ。最も大事なこと：ユーザの技術的能力を考えよう。ユーザが増えると、技術の能力の平均も下がる。
- プロダクトは、最初の体験が超重要。
- 複雑さを隠す。Google検索画面。ただし、上級ユーザを不自由にしてはいけない。
書誌情報
- 書籍名：TeamGeek Googleのギークたちはいかにしてチームを作るのか
- 著者：ブライアン・W・フィッツパトリック
- 出版社：オーム社
- ISBN：978--4-87311-630-3