「Team Geek Googleのギークたちはいかにしてチームを作るのか」という本を読みました。
この本はマネジメントを成功させるための本ではなく、素晴らしいチームを作るための心構えを説く本です。
世の中の多くの人は
「一人の天才が世界を変えた」
というような神話を好みます。
僕自身もそういうストーリーに憧れます。
とはいえ、大きな仕事を成し遂げるのは個人ではなく、チームである場合がほとんどです。
スーパースターはたしかに素晴らしい。
でも、それ以上に、偉大なチームを作るほうが素晴らしいのです。
Team Geekの著者は「孤高のプログラミング職人はいない」と強調します。
プログラミングに限らず、たった一人で何か大きな仕事を成し遂げる人は稀でしょう。
孤高の職人がいたとしても、一人で超人的な偉業を達成できるわけではありません。
「世界を変えるような功績は、インスピレーションの閃きとチームの努力の結果である」
というのは本書で強調されていることです。
チームを成功させるには、良い文化を醸成しなければなりません。
優れたチームには謙虚・尊敬・信頼の文化を根付いています。
どんなチームを作るにしても、謙虚・尊敬・信頼は必ず必要になります。
エンジニアに限ったことではなく、どんな業種でも同じです。
謙虚・尊敬・信頼は人間関係を円滑にして、健全な対話とコラボレーションを行う上での基盤になります。
- 謙虚(Humility) 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。
- 尊敬(Respect) 一緒に働く人のことを心から思いやろう。相手を一人の人間として扱い、その能力や功績を高く評価しよう。
- 信頼(Trust) 自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
頭文字をとって、HRT(ハート)の法則と呼ばれます。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものです。
コミュニケーションの中心にHRTがなければいけません。
たとえば何か製品の問題について否定的な意見を言うときも、そこに尊敬がなければいけません。
「君は間違っている。僕のこのやり方でいくべきだ」
と相手を否定するようでは、そこに尊敬があるとはいえません。
謙虚になって、相手に敬意を払いながら
「この製品のこの部分がよくわからないのですが、XXXに変えればもっと良くなるでしょうか？」
というような聞き方をします。
相手が間違っていると否定のではなく、謙虚になって、自分が理解できないだけであることを強調するのです。
チームメイトは信頼すべき仲間であり、競争相手ではありません。
お互いに尊敬し、自分が正しいというエゴを捨て、謙虚さを忘れずに、お互いから学ぶ必要があります。
間違いがあればそれを素直に認め、弱いところを隠す必要はありません。
ときには「わからない」ということを正直に認めるのも大切です。
それは長期的には信頼を生み出し、立場を向上させます。
文化を醸成するのは大変です。
チームの文化の基礎を作るのは、会社に最初からいるメンバーです。
ただし、文化はチームが続く限り、変化・発展していくものです。
文化を軽んじてはいけません。
チームの文化で興味深いのは、強固な文化を構築すると、「自己選択的」になることです。
敵対的で意地悪で、個人を攻撃するような文化のチームは、敵対的で意地悪で、個人を攻撃するような人を引きつけます。
開放的でお互いを尊敬し、信頼しあっているチームには、同じように開放的で敬意を大切にし、信頼を築こうとする人が引きつけられてきます。
文化に合う人が自然と集まってくる様子を「自己選択的」といいます。
Googleでは採用のときに「文化にマッチするか」を重視しており、チームに働けそうにない人には面接者が赤いフラグをつけるようにしているそうです。
コミュニケーションとミーティングの原則
コミュニケーションの原則は、ミーティングのような同期コミュニケーションに参加する人数を減らし、メールなどの非同期コミュニケーションに参加する人数を増やすことです。
同期・非同期という言葉は聞き慣れないかもしれませんが、同期コミュニケーションとは、顔を合わせてお互い会話するようなコミュニケーションのことです。
非同期というのは、相手の反応を待つことなく、メールのように投げておくことができるコミュニケーションのやり方を指します。
うまくいっているチームには、
- チャット
- メーリングリスト
- ドキュメント
- オンライン会議
- ノウハウページ
多数のコミュニケーションチャンネルが用意されています。
今ではメールを使わずにSlackなどのチャットツールを使うチームも増えてきたかもしれませんね。
社会人になりたての頃、先輩社員が一日に参加している会議があまりにも多いことにびっくりしていました。
一日の半分以上を会議に費やしている方もいて、日中は自席にはほとんど戻らず、会議に出るのが仕事なのかなと思っていました。
そうしたら、日が暮れてから自席に戻ってきて、それから自分の仕事を始めていたのです。
一日のほとんどを会議に参加して、日が暮れてからやっと、疲れた顔で自分の仕事を進める先輩を見て、本当にすごい人だと思いました。
なんでこんなに働けるんだよ...と。
とはいえ、ドラッカーが
「理想的な組織とは会議のない組織である」
と言っていたように、参加している会議が全て必須のようにはどうしても思えませんでした。
Team Geekではミーティングを開くときの５つのルールを紹介しています。
- 絶対に必要な人だけ呼ぶ
- アジェンダを作ってミーティング開始前に配布する
- ミーティングのゴールを達成したら時間前でも終了する
- ミーティングを順調に進める
- ミーティングの開始時間を強制的に中断される時間(お昼休みや就業時間)の前に設定する
重要なのは「ゴールの達成に必要な人だけをミーティングに招待する」ということです。
「なんとなく呼ばれた会議に多大な時間を費やす」
というのはよくあることです。
会議中にメールを読み出す人はどの会社にもいると思いますが、それに対して
「会議中はノートPCの使用禁止」
というルールを設定しても無駄です。
なぜなら、会議の参加者がメールを読み出すのは、そもそもミーティングに参加しなくてもいい人だからです。
絶対に必要な人だけを呼ぶ
という点を気をつけておけば、ノートPCで副業をする人はいなくなります。
ちなみにGoogleでは「木曜日はミーティングなし」という伝統があり、その日は仕事をするためだけに時間を使っているそうです。
ミーティングで作業を中断させられていたら、深い集中に入り込むことができません。
なので、３〜４時間のブロックを「クリエイターの時間」として、まとめて仕事を片付けることが推奨されています。
あと、これは僕の経験からも言えるのですが、ミーティング前に事前にアジェンダを作っておくことはとても大切です。
というのも、ミーティングに参加する全ての人の時間を節約できるからです。
何を話すのか、何を話さないのか。
ポイントは何か、ということをまとめておかないと、会議は簡単に方向に見失います。
あらかじめポイントを絞って、何のためのミーティングなのかを明確にすることで、短い時間で密度の濃い時間を過ごすことができます。
時間いっぱい使うのではなく、「会議は早く終われば早く終わるほどよい」という考え方をチームに浸透させていきたいな、と思っています。
失敗を恐れない
同じ失敗を繰り返さない限り、失敗することによって多くのことをすばやく学ぶことができます。
犯人探しや責任のなすりつけをしてはいけません。
Googleで失敗したときは、ポストモーテムと呼ばれるものを開催しています。
失敗につながった出来事を文書化して、同じ失敗を繰り返さないための手続きです。
失敗を批判するのではなく、失敗から学ぶために振り返りを行います。
失敗の責任を追求すると、チームは分裂し、リスクを取らなくなります。
僕が新人の頃に所属していたチームでは、マネージャーが失敗した人を吊し上げ、「なぜそんなミスをしたのか」を執拗に責めるような文化がありました。
人を責める文化が浸透してしまうと、チームは全くリスクを取らなくなります。
マネージャーの顔色を伺い、彼の許可なしでは何もしなくなり、自律心を失い、誰も新しいことを提案しなくなり、
「マネージャーに言われたことを怒られないようにこなす」
という奴隷のような働き方をするチームになっていたことを覚えています。
みんな死んだ魚のような目、怯えた子犬のような顔で仕事をしていました。
信頼・尊敬・謙虚のどれもが欠けていて、それゆえに人の目ばかりを気にする臆病なチームになっていました。
Team Geekでは、マネージャーのスタイルはあくまで「サーバントであること」が推奨されています。
「管理したくなる衝動」を抑え、チームに奉仕して、謙虚・尊敬・信頼（HRT）の雰囲気を作り出します。
「チームを良くするためにチームに尽くす」というのがリーダーに求められる姿勢です。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 作者:Brian W. Fitzpatrick,Ben Collins-Sussman
- 発売日: 2013/07/20
- メディア: 単行本（ソフトカバー）
