Team Geekの読書メモ

ふと本棚にあった『Team Geek』を読み直したので気になった言葉を残しておきます。

前に読んだもののすっかり忘れてしまっていて新鮮な気持ちで読むことができました。

（なので次はすぐ振り替えれるようにメモをまとめておくことにしました）

特に本書全体を通して何度も登場した HRT はこの本で一番大事なことだと思うので、常に心がけていきたいものです。

大事な3つの原則（HRT）

ソーシャルスキルの三本柱（それぞれの頭文字を取ってHRTと呼ぶ）

1. 謙虚：Humility

世界の中心は君ではない。 君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。

2. 尊敬：Respect

一緒に働く人のことを心から思いやろう。 相手を一人の人間として扱い、その能力や功績を高く評価しよう。

3. 信頼：Trust

自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば、仕事を任せることができる。

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

ミッションステートメントについて

何を作り上げるのかを暗黙の了解にするのではなく、常に思い起こせるようなシンプルな形で書き起こしたものがミッションステートメントだ

本書のミッションステートメントは以下

本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。

「 誰のために 」、「 何のために 」が明確になっていて分かりやすいですね。

ポストモーテム

同じ過ちを繰り返さないための仕組み

過ちから学ぶには、失敗を文書化することである

1. 概要
2. イベントのタイムライン
3. イベントの根本原因
4. 影響と損害の評価
5. すぐに問題を解決するための行動一式
6. 再発を防止するための行動一式
7. 学習した教訓

これをテンプレート化して、失敗時にはチームですぐ共有できるようにしておきたいです。

リーダーのためのアンチパターン

• 自分の言いなりになる人を採用する
• パフォーマンスの低い人を無視する
  • 解決策：小さな目標を立てて少しずつ進捗を出していく
• 人間の問題を無視する
• みんなの友達になる
• 採用を妥協する
• チームを子どもとして扱う

リーダーシップパターン

• エゴをなくす
• 禅マスターになる

エンジニアが相談を持ちかけるのは、君に問題解決をして欲しいからではない。彼が問題解決するのを手伝ってほしいからだ。そのためには、彼に質問をすればいい。

• 触媒になる

多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある

• 先生やメンターになる
• 目標を明確にする
• 正直になる
• 幸せを追い求める

3つの箇条書きと行動要請

問題について説明する最大3つの箇条書きと、1つだけの行動要請に絞ると、表現がシンプルになり忙しい人でも反応してくれやすくなる

その他 惹かれた言葉たち

1章：天才プログラマの神話

優れたコードを書くだけではプロジェクトは成功しない 最終目標に向かってみんなが協力することが重要なのである

「人間は断続的なバグの大きな塊だ」

人間は本質的に不完全である。だが、他人のバグを理解する前に、君自身のバグを理解しなければいけない。

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

高速なフィードバックループは、コードレベルだけでなくプロジェクトレベルにも必要だ

謙虚になるにはエゴをなくす

プロのソフトウェアエンジニアリングの世界では、批判は個人的なものではなく、優れたプロダクトを作るためのプロセスの一部にすぎない。

建設的な批判をする人は、心から他人を思いやり、成果を改善して欲しいと願っている。 同僚を尊敬し、建設的な批判の方法を学ぼう。

自分のスキルに謙虚になるだけでなく、他の人があなたに恩恵をもたらしてくれると心から信頼し、自分がバカだと思わないことである。 プログラミングはスキルなので、練習すれば向上する。

自分の価値を自分の書いたコードと結びつけてはいけない。繰り返しになるが、君は君の書いたコードではない。大事なことなので何度でも言うが、君は君の書いたコードではない。君がそう思うだけでなく、同僚にもそう思ってもらうようにしよう。

相手に対する疑問ではなく、自分の疑問として謙虚に聞くのである。

失敗は選択肢の一つ（Googleの社是）

一流プレーヤーを目指すことは簡単だが、方向性を変えてあたらしいことに挑戦するには、エゴを捨てなければいけない。 謙虚になって、誰かに教えるのと同じくらい自分でも学ぶようにする。コンフォートゾーンの外側に自分の身を置くのである。

ときには「わからない」と言うことが大切なのだ。

2章：素晴らしいチーム文化を作る

