同僚に借りて読んだ。
ソフトウェア開発者を対象に、チームのなかでどのように振る舞うべきか、どのようなチームにしていけばいいのか、チームを守るために何をすべきか、チームリーダーの役割とは、といったものを説いていく。
非常に有名な本で、自分もタイトルだけは知っていた。
本書で紹介されているHRT（謙虚、尊敬、信頼）という概念も有名で、求人ページの「求める資質」でHRTが挙げられることもある。
翻訳が上手く、ページ数も少ないので手軽に読める。
有名な本ではあるが、「人に親切にしろ」「正しく振る舞え」といったことを主張してくるようなものをイメージしていて、あまり興味がなかった。
「義務」を説いたり、「チームのために身を粉にしろ」と主張したりして、「プログラマとしての在るべき姿」を主張しているのだと思っていた。
だが実際はそうではなく、あくまでも自分（やチーム）が幸福になるためというスタンスで書かれており、意外だった。
「こうすべき」という振る舞いが色々と書かれているが、それは何も品行方正になれということではなく、それをやることで成功や幸福に近づけるからやりましょうというロジック。
本書に書かれてあるのは面倒くさいこと、大変なことばかりだが、好きなこと（ソフトウェア開発）に多くの時間を割くためにはこれがベストだという。
HRTをベースにした振る舞いを心がければ、社内政治や衝突や人間ドラマに時間を割かずに済む。
成功するためにも、コミュニケーションやチームワークは重要になる。
ソフトウェア開発はチームスポーツであり、それが生産性や効率性を左右するから。
プログラマが、幸福や成功のために重要な「他人とのコミュニケーションやコラボレーションの能力」を高めることが、本書の目的。
しかしそうは言っても、本書の内容はなかなか実践できるものではない。
自分さえ頑張ればどうにかなるものでもない。
言っていることは分かるが現実的ではないのではと思っていたが、翻訳者のインタビュー記事を読んで納得できたかもしれない。
もし相手を信頼できなかったとしても、それをそのまま口に出して言う必要はないですよね。心の中で思うのは自由だけど、仕事としては割り切ってHRTやりましょうっていうことだと思います。
天才でなくていい！『Team Geek』訳者・角 征典と考える、チームに貢献するエンジニアの気配り力 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
HRTを、仕事のためのスキル、仕事を円滑に進めるためのインターフェイスと捉えている。
確かに「HRTを大切にしよう」と無理をするより、「仕事の一環としてのHRT」と割り切ったほうが、自分の中で受け入れやすいかもしれない。
以下、各章のメモ。
1章
- 偉大な仕事は一人では出来ない
- リーナス・トーバルズは一人でLinuxを作ったのではない
- 成功を手にするためには他者との協業が必須。我々は一人でなんでも成し遂げられる天才ではないのだから。
- 一人で仕事をするのはリスクが高い
- 間違いに気付かない、気付くのに時間がかかる
- スピードも遅い
- ソフトウェア開発はチームスポーツであり、成功の鍵は高機能なチームにある
- チームで働く時の原則はHRT。謙虚、尊敬、信頼。
- まずは自分自身がそれを実践し、それをチーム、組織、ユーザーへと、広げていく
- 相手を尊敬し建設的な批判をすることが大切。自分だけではなくチーム全員がそれを理解していないといけない。
- 自分の書いたコードと、自分の人格を、切り分ける。これは自分に対してそう考えるべきだし、他者に対してもそう考える。人格とコードは別。
- 議論しているのはコードのことであり、誰かのコーディングスキルや価値のことではない
- 尊敬が欠けている指摘は、相手を感情的にさせ、必要以上に防御的にしてしまう。誰も得しない。
- 過ちから学ぶためには、失敗を文書化することが大切。ポストモーテム。
- これは、謝罪や言い訳を羅列するものではない。何を学んだか、何を変更するか、を書く。
- 間違いや能力不足を認め、弱さを見せることで、長期的には立場は向上する。尊敬を得られる。
2章
- メンバーがチームの方向性を正確に理解するためには手間がかかるが、チームの生産性や幸福のためには必要な投資
- ミーティングなどの同期的なコミュニケーションではなく、メールなどの非同期なコミュニケーションを増やすのが原則
- ドキュメントから全ての情報を得られるようにすべき
- ミッションステートメントを定めて、プロダクトのスコープを制限する
- 集中するためには、何をやらないか決めるのが大事なのだから
- 何をどうしたいのか書いた設計文書。それが、優れたプロダクトや実装につながる。
- 設計文書は、プロジェクトの進行に合わせて変化していくべき
- 議論のアーカイブがどこかにあることで、検索可能になる
3章
- リーダーはチームのために道をつくり、チームの安全・安心に気を配る。全てはチームのニーズを満たすため。
- サーバントリーダー。リーダーは、執事や召使いのようにチームに奉仕する。
- 人は、自分が扱われるように振る舞う。そのため、メンバーを子供や囚人のように扱えば、彼らはそのように振る舞う。
- チームの合意形成や方向性の決定を支援するのが、リーダーの役割。目標の達成方法は、プロダクトを作る人たちが決める。
- メンバーに相談されたら、リーダーはメンバーの代わりに問題解決するのではなく、メンバーが問題解決できるように手伝う。そのためには質問することで問題を整理するのが有効。
- リーダーは障害を取り除くための答えを知っている必要はなく、取り除ける人を知っていることに価値がある
- チームに安心感を与えてリスクを取れるようにすべき。そうすることで成功率が高まる。
- 安心感を育てるためには、失敗を許容することが大切。個人ではなくチームとして失敗し、そこから学んでいく。
- チームの方向性と目標を明確にして、あとは自律性に任せる
- エンジニアによって必要なものは異なる。それを把握することが大切。
- 内発的動機には、自律性、熟達、目的の3つが必要。給料に不満がないという前提だが。
- プロダクトオーナーシップを感じることが出来れば、モチベーションにつながる
4章
- 本書では分かりやすさのために「有害な人」という言葉を使っているが、排除すべきは「有害な振る舞い」であって人ではない
- 好ましくない振る舞いが続けば、生産性が落ちるだけでなく、チームの文化そのものが悪化していく
- 有害な振る舞いは、チームから注意と集中という貴重なリソースを奪う。ソフトウェア以外のことにそれらを浪費させられてしまう。
- 貴方の仕事は優れたソフトウェアを作ることで、訪問者の機嫌を取ったり自分のこれまでの行為を正当化したりすることではない。
5章
- 悪いマネージャーの特性
- 失敗を恐れ、リスクを回避する
- 自分の立場や地位のために情報やコミュニケーションチャネルを占有しようとする
- 組織内で戦うときは、勝てる見込みのある重要な争いを選択する。勝てない争いで社内政治のための資本（政治資本）を消費してはいけない。
- エンジニアはプロダクトのローンチにエネルギーを注ぐべき。ローンチこそが、信頼、名声、政治資本の増加につながる。
- 仕事には、UIの改善などユーザーに見える「攻撃的な仕事」と、リファクタリングなどの「防御的な仕事」がある。
- 「防御的な仕事」はいくらやっても評価されず、そればかり行うのは政治的な自殺行為。最悪の場合、プロジェクト自体が中止に追い込まれてしまうかもしれない。
- 積極的に人に親切にすると、自分に返ってくる
- 昇進することで、自分の運命をコントロールできる度合いが高まる
- 多忙な「偉い人」にメールを送るときは簡潔に。（最大）3つの箇条書きと、1つだけの行動要請を書く。
- 悪い組織からは逃げることも出来る。選択肢を知ることで、自由になれる。
