Team Geek ―Googleのギークたちはいかにしてチームを作るのか
概要
目的
オススメされたので読んでみる。
経験だけでチーム活動をしているので、体系的に学びたい。
目標
チーム活動で活かせるものを見つける。
総評
少し前の本だが、今でも現役で通じるところが多いと感じた。
リーダーに急になったときの振る舞い方は参考になるし、有害な振る舞いを正すところは目からうろこだった。
真の意味で他者向き合うためには、ネガティブなフィードバックが大切なんじゃないかと思ってきた。
ピックアップ
1章 天才プログラマの神話
- コードは隠さない
- HRT（謙虚・尊敬・信頼） の2点が刺さった。
コードは隠さない
これは結構大事だと思う。
冗長かもしれないが、自分は一日の実装が終わったら、コードをプッシュするようにしている。
いつでも引き継ぎができることを意識して。
GitHubにDraftがあるので、気軽にPRを作って、作業状況を可視化するのあり。 Draftの時点で、コメントで認識違いを気づけるし、積極的に使っていきたい。
HRT
個人としては「君は君の書いたコードじゃない」という所が刺さった。
相手にそう思わせる指摘をしたり、自分もそう思っちゃう時があった。
コードレビューするときは言い回しに気をつけたいところ。
2章 素晴らしいチーム文化をつくる
- 文化
- コミュニケーション がこの章のポイントと感じた。
文化
チームには強い文化が必要で、それがないと新参者が入ったときに、その新参者が持ち込む菌に耐えられないと。
サッカーが好きなので、サッカーで例える。 レアル・マドリーにはマドリディスモという文化があり、それは人が変わったとしても受け継がれている。
エンジニアチームも同じなんだろうなと理解した。 変化の受け入れはもちろん必要だけど、慎重にやるべしといったところか。
新参者…というわけではないが、自分たちはコロコロ実装方針を変えてしまっているところがある。 それは新しい人が入りづらくなるし、リポジトリもカオスになってしまっている。
まずは今いるメンバーで文化を整えるのが大事と思った。
コミュニケーション
MTG
自分も本書の記載にある「エンジニアはMTGが嫌い」に該当する。 これは本書である通り、アジェンダがまとまっておらず、何を話すか決まっていないのが大きい。
議論
自分たちのチームはよく議論をするが、それがドキュメントにまとめられる事は少ない。 「スクラムでコミュニケーションを重視する」といえば聞こえが良いが、空中に霧散して、「どうなったっけ？」 となることも少ない。
議論したものについて、ドキュメント化して、霧散しないようにしたい。
3章 船にはキャプテンが必要
本章はなんとなくエンジニアからリーダーになってしまった人に向けたものだ
上記に書かれているように、いきなりリーダーになった人向けの内容となっている。
エンジニアがマネージャーになることを嫌がる1つに、コードを書くこと = 仕事していること
上記は去年スクラムマスターになってみて実感した。
今までコードを書くことが仕事だったが、コードを明確なアウトプットが期待できるので手応えがある。 しかし、スクラムマスターでチームビルディングとかを業務にすると、明確なアウトプットが無いことが往々にしてあるため、手応えがないことが続いた。
自分の仕事を測る指標が変わったことは意識する必要があったな。
アンチパターン
- パフォーマンスが低い人を無視する
- みんなの友だちになる
- メンバーを子供として扱う
ここを読んで、他者と他者のキャリアに、ちゃんと向き合うことが大切なんじゃないかと思ってきた。
ポジティブフィードバックだけじゃなく、ネガティブフィードバックもできること。向き合うってそういうことだよなと。
4章 有害な人に対処する
「有害な人」とタイトルは銘打ってあるが、正しくは「有害な振る舞いをする人」である。
振る舞いは正すことが出来るので、その対処方法が書かれている。
「有害な振る舞いをする人は、自分のアクションが有害だと気づいていないので、まずは気づきを与えよう」と書かれているように感じた。
長期的に考えるという部分が大事だと感じた。
ここでは、短期的なメリットを得ることで、長期的にデメリットになることを防ごうと書いてある。
※成熟した文化を壊す必要がないという意味
これは確かにそうだなと思っていて、「リリース優先」と言われると現場猫してしまうが、それが長期的には良くない結果になると思う。
勿論バランスなんだが、「長期的にどうか？」というのは頭に置いておくべきだろう。
5章 組織的操作の技法
理想のチームにしていくために、組織の中でどうやって振る舞っていくかを書いてある。
所謂「社内政治」に触れていたり、何をやっても改善しない場合は「逃げる」ことも述べられていたり、こういった本では語られない部分がある印象。
「攻撃的な」仕事と「防御的な」仕事は参考になった。
ここでは、ビジネス貢献のあるものを「攻撃的」、リファクタリングといったユーザ貢献が少なくみえるものを「防御的」と呼んでいる。
防御的な仕事は大事だが、そればっかりあるとビジネス貢献をしていないように見えるので、攻撃的な仕事とバランスを取る必要があると述べられている。
ちょうど自分たちの部署は毎月10%は保守に割く方針をとっているので、アプローチは近いなと思った。
6章 ユーザも人間
対ユーザの話。
ユーザを意識しないと良いソフトウェアは作れない。
複雑さを隠すという章が印象的。
ユーザが楽にできることを意識すると、コードが複雑になることがある。
そういった部分に自分は消極的であったが、たくさんユーザに使われるものを作ろうとしたら、そういうことを意識する必要があると考え直した。
