読者です 読者をやめる 読者になる 読者になる

書評:TeamGeek ~ Googleのギークたちは いかにしてチームを作るのか ~

書評

久しぶりの更新。ちょっとこの半年色々とあったのでそれは別の記事で。

www.amazon.co.jp

読んだ感想

チーム運用ってどこの会社でも苦悩するものだと思うんですよね。

この書籍では、

  • 個人が(リーダーとして)どう振る舞うか
  • リーダーシップ、チームワークとは何か
  • (チームや個人の)成果を上げる為の手法や工夫

Google流に書かれていて、外資系らしい内容であり、 日本人が気を使ってうまく出来ていない事が上手に説明されている気がした。

良書だと思ったので印象に残った部分の感想や、自分へのメモとして記していこうと思うます。

HRT

HRT:ハート:heart(心)

  • Humility(謙虚)
  • Respect(尊敬)
  • Trust(信頼)

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。

この本といえばこれ。人間関係ほんと大事。

私の妄想だとHRTを欠いたチームだとこうなる。

A「このコード糞アンド糞。なんでこんなコード書いたの?」
B「は?お前糞とか言ってるけど世界で一番いいコード書けんの?」
C「それマッツの前で言えんの?あ?」
D「てめぇこそバグばっか埋め込んでるしひっこんどけ!」

みたいになりがち。

言い方や伝え方も大事。

自分の書いたコードが全て正しいわけじゃないし、改善点もあるはず。

思った事をそのまま伝えていてもチームワークが良くなるとは限らない。むしろ悪くなる事が多かった気がする。

本書はこのHRTが何度も出現してきて事例と共に大事さを教えてくれる、そんな一冊。

コードの公開とチームワーク

プログラマには不安やプライドがあったりして、 プライベートリポジトリや、最初から書き直したい、完成するまで公開しないってなったりする。

機密情報としての価値があるならともかく、個人での作品なら

公開する事でクソコードだろうが人に見られて、指摘されて失敗しなくなるってのはもっともだと思う。

自分もバケツの中にゴミがたくさん溜まっていて、公開していれば誰かのレスポンスがあったりして継続して完成させるモチベーションになったのだろうか。

Googleはやっちゃえ!的なところを感じててこういう思想や文化があってソースコードの公開に踏み切るのかなぁと。

一人での作業はリスクが高い

「明日自分に何か起きても仕事は回るようにしておけ」なんて言葉を聞くのだけれど、個人のプロジェクトも複数人で作業すれば継続できるという事。

C言語を生み出したデニス・リッチー先生が亡くなってもC言語が滅びないように。

ソフトウェア開発はチームスポーツである。

これはすごく共感。

体力いるしね。人から学べるしチームワークのいいチームにいると仕事も楽しい、捗る。

失敗や間違えへの姿勢

失敗も選択肢の一つ

失敗時の教訓はとても大事。

失敗する事自体は誰にでもあるので、その後の行動が大事。

優れたポストモーテム(事後検証)にはこれが含まれるらしい。

  • 概要
  • イベントのタイムライン(調査開始から解決に至るまで)
  • イベントの根本原因
  • 影響と損害の評価
  • すぐに問題を解決するための行動一式
  • 再発を防止するための行動一式
  • 学習した教訓

