Team Geek読書メモ

Jan 31, 2018

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

  • ソフトウェア開発はチームスポーツである
  • 1人でアイデアを隠したままやっていると、失敗のリスクが高くなる。成長の可能性も失う。また、書くソフトウェアの規模も大きなものを作っていくのは難しい
  • HRTの三本柱
    • Humility 謙虚
    • Respect 尊敬
    • Trust 信頼
  • あらゆる人間関係の衝突は、HRTの欠如によるもの
  • 建設的な批判には尊敬が含まれる。批判を受ける側は、謙虚になるべきだし、批判してくれる人のことを信頼する。プログラミングはスキルなので、練習して向上させていく。個人に対する批判だとは思わないこと
  • 例えばコードレビューの際は、相手に対する疑問ではなく、自分に対する疑問として謙虚に聞く。相手が間違っている、というような表現ではなく、自分が理解できていないことを強調する
  • 不完全なソフトウェアを見せても構わないという謙虚さと、ユーザがその対応を賞賛し、迅速な改善を望んでいるという信頼をもつ
    • 過ちから学ぶには、失敗を文書化する。これをポストモーテムという。
  • すぐれたポストモーテムには以下を含む:
    • 概要
    • イベントのタイムライン(調査開始から解決に至るまで)
    • イベントの根本原因
    • 影響と損害の評価
    • すぐに問題を解決するための行動一式
    • 再発を防止するための行動一式
    • 学習した教訓
  • 常に自分の専門外のことも学習する時間を残す。コンフォートゾーンの外に身を置く
  • 間違いや能力不足を認める。謙虚さを見せる。それは、他人の意見を信頼することである。それによってみんなが尊敬してくれる

第2章 素晴らしいチーム文化をつくる

  • 優れたチームの文化は、ソフトウェアを届けることに集中している。(飲み会、ミーティング、技術力向上に集中することではない)
  • 強固な文化を構築すると、自己選択的になる。OSSの世界では、クリーンでエレガントなコードを書く人が集まると、それを重視する人が集まってくる。敵対的でいじわるな文化のチームには、そういった人が集まってくる
  • 優れた仕事をするには、エンジニアが安全にアイデアを共有できて、意思決定プロセスに口を挟める文化を作らなければいけない
  • 合意は、チーム全員がプロダクトの成功に強い責任を持ち、リーダーがチームの意見に耳を傾けること
    • たとえば、長時間の振り返りと議論が欠かせない場合がある
    • もしくは重要な意思決定をリーダーがする。また、チームメンバーが一丸となってミッションに合意する
    • こういったとき、ミッションステートメントは役にたつ
  • コミュニケーションの原則は、同期の人数を減らし、非同期の人数を増やすこと
    • 同期コミュニケーションの人数が増えると決まるものが決まらなくなる
    • できるだけ多くの人がプロジェクトの情報を取れるようにする(非同期コミュニケーション)
  • ミッションステートメントをつくる。エンジニアリングチームのミッションステートメントであれば、チームの方向性を定義して、プロダクトのスコープを制限するだけでよい
    • それによって、やること・やらないことが明確化され、仕事の節約につながる
    • 方向性スコープの制限を含めた一文にする
    • 例:GWT のミッションは、開発者が既存の Java ツールを使って AJAX を構築できるようにすることで、ユーザーのウェブ体験を劇的に改善することである。
    • ミッションステートメントは環境が変わったら随時アップデートする
  • 新しいものを設計する場合は、ミーティングに5人以上参加させてはいけない。意思決定者が5人のなかにいないのであれば、話がまとまらない
  • 3-4時間のブロックをクリエイターの時間として、まとめて仕事を片付ける
  • ミーティングはお昼休みや終業時間前など、制限がかかるようにする
  • 木曜日はミーティングなし、などにする
  • ミーティングのルール
    • 絶対に必要な人だけ
    • アジェンダは実施前に配布
    • ミーティングのゴールを達成したら時間前でも終了
    • ミーティングを順調に進める
    • 開始時間を強制的に中断される時間の前に設定する
  • 実装前に設計文書のレビューをいれる。何をやりたいのか、低コストでチームに伝える。コードを書く前なので容易に批判を受け入れることができる
  • コメントはコードの「なぜ」を説明するもので、「何」をしているかを説明するものではない
  • コードは人と人とのコミュニケーションである
    • ミッションステートメント、ミーティング、チャット、コメント、ドキュメント、意思決定プロセス

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

  • マネージャーになるべき理由:
    • 自分をスケールできる。1人で書けるコードには限界がある
    • リーダーシップの真空状態に巻き込まれたエンジニアの多くは、ガイド・ヘルプ・空中援護をすることが得意になる
  • サーバントリーダーシップを身につける
    • HRTの雰囲気をつくりだす
    • チームの合意形成を支援する
    • チームが順調に進めるように穴を埋める。自分の手を汚す。技術的なタスク、人間関係
  • 自分より頭のいい人と仕事をし、自分に休暇を与えてくれていると考える
    • その間に別のチャレンジができる
  • パフォーマンスのでない人に対する対処。足を痛めた人がリハビリをしていることを間会える。一時的なマイクロマネジメントえ支援する。HRTがある前提でやる。
  • 自分のエゴではなくチーム全体のエゴやアイデンティティを育むべき
  • チームのマイクロマネジメントをしなくなれば、メンバーのほうがリーダーよりも仕事に詳しくなる。メンバーに責任を与える
  • リーダーはすべてを正しくやる必要はないし、あらゆる質問に答える必要もない。意見を歓迎する。チームとして何を達成したいかを考える。
  • ミスをしたときに謝る。
  • 懐疑的な言葉は慎む。仕事の複雑さや障害物についてはチームに知らせる

エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいか らではない。彼が問題解決するのを手伝ってほしいからだ。そのためには、彼 に質問をすればいい。何もマジック 8 ボール† の代わりになれと言っているわ けではない。それでは役に立たないし、イライラさせるだけだ。そうではなく、 問題を整理したり調査したりすることで、彼が自分で問題解決できるように支 援するのである。そうすれば、彼の答えが見つかる††。このことは、本章でも 説明した当事者意識や責任の話と関連する。君が答えを持っている必要はない。

ヒント

  • 移譲せよ。ただ手は汚せ。
    • リーダーになると何もしなくなってしまう。最初は自分がやったほうが早くてもメンバーに任せる。チームが学習する機会になる。しばらくチームをリードした後、あるいは新しいチームと打ち解けるときは自分で手を汚す
    • 特に誰もやりたがらないような仕事をやって貢献する
  • 自分自身を置き換える
    • チームメンバーに代わりをしてもらいたければ、自分より優秀な人に責任を引き受けてもらう機会をつくる
  • 事を荒立てるときを知る
    • 自然とよくなることはない。すぐやる
  • 会社の上空で何が起きているかをチームに知らせる
  • チームのよいところをフィードバックする
  • 挑戦したがるメンバーがいる場合は、やり直しが簡単にできるなら簡単にいいよと言える。取り返しがつくかどうかの判断をする
  • 生産的にするには、外部的動機(金など)ではなく、内発的動機である内発的動機には、自立性、熟達、目的の3つの要素が必要
    • 自分で考えて行動できるときは自立性があるといえる。こちらからプロダクトの大まかな方向性を示す
    • 熟達は、エンジニアが新しいスキルを学び、既存のスキルを向上させるための機会をつくること
    • 上記2点は理由もなく仕事をしている人のモチベーションにはつながらない。その場合は目的を与える。プロダクトに対するフィードバックを与える
Retrun to top