『Team Geek』読書メモ: ソフトウエア開発はチームスポーツである

Team Geek――Googleのギークたちはいかにしてチームを作るのかという本は、「自分のプログラマーキャリアに最も影響を与えているいくつかの本の一つ」として、複数のブログで推薦されていることを見かけたので、GW期間中に読み終えた。

以下、読書メモ。

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

エンジニアリングは簡単だ。人間が難しい。

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

本書の基本的な考え：

ソフトウエア開発はチームスポーツであるり、技術的要因と同じだけ人の要因が影響するというものだ。

このチームスポーツの考え方が本書で何度も強調されている。

天才プログラマーの神話を破る

プログラマーのコミュニティには、天才プログラマーの神話がある。しかし、実際には、素晴らしい成果の背後には、必ずチームがいる。

優れたアイデアやプログラミングスキルがあっても、開発したソフトウェアが必ずしも成功するとは限らない。

多くのプログラマは、開始したばかりの作業を共有したいとは思わない。完璧ではないコードが見られ、バカだと思われるのが怖いからだ。

しかし、隠したらダメになる。失敗のリスクが高くなる。

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

早い段階から成果を共有することで、つまづきを回避したりアイデアを検査したりできるようになる。自分の成長にもつながる。

プロジェクトのバス係数を高めることもできる。

※バス係数：チームの中で何人がバスに轢かれたら、プロジェクトが破綻するのか。

つまり、一人だけ情報を持っていると、その人がバスに轢かれたら、プロジェクトは破綻する。情報を共有することで、バス係数を高めることができる。

チームがすべて

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

HRTの三本柱：「謙虚」「尊敬」「信頼」

• 謙虚(Humility)

  自分が全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。

• 尊敬(Respect)

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

• 信頼(Trust)

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

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

  人間関係の力を過少評価してはいけない。人間関係は確実にプロジェクトよりも長続きするものである。

実践HRT

• エゴをなくす。何でも知っているかのような印象を与えてはいけない。

• 自分の価値を自分の書いたコードと結び付けてはいけない。

• 相手に対する疑問ではなく、自分の疑問として謙虚に聞く。

  「このフローは間違っている。こうすべき」ではなく、「このフローはよくわからないが、こうしたら読みやすくなるでしょうか？」にすれば、相手も受け入れやすい。

• 過ちから学ぶには、失敗を文書化すること。何を学んだか、何を変更するかを記述する。

優れた例：

• 概要
• イベントのタイムライン
• 影響と損害の評価
• すぐに問題を解決するための行動一式
• 再発を防止するための行動一式

• 学習した教訓

• 弱みを見せる。間違いや能力不足を認めることは、長期的に立場を向上させるのである。時には「わからない」と言うことが大切。

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

チーム文化とは

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

コードレビュー、テスト駆動開発、事前の設計書など開発に関係するものもあれば、毎週木曜日のランチには決まったレストランに行ったり、金曜日には行きつけのバーに飲みに行ったりするような、人間関係にまつわるものもある。

プロダクトの開発方法、社員への接し方、競合との戦い方などあらゆる側面に浸透しているもの。

ただ、チーム文化は強烈な個性を持つ新来者が現れると、簡単に変えてしまう可能性あるため、チームは文化を維持・防衛する必要がある。

新来者がチームリーダーから文化を教えてもらうのでなく、チームメンバーから学ぶのである

チームがどのように働いているのか、どのようにやり取りをしているのか、どのように問題に取り込んでいるのかを観察することで、チームの文化がわかるようになる。

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

コミュニケーションの原則は、

• 同期コミュニケーション（ミーティングなど）の人数を減らし、と
• 非同期コミュニケーション（メール、ドキュメントなど）の人数を増やすこと。

効率的なミーティング

ミーティングは作業時間の邪魔になる。頻繫なミーティングで作業を中断させられていたら、エンジニアはゾーンに入ることができない。３～４時間のブロックを「多忙」や「クリエイターの時間」にして、まとめて仕事を片付けよう。

ミーティングを開くときの５つの原則：

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

最も重要なのは、アジェンダが済んだら、ミーティングを終了すること。

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

伝統的なマネージャーはどうやって仕事を完了させるかを考える。

リーダーは何ができるかを考える。

どうやって仕事を完了させるかはチームに考えてもらう。リーダーはそのための道を作る。

マネージャーは労働者を管理したくなる衝動を抑えるべき。

マネージャーの役割として、最も重要なのは、執事や召使いのようにチームに奉仕することだ。

謙虚・尊敬・信頼の雰囲気を作り出さなければいけない。

リーダーのアンチパターン

• 自分の言いなりになる人を採用する

• パフォーマンスが低い人を無視する

  わずか１～２人のパフォーマンスの低い人がいるだけで、チームはうまくいかなくなってしまう。

  低パフォーマンスの人をコーチングするには、

  • 期限を設定して、達成してもらいたい目標を決める
  • 小さな成功を何度も経験するため、最初の目標は小さくして、少しずつ大きくする
  • 成功か失敗かを判断できるように、マイルストーンを明確な期待で設定する。
  • 毎週進捗を確認する。続けられないようなら、早い段階で中止する。

