Team Geekを読んで
タイトル通りだが、Team Geekという本を読んだ。（下記リンク）
Team Geek -Googleのギークたちはいかにしてチームを作るのか
この本の対象は、「ソフトウェア開発者、特に上昇志向の強い人や優れたソフトウェアを届けたい人」とのこと。
まあ、上昇志向がなければわざわざこの本は読まないと思う…。
内容は、チームで仕事をするにあたって、例を出しつつ、こういう風にするとよい、これはダメ、などが書かれている。確かに、プログラマだからといって技術だけを学べばいいわけではない。ソフトを開発している以上、チームで仕事することは多い。同僚のプログラマ、チームリーダー、他チーム、ユーザ、とにかく様々な人間とかかわって仕事をすることになる。また、自分の望みとは裏腹に、管理職になることもある。
この記事は、本の中から気になった点を抜粋した個人的なメモ。
1章、チームで仕事をすることについて
一人で仕事をするのはデメリットが多いという話。
・自分が正しい方向に進んでいるかがわからない
・他社の協力が得られないので、完成が遅れる
・コードの理解者が自分だけだと、自分が事故にあった場合にプロジェクトが終わってしまう
・チームで開発することで、みんなの知恵を使える
→大量のコードをすべて書き終えてからコンパイラに通すか？の例えが良いと思った。そんなことをしたら、ものすごい量のエラーやワーニングが出る可能性はとても大きい…。
・高速なフィードバックループが必要
→いわゆるアジャイル。
・チームで働くために、謙虚、尊敬、信頼（以下、HRT）が必要。
→自分の話を聞いてもらうには、まず相手の話を聞く必要がある。この本に限らず、様々な場面でこのようなアドバイスはされるが、相手の話を聞こうとしない人は結構多い…。
→また、自分の間違いや能力不足は認めて受け入れることも必要だが、なかなか難しい。自分が間違っていた、ごめんなさいとは言いづらいこともある。別ページにも記載されていたが、これができる上司はメンバーから信頼される。
2章、チーム文化について
・文化が重要である。（ただし、文化は進化、変化していく）
→チームがどこを重視しているか、どう働いているか、どう問題に取り組んでいるか、同やり取りをしているかなど。チームによって特色があるので、まずはそれを理解しなければいけないと思う。
・同期コミュニケーション（ミーティングなど）を減らし、非同期コミュニケーション（メールなど）を増やすこと。
→すべてを非同期にすればいいかというとそういうわけでもないので、このバランスは難しい。本書内でも別に触れられていたが、直接会って会話をすることも時には必要である。文章では理解しづらいこともあるし、顔を合わせることでほかにも何か会話が生まれたり、この人は必要な時にはしっかり会ってくれる人だと思ってもらえる。
・チームが目指すもの、目指さないものを明確にする。
→認識の違いを明らかにし、プロダクトの方向性を確認できる。ただし、変化は受け入れる必要がある。環境やビジネスが変わることもあるので、古いままではいけないと思う。
・ミーティングはうまく使えば効果的だが、時間の無駄にはしないようにする。関係者だけで議論すればよい。メールで済ませることも必要。
→先ほどの話と同じ。じゃあ、アジャイルのデイリースタンドアップミーティングは？と思ったが、それはOKらしい。１５分程度だから。
・ミーティングでメールを読みだす人がいた場合、それを禁止するのではない。
→よくいる。メールを読んでいたりスマホをいじっていたりして、この人なんで話聞いてないんだろう…いる意味なくない？と思うことがある。本書では、その人がミーティングに必要ないから別のことをしてしまう、と書かれていた。確かにそうである。不要なら、呼ばない、来ない、も必要かと思った。（でも、相手方が設定してきて、勝手にそのミーティングに来て暇そうにしている人もいる…）
・IMは、１：１で何でも気軽に聞ける。アホみたいな質問もできるが、共有知識が作られないので、何度も同じ質問をすることになり、チームの負担が増える。
→確かにそうだ。その知識を、メンバー全員が参照できるところに集約するべきだ。
3章、リーダーについて
・エンジニアはマネージャーになりたがらない。コードを書く時間が減るから。マネジメントの仕事は定量化して評価するのが難しいから。また、無能なマネージャにしかついたことがなければ、なりたいとは思えない。
・フィードバックと批判をオープンに受け止める
・ミスをしたときに謝る
・エンジニアが相談してきたとき、すぐに問題解決をしようとしがちだが、そうではなく、問題を整理したり調査したりして、エンジニア自身で問題解決できるように応援する
→エンジニアあがりのリーダーだと、たぶんリーダーが解決したがると思う。でもそうではなく、エンジニアが自分で解決できるよう、うまく導いてあげるリーダーがいたらすごいと思う。時間もかかるだろうし、リーダーがやったほうが早い…となってしまいそうで難しい。
・適切な答えを知るよりも、適切な人を知るほうが価値があることのほうが多い
→Aについてはこの人、Bについてはこの人、という風に、だれが何に詳しいのかを把握しておくことは重要だと思う。自分だけの知識や技術には限界があるから、必要な人を必要な場面で頼れるようにしたい。
・自分がチームをリードしようと考えていないくても、本書を読んでおくことでチームリーダーの行動を理解できる
→リーダーが何を考えて私たちと対話しようとしているのか、どのようにチームを動かそうとしているのかは理解しておいて損はないと思った。
4章、有害な人
・HRTが欠けているが、それが悪いことだと気づいていないか、そもそも気にしていない有害な人がいる。HRTがあって善意もある人でも、完ぺき主義は問題になる。ソフトの設計に時間をかけすぎるので、チームが停滞する。
・わざと怒らせてくる人は黙殺する。相手をしてもらえないと興味を失ってその場を去る。
→荒らしへの対応と同じだと思う。かまってもらえるとわかると、延々と攻撃してくる…。
・最終的には有害な人を追い出すことも必要。文化を守るほうが大切。
→追い出す前にも色々とできることはあるが、それでもどうしようもなくなったらこの手を取るしかないんだな～。
5章、組織について
・攻撃的な仕事（UIなどの改善）と防御的な仕事がある。目に見てわかりにくい防御的な仕事ばかりでは、政治的な信頼は獲得できない。
→防御的な仕事は、例えばちょっとしたパフォーマンスがよくなるとか、データの管理がきれいにできるとかそういう目に見えないことだと思う。エンジニアにとってはすごく意味のあるように思える改善だったとしても、それが目に見てわかりにくければ、上司や社内で評価されにくいとは思う。時には攻撃的な仕事もやらなければいけない。
6章、ユーザについて
・手を出しすぎない、万人受けを目指さない。
→これはとても重要だと思う。「色々できます、何でもできます！」は、もう何がなんだかわからない状態になってくるし、ユーザはそこまで望んでいないと思う。個人的には最近は家電やスマホに対してこう思うことが多い。そんな細かい設定をしたがるだろうか？そんなにボタンが必要だろうか？と思う…。余計なメニューやボタンは消し去ってほしい。
まとめ：チームに謙虚、信頼、尊敬の文化を育てる。サーバントリーダーとしてチームをリードする。ネガティブな影響からチームを守る。
→リーダーはチームの潤滑油（就活でよく聞く潤滑油…）であるぐらいがいいと思った。最近はよくサーバントリーダーが推されているのを聞く。流行っているのか？
