読書感想文 #13 TeamGeek Googleのギークたちはいかにしてチームを作るのか

今回読書したのは「TeamGeek Googleのギークたちはいかにしてチームを作るのか」です。

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

例によって例の如くメルカリによってお安く手に入れました。

1章：全ての問題を解決してしまう,「天才プログラマ」は存在しない.

人は何かしらの偶像を信仰したいものである.
自分の間違いを指摘されることを恐れる.
早い段階でフィードバックを受けることは重要である.
バス係数…その物事を把握している人数の合計
それに伴ってエンジニアのオフィス環境も変化してきた.昔は個室に篭っていたら,今はやりとりが必要なので仕切りのない部屋で作業をしている.そして話しかけて欲しくないときには合図をしておく.
一人の人間ができることには限界があるので,何かを成し遂げたいとおもうのならば,誰かと協力してチームとしての成果を上げなければならない.

良いチームを作るための三原則
謙虚・尊敬・信頼
これが欠けてしまうと,人間関係において衝突してしまう.

常に謙虚な組織であるために,自分自身や身の回りでエゴを働かせている人がいないかを確かめる.また,他人のエゴによって自分が無駄な労力を払わなくても済むようにする.

批判をする際にも細心の注意を払う.自分が正しいと意見を通すだけではなく,指摘をされた人の自尊心が傷つかないようにする.

「あなた」と「あなたが書いたコード」は異なる.

早い段階で失敗.学習.反復を行う.

成長の余白を残す.担当する領域が限られ,その分野の第一人者になってしまうと向上心が働かなくなってしまい満足度が減少する.
なので,より成長し続けることができる環境を整える.

自分の弱さを見せることが強さである.強い人間は他人に弱い部分も曝け出すことができる.

2章：良いチーム運用が大事

美味しいパンを作るためにはイースト菌と乳酸菌の分量が大事なことと同じように,新参者によって組織の文化がどのように変化するのか,ということも良いチームを作る上では重要なことである.

Googleの採用においても,技術の面以外に文化の面でチームに溶け込むことができるかを判断している.

優秀なエンジニアを採用は優秀なエンジニアと一緒に働きたいと考えているので,まずは優秀なエンジニアを確保しなければならない.
そのとき,優秀なエンジニアは自分自身の手によってプロジェクトをドライブしたがることから,そのようにメンバーにある程度任せることができる文化が必要である.

エンジニアが正しい製品を作れているかどうかを確かめるために,コミュニケーションを絶やさないことが欠かせない.ミーティングを同期コミュニケーション,メールを非同期コミュニケーションという.

チームのミッションステイトメントを決めておくことによって,何をやるか(やらないか)の判断ができるようになる.また,向かうべき方向性も知ることができるので,無駄な時間を削減することができる.

会議は短時間に,関係のない話が始まったら誰かが仕切らないと収集がつかない.

ミーティングを開くときの5原則

1.必要最低限の参加人数.
2.アジェンダを事前に配布.
3.ゴールを達成したら時間前でも終了.
4.順調に進める.
5.開始時間を強制的に終われる時間の前に設定(お昼や退勤時間前).

リモート環境で仕事をしていても,顔を合わせる時間を定期的に設ける.

作業に取り掛かるまえに,設計書を作成する.ただし,作業の効率を下げる場合には不要.

チャットはできるだけ全体で話し合う.同様の疑問に対して何度も返事をしたりしないためである.

コードに名前をつけたりしない.多くの人が触れる可能性があるからだ.

3章：誰からチームの舵取りになる必要がある

誰かがプロジェクトのリーダーになる必要がある.

リーダーはメンバーを信頼する必要があるし,メンバーはその期待を良いプレッシャーとしなければならない.

人々は無能なマネージャーと出会ったことはあるので,自分も無能になりたくない,という思いからマネージャーになりたがらない.

マネージャーはチームの執事のように振る舞う.

パフォーマンスが低い人に対しての対応は早めに行わなければならない.彼らは自分からその席を離れようとはせずに,逆に周りの優秀な人たちから席から離れようとしてしまう.
そんな彼に対しては常に働きかけることによって,彼が「成長したい」のか「単に仕事をしていないのか」を見極める必要がある.

