Team Geekを読んで個人的に大事だと思った箇所まとめ

この記事を書くきっかけ

Team Geek ―Googleのギークたちはいかにしてチームを作るのかを読む機会があり、内容として学びになる箇所が多かったので重要と思った箇所をまとめました。
(全体の要約ではないため悪しからず、、、)

はじめに

ピッチ

• プログラマとして成功するには新しい言語を学ぶことや高速でコードを書くことだけではない。
• プログラマはチームで仕事する。チームは個人の生産性や幸福に直接影響する。
• ソフトウェア開発はチームスポーツであり、技術的要因と同じだけ人的要因が影響するもの。

天才プログラマの神話

1.3隠したらダメになる

• いつも一人でやっていると失敗の可能性が高くなる。また成長の可能性が低くなる。
• 検証を重視した早い段階で、高速に、何度も失敗せよの精神が大事。
• 早い段階から成果を共有することで、つまづきを回避したりアイデアを検査できるようになるだけでなくバス係数を高めることができるようになる。
• コードを書いてコンパイルするとき5万行一気に実行するか？
  • すぐコンパイルをかけるはず
  • それと同じで少しの成果でフィードバックを得る
  • エンジニアには強いフィードバックループが必要

バス係数に関して

• もし自分だけがプロジェクトを回していてうまくいっていたとしても自分が死んだら終わり、、、係数1
• 2人チームで回していたらバス係数は2になる

1.5 3本柱

• Humility(謙虚)

• 世界の中心は君ではない。君は全知全能ではない、絶対に正しいわけでもない。

• 常に自分を改善していこう。

• Respect(尊敬)

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

• Trust(信頼)

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

• 上記3つを合わせてハートという。

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

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

• 過ちから学ぶには失敗を文書化することである。
  • 上記をポストモーテムと呼ぶ
• 適切なポストモーテムには学習した結果として何を学んだかと何を変更するかを記述する。

1.7.4 影響を受けやすくする

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

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

2.1 文化とは何か

• パンづくりで例えると、パンにとって大切なのは小麦と水を食料にするイースト菌と乳酸菌の「スタータ」の存在。
• チームの文化はサワードパンのようなもの。スタータ(創業者)がパン生地(新来者)に菌(文化)を植え付ける。イースト菌と乳酸菌(チームメンバー)が発酵(成長)すると美味しいパン(チーム)の出来上がり。

2.4 成功する文化のコミュニケーションパターン

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

2.5.3「地理的障害」のあるチームで働く

• リモートで業務過剰であってもフェイスツーフェイスの帯域を過小評価してはならない。
  • どんなにメールやチャットや電話をしていても定期的に飛行機に乗ってチームに会いに行くべき。

2.8.1 コードコメント

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

2.9 全てはコードに通ず

• コードを書くことを目的とする強いチームを作るには膨大なコミュニケーション(感情的な時間や労力も含まれる)が必要になる、
• コードはマシンとのやりとりではなくて人と人のコミュニケーション

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

3.3 サーバントリーダーシップ

• 新人のマネージャーに襲いかかる病気がある。
• マネジメント病...自分がマネージャーから受けたひどい仕打ちを忘れて、それと同じようにエンジニアをマネージし始めるというもの。
  • 必要以上にマイクロマネジメントしたり、部下を無視したり自分の言いなりになる人を採用したりする。
• マネジメント病の治療法として「サーバントリーダーシップ」...マネージャーの役割として重要ん愛は執事や召使いのように奉仕すること。
  • サーバントリーダーとしてHRTの雰囲気を作り出さなければならない。
  • サーバントリーダーはチームにアドバイスを与えるだけでなく、必要であればチームが順調に進むように穴を埋める。
  • サーバントリーダーが管理するのは技術的な側面とチームの人間関係である。

3.4 アンチパターン

• 自分の言いなりになる人を採用する
• パフォーマンスの低い人を無視する
• 人間の問題を無視する
• みんなの友達になる
• 採用を妥協する
• チームを子供として扱う

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

3.5.1 エゴをなくす

• 謙虚は自信がないこととは違う

• 個人のエゴではなく、チーム全体のエゴやアイデンティティを育むべき

• 目標の達成方法はプロダクトを作る人が蹴っていずべきこと

  • プロダクトの当事者意識を植え付けるだけでなく成功(失敗)の説明責任と最終責任を与えることができる。

3.5.3 触媒になる