謝罪不可症候群(最悪は死に至る)にでもかかってるのだろうかという人がたまにいるけど、大変だなと(他人事

謝り過ぎもよくないし謝ってはいけない立場の人もいるけれど、ほどほどに。

間違いや能力不足を認め、説明と責任を果たせば信頼され、尊敬されますよって事が書かれてる。

文化

文化はそれぞれのチームにあるし発展していく。

チーム文化を作る要素は色々あって、チームの文化は人を引きつける。逆も然り。

エンジニアに優れた仕事をしてもらうには、安全にアイデアを共有できて意思決定プロセスに口を挟めるような文化が必要。

合意のない仕事、降ってきた仕事だと、

「作りたくないもの作りたくないしね、仕事だからするけど。」

になるとクオリティの追求をしなかったりするだろうし。

目標の設定だけではなく、やらない事を定義する、強いチームと優秀なチームなど。

ミーティング

エンジニアはミーティングを必要悪と思っている。

私の場合はそうでもないけど、段取りよくして効率的、品質の高いミーティングにはしたい。

だらだらするのだめ、絶対。

新しいものを設計するのであればミーティングに5人以上参加させてはいけない

よくある、決まらなくなる。

技術的にこだわりだす人が複数いると終着点が見えなくなってくる事も多々ある。

ミーティングでの簡単なルールが書かれてた。

絶対に必要な人だけを呼ぶ
アジェンダを作って開始前に配布
ゴールを達成したら時間前でも終了
順調に進める
開始時間を強制的に中断される時間(休憩、終業)の前に設定する

私の経験した炎上プロジェクトではゴールの無いミーティングもたまに開催されてしまうので、 そういうに巻き込まれたらトイレと言ってで抜け出して自席に戻る方法がオススメ!

リーダーシップパターン

当然、コーディングするだけがリーダーの仕事じゃないのでどう振る舞うといいかが書かれてる。

チームメンバーと円滑にコミュニケーションしたり、目標や求めている事の共有ができてるとチームは幸せだし楽しいよね。

外のチーム(例えばマーケティング部など)ともうまくやりたいし、カオスからチームを守りたい。

メンバーの成長に必要なものってそれぞれ違うし、自律的に動けて自発的で興奮できる事のほうがより良い。

リーダーになる必要はないけど、リーダーに必要なものをわかっておくとリーダーとも付き合いやすくなるよって話。

まぁリーダーに求められるものもそれぞれの環境で違ってくるとは思うけれど可用性のありそうなベースを知れた事はよかったと思う。

有害な人への対処

チームの外部と内部にいる有害な人が最初に定義があり、有害な人というのは個人ではなく振る舞いであると説明される。

チームの注意と集中は有限なので浪費しないようどうするかって事から始まり、簡単な例を添えてアンチパターンが説明される。

アンチパターンは以下

  • 他人の時間を尊重しない
  • エゴ
  • 権利を与えすぎる
  • 未熟、複雑なコミュニケーション
  • パラノイア(被害妄想)
  • 完璧主義

その後、具体的な対処法

  • 完璧主義者には別の方向性を示す
  • 生命体にエサを与えない
  • 感情的にならない
  • 不機嫌の真実を探せ
  • 優しく追い出す
  • 諦めるときを知る
  • 長期的に考える

メモ的な要素が多く目次みたいになってしまった。

確かに自覚症状なく暴走する人もいたりで、私もそうなってしまっていた事も振り返ればある気がする。

なのでメモっておいてすぐ思い出せるように目次みたいにメモ。

組織との付き合い方やパターン

理想的なマネージャー(がいる場合)、悪いマネージャーの振る舞いとは何かがいくつかのパターンとして紹介されて、

組織、上司との付き合い方と働き方、そして逃げるという選択肢も挙げられてる。

もう少しここを詳しく知りたかったけどマネジメント側の内容は別の本で学ぼう。

ユーザーも人間

プロダクトと、ユーザーとの付き合い方や第三者(ユーザー)になって見るためにどうするか。

プロダクトの成長に対してできる事、考えどころなど。

ユーザーが増えると少ない時に比べて流入が増えると、ユーザーのサイトを操作する技術が平均的に落ちてきますよーとかグラフで書かれてたり。

あとは機能が増えてくけど単に増やすだけだとユーザーは戸惑うから隠蔽しよう!みたいな事とか。

確かにどこかのタイミングで行動しないと機能の追加追加では破綻して使いにくくなってく。

数年に一回ぐらい大幅リニューアルできればいいのになぁ(予算が・・負の遺産が・・バグが・・

目的はユーザーに使ってもらう事、プロダクトを届ける事を忘れないように心がけたい。


最後に

目次だけでも結構面白いと思うけどアマゾンで目次まで公開されていないのね。

ソフトウェア開発って、かなり多くの部分で人間関係が大事だと思うので、HRTを定期的に思い出して大切にしたく思う。

いい本だしチームワークとか自分の振る舞いが気になる人にはオススメできる気がする。

事例を添えての説明が多く、技術的な話はそんなに出てこない。

かなり読みやすく、エンジニアじゃなくても読んで損しないのでは?と思うぐらいですた。