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

ega
106
3
4

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

Published at October 16, 2019 6:20 p.m.
Edited at November 19, 2019 8:41 a.m.

本書の紹介

今回オフィスの本棚にあった Team Geek を読んだのでまとめてみた。

複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しません。

プログラマを経てリーダーを務めた著者が、プロジェクト成功のカギとしてチームの協力関係や全員が最終目標に向かって協力することを主張している本。
「チームを作る三本柱」や「チーム文化のつくり方」から「有害な人への対処法」まで、エンジニアに求められる社会性について楽しい逸話と共に解説してある。

目次

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

僕のモチベーション

  • hane に開催いただいたアジャイル説明会の中で、ワーキング・アグリーメント ( Working Agreement ) を作成した。
  • 知の探求 - サーキュレーションのビジョン・イズムの体現
  • 【技術書まとめ 】 をシリーズ化していこうという 挑戦

各章のメモ

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

  • 天才の神話
    • 密かに誰もが天才になりたいと願っている(もちろん僕も)
    • でも完成していないもの見られて何か言われるんじゃないかと不安になる。バカだと思われるんじゃないかと思って隠したくなる。
  • 隠したらダメ
    • ミスをしやすくなるし、車輪の再開発をする可能性も高くなるし、他人と協力するメリットも失われる。
    • バス係数 を高く保つ!
      • バス係数:チームのどれくらいの人間がバスに轢かれたらプロジェクトが破綻するかという指標
      • これは Tech Lab の弱いところなので今後の課題!
  • ソフトウェア開発はチームスポーツである
    • 孤高のプログラミング職人なんていない
    • いたとしても世界を変えるような功績は出せない
  • 大原則 HRT を行動指針の3本柱とする
    • 謙虚 - Humility
    • 尊敬 - Respect
    • 信頼 - Trust
    • あらゆる人間関係の衝突はこれらの欠如によるもの
  • 早い段階で失敗・学習・反復する
    • どんどん挑戦しよう(リリースの頻度、新しい技術選定、プロダクトを生み出し続けるサイクル)
    • 失敗したらその都度学んで kibe に la する習慣
  • 学習の時間を残す
    • 学習しないと、知らないうちに時代遅れになってしまう
    • shirayee によるインフラ系勉強会は最高の機会としてフル活用する

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

  • 文化を作る
  • ミッションステートメント(いや、マジで)
    • サーキュレーションの 「 Making GWT Better 」 を作ろう。
      • チームの方向性とプロダクトの目指すところ(と目指さないこと!)を議論して決めよう。
  • 効率的なミーティング( WA で言う Aggressive Meeting
    • 5 つの簡単なルール
      • 絶対に必要な人だけを呼ぶ。
      • アジェンダを作ってミーティング開始前に配布する。
      • ミーティングのゴールを達成したら時間前にでも終了する。
      • ミーティングを順調に進める。
      • ミーティングの開始時間を強制的に中断される時間(昼休みや終業時間)の前に設定する。
    • デイリースタンドアップミーティング
      • 福岡では既に採用している :+1:
    • 「地理的障害」のあるチームで働く(これも Tech Lab の課題)
      • face to face の帯域を過小評価してはいけない。
        • 定期的に飛行機に乗ってでもチームに会いに行くべき。
    • エンジニアリングとしてのコミュニケーション
      • コードコメントは 何をしているか ではなく なぜ を説明する
      • レビュワーは全てのコミットにコードレビュー、レビュイーはレビューしやすいように努める
      • テストコードを書いて品質に自信を持てるようにしよう。

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

  • マネージャは、サーバントリーダーシップを身につけよう。
    • HRT の雰囲気を作り出す
    • チームが順調に進めるように穴を埋める
    • 人間関係を円滑に保つ
  • リーダーのアンチパターン
    • 自分の言いなりとなる人を採用する
    • パフォーマンスの低い人を無視する
    • 人間の問題を無視する
    • みんなの友達になる
    • 採用を妥協する
    • チームを子供として扱う
  • リーダーシップパターン
    • エゴをなくす
      • チームを信頼する。
      • エンジニアからの質問を歓迎する。
      • ミスした時に謝ろう。
    • 目標を明確にする
      • ref. ミッションステートメント(いや、マジで)
      • チームの効率が劇的に向上する。
  • エンジニアを幸せで生産的にする 内発的動機 を高める
    • 自律性・熟達・目的 の3つが必要
      • 自律性:自分で考えて行動できる。プロダクトオーナーシップ。
      • 熟達:新しい技術を学び、スキルを向上させるための機会。
      • 目的:顧客・世界に与える影響。

4章 有害な人に対処する

  • 有害の定義
    • 排除するのは有害な人ではなく、有害な 振る舞い
  • チームを強化する
    • ミッションステートメントを決めて、目標とそれ以外の両方に集中する。
    • メール(チャット)でのマナーを作る。
    • 全ての履歴を文書化しよう。コードだけでなく設計書、これまでの失敗など。
    • バージョン管理システムを利用し、「バス係数」を高く保つ。
    • バグ修正・テスト・リリースなどについては明確なポリシーや手続きを用意する。
    • 新来者の参入障壁を下げる。
    • 合意ベースの決定を信頼する。合意できない場合の衝突解消プロセスを定義しておく。
  • 短期的なメリットのために文化を妥協しない。
    • HRT の重要性を認めない「頭の良い」コントリビュータに気をつけよう。
  • HRT の精神を忘れない。HRT に対する期待を明確にする。

5章 組織的操作の技法

  • 理想 :チームがうまく機能している組織
    • HRT のあるサーバントリーダーなマネージャ
    • チームメンバー
      • 自分の責任範囲を広げよう。
      • リスクを取ろう、なんでも挑戦しよう。
      • 大人らしく振る舞おう。
      • 質問しよう。
      • マネージャはエスパーではないことを理解しよう。
  • 現実 :環境が成功の邪魔になっているとき
    • 悪いマネージャ = オフィスの政治家
  • 組織を操作する
    • 悪い習慣をやめることはできないので、良い習慣に置き換える
    • 「攻撃的な仕事」>「防御的な仕事」
  • プランB :(何をしても改善できそうになかったら)逃げる!
    • 正しいことをして解雇されるのを待とう

6章 ユーザーも人間

  • 君のソフトウェアはどれだけ使いやすいだろうか?
    • Google のモットー 「 ユーザーに集中すれば、他のことはすべてついてくる
    • ユーザを選ぶ( 想定するユーザー層 )。
    • 速度( レイテンシー )はかなり重要!
    • ユーザではなく、 利用 を計測する。
    • 複雑さを隠す
  • ユーザーとの関係を管理する
    • ユーザーには常に敬意を払おう(バカにしてはいけない)。
    • 信頼と喜びを届ける
  • ユーザーのことを忘れない。
    • マーケティング
      • ソフトウェアがどのように見られるかに気を配ろう。それによって、ソフトウェアを使ってもらえるかどうかが決まる。
    • ユーザビリティ
      • ソフトウェアが簡単に使用できなかったら、遅かったら、使いにくかったら、アクセスできなかったら、ユーザー立ち去ってしまう。
    • 顧客サービス
      • ユーザーとの長期的な関係構築が、ソフトウェアの進化やユーザの定着に影響を与える。

まとめ

テクラボもメンバーが増えこれから文化やルールが形成されていくと思いますが、常に HRT の精神 を忘れずに仕事をできればなと感じました。

長々とまとめてきましたが、 技術だけでなく、人間やチームに気を配りましょう というのが、本書の内容でした。
それができている前提で、技術力を高めたいっていう意欲の強いエンジニアのためにもいい環境作りができたらなと思います。

おまけ

最後まで読んでいただきありがとうございます。
意見や指摘等あればコメントいただけると大変嬉しいです。

このシリーズを続けていけたらと思ってます。いいね:+1: やコメントいただけると大変励みになりますのでお願いします。

記事を書く時、画像探しが楽しくて止まらなくなってしまったので次回からは気をつける。

  • ega
    このアウトプットは素晴らしい。要点もよくまとまっていて読みやすかった!
    そして、江頭さんがこの考え方を身につけてもらえると、僕がアジャイルの文脈でお話した「文化」や「習慣」の話にも説得力が生れてくるし、誰かの「トップダウン」ではなく、みんなで考える「チームビルディング」の精神も養われるので、とてもいい組織が作られていくのではと感じます。

  • hane
    読んで頂きありがとうございます!
    組織作りみんなで頑張りましょう:smile:

  • takehiro_tazaki

    ega
    私も昔読みました〜!そして、たまに読み返しているので思い起こす良いきっかけになりました。
    そして、flexyメンバー(自チームのみですが)にもエンジニアを理解するためには、まずは、TeamGeekは読んでおけと普及活動していますw

  • takehiro_tazaki
    コメントありがとうございます!

    エンジニアとしても働く上での振る舞いやマインドをかなり学びせてもらいました。
    素晴らしい普及活動!ぜひ引き続きお願いしますw