月曜日までに考えておきます

ITネタとゲームネタ中心に興味のあること色々書きます。

「Team Geek」読みました

身近なエンジニアの人達が面白いって言っているので、気になってはいたもののまだ読んでいなかった「Team Geek」をようやく買って読みました。

内容

エンジニア及びエンジニアのマネジメントをする立場向けの本ですね。とはいえ、技術的に難しい話はなく、謙虚・尊敬・信頼を持ってメンバーと接しよういうのが中心のメンタルに訴えかける感じの本ですね。私としては転職をしたこともあり、今は幸福な感じなんですが、これから生きていくのにつらくなったら読み返すべき内容がたくさんあるな、という感想を持ちました。

GoogleのエンジニアというすごいGeekな人たちの話になるものの、普通のエンジニアである自分が読んでも共感できる内容はたくさんありました。

特に良かったポイント

p.xxv 趣味(コンピュータで遊ぶこと)で生計を立てられることがわかった

なにげなくさらっと書いてあるんですが、いつの間に、(仕事で)コンピュータさわることが「今日も頑張ります!」みたいな感じなっちゃったのかなぁ、って考えさせられました。本当はコンピュータさわるの楽しくて仕方なかったのでこの仕事についたはずなので、初心を取り戻す必要があることを感じました。

P15. 三本柱

先程述べた謙虚・尊敬・信頼の話ですね。本書ではHumility, Respect, Trustの略でHRTという用語が何度も繰り返し出てきます。

p21. コードの否定の話

「君は君の書いたコードではない」という、指摘される側に向けたアドバイスが有りつつも、指摘する側に対しても「間違ってます」ではなく、「こうすればどうだろうか」とすべきという話が書いてあるのは良かったですね。つまり、「こんなひどいコードを書くのは間違いである!」&& 「コードの否定は人格否定ではない」というのを同じ人が考えているのはとてもまずくて、お互いのHRTが大事ということですね。

p47. 「ミーティング中はノートPCの使用禁止」みたいなことを言い出す人がいるが、それでは何も解決しない。メールを読み出すのは、おそらくミーティングに参加しなくてもいい人だからだ。

会議に呼ばれたので内職します VS ノートPCの使用禁止おじさんの夢の対決、よくある

  • p71,72. パフォーマンスの低い人への対処の話
  • p85. 建設的な批判の話
  • p89. 事を荒立てるときを知る

明らかに生産性が低い人やチームへの対処として静観してても改善されないし、やんわり伝えても改善されない、みたいな状況の時にどうすべきかということの悩みを前職の時に持っていたので、しっかりとなにが問題なのかを伝えるということをしていかないといけないなと認識しました。

p87. 誰かがやらなくてはいけない面倒で報われないタスクをまとめて表にして、チームに均等に割り当て

このやり方は参考になると思いました。特にエンジニアリングでいうと自動化で楽になろう、という話が流行ですが、どうしてもすぐには自動化できなくて手作業が必要な苦しい作業が残ってくるので、こういうのを均等にやるっていうのは大事だと思います。

p128. オフィスの政治家

こんな言葉知らなかったけど、たしかにこういう人いるなぁと思いました。

p136. 「攻撃的」な仕事と「防御的」な仕事

ひたすら技術的負債を気にせずにその場しのぎの汚い設計、コードで機能追加させるやり方と、リファクタリング疎結合に時間をかけきれいな設計を作りつつ顧客になんの価値も届けてないというどちらの状況も良くないですね。最近、「技術的負債」に関する話題が盛り上がってますが、自分もきれいな設計とビジネスの成功の因果関係は最近気になっていました。技術的負債の解消に関する仕事を「防御的」な仕事と定義し、それに労力の1/3〜1/2を掛けないという話を書いていました。この分量の話は考え方の参考になると感じました。

p145. 正しいことをして、解雇されるのを待とう。

正しいことをしていく、というのがキャリア戦略の話。

最近、会社を辞める話をした時に「大企業やめてベンチャー行って大丈夫か?」的なことをすごく聞かれたのですが、会社に縛られるキャリアではなく、ビジネスの成功のために技術的貢献ができるキャリアでありたいと考えて転職したので、この話はすごくしっくり来ました。

p160. ウェブページの読み込み

いきなりアカウント登録させるUXのダメさと、ウェブページの読み込み秒数を早くという話。 「遅い」と不満が出てから解消するのでは遅くて、継続的に観測して手を打っていかないといけないな、と感じました。

p170. ユーザの技術的能力が下がる話

アーリーアダプタとレイトマジョリティの話ですね。 ユーザが増えていくと既存のユーザはより進化した機能を求めますが、難しくしてしまうと新規ユーザの流入が止まってしまうというのは、成熟してきたソフトウェアにもありますし、ゲームの続編(特に音ゲーや格ゲーみたいなスキル求められるやつ)なんかにもある話だと思います。

まとめ

技術的にすごい何かが即効性で身に付くような本ではないですが、今後のエンジニア人生における考え方として共感できる部分が多いです。 前向きに働けるようになると思うのでぜひ読んでみてください。

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

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