TeamGeekを読んだので殴り書き

今回読んだ本は、「TeamGeek」。
Googleのエンジニア2人が自分たちの経験に基づいて書き出した本で、エンジニアリングチームで成功するための心構えを語ってくれる。

ちなみに、本を読んで殴り書きする理由は、

• 自分に足りないことを補充する
• 忙しい生活の中で、忘れないようにメモしとく
• 何日後、何ヶ月後、何年後にもメモを見て思い出す

ためであるので、今後も本を読んだあとの殴り書きは続くよー

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

前置き

まず、この本のミッションステートメントと構成(=目次)を確認しよう。

一番最初に印象に残ったのは、この本の「ミッションステートメント」。我々のプロジェクトにもこのようなミッションステートメントを設定・公言すべきだろうなー

ミッションステートメント

本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。

目次

6章と2つの付録で構成されていて、各章はまたいくつかの節で構成されている。ここでは、6章のタイトルのみ列挙する。

• 1章 天才プログラマの神話
• 2章 素晴らしいチーム文化を作る
• 3章 船にはキャプテンが必要
• 4章 有害な人に対処する
• 5章 組織的操作の技法
• 6章 ユーザーも人間

中身

じゃ、実際に本を読んで心に残ったことまたは残したいことを忘れないうちに！

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

エンジニアリングチームで成功するには、自分が「謙虚・尊敬・信頼」の原則に基づいて行動できているかを認識しなければいけない。

リーナスの本当の功績は、そういつ人たち(=数百人もの頭のいい人たち)をリードしてうまく調整したことだ。Linuxは協働作業の輝かしい成果である。

人間は本能でリーダーやロールモデルを設定し、崇拝し、模倣しようとする。

いつも1人でやっていると、失敗のリスクが高くなる。そして、成長の可能性が低くなる。
そもそも、どうやって正しい方向に進んでいるとわかるのだろうか？

検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神を忘れないようにしよう。

最高のチームはスーパースターをうまく活用している。全体は部分の総和よりも大きい。

ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして、素晴らしいチームを作るんだ。

人間関係は確実にプロジェクトよりも長続きするものである。

自分をよく見せようとするよりも、「集団」のエゴを考えてみてはどうだろうか。

建設的な批判をする人は、心から他人を思いやり、成果を改善してほしいと願っている。

相手に対する疑問ではなく、自分の疑問として謙虚に聞くのである。相手が間違っているのではなく、自分が理解できないだけであることを強調する。

学習をやめると退屈になる。知らないうちに時代遅れになってしまう。

影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる。

三本柱(HRT)

謙虚(Humility)

世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。

尊敬(Respect)

一緒に働く人のことを心から重いやろう。相手を1里の人間として扱い、その能力や功績を高く評価しよう。

信頼(Trust)

自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。

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

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

チームの文化とは、エンジニアリングチームが共有する経験・価値・目標のことである。

プロセスそのものよりも、衝突を解消するプロセスを持っていること、それを守っていることが重要だ。

コミュニケーションの原則は、同期コミュニケーション（ミーティングなど）の人数を減らし、非同期コミュニケーション（メールなど）の人数を増やすことである。

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

意思決定者がいない限り、部屋に5人以上いたら決まるものも決まらない。

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

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

Googleのマネージャーという言葉には「部下がいる」以上の意味はない。

チームの幸せと生産性を高めることがマネジメントの仕事の指標になる。

必要以上にマイクロマネジメントをしたり、パフォーマンスの低い人を無視したり、自分の言いなりになる人を採用したりする。すぐに治療しなければ、チーム全体を殺してしまう。

管理したくなる衝動を抑えるんだ。

君よりも頭がよくて、代わりになるような人を採用したほうがいい。

ソフトウェア開発において人間を扱う部分がいちばん難しい。そのなかでも最も難しいのは、期待に応えない人をどうするかという部分である。

パフォーマンスの低い人に直接働きかけることで、必要かつ重要な変化の触媒となるのである。

友人関係とチームをリードすることを混同してはいけない。

人は自分が扱われるように行動する。

