読んだ本
Team Geek
結論
- 読んでよかった
- ストーリーベースの内容で非常に読みやすい
- ページ数が少ないので気楽に読める
- Googleの中の人によって書かれており、トップレベルの組織におけるエピソードが知れる
- 三本柱（謙虚、尊敬、信頼）が原則
読もうと思った経緯
名前だけは以前から聞いたことがある本でした。現職で開発チームにおけるスクラムマスターなどを目指す過程として、開発組織でエンジニアをリード、マネジメントすることの難しさと心構えを知りたいと思い、読もうと思いました。あとはGoogleのことが書かれているというのも聞いていたので、単純に内容が面白そうだなーという気持ちも後押しました。
読んだ感想
ざっくりとは最初の結論の通りですが、もう少し詳細に書いてみます。
読みやすい
基本的に筆者や筆者の周囲の人がGoogleやそれ以前の職場で実際に体験した経験談をベースに書かれています。そのため内容が頭に入ってきやすいですし、読んでて楽しいです。
また、ページ数が200ページ以下と少ないのでそれほど時間がかからず読み終わります。多すぎると読む前に絶望しがちなので気楽に読めて良いです。
エンジニア組織に限らず適用できる
本書はエンジニア組織における考えとして書かれていますが、内容はどの組織においても、組織以外の人間関係に関しても適用できる内容になっています。原則は三本柱である謙虚、尊敬、信頼です 。これが欠けると能力のあるメンバーが多くいても仕事がうまく行くことはないです。
また、人間という不確実性に向き合う勇気を貰える内容になっていると思います。
エンジニアなら共感できるあるあるがたくさん
読んでいて「あ〜分かる〜」と思うポイントが複数ありました。
天才を崇拝し、自分もそう なりたいと思う
エンジニア界で名前の知れた偉人達は、多くの人に慕われ尊敬されています。能力があり実績を残してきた人達です。多くのエンジニアが彼らのようになりたいと思うものです。私も思います。でも、それらの人達でさえ、実際には組織やチームとして行動して大きな成果を残してきたのです。
完成するまで隠したくなる
中途半端なものを見せるのは多くのエンジニアにとって恐ろしいことに感じるはずです。より短く、より的確に、より安全に書けるのではないかと指摘される恐怖がつきまとうからです。でもそれらはより早く指摘される方が良いことなのです。コードが指摘を受けることは、コードを書いたエンジニア自身が否定されることにはならないのです。
知らないことを悟られたくない
これも前述の話と似ています。無知であると思われなくない心理は多くの人にあります。そのために必要な確認を怠り、正確な仕事をすることを妨げることはよくあることです。メンバーの多くがこの心理に陥っているチームは悲惨な状態になります。
リーダーの共感できるあるあるもたくさん
リーダー目線でも読んでいて「あ〜分かる〜」と思うポイントが複数ありました。
チームメンバーを子ども扱いする
子ども扱いというと極端な言い方かも知れないですが、メンバーを信頼せずマイクロマネジメントをしようとするのはよくあることです。私も近いことをやってしまっていたことがあります。信頼されなければメンバーのモチベーションも下がっていきます。
なお、信頼できないメンバーの場合は採用を間違えています。
リーダーなのに答えを積極的に提示する
メンバーが悩んでいる時、相談に乗ることは多くあります。自身もエンジニア経験があればすぐ問題解決モードに入 ってしまいがちです。でも、本当に良いリーダーになりたいなら、メンバーが答えを出しやすいように支援することに注力するべきです。
メンバーに隠し事をする
立場上話せないこと、話しにくいことはあるものです。それをうやむやにしたり、下手に誤魔化そうとすべきではないです。話せないなら話せない、話しにくいなら話しにくいと正直に言えば良いです。
また、リーダーとして振る舞わないといけないと思うと、つい弱みを見せたくないと思うものです。でも、メンバーはそれほど気にしていませんし、むしろ開示することは信頼を得ることにつながります。
具体的な実践的な提案が書かれている
本書が一番に伝えたいことは抽象的なマインドセットになると思いますが、すぐに実践できる具体的な行動例が多く記述されています。
- コミュニケーションの取り方
- ミーティングの取り扱い
- コードでのコメント、レビュー、リリースに対する取り組み方
- リーダーシップのパターン、アンチパターン
- 「有害」への向き合い方
おわり
分かっていても実践が難しい部分も多いなーと感じます。一回読んで満足せずに、定期的に現状と照らし合わせるために読み返したい本だと感じました。
とりあえず本を読んだ感想シリーズの2つ目を書けて満足。
