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

日本語版まえがき

本書の素晴らしいところは、エンジニアリングの重要な要素であるにも関わらず、忘れられがちな存在であった「人間」に焦点を当てたところである。

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

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

はじめに

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

成功するにはコラボレーションについて学ぶことも必要である。ソフトウェアエンジニアリングの「ソフトスキル」に投資すれば、同じだけの努力でより大きな効果が得られるだろう。

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

1.3｜隠したらダメになる

自分が正しいことに取り組んでいるのか、それがうまくできているのか、すでに完成していないかを確認する必要がある。

早い段階で失敗する可能性は高い。しかし、その段階でフィードバックを求めれば、それだけリスクは下がる。

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

しょーもないことに１人でつまづいたら、どれだけ時間がムダになるだろうか？

一緒に仕事をする人たちが君の仕事を見てくれて、間違いや解決方法を（すぐに）指摘してくれるとしたらどれだけ違うだろうか？

これがまさにソフトウェア会社にチームがある（あるいはペアプログラミングをする）理由だ。第二の目が必要になることがわかるだろう。

1.4｜チームがすべて

ソフトウェア開発はチームスポーツである。

誰かと一緒に仕事をしなければいけないんだ。ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして、素晴らしいチームを作るんだ。

本書では、このチームスポーツのコンセプトを何度も繰り返す。成功の鍵は高機能なチームにある。どんなやり方であってもこの技能を身につけるべきだ。それが本書の目指すところである。

1.5｜三本柱

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

1.7｜批判の配分と対応を学ぶ

批判を耳にする側としては、それを受け入れる方法を学ばなければいけない。自分のスキルに謙虚になるだけでなく、他の人があなた（とプロジェクト！）に恩恵をもたらしてくれると心から信頼し、自分がバカだと思わないことである。

プログラミングはスキルなので、練習すれば向上する。ジャグリングの改善点を指摘されたときに、自分の性格や人間としての価値が攻撃されたと思うだろうか？そんなことはないはずだ。自分の価値を自分の書いたコードと結び付けてはいけない。

繰り返しになるが、君は君の書いたコードではない、大事なことなので何度も言うが、君は君の書いたコードではない。君がそう思うだけでなく、同僚にもそう思ってもらうようにしよう。

1.7.1｜早い段階で失敗・学習・反復する

過ちから学ぶには、失敗を文書化することである。我々の業界では「ポストモーテム」を書くという。

適切なポストモーテムには、学習した結果として何を学んだかと何を変更するかを記述する。書き終わったら見つけやすい場所に置いて、変更を継続できるようにする。

失敗を適切に文書化しておけば、（現在と未来の）他人がそれを読んで学習し、歴史を繰り返さずに済む。あとに続く人たちの滑走路となるように、君の軌跡を消さないでもらいたい！

1.7.4｜影響を受けやすくする

間違いや能力不足を認めることは、長期的に立場を向上させるのである。そこには、HRT（Humility, Response, Trust）のすべてが含まれている。

それは、謙虚を見せることである。それは、説明と責任を果たすことである。それは、他人の意見を信頼することである。そして、その正直さと強さによって、みんなが尊敬してくれる。ときには「わからない」と言うことも大切なのだ。

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

2.2｜なぜ気にかける必要があるのか？

新しいチームメンバーが文化に合致するかを確かめる唯一の方法は、そのことについてインタビューすることだ。多くの会社では応募者が文化に合致するかどうかを採用基準にしている。

採用ミスを回避するために、技術のインタビューの前に文化のインタビューをする会社もある。技術的に合致していたとしても、文化的に合致していない人を検討したくないからだ。

文化を守るためにはこうしたプロセスが重要となる。文化は偶然に生まれるものではなく、創業者や初期の従業員が継続的に作り出すものなのだ。

2.3｜文化と人々

ソフトウェアの世界では、クリエイティブな考えがエンジニアに求められる。エンジニアに優れた仕事をしてもらうには（続けてもらうには）、エンジニアが安全にアイデアを共有できて、意思決定プロセスに口を挟めるような文化を作らなければいけない。

2.5｜ハイレベルの同期

2.5.2｜効率的なミーティング

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

2.5.4｜設計文書

設計文書は、通常は１人の人間が所持するものである。それを大勢の人たちがレビューして、２〜３人の人間が承認する。

プロジェクトの未来を描いたハイレベルの青写真だが、何をどうしたいのかを低コストでチームに伝える手段でもある。

コードを書いていないので、容易に批判を受け入れることができる。それが優れたプロダクトや実装につながっていく。

