Team Geek
複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しません。
全員が最終目標に向かって協力することが重要であり、チームの協力関係はプロジェクト成功のカギとなります。
本書は、Subversionをはじめ、たくさんのフリーソフトウェア開発に関わり、その後Googleでプログラマを経てリーダーを務めるようになった著者が、「エンジニアが他人とうまくやる」コツを紹介。
「チームを作る三本柱」や「チーム文化のつくり方」から「有害な人への対処法」まで、エンジニアに求められる社会性について楽しい逸話とともに解説します。
masuyama13.icon この本を読む目的・この本から得たいこと
チームの協力関係の築き方を知る
「エンジニアが他人とうまくやる」コツを知る
チーム内の一人のエンジニアとして、どういうことを考え、どう動けばいいかのヒントを得る
masuyama13.icon 大事だと思ったこと
「早い段階で、高速に、何度も失敗せよ」
ソフトウェア開発はチームスポーツである
ビジョンを共有しよう
仕事を分担しよう
他人から学ぼう
素晴らしいチームを作る
チームで働くときのポイント
謙虚（Humility）
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
尊敬（Respect）
一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
信頼（Trust）
自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ
コードを批判されても、自分の性格や人間としての価値が攻撃されたと思わないこと
プログラミングスキルは練習すれば向上する
相手に伝えるときは、自分の疑問として謙虚に聞く
議論しているのはコードのことであり、誰かの価値やコーディングスキルのことではない
影響を受けやすくする
影響を受けやすくなれば、それだけ影響を与えやすくなる
弱いところを見せれば、それだけ強い人だと思われる
チームメイトは競争相手ではなく仲間
チームの文化
エンジニアリングチームが共有する経験・価値・目標のこと
強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的
許可を求めるより寛容を求めるほうが簡単
「運」は鍛えることができる
運のいい人は「チャンスに気がつく」
他人がそのソフトウェアを使って幸せにならなければいけない
ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくフィードバックループを回さなければ、ソフトウェアは死んでしまう
ユーザーに集中すれば、他のことはすべてついてくる
ハードルを下げる
プロダクトは、最初の体験が超重要
ユーザー数ではなく利用（アクティブ数）を計測する
速度重要
Less is more（少ないことはよいことだ）
怠けない
フォームの入力値は寛容に
複雑さを隠す
ユーザーの意見を直接聞く
見下さない
ユーザーには常に敬意を払おう
我慢する
多くのユーザーは問題をうまく表現できない
何を意図しているかを理解することが重要なスキル
信頼は最も大切なリソース
ユーザーのことを忘れない
ソフトウェアを書く理由
自分、チーム、会社のためではない
ユーザーの生活を豊かにするため
メモ
他人のバグを理解する前に、自分のバグを理解する
コードを隠したいという気持ちの裏には「不安」がある
スキルだけでは不十分
同僚たちとうまく協業できるかにかかっている
未完成のコードを見られたらバカだと思われないか
一人でやっていると、失敗のリスクが高くなる
成長の可能性も低くなる
完成するまで誰にも話さないのはリスクの高い賭け
ミスに気づけない
「早い段階で、高速に、何度も失敗せよ」
バス係数
万が一バスにひかれたら
一人で仕事をするほうがリスクが高い
ソフトウェア開発はチームスポーツである
ビジョンを共有しよう
仕事を分担しよう
他人から学ぼう
素晴らしいチームを作る
チームで働くときのポイント
HRT（ハート）
謙虚（Humility）
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
尊敬（Respect）
一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
信頼（Trust）
自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ
エゴをなくす
君は君の書いたコードではない
自分の価値とコードを同一視してはいけない
コードを批判されても、自分の性格や人間としての価値が攻撃されたと思わないこと
プログラミングスキルは練習すれば向上する
相手に伝えるときは、自分の疑問として謙虚に聞く
議論しているのはコードのことであり、誰かの価値やコーディングスキルのことではない
早い段階で失敗・学習・反復する
失敗は文書化して共有する
コンフォートゾーンの外側にいく
影響を受けやすくする
影響を受けやすくなれば、それだけ影響を与えやすくなる
弱いところを見せれば、それだけ強い人だと思われる
チームメイトは競争相手ではなく仲間
チームの文化
エンジニアリングチームが共有する経験・価値・目標のこと
強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的
ミッションステートメント
ダメなミーティングは拷問
ミーティングを開くときのルール
1. 絶対に必要な人数だけを呼ぶ
2. アジェンダを作ってミーティング開始前（前日まで）に配布する
3. ミーティングのゴールを達成したら時間前でも終了する
4. ミーティングを順調に進める
5. ミーティングの開始時間を強制的に中断される時間（昼休みや終業時間）の前に設定する
エンジニアリングとしてのコミュニケーション
コードコメント
コードの「なぜ」を説明する
チームのコメントスタイルを決める
すべてのコミットにコードレビュー
リアルなテストとリリースプロセス
「マネージャー」じゃなく「リーダー」にしたほうがいい
マネージャーはどうやって仕事を完了させるかを考える
リーダーは何ができるかを考える（どうやって仕事を完了させるかはチームに考えてもらう）
サーバントリーダー
チームに奉仕する
リーダーシップパターン
エゴをなくす
平静を保つ
質問することでメンバーが自分で問題解決できるように支援する
先生やメンターになる
目標を明確にする
正直になる
幸せを追い求める
「有害な人」を追い出す
その人ではなく「有害な振る舞い」を追い出す
不機嫌の真実を知る
指摘された点を好意的に解釈する
多くは誤解や見当違いが原因
オフィスの政治家には近づかない
上司の扱いが特にうまく、自分の昇進のために同僚や部下を活用する
すぐに他人のせいにするし、隙あらばすべてを自分の手柄にしようとする
悪い組織
官僚制や手続き
果てしない権力闘争
許可を求めるより寛容を求めるほうが簡単
仲間を探す
道がないなら道を作る
悪い習慣をやめることはできない。よい習慣と置き換えなければいけない
「運」は鍛えることができる
運のいい人は「チャンスに気がつく」
「親切の経済」
誰かを手伝うチャンスを見逃さない
強力な友達を探す
忙しい経営者（や知らない人）にメールでお願いする方法
3つの箇条書きと行動要請
問題について説明する（最大）3つの箇条書き
1つ（1つだけ）の行動要請
簡単に転送できるように
できるだけ短く
HRT を込める
プランB：逃げる
正しいことをして、解雇されるのを待とう
選択肢を知れば人間は自由になれる
他人がそのソフトウェアを使って幸せにならなければいけない
ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくフィードバックループを回さなければ、ソフトウェアは死んでしまう
マーケティングは無視できない
「認知したもの勝ち」
マーケティング戦略の基本
第一印象に注目する
小さく約束して、大きく届ける
業界のアナリストと付き合う
ユーザーに集中すれば、他のことはすべてついてくる
ハードルを下げる
プロダクトは、最初の体験が超重要
ユーザー数ではなく利用（アクティブ数）を計測する
速度重要
いろいろ手を出さない
ソフトウェアはトースター
Less is more（少ないことはよいことだ）
怠けない
フォームの入力値は寛容に
複雑さを隠す
例：Google 検索
ユーザーの意見を直接聞く
ユーザーを「人間」として扱う
見下さない
ユーザーとやり取りをしたくないのは、ユーザーのことをバカだと思っているから
車の修理ができない人を自動車工がバカだと思うか？
ユーザーには常に敬意を払おう
我慢する
多くのユーザーは問題をうまく表現できない
何を意図しているかを理解することが重要なスキル
信頼は最も大切なリソース
ユーザーのことを忘れない
ソフトウェアを書く理由
自分のため、チームのため、会社のためではない
ユーザーの生活を豊かにするため