Rso's Jotter

日々の開発の知見のメモやその他雑記

Team Geekを読みました

ブログの記事を絶やさないためにも、 読んで良かった本の所感を残していくことにします。 目指せ年間記事100本。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

内容ざっくり

推薦の言葉にも書いてあったのですが、 一言で言うと "エンジニアリング版 「人を動かす」"です。 ソフトウェアは一人で開発するものではなく、チームとしてパフォーマンスを上げていくことが大事で、 テック集団のGoogleもそれは例外ではない。Google 出身の著者2名が HRT (謙虚、信頼、尊敬)を元にどのようにチームとその 文化を醸成していくかが書かれています。

著者の一人Ben Collins-SussmanはSubversionの初期の開発者であり、開発のパフォーマンスに影響する"人の問題"にどのように対処して行ったかなどの実例を元に対処法を解説しています。

所感

私にとってはかなり耳の痛い内容が多く、エンジニアはつい技術的な問題の解決に目を向けがちになりますが、大事なのはチームとしてのパフォーマンスであり、それらをうまく扱っていくことが良いプロダクトを開発する鍵となるとのこと。そうですよねと言う感じです。エンジニアは技術的な教育は学生時代や新人時代に培われますが、エンジニア気質の他のメンバーやステークホルダーとの付き合い方については、学ぶ機会はなく、私も積極的に学ぶことはありませんでした。(と言うか学びたくなかった)

本書で度々言及される HRT (謙虚、信頼、尊敬) を元に、時間をかけて文化の醸成が大切と言うことを感じるととともに、個人的に特に印象に残ったのは、パフォーマンスの出ないメンバー、チームの文化と合わないメンバーとどのように向き合っていくかについて、1章を割いて解説しているところです。この章から、いかに著者がこれらの合わないメンバー(本書では"有害なメンバー")と関わることに悩み、答えを出していたのかが伺えます。 最終的には "追放" と言う決断も辞さないと言う内容からもそれが伺えます。

私の経験で言えば、社内で本人は頑張りたいのにどうしてもできない、頑張れないと言う メンバーと一緒に仕事をしたことがあります。できない理由は適性やら体調など、止むを得ない内容を含む様々な問題があったのですが、チームとしてのパフォーマンスがあがらない一方、その問題の対処に多く時間が割かれていると言う問題がありました。そう行った中、チームとしての文化を守るためには、そう行った問題を見過ごさず、慎重に対処することが重要と述べていました。

恋愛も言われていることですが、仕事も付き合いを始めるより別れる時の方が3倍しんどい、と言うことをその時は身にしみて感じます。

こう言う問題があるがゆえに、ただでさえか見つからないエンジニアの採用を、チームの文化と合うかどうかをチェックしたりなど、より慎重に行っていく必要があり、さらに難しくしているんでないのかと思います。。

エンジニアリングに関して技術的にある程度知見を持っている人で、チームとしてプロダクトを作ってる思う人(=ほとんどのエンジニア)には、 オススメではなかろうかと思います。