チームの文化を作る要素はさまざまだ。コードレビュー、テスト駆動開発、事前の設計書のようにソフトウェアに関係するものもあれば、毎週木曜日のランチには決まったレストランに行ったり、金曜日には行きつけのバーに飲みに行ったりするような、人間関係にまつわるものもある。部外者にはアホみたいに思えたり、意味不明だったりするものもあるかもしれない。 （中略） こうしたことがチームの文化を作り、チームの生産性やメンバーの定着に影響を与えるのである。

チームが大切にしている文化を守ることが重要だ。チームが文化を大切にできなければ、チームのアイデンティティや仕事の誇りを作り出せないだけでなく、新来者がクソみたいな文化に簡単に変えてしまう。 エンジニアは、チームリーダーがチームの文化を作ると勘違いしている。これは真実とはほど遠い。 （中略） チームの文化の定義、維持、防御に責任を持つのはチームメンバーだ。

強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的だ。 優れたチームの文化は、ソフトウェアを届けることに集中している。

エンジニアはコミュニケーションをできるだけ排除して、コードを書かなければいけないと考えている。しかし、チームが合意していなかったり、情報が伝わっていなかったりすると、君が正しいコードを書いているという保証はない。 （中略） みんながチームの方向性に同意して、すべてを正確に理解するには、相当な手間が必要となる。だが、こうした手間は生産性の向上とチームの幸せのために必要な投資だ。

コミュニケーションの原則は、同期コミュニケーションの人数を減らし、非同期コミュニケーションの人数を増やすことである。できるだけ多くの人が、プロジェクトの文章からすべての情報を取得できることが重要だ。

新しいプロジェクトが始まると、すぐにコードを書きたくなる。こうした衝動を抑えるのは難しい。だが、それではうまくいくはずがない（適当なプロトタイプをかき集めることになる）

設計文章は、通常は一人の人間が所持するものである。 それを大勢の人たちがレビューして、2〜3人の人間が承認する。

コメントはコードのなぜを説明するものであり、コードが何をしているかを説明するものではない。

3章：船にはキャプテンが必要

伝統的なマネージャはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考える。（どうやって仕事を完了させるかはチームに考えてもらう）

「マネジメント」病の治療法は「サーバントリーダーシップ」である。 マネージャの役割として最も重要なのは、執事や召使のようにチームに奉仕することだ。 サーバントリーダーとして、謙虚・尊敬・信頼（HRT）の雰囲気を作り出さなければいけない。

自らの手を汚すのがサーバントリーダーだ。 サーバントリーダーが管理するのは、技術的な側面とチームの人間関係である。 両方やらなくっちゃあならないってのが「サーバントリーダー」のつらいところだな（人間関係のほうが難しい！）

人は植物 日光を必要とする人もいれば、水を必要とする人もいる リーダーとしての仕事は、どのエンジニアが何を必要としているかを把握して、それを与えることだ

5章：組織的操作の技法

リスクをとろう。失敗を恐れるな。

年に一回でも失敗していないようなら、それはリスクを取っていないのである。

幸せな家庭は同じようなものだが、不幸な家庭にはそれぞれの不幸の形がある（レフ・トルストイ『アンナ・カレーニナ』）

道がないなら道を作る

悪い習慣をやめることはできない。よい習慣と置き換えなければいけない。

6章：ユーザーも人間

ユーザーに集中すれば、他のことはすべてついてくる（Googleのモットー）

いろいろ手を出さない 成功しているソフトウェアというのは、問題を限定してそれをうまく解決したものだ。 あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題をうまく解決しているのである。

ソフトウェアはトースターだと思ってほしい。 トースターはなんでも調理できるだろうか？ そんなことはない。 でも、多くの食材を調理できるし、ほぼすべての人が使える。 機能が多すぎて圧倒されることもない。 トースターを作ろう。Less is more.

読みながら適当にメモしていた言葉を載せただけでも結構な量になってしまいました。

本書に書かれていた内容をチーム全員が実行できればたしかに強いチームになれそうです。

「 まずは自分から 」ということで定期的にメモした言葉を振り返って実践していきます。

本書には他にもたくさんの言葉が詰まっていたので、チーム作りに興味がある方はぜひ読んでみてください。