友人関係とマネージャーの関係を混同してはいけない.どちらも切り離して考えることができる.

いくら人数が必要だからと言って,必要なレベル以下の人材を採用してはいけない.

エンジニアに相談をされた時にはその問題の整理をしてあげることによって彼が問題を解決する手助けをする.

リーダーの人脈が広ければ,そのチーム内で解決できなかった問題を解決できるような人とコンタクトを取ることが可能になる.

失敗をしても良いことをチームメンバーに適切に伝える.

問題は,「解決しなければならない時」が必ずやってくるものである.

やり直しが可能なことであれば,新しい挑戦であろうと許可をする.

個人によって居心地のよい環境は異なる.
そのために大まかに「モチベーション」と「方向性」に分けてそれぞれにあった対応策を提示するようにする.

4章：有害な人に対応する

・他人の時間を尊重しない例.まずは自分で調べられる範囲での検索などを行う.

・問題は「正誤」だけでなく,「答えを出せるのか」も大事な要件である.

・完璧主義者はチームの作業の停滞を招くため,適切な方向性を示してあげることが必要.

・悪意には反応しない.反応することはエサを与えることに等しい.

知らないだけの人を悪として扱わないようにする.

5章：会社の中で「うまくやる」方法

理想的な組織のおいては,期待以上の成果を上げることを意識する.
さらに物分かりの良いマネージャーがいる環境であれば,失敗を積むことが可能である.
これによってさらに大きな仕事を任せてもらえるような可能性が増える.
コミュニケーションは「とりすぎる」ことはない.

失敗に対する不安を抱えているマネージャーは「悪い」マネージャーとして映りやすい.

・道がないことを嘆くのではなく,自ら道を作る.

・言われたことをただこなすだけではなく,自分で機転を利かせたり,アイディアを持ちながら取り組むようにする.

・自分がポジションを取れる場所を見つけ,その場所で価値を発揮することによって信頼を獲得することができる.

・「3つの箇条書きと行動要請」のテクニック

問題点を3点以内で簡潔に書くならべ,それによって相手に求める行動を最後に記載する

・正しい行いをして,解雇されるのを待ち続けるしかない.
解雇されたのなら,雇用主を間違えたことと同義である.

6章

良いソフトウェアは他人に「幸せ」を提供しなければ「良い」とは言えない.

相手に選んでもらうようなプロダクトを開発することが必要である.

使用した場合の最初の1分間の感覚が重要である.

本質的な価値よりも,それを利用する人々がどのように評価をするか,などの方が大事.

実際に利用者数を把握することが必要である.

ユーザーは言いたいことを言うだけだが,それを傾聴していることが重要である.

ユーザーからの信頼が重要である.

感想

まずは文章がクレイジーで面白いという印象を受けました.

訳者のあとがきの中でも「理解できなかった箇所があった」と書かれていたので,原文はもっとイカれているのでしょう(良い意味で).

全体を通じて

・求められるものを作らないと,エンジニアとしての価値はないということ.
・良いものは,良い文化,良い組織,良いチームから生まれる.

ということを痛感しました.

全てが一人で解決できる問題ではないので,どうにかしてお互いに協力をしてうまくやっていかなければならない.

本質的な価値も重要だが,実際にプロジェクトを走らせて何かしらの成果物を作らなければならない.

といった,言われたら当たり前ではあるが,普段は忘れてしまってるようなことが盛り沢山でした.

きっとこうした内容が前提知識として存在しているため,組織として良い文化や雰囲気が生まれて成果につながっているのだなと感じました.

また,メンバーのエネルギーを無駄遣いしてしまう人への対処法なども書かれていて,自分がその場面に出くわした時には使おうと思います.

なんだか陳腐な感想文になって面白くないですね.

とりあえず,「みんなを幸せにする」ために,限られた時間とリソースの中で全力を尽くそうぜ!イェイ！

みたいなノリでGoogleという会社で働いている人がいることがわかりました.