【読書まとめ15】Team Geek ―Googleのギークたちはいかにしてチームを作るのか

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第15弾です。

今回は Team Geek ―Googleのギークたちはいかにしてチームを作るのか を読みました。

Googleのエンジニアが書いた、チーム作りについての本です。

先週読んだ チームが機能するとはどういうことか もチーム作りについてでしたが、Team Geekは内容がエンジニアに特化しており今回も学ぶことが多かったです。

読み終わった今、チーム作りへの興味が猛烈に出てきています。チーム作りに興味がある方はこの記事をぜひ読んでみてください。

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

はじめに

• プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。自分が思っている以上に、チームは個人の生産性や幸福に直接影響する

• ソフトウェア開発はチームスポーツであり、技術的要因と同じくらい人的要因が影響する。何十年もかけてプログラミングの技術面を学んだとしても、人間的要因を学んでいない人がほとんどである。成功するにはチームでのコラボレーションについても学必要がある

 

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

• エンジニアリングチームで成功するには、以下3つ原則に基づいて行動する必要がある。この３つは、頭文字をとって「HRT」（ハート）と呼ばれる
• • 謙虚（Humility）
• • 尊敬（Respect）
  • 信頼（Trust）

• あらゆる人間関係の衝突は、謙虚・信頼・尊敬の欠如によるものである

• 早い段階から成果を共有することで、つまづきを回避したりアイデアを検証したりできるようになる。共有を防いでしまうのは、未完成のものを見せたら何か言われたり、バカだと思われてしまうのではないかという不安である。しかし、一人で仕事をして間違ったことで時間を無駄にしてしまうことの方がリスクが高いと考えるべきである

• コードレビューをするときに最も重要なのは、同僚を尊敬することである。建設的な批判をする人は、心から他人を思いやり、成果を改善して欲しいと願っている

• コードレビューを受ける側で大事なのは、自分のスキルに謙虚になるだけでなく、他の人が恩恵をもたらしてくれると信頼し、自分をバカだと思わないこと。
• プログラミングはスキルなので、練習すれば必ず向上する

• 過ちから学ぶには、失敗を文書化することが有用。謝罪や言い訳ではなく、何を学んだか、何を変更するかを記述する。書き終わったら見つけやすい場所に置いて、変更を継続できるようにする。失敗を適切に文書化しておけば、他人がそれを読んで学習し、歴史を繰り返さずに済む。以下は優れた失敗の文書のフォーマット
• • 概要
  • イベントのタイムライン（調査開始から解決に至るまで）
  • イベントの根本原因
  • 影響と損害の評価
  • すぐに問題を解決するための行動一式
  • 再発を防止するための行動一式
  • 学習した教訓

• 間違いや能力不足を認めることは、長期的に立場を向上させる。謙虚さを見せ、他人の意見を信頼すると、その正直さと強さによってみんなが尊敬してくれるようになる。ときには「わからない」ということも大切である

 

2章 素晴らしいチーム文化を作る

• 強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的である。すぐれたチームの文化は、ソフトウェアを届けることに集中している。強い文化は、集中・効率・強度を与え、それがみんなを幸せにする

• 強固な文化を構築すると「自己選択的」になる。クリーンでエレガントで保守性の高いコードを書くことに集中すると、クリーンでエレガントで保守性の高いコードを書く人たちが興味を持ってくれる

• 会社では採用の時にチームが自己選択をする。応募者にスキルや強みがあるかどうか、文化が合致しているかどうかを見極める。新しいチームメンバーが文化に合致するかを確かめる唯一の方法は、そのことについてインタビューすることである。Google含め多くの会社では、応募者が文化に合致するかどうかを採用基準にしている。採用ミスを回避するために、技術のインタビューの前に文化のインタビューをする会社もある。文化は偶然に生まれるものではなく、創業者や初期の従業員が継続的に作り出すものである

• コミュニケーションの原則は、同期コミュニケーション（ミーティングなど）の人数を減らし、非同期コミュニケーション（メールなど）の人数を増やすことである。また、できるだけ多くの人が、プロジェクトの文書から全ての情報を取得できることが重要である

• エンジニアリングチームのミッションステートメントであれば、チームの方向性を定義して、プロダクトのスコープを制限するだけで良い。ミッションステートメントを書くには時間や手間がかかるが、やること／やらないことを明確にしておけば、年単位で仕事の節約になる可能性もある

• ミーティングを開くときの５つの簡単なルール
• • 絶対に必要な人だけを呼ぶ
  • アジェンダを作ってミーティング開始前に配布する
  • ミーティングのゴールを達成したら時間前でも終了する
  • ミーティングを順調に進める
  • ミーティングの開始時間を強制的に中断される時間（お昼休みや就業時間）の前に設定する

 

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

• 船にキャプテンが必要なように、チームにはリーダーが必要である

• 伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考え、どうやって仕事を完了させるかはチームに考えてもらう

• Googleのエンジニアリングディレクターからのアドバイスは、管理したくなる衝動を抑えることであった。新人のマネージャーは労働者を管理しようとしてしまい、管理するのがマネージャーの仕事であるという思い込みは、悲惨な結果につながる

