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

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

読書感想文。いくつか書いてみてわかったけど、人が読むことはあんまり意識していなくて、自分が本を読んだことをかみしめるプロセスのよう。（そのため、何が言いたいのかよくわからない文章だし、読みにくい）

買ったときは気づかなかったがオライリー本だったようで、独特な日本語の言い回しでサクサク読み進められる感じ。

基本的には「チームをうまく機能させること」が書かれている本で、何が有害か、とか、有害な人への対処の仕方とかまで書かれている。

帯や本の中でも語られているとおり、「ギークでなくても読む価値がある」本だと思う。というか、どんなチームにおいてもこの本に書かれていることは当然念頭に置いておくべきで、実際書かれていることの半分くらいは自分のチームでも実践してきたことである。
では、この本のポイントはというと、

• チームを上手に機能させるテクニックをしっかりと言葉にしていること
• エンジニア（ギーク）とうまくやること

が書かれていることである。

今回は中でも特に印象に残った部分をいくつか紹介する。

三本柱

チームで働くときのポイントである。
我々が思い浮かべるチームと言えば、古来よりマネージャが存在していて、マネージャによって細かく管理された仕事をこなすものである。
しかし実際は一人ではできないこと、難しいことを複数人でやるための組織であって、工場の工程のようなひとつの作業ユニットではない。

• 謙虚（自分が常に正しいわけではない）
• 尊敬（相手を一人の人間として扱い、能力や功績を高く評価する）
• 信頼（自分以外の人は正しいことをすると信じれば、仕事を任せられる）

自分で運転できるバスに乗りたい

優秀なエンジニアに優れた仕事をしてもらうには、エンジニアが安全にアイデアを共有できて、意思決定プロセスに口を挟めるような文化を作らなければいけない。

思い通りにさせるということではなく、メンバー全員がチームの成功に責任をもつ状態を作るという意味だ。
確かに自分が決定に関わっていない仕事の責任はとりたくないし、とらなければならない理由も納得がいかない。

建設的な批判

「信頼」とは、フィードバックや批判をしないということではない。
建設的な批判は大変貴重なものであるが、多くの場合は避難したり嘲笑するよりも難しい。また、建設的な批判を頼むことも難しい。
建設的な批判をしてくれる相手を見つけたら、手放さないようにしたい。

アンチパターン：パフォーマンスの低い人を無視する

多くのチームリーダーは、歯を食いしばって目を背け、パフォーマンスの低い人が奇跡的に成長するか、どこかへ行くことを願っているだけだ。いずれの可能性も極端に低い。

パフォーマンスが低い人を放置することは、チームにとってはボトルネックになるので無視できない。「ザ・ゴール」にも書かれていたように、他の人がどれだけ高パフォーマンスを発揮してもチームのパフォーマンスはボトルネックに支配される。それに、パフォーマンスの低い人が高いパフォーマンスを発揮できる場所へ行く機会を奪うことにもなる。

わかるのだが、とは言っても「はいさようなら」とやめさせられることも多くはないので、実際にどうすべきかは悩みどころである。 そこで、特に参考になったのは「ではどうやってパフォーマンスの低い人をコーチングするのか」である。

「三本柱」がちゃんとある前提で、期限を設定して課題を決め、小さな成功を何度も経験させるといいらしい。うまくいかなければ、うまくいかないことが ２人に わかるし、うまくいけばそのまま改善させられるかもしれないということだ。ボトルネックに働きかけるということね。なるほど。

さいごに

この本に書かれているいい話はすごくたくさんあって、まぁすごくたくさんあるので紹介しきれないからこのあたりにしておこうと思う。
「チームをうまくやる」本ではあるが、「チームでうまくやる」ためにも役立つし、本当にギークじゃなくても役に立つと思う。
エンジニアに何も言わずに「リーダブルコード」をおすすめするように、誰でも一度は読んでみてほしい一冊です。

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