ただし、コーディングを開始したあとは、「生きた文書」として扱うべきだ。設計文書は石に刻まれたものではない。プロジェクトが進むにしたがって、更新するべきである。

そうは言っても「設計文書至上主義」になってはいけない。設計文書を書く時間で何度もスクラッチから書き直せるのであれば、その設計文書は時間のムダだ。どちらがいいかは自分の経験で判断してほしい。

2.8｜エンジニアリングとしてのコミュニケーション

2.8.1｜コードコメント

コメントは欠けている情報やよくない名前を補足するときに使うことが多い。つまり、コードに書かれてあることを説明し直すのがコメントだ。

ただし、コメントはコードのなぜを説明するものであり、コードが何をしているかを説明するものではない。

2.8.3｜すべてのコミットにコードレビュー

リポジトリに入るすべてのコード行のスタイル・品質・ケアレスミスなどを第三者が確認すべきだ。

コードの変更はレビューしやすいように小さくする。コード整形以外でチェンジセットが数千行もあるとレビューが大変だ。

コードレビューをすれば品質が高くなるだけでなく、品質に対するチームの誇りを育むこともできる。

2.9｜すべてはコードに通ず

チームの文化の大部分はコミュニケーションで成り立っている。ミッションステートメント・ミーティング・メーリングリスト・オンラインチャット・コードコメント・ドキュメンテーション・意思決定プロセスは、すべてがチーム内外のコミュニケーションだ。

コードを書くことを目的とする強いチームを作るには、膨大なコミュニケーション（感情的な時間や労力も含まれる）が必要となる。そのことに驚く人も多いが、それが真実だ。コードはマシンとのやり取りではなく、人と人とのコミュニケーションである。

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

3.2｜@Deprecatedマネージャー

3.2.1｜「リーダー」は新しい「マネージャー」

本章では、以下のことを覚えてほしい。

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

3.3｜サーバントリーダー

「マネジメント病」の治療法は「サーバントリーダーシップ」である。マネージャーの役割として最も重要なのは、執事や召使いのようにチームに奉仕することだ。

サーバントリーダーとして、謙虚・尊敬・信頼（HRT）の雰囲気を作り出さなければいけない。

サーバントリーダーはチームにアドバイスを与えるだけでなく、必要であればチームが順調に進めるように穴を埋める。自らの手を汚すのがサーバントリーダーだ。

サーバントリーダーが管理するのは、技術的な側面とチームの人間関係である。

3.5｜リーダーシップパターン

3.5.3｜触媒になる

リーダーは、障害を取り除くための答えを知る必要はない。取り除ける人を知るだけでいい。多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。

チームに変化を引き起こすもう１つの方法は、安心感を与えてリスクをとれるようにすることだ。リスクをとれば成功の確率が上がるのに、保守的に小さな成功を目指そうとする。ぼくたちはGoogleで以下のようなことをよく言っている。

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

リスクのとれる文化を育てるには、失敗してもいいことをチームに知らせればいい。

個人の成功と失敗は少し違う。個人の成功は称えてもいいが、失敗の責任を追求するようならチームは分裂し、リスクをとらなくなる。チームとして失敗し、その失敗から学んでいけばいい。

個人の成功はチームの前で称えよう。個人の失敗はプライベートで建設的な批判をしよう（みんなの前で個人を批判してはいけない）。いずれの場合もHRTをうまく使い、チームが失敗から学べるように支援しよう。

3.5.4｜先生やメンターになる

新人は特に自力で学ぶことが重要だ。チームの技術やコードだけでなく、チームの文化や想定される責任レベルについても学ぶ必要がある。

メンターになるための教育や準備は必要ない。以下の３つがあればいい。

それは、チームのプロセスとシステムの経験、誰かに教える能力、相手がどれだけ支援を必要としているかを把握する能力だ。最後の項目が最も重要である。メンターには、必要十分な情報を与えることが期待されている。

3.5.8｜その他のヒントやトリック

しばらくチームリードをしたあとであれば、あるいは新しいチームと打ち解ける段階であれば、自分で手を汚したほうがいい。チームの尊敬を集めることができるし、仕事のペースが上がるからだ。

特に誰もやらないような仕事を担当するといいだろう。これまでの経歴や実績があるかもしれないが、実際に仕事をする以外にチームに自分のスキルや献身（や謙虚）を伝える術はない。

新しくチームリーダーになった人の多くは、チームメンバーの欠点ばかり気にしていて、チームのいいところを十分にフィードバックできていない。