• 触媒とは化学反応を早めるものでありそれ自身は科学変化しない
• 上記がリーダーの務め
  • チームリーダがやるのは合意形成
  • 合意形成はリーダーシップのスキルであり、権力を必要としない非公式のリーダーもよく使っている。
• リーダーは、障害を取り除くための答えを知る必要がない
• 多くの場合、適切な答えを知るよりも適切な人を知る方が価値がある

3.5.6 正直になる

• 難しいフィードバックを伝えるとき、言葉のサンドウィッチを使うのがテンプレート。しかしそれは間違い

• 「褒め言葉、指摘の言葉、褒め言葉」

• 親身になって共感することが重要な意味を持つ

3.6 人は植物

• 6人の子供に対して同じだけの水、日光、肥料を与えていたら誰として本当に必要なものは手に入らない可能性が高い
• エンジニアを幸せで生産的にするにはモチベーションを方向性を与えることが重要である

3.7 内発的同期と外発的動機

• 人を生産的で幸せにするには内発的を動機を高めることが重要である

• そして内発的動機には、自立性、熟達、目的の3つに要素が大事である。

• エンジニアであれば誰かがマイクロマネジメントするのではなく自分で考えて行動できる自立性があると言える。

• 熟達というのはつまりエンジニアが新しいスキルを学び既存のスキルを向上させるための機会を作ることである

• 自立性と熟達は理由もなく仕事をしている人もモチベーションにはつながらない。そのような人には仕事の目的を与えなければならない

5 組織的操作の技法

5.4.2 道がないなら道を作る

• チームの悪い週間はそう簡単に無くせない。良い週間と置き換える必要がある。
• 週時MTGが嫌なら元お効果的な方法と置き換える検討を

5.4.7 忙しい経営者にメールで依頼する方法

• 短いメールの方が返事をもらえる可能性が高い
• これを「3つの箇条書きと行動要請」のテクニックと読んでいる
  • これには問題に対する3つの箇条書きと1つだけの行動要請が書かれている。

6 ユーザーも人間

6.2.5 いろいろ手を出さない

• 成功しているソフトウェアというのは問題を限定してしてうまく解決したもの、
• ソフトウェアはトースターだと思っていい。トースタはなんでも調理できるだろうか。
• でも多くの食材を調理できるし、ほぼ全ての人が使える。機能が多くて圧倒することはない。
• less is more(少ないのは良いことだ)

6.2.7 複雑さを隠す

• ユーザーにとって複雑なことであっても簡単なことをしていられるように感じるべき。

6.3.1 見下さない

• ユーザーやり取りしたくないのはユーザーのことを見下している節があるから。
• コンピュータを扱う能力が高ければ一般知能が優れているわけではない。
• ユーザーには常に敬意を払おう。

読んでみての感想

• チームとタイトルに入っているだけあってチームマネジメント的な内容がメインかと思いきや、一エンジニア/チームメンバとしてどう振る舞うべきかが記載されていた。

  • 私自身はリーダー経験はないため「一エンジニア/チームメンバとしてどう振る舞うべきか」の内容がより身近に感じた。

• 「早い段階で、高速に、何度も失敗せよ」や「エンジニアには強いフィードバックループが必要」の箇所は今日から実践できる内容であると感じた。

  • コードは一気にコンパイルせず、コードをある程度更新したらコンパイルするよね？という流れは説得のある文章。失敗や指摘を恐れて自分自身の成果をコンパイル(他者にチェックしてもらう)することを行わないのはかえって遠回りな行動であると考えた。
  • ただ闇雲に人に確認してもらうのではなく、自分のフィードバックループを確立していきたい。

• リーダーシップパターンの「触媒になる」は共感を感じる部分が多かった。リーダーとして人を仕切る感じでマイクロマネジメントをしてしまうのは古いリーダー像でありリーダーとメンバー間に上下関係が強まってしまうと考えていた。

• あくまでリーダーという役職であり、メンバーをよりよく動かす潤滑油的な存在が実際に求められるリーダーの姿であるということを発見し、リーダー職へのハードルが下がったように思う。

• 内発的同期と外発的動機のセクションでは、自分が働いてきて感じていた言葉にできない感情を言い表してくれてる内容でモヤが少し晴れた気がした。

• どうしてもアレコレをやれというトップダウンの形式では、仕事のやりがいも感じず、やらせているだけでいわゆる「仕事」感が強いなと感じた。

• しかし目的を持たせ、オーナシップと裁量があることでやりがいを感じそれが新たなモチベーションにもつながると感じた。