• マネージャー役割で最も重要なのは、執事や召使いのようにチームに奉仕することである。謙虚・尊敬・信頼（HRT）の雰囲気を作り出し、エンジニアでは対処できない社内の障害物を排除することや、チームの合意形成を支援したりする

• チームメンバーがアドバイスを求めてきたら、問題解決のチャンスである。エンジニアが相談を持ちかけるのは、問題解決をしてほしいからではなく、問題解決をするのを手伝ってほしいからである。そのためには質問をすればよく、問題を整理したり調査したりすることで、自力で問題解決できるように支援するのである

• リスクのとれる文化を育てるには、失敗してもいいことをチームに知らせればいい。同じ失敗を繰り返さない限り、失敗によって多くのことがすばやく学べる。犯人捜しや責任のなすりつけをするのではなく、失敗を学習の機会と考えるべきである

• フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかどうかを意識する。相手を防御的にするような伝え方では、どうすれば改善できるかを考えることができずに、逆にこちらが間違っていると反論されてしまう

• チームの幸せを追い求めるには、1on1ミーティングの後に「何か必要なものはある？」と質問するとよい。チームメンバーが生産的で幸せになるために必要なものを簡単に把握できる

• モチベーションには外発的動機と内発的動機の2種類がある。外発的動機は外からの力（対価など）で生まれるものであり、内発的動機は自発的なものである。人を幸せで生産的にするのは外部的動機（例えば札束）ではなく、内発的動機を高めることである。そして、内発的動機には、以下3つの要素が必要である
• • 自律性：自分で考えて行動すること。自律性のあるエンジニアは、プロダクトの大まかな方向性を示せば、あとはどうやってそこに行くかを自分で決められる。プロダクトのオーナーシップが感じられることがモチベーションに繋がる

• • 熟練：エンジニアが新しいスキルを学び、既存のスキルを向上させるための機会を作ること

• • 目的：顧客からの役に立ったというフィードバックがチームのモチベーションを高める

 

4章 有害な人に対処する

• 有害な人を追い出すのではなく、有害な振る舞いを排除する

• 有害な振る舞いに対応するときは、以下の二つの質問について考え、答えが「ノー」であれば、出来るだけ早くその振る舞いを中止する必要がある
• • 短期的にはチームの注意や集中をムダにしても、長期的にはプロジェクトにメリットがあるだろうか？

• • その衝突は有益な方法で解決できるだろうか？

 

5章 組織的操作の技法

• 組織の悪い習慣を排除するのは難しく、悪い習慣を止めることはできない。止めるのではなく、良い習慣と置き換える必要がある

• 運のいい人はチャンスに気がつく。規則通りに仕事をやって、自分の仕事を完了させることだけに集中し、他のことを排除しているとチャンスは少ない。自分の仕事に関係なくても、他の人の仕事を手伝うようにすれば、いずれ誰かが喜んで手伝ってくれるようになる

• 権力を持つ人たちは、問題解決を喜んでやる。そして、短いメールの方が返事をもらえる確率が高い。「3つの箇条書きと行動要請」（問題について説明する最大3つの箇条書きと1つだけの行動要請を書くフレームワーク）を使えば何かをやってもらえる確率が向上する

 

6章 ユーザーも人間

• ソフトウェア開発プロセスは、プロダクトが完成したら終わりではない。ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくことである

• Googleはプロダクトの機能を事前に予告しないという、よく考えられたポリシーを持っている。そのおかげで、新しい機能を公開した時に嬉しい驚きがある。非現実的な期日に間にあわせるためにデスマーチをすることもない。ソフトウェアは、実際に準備されて利用できるようになってからリリースされる

• Googleのモットー：ユーザーに集中すれば、他のことはすべてついてくる

• プロダクトは最初の体験が最も大事である。ソフトウェアを初めて使うときにどれだけ難しいと感じるかを考える

• 信頼は最も大切なリソースであり、残高に気を配るべきである。短期的な利便性ではなく、長期的なイメージを大切にする

• ユーザーを驚かせて幸せな気分にさせよう。ちょっとした喜びやユーモアを取り入れることで、ユーザーのことを考えていることや、関係性を大切にしていることが伝わる

• プログラマは多忙の中で、ソフトウェアを書く理由を忘れてしまう。ソフトウェアは自分のためでも、チームのためでも、会社のためでもない。ユーザーの生活を豊かにするためである。ユーザーがプロダクトについて何を考えているか、何を言っているか、何を体験しているかに注目することが、長期的に重要なことになる

おわりに

ここまで読んでいただきありがとうございます。

当然のことではありますが「HRT」はどんな時も忘れずに仕事したいですね。

本記事では書ききれませんでしたが、各項目でGoogleでの具体例がたくさん書かれていてとても分かりやすかったのでオススメです。（kindle版がないのが残念）

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

２週連続でチーム作りに関する本を読んだので、チーム作りに関する興味がかなり出てきて、将来はマネジメントに進むのもいいなーと思うようになりました。

来週からはまた技術書を読んでいこうと思います。

来週も頑張ります。