チームのマイクロマネジメントをしなくなれば、前線で働く人たちのほうがリーダーよりも仕事に詳しくなる。つまり、リーダーの仕事はチームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきことだ。

エンジニアからの質問を歓迎しよう。君の意思決定や意見に対して質問してきたら、その人は君のことをもっとよく理解しようと思っているのである。質問を歓迎すれば、優れたリーダーになるための建設的な意見が手に入る。

チームとして何を達成したいかを考えよう。フィードバックと批判をオープンに受け止めよう。

失敗したときに謝罪できるリーダーは尊敬される。

エンジニアであれば、懐疑的や批判的な感度を高めていると思うが、チームをリードするときには、そのことがマイナスになる。

エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決するのを手伝ってほしいからだ。

リーダーはチームに貢献することが嬉しい（貢献することが可能である）ことをチームに理解してもらおう。

多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。

不可能な目標を達成しようとすると、失敗する可能性が高くなる。だけど、簡単にできそうなことをするよりも、できそうもないことに挑戦して失敗するほうが道が開けるはずだ。

自力で学ばせようとするのは難しいが、それはリーダーの大切な役目でもある。

フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかどうかが重要だ。

（優秀なリーダーたちは、）チームメンバーの幸せを調べて、やるべきことを理解しているかを確認し、その仕事に満足できるようにしていた。

委譲せよ。ただし手は汚せ。

優秀なリーダーは、取り返しがつくかどうかの判断に優れている。

リーダーとしての仕事は、どのエンジニアが何を必要としているかを把握して、それを与えることだ。

仕事の目的が見つかれば、モチベーションと生産性が驚異的に向上する。

4章 有害な人に対処する

ネガティブな振る舞いを拒否するような文化を作るほうが健全だ。排除するのはあくまでも振る舞いであり、特定の個人ではない。

好ましくない振る舞いをする人は、それが悪いことだと気づいていない。あるいは、そもそも気にしていない。無知や無関心は悪意よりもタチが悪い。るまりは、HRTが欠けているのである。

誰が正しいか間違っているかではなく、結論にたどり着くかどうかが重要だ。

有害な振る舞いを排除すれば、頭がいい（けど人付き合いの苦手な）人は生産性の高いメンバーになる。

感情が高まってしまうと、相手にする価値のない人に一生懸命返事を書いて、何時間や何日間も時間をムダにしてしまう。

言葉にトゲがあったり無礼な感じだったりしても、まずは指摘された点を好意的に解釈する。

短期的なメリットのために文化を妥協する必要はない。

5章 組織的操作の技法

先を見越した行動や責任を自ら求める振る舞いによって、マネージャーの作業を軽減することができるし、今のレベル以上の仕事が可能なことも提示できる。また、コンフォートゾーンを抜け出して、新しいことに挑戦したいという気持ちも表わせる。

自分が期待することを他人に伝えること。

組織を動かして、自分の仕事に利用できる仕組みを見つけよう。自分が居心地のいい場所を作り出すのである。

勝てる見込みのある重要な争いを選択しよう。勝てない争いで資本を使い果たしても意味がない。ストレスになるし、これといった理由もなくキャリアに制限がかかってしまう。

君のやっていることだけでなく、君が「うまく」やっていることを上司やチームの外部にいる人たちに知らせる必要がある。

攻撃的な仕事は、ユーザーに見えるものである。

防御的な仕事は、プロダクトを長期的に健全にするためのものである。

ぼぐたちは、技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3～1/2をかけないといるルールを作っている。それ以上は政治的自殺行為につながるからだ。

選択肢を知れば人間は自由になれる。

6章 ユーザーも人間

ユーザーに集中すれば、他のことはすべてついてくる。

はじめて使うユーザーのことを考えてみよう。

プロダクトは最初の体験が超重要なのだ！

成功しているソフトウェアというのは、問題を限定してそれをうまく解決したものだ。

優れた設計は簡単なものを簡単に、難しいものをできるだけ簡単にする。

ユーザーには常に敬意を払おう。

信頼は最も大切なリソースだ。