• 人間的な側面を無視する

  例：仕事と家庭を両立したい人に対して、在宅勤務を許可しない。

• チームを子供として扱う

  人は自分が扱わるように行動する。つまり、子供や囚人のように扱えば、チームはそのように振る舞う。

  マイクロマネジメントしたり、その人の能力を貶したり、仕事の責任を与えなかったりすればすぐに伝わる。

  信頼していることを伝えれば、相手は普段魅せないような力を発揮してくれる。

メンターになるための要素

• チームのプロセスとシステムの経験
• 誰かに教える能力
• 相手がどれだけ支援を必要としているかを把握する能力。これが一番重要。

チームの幸せを追い求める

リーダーとして、チームを長期にわたって生産的に（そして離脱者を少なく）するには、時間を作ってチームの幸せを計測すればよい。

チームの幸せを追い求めるには、1対1のミーティングのあとに「何か必要なのものはある？」と質問するといいだろう。

チームメンバーのキャリアを追い求めるということもである。

誰もがやりたいことを持っている。

昇進。新しいことを学ぶ。すごいものをローンチする。頭の良い人と仕事する。口に出さなくてもエンジニアは様々なことを歓迎る。

有能なリーダーになりたければ、こうしたことをどうすれば実現できるかを考えるべきだ。そして、きちんと考えいてることをチームに知らせるべきだ。ここで重要なのは、暗黙的な目標を明確化することである。

チームのモチベーションを高める

人を幸せで生産的にするのは、外部的動機（例えば、報酬）よりも内発的動機（例えば、楽しさ）を高めることである。

内発的動機には、自律性、熟達、目的の三つの要素が必要だ。

• 自律性

  自分で考えて行動できる。

• 熟達

  新しいスキルを学び、既有のスキルを向上させるための機会を作る。

• 目的

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

有害な人に対処する

排除するのは、あくまでも振る舞いであり、特定の個人ではない。

個人を「いい」とか、「悪い」とかで考えるのは単純すぎる。

目に余る振る舞いを特定して、そのことを批判するほうが建設的で実践的である。

有害な脅威の例

• 他人の時間を尊重しない
• エゴ
• 権利を与えすぎる
• 未熟なコミュニケーションと複雑なコミュニケーション
• 被害妄想
• 完璧主義

理想：チームがうまく機能している会社

理想なマネージャー

マネージャーが君に成功を支援してくれるのであれば、マネージャーの仕事を楽にできる簡単なことがある。

• 責任の範囲を広げよう

  先を見越した行動や責任を自ら求める振る舞いによって、マネージャーの作業を軽減することができるし、今のレベル以上の仕事が可能なことも提示できる。

• リスクをとろう

  失敗を恐れるな。すばやく学習できるし、何ができて何ができないのかがわかるし、時間をかけて成長していくこともできる。

• 大人らしく振る舞おう

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

• 質問しよう

  納得できないことをマネージャーが決めたとしたら、その根拠について質問したり議論したりすることを恐れてはいけない。

• マネージャーはエスパーではない

  リーダーから何かを聞かれる前に、こちらから何をしているかを報告しよう。コミュニケーションを取りすぎているひとはいないので、躊躇することはない。

  障害物に遭遇した時、仕事がうまくいったとき、何かが必要なとき、何かを期待しているときに、マネージャーに知らせよう。そうすると、マイクロマネジメントの回避にもなる。マネージャーが監視に来るのと同じ頻度でメールを送ることで、マネージャーが確実に来なくなる。

  現実:　環境が成功の邪魔になっている

  悪いマネージャー

  • 失敗に対する不安によって、保守的になる。
  • 情報を隠そうとする。

  悪い組織

  官僚制や手続きを導入することによって、会社の成功を妨げるようになる。

  経営者はエンジニアをビジネスゴールを達成するための手段だと考えて、従業員を犠牲にして、非現実的な要求を作り出してしまう。

  最悪の組織は、封建制度のような指揮統制型の構造。

  例えば、バグの受け渡しに厳格なルールのある会社。

  バグを修正するには、責任のあるチームにメールで連絡するのではなく、自分たちで徹夜でバグを再現して、データを収集し、障害報告書を作成する必要があった。マネージャーにメールを送ると、マネージャーがディレクターにメールを送る。そのディレクターがメールをチームのマネージャーに送る。そこから１０日以上過ぎてから、二人のマネージャー、二人のディレクター、三人のエンジニアと一緒に、このバグをすぐに修正するのか、次のローンチまで保留するのか、というミーティングを開く。

会社から言うことを聞かない子どものように扱われていないだろうか？

Firewallが厳しすぎて、普通のサイトが見れないことないだろうか？１日の行動を詳細にタイムカードに記録する必要はないだろうか？１週間に書いたコード行数のような意味のない方法で生産性を計測する会社もあるくらい。

逆に、Googleでの例を見ると、

Gmailのタイポを見つけた時、ソースコードを開いて、タイポを修正して、Ｇmailチームにパッチをメールすると、ここから感謝してもらえた。

そのような組織に入ったらどうする？

1. 組織を動かして、自分の仕事に利用できる仕組みをみつけよう。
2. プランＢ：逃げよう。