その人の悪いところだけでなく、いいところも知らせてあげよう。素晴らしいところはチームにも知らせてあげるといいだろう。

3.7｜内発的動機と外発的動機

新しいことを学んだり、技を身につけたりする機会を作ることが、エンジニアを鋭くて、効率的で、効果的にさせるのだ。

仕事の目的が見つかれば、モチベーションと生産性が驚異的に向上する。ぼくたちのよく知るマネージャーは、「影響力の小さな」プロダクトに対するメールのフィードバックに目を光らせていた。

そして、顧客から役に立ったというメッセージがあると、すぐにエンジニアチームに転送した。こうしたことが、チームのモチベーションを高めるだけでなく、プロダクトを改良するきっかけになるのである。

6｜ユーザーも人間

ソフトウェア開発プロセスとは、プロダクトを壁越しに投げたら終わりではない。ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくことだ。

本章では、ユーザーエンゲージメントの3つのフェーズを調査する。

まずは、ユーザーにソフトウェアを知ってもらう必要がある。ユーザーはソフトウェアの存在に気づいているだろうか？ユーザーにどうすれば気づいてもらえるだろうか？

次に、ソフトウェアを使ったときの体験について考える必要がある。ユーザーの期待に応えられるだろうか？ユーザーはうまく使えるだろうか？ユーザーはこれで何かすごいことができるだろうか？

最後に、ユーザーがソフトウェアを使い始めたあとに、うまくやり取りをする方法について見ていくことにする。こうしたやり取りもソフトウェア開発の一部である。

6.1｜一般認識を管理する

6.1.1｜第一印象に注目する

初心者にとってソフトウェアとはどのようなものだろうか？ソフトウェアはユーザーのことを歓迎しているだろうか？使ってもらいやすくなっているだろうか？

もっと具体的に言うと、最初の30秒間のユーザーエクスペリエンスはどのようなものだろうか？「最初にメニューを見て、ログインボックスを...」という答えはいらない。

ここでは感情的な答えが聞きたい。1分後にどのように感じるだろうか？すでに使いこなしているだろうか？それとも混乱しているだろうか？改善できることはあるだろうか？

ソフトウェアを受け止めてもらうには、こうしたことを真剣に受け止めなければいけない。

6.2｜君のソフトウェアはどれだけ使いやすいだろうか？

6.2.2｜ハードルを下げる

プロダクトがウェブアプリケーションであれば、高速に読み込むべきだ！ぼくたちはウェブページに時間を搾取されている。3~4秒で読み込まなかったら、そのページに興味を失うだろう。弁解の余地はない。

入口で待たせてしまったら、ユーザーが入ってくれるはずがない。すぐにどこかへ移動してしまう。ページの読み込みを待つよりも、他のことをしたほうがいいからだ。

6.2.3｜ユーザーではなく利用を計測する

利用の計測方法も考えておくべきだ。インストール数やユーザー登録数ではなく利用だ。プロダクトはダウンロードではなく、利用されなければいけない。

多くの会社が（Googleも含めて）利用の計測に時間をかけている。よく使う指標は「7日間のアクティブ数」や「30日間のアクティブ数」だ。これは一定期間にソフトウェアを利用したユーザー数のことである。

ソフトウェアがうまく行っていることを示す重要な数値だ。ダウンロード数は無視して、アクティブ数を計測する方法を見つけよう。これがソフトウェアを理解するための本物の指標だ。

6.2.5｜いろいろ手を出さない

君のソフトウェアはいろいろやり過ぎていないだろうか？成功しているソフトウェアというのは、問題を限定してそれをうまく解決したものだ。

あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題をうまく解決しているのである。

ソフトウェアはトースターだと思ってほしい。トースターは何でも調理できるだろうか？そんなことはない。でも、多くの食材を調理できるし、ほぼすべての人が使える。機能が多すぎて圧倒されることもない。トースターを作ろう。Less is more(少ないことはよいことだ)。

6.2.7｜複雑さを隠す

優れた設計は簡単なものを簡単に、難しいものをできるだけ簡単にする。複雑なことであっても、簡単なことをしているように感じられるようにするべきだ（ここでもユーザーの感情に注目している）。

このことを「複雑さを隠す」と呼びたい。複雑な問題を分割して、何かで包み込んで、どうにか簡単に見せるようにする。

Googleの例も有名だ。Googleの検索インターフェイス（とハードル）は存在しないに等しい。そこには文字を入力するだけの不思議な箱があるだけだ。テキストボックスの裏側に膨大な技術が待ち構えているが、その複雑さは隠されているのだ。