第1章 天才プログラマの神話
- ソフトウェア開発はチームスポーツである
- 1人でアイデアを隠したままやっていると、失敗のリスクが高くなる。成長の可能性も失う。また、書くソフトウェアの規模も大きなものを作っていくのは難しい
- HRTの三本柱
- Humility 謙虚
- Respect 尊敬
- Trust 信頼
- あらゆる人間関係の衝突は、HRTの欠如によるもの
- 建設的な批判には尊敬が含まれる。批判を受ける側は、謙虚になるべきだし、批判してくれる人のことを信頼する。プログラミングはスキルなので、練習して向上させていく。個人に対する批判だとは思わないこと
- 例えばコードレビューの際は、相手に対する疑問ではなく、自分に対する疑問として謙虚に聞く。相手が間違っている、というような表現ではなく、自分が理解できていないことを強調する
- 不完全なソフトウェアを見せても構わないという謙虚さと、ユーザがその対応を賞賛し、迅速な改善を望んでいるという信頼をもつ
- 過ちから学ぶには、失敗を文書化する。これをポストモーテムという。
- すぐれたポストモーテムには以下を含む:
- 概要
- イベントのタイムライン（調査開始から解決に至るまで）
- イベントの根本原因
- 影響と損害の評価
- すぐに問題を解決するための行動一式
- 再発を防止するための行動一式
- 学習した教訓
- 常に自分の専門外のことも学習する時間を残す。コンフォートゾーンの外に身を置く
- 間違いや能力不足を認める。謙虚さを見せる。それは、他人の意見を信頼することである。それによってみんなが尊敬してくれる
第2章 素晴らしいチーム文化をつくる
- 優れたチームの文化は、ソフトウェアを届けることに集中している。（飲み会、ミーティング、技術力向上に集中することではない）
- 強固な文化を構築すると、自己選択的になる。OSSの世界では、クリーンでエレガントなコードを書く人が集まると、それを重視する人が集まってくる。敵対的でいじわるな文化のチームには、そういった人が集まってくる
- 優れた仕事をするには、エンジニアが安全にアイデアを共有できて、意思決定プロセスに口を挟める文化を作らなければいけない
- 合意は、チーム全員がプロダクトの成功に強い責任を持ち、リーダーがチームの意見に耳を傾けること
- たとえば、長時間の振り返りと議論が欠かせない場合がある
- もしくは重要な意思決定をリーダーがする。また、チームメンバーが一丸となってミッションに合意する
- こういったとき、ミッションステートメントは役にたつ
- コミュニケーションの原則は、同期の人数を減らし、非同期の人数を増やすこと
- 同期コミュニケーションの人数が増えると決まるものが決まらなくなる
- できるだけ多くの人がプロジェクトの情報を取れるようにする（非同期コミュニケーション）
- ミッションステートメントをつくる。エンジニアリングチームのミッションステートメントであれば、チームの方向性を定義して、プロダクトのスコープを制限するだけでよい
- それによって、やること・やらないことが明確化され、仕事の節約につながる
方向性とスコープの制限を含めた一文にする- 例:GWT のミッションは、開発者が既存の Java ツールを使って AJAX を構築できるようにすることで、ユーザーのウェブ体験を劇的に改善することである。
- ミッションステートメントは環境が変わったら随時アップデートする
- 新しいものを設計する場合は、ミーティングに5人以上参加させてはいけない。意思決定者が5人のなかにいないのであれば、話がまとまらない
- 3-4時間のブロックをクリエイターの時間として、まとめて仕事を片付ける
- ミーティングはお昼休みや終業時間前など、制限がかかるようにする
- 木曜日はミーティングなし、などにする
- ミーティングのルール
- 絶対に必要な人だけ
- アジェンダは実施前に配布
- ミーティングのゴールを達成したら時間前でも終了
- ミーティングを順調に進める
- 開始時間を強制的に中断される時間の前に設定する
- 実装前に設計文書のレビューをいれる。何をやりたいのか、低コストでチームに伝える。コードを書く前なので容易に批判を受け入れることができる
- コメントはコードの「なぜ」を説明するもので、「何」をしているかを説明するものではない
- コードは人と人とのコミュニケーションである
- ミッションステートメント、ミーティング、チャット、コメント、ドキュメント、意思決定プロセス
第3章 船にはキャプテンが必要
- マネージャーになるべき理由:
- 自分をスケールできる。1人で書けるコードには限界がある
- リーダーシップの真空状態に巻き込まれたエンジニアの多くは、ガイド・ヘルプ・空中援護をすることが得意になる
- サーバントリーダーシップを身につける
- HRTの雰囲気をつくりだす
- チームの合意形成を支援する
- チームが順調に進めるように穴を埋める。自分の手を汚す。技術的なタスク、人間関係
- 自分より頭のいい人と仕事をし、自分に休暇を与えてくれていると考える
- その間に別のチャレンジができる
- パフォーマンスのでない人に対する対処。足を痛めた人がリハビリをしていることを間会える。一時的なマイクロマネジメントえ支援する。HRTがある前提でやる。
- 自分のエゴではなくチーム全体のエゴやアイデンティティを育むべき
- チームのマイクロマネジメントをしなくなれば、メンバーのほうがリーダーよりも仕事に詳しくなる。メンバーに責任を与える
- リーダーはすべてを正しくやる必要はないし、あらゆる質問に答える必要もない。意見を歓迎する。チームとして何を達成したいかを考える。
- ミスをしたときに謝る。
- 懐疑的な言葉は慎む。仕事の複雑さや障害物についてはチームに知らせる
エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいか らではない。彼が問題解決するのを手伝ってほしいからだ。そのためには、彼 に質問をすればいい。何もマジック 8 ボール† の代わりになれと言っているわ けではない。それでは役に立たないし、イライラさせるだけだ。そうではなく、 問題を整理したり調査したりすることで、彼が自分で問題解決できるように支 援するのである。そうすれば、彼の答えが見つかる††。このことは、本章でも 説明した当事者意識や責任の話と関連する。君が答えを持っている必要はない。
ヒント
- 移譲せよ。ただ手は汚せ。
- リーダーになると何もしなくなってしまう。最初は自分がやったほうが早くてもメンバーに任せる。チームが学習する機会になる。しばらくチームをリードした後、あるいは新しいチームと打ち解けるときは自分で手を汚す
- 特に誰もやりたがらないような仕事をやって貢献する
- 自分自身を置き換える
- チームメンバーに代わりをしてもらいたければ、自分より優秀な人に責任を引き受けてもらう機会をつくる
- 事を荒立てるときを知る
- 自然とよくなることはない。すぐやる
- 会社の上空で何が起きているかをチームに知らせる
- チームのよいところをフィードバックする
- 挑戦したがるメンバーがいる場合は、やり直しが簡単にできるなら簡単にいいよと言える。取り返しがつくかどうかの判断をする
- 生産的にするには、外部的動機（金など）ではなく、内発的動機である内発的動機には、自立性、熟達、目的の3つの要素が必要
- 自分で考えて行動できるときは自立性があるといえる。こちらからプロダクトの大まかな方向性を示す
- 熟達は、エンジニアが新しいスキルを学び、既存のスキルを向上させるための機会をつくること
- 上記2点は理由もなく仕事をしている人のモチベーションにはつながらない。その場合は目的を与える。プロダクトに対するフィードバックを与える
