『Team Geek』のアウトプット

スポンサーリンク

はじめに

Team Geek ~Googleのギークたちはいかにしてチームを作るのか~ を読みました。
この本はソフトウェアを開発する組織とそのリーダーについて記された書籍です。

参考リンク:Team Geek ~Googleのギークたちはいかにしてチームを作るのか~

ソフトウェア開発はチームスポーツ

  • 天才プログラマを目指して1人で活動するのはリスクが高い
  • ビジョンを共有し、仕事を分担し、誰かと一緒に仕事をして世界を変える

リリースされるソフトウェアはコンピュータが解釈のブレを有さずに動作します。
そのためにはソフトウェアは誤解の余地なく明晰に言語化されたものでなければなりません。

一方で、完成前のプロダクトは「〜みたいな機能があったら良いな」と極めて曖昧な自然言語で理想像が語られます。これは聞き手の自然言語の解釈に応じてブレがある状態です。

このブレを明晰な言語化によってメンバ間の認識齟齬をゼロに近似させ、プロダクトたらしめる作業が「Engineering」であり、重要な役割と考えますが、それをこの本では「チームスポーツ」と表現していてとても馴染みやすいと感じました。

三本柱 HRT (ハート)

謙虚 (Humility)

自分が世界の中心ではない。全知全能でもない。絶対に正しいわけでもない。自分を常に改善する。

尊敬 (Respect)

一緒に働く人を心から思いやる。1人の人間として扱い、能力や功績を高く評価する。

信頼 (Trust)

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

この HRT こそが本書の大テーマです。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものと記載されていて確かに大きく納得するところがありました。

「コードを憎んで人を憎まず」にも近しい表現な気がします。

チーム文化

  • チーム文化を創り、それを維持・改善する
  • コードはマシンとのやり取りではなく、人と人とのコミュニケーション
  • コミュニケーション例
    • ミッションステートメント
    • コードレビューの粒度・頻度
    • リリースプロセス
    • ・・・

特にミッションステートメントの領域であるミッション、ビジョン、バリュー、戦略等についてまだまだ言語化できていないが故に、事業成果の最大化が出来ていない状態になってしまっているのでここは改善したいと思っていた点でした。

書籍では、ミッションステートメントを作ることで、目指すこと・目指さないことのスコープ境界がくっきりするので、認識の相違が明るみになり、ネクストアクションの合意が取れるという作用があるとのことです。

リーダー

「マネージャー」は Deprecated

  • 組立ラインの労働者とは違い、エンジニアは創造的な仕事
  • どうやって仕事を終わらせるか?はチームに考えてもらい、その道を作るのがリーダー

アンチパターン

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

パフォーマンスの低い人を無視するについては、成長の後押し or 退場の判断をリーダーとして行わないといけなくて、「Aさんのパフォーマンスは上がってくれないかな」と願うだけでは戦略ではない点が記憶に残りました。

エンジニアは技術に興味があるので技術面に寄ってしまいがちですが、人間的な側面も気に留める。しかし、いい兄貴問題も回避しないといけない点も確かにアンチパターンです。

リーダーシップパターン

  • エゴをなくす:チームを信頼し、権限移譲する
  • 禅マスターになる:自分の考えを伝えて平静を保つ
  • 正直にフィードバックする
  • 事を荒立てるタイミングを知る
  • カオスからチームを守る
  • チームのいいところをフィードバックする

人は植物

これは印象的でした。メンバそれぞれは、種の異なる植物が水・日光・肥料等欲しい養分が当たり前に異なるのと同様に、動機のモチベーションや成長のベクトルが異なるので、それを観察しないといけないのです。まだ事業規模が小さいのでアンチパターンにハマったことはないですが、肝に命じます。

久しぶりのブログですが、今回はこんな感じ。

この記事の内容が役に立ったと思いました、SNSで記事を共有していただけますと幸いです。