ずっと興味があった & 東大の先輩がおすすめしていたので手にとって読んでみました。
パパッと読める内容ではありましたが、なかなか響くものがあったので印象に残った点を共有していきます。
主にエンジニアがチームで「人」と働くときに意識すべきことが書かれています。現場にいる人間なら特に、響く内容が多い気がします
前提: ソフトウェア開発はチームスポーツ
チームというのは奥が深いもので、強いプレイヤーが単純に集まっただけでもチームの強さが足し算だけで反映されることはありません。
強いチームを強いチームたらしめるもの、その答えは僕にもまだわかりませんが、少なくともこれは個人で生きていて付けられる能力とは少し違ったものです。
本書では、Google なりの強いチームの条件が豊富な具体例とともに書かれています。ソフトウェアのバグに向き合うのは前提で、その次のステップとして人間というバグの塊に向き合うための本になってます。
優れたチームのための「三本柱」―謙虚、尊敬、信頼
あらゆる人間関係の衝突は、謙虚、尊敬、信頼の欠如によるものだ。
本書では「謙虚（Humility）、尊敬（Respect）、信頼（Trust）」の3つこそが、チームで働くときのポイントになると書かれています。
僕が応援するJリーグチームの鹿島アントラーズでも、これと似たようなものに「ジーコスピリット」と呼ばれるものがあります。
献身: 己のためにプレーするのではない。全員がチームの勝利のために戦う
誠実: プロとしていかにあるべきか。生活の中から常に問いつづけろ
尊重: 相手を敬い、チームメートを敬う。サッカーが出来る環境に感謝する
僕は鹿島サポなので 「献身・誠実・尊重」 という言葉を噛み締めて毎日を生きていますが、Team Geek に書かれている「謙虚、尊敬、信頼」も同じようなもので、強いチームを作り、そこで働くうえで必要不可欠な概念であることを感じました。
失敗を文書化し、過ちから学べ
失敗の文書化で気をつけたいのは「謝罪・反省・言い訳」を書くのではなく、「そこから何を学んだのか？」「なにをしたのか？」を書くことです。
失敗を適切に文書化することで、チーム内の他人が同じ轍を踏まずに済むようになります。これはチームとして大きな進歩ですね。
優れた文書のフォーマット
- 概要
- イベントのタイムライン（調査開始から解決に至るまで）
- イベントの根本原因
- 影響と損害の評価
- すぐに問題を解決するための行動一式
- 再発を防止するための行動一式
- 学習した教訓
失敗をすることを恐れるのではなく、このように文書化して失敗する可能性を潰していきながら、早い段階で失敗・学習・反復することが重要です。
チーム文化をつくるためのミッションステートメント
素晴らしいチームには素晴らしい文化があります。ミッションステートメントを決めることでチームの方向性を明らかにするだけでなく、方向性についての認識の違いが明らかになり、合意が取れるようになります。
また、やること / やらないことをチーム指針として明確にすることで、個人の不要な時間の削減にも繋がります。
「言葉遊びを鼻で笑うことなかれ」ですね。
原則: 同期コミュニケーションの人数を減らし、非同期コミュニケーションの人数を増やす
ミーティングなどの同期コミュニケーションには必要最低限の参加人数で臨み、すべての情報を文書から取得できるようにするのが健全でスムーズ。（後半がなかなか難しいけど…）
最近はオンラインでもコミュニケーションのツールが増えてしまい、どこで何が決まっているのかが不透明になりがちです。
「 slack の #channel_name で議論がなかったら、それは何も起きていないということ」といったように、合意形成に関してもルールを策定し、コミュニケーションを意識的に透明化するはたらきかけが必要で重要になります。
ミーティングを開くときの鉄則
- 絶対に必要な人だけを呼ぶ
- アジェンダを作り、開始前に配布する
- MTG のゴールを達成したら時間前でも終了する
- MTG を順調に進める
- MTGの開始時間を強制的に中断される時間（昼休み、終業時間）の前に設定する
というわけで、エンジニアの実務ベースというよりもチームビルディング目線で感想を書いてみました。（他にもエンジニアの実務に役立つレベル感で色々書いてあります）
細かい内容については ↓ で紹介する書評のリンクとか読んでもらえるとだいたい分かると思います。興味ある方はぜひ、手にとって読んでみてください。