『Team Geek』を読んだ

どんな本か

複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しません。
全員が最終目標に向かって協力することが重要であり、チームの協力関係はプロジェクト成功のカギとなります。
本書は、Subversionをはじめ、たくさんのフリーソフトウェア開発に関わり、その後Googleプログラマを経てリーダーを務めるようになった著者が、「エンジニアが他人とうまくやる」コツを紹介。
「チームを作る三本柱」や「チーム文化のつくり方」から「有害な人への対処法」まで、エンジニアに求められる社会性について楽しい逸話とともに解説します。
Amazon.co.jp より

なぜ読んだのか

「角谷トーク」で知って、「ほしい物リスト」に入れていた本。

Kindle 版がないため購入を躊躇していたが、先日LT会で紹介されているのを見て、さらに読みたくなったので買うことに。

フィヨルドブートキャンプでもチーム開発の課題に入ったので、タイミング的にも今読もうと思った。

この本を読む目的・この本から得たいこと

  • チームの協力関係の築き方を知る
  • 「エンジニアが他人とうまくやる」コツを知る
  • チーム内の一人のエンジニアとして、どういうことを考え、どう動けばいいかのヒントを得る

大事だと思ったことをメモ

  • 「早い段階で、高速に、何度も失敗せよ」
  • ソフトウェア開発はチームスポーツである
    • ビジョンを共有しよう
    • 仕事を分担しよう
    • 他人から学ぼう
    • 素晴らしいチームを作る
  • チームで働くときのポイント
    • HRT(ハート)
    • 謙虚(Humility)
      • 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
    • 尊敬(Respect)
      • 一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
    • 信頼(Trust)
      • 自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
  • あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるもの
  • コードを批判されても、自分の性格や人間としての価値が攻撃されたと思わないこと
    • プログラミングスキルは練習すれば向上する
  • 相手に伝えるときは、自分の疑問として謙虚に聞く
  • 議論しているのはコードのことであり、誰かの価値やコーディングスキルのことではない
  • チームの文化
    • エンジニアリングチームが共有する経験・価値・目標のこと
  • 強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的
  • 許可を求めるより寛容を求めるほうが簡単
  • 「運」は鍛えることができる
    • 運のいい人は「チャンスに気がつく」
  • 他人がそのソフトウェアを使って幸せにならなければいけない
    • ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくフィードバックループを回さなければ、ソフトウェアは死んでしまう
  • ユーザーに集中すれば、他のことはすべてついてくる
    • ハードルを下げる
    • プロダクトは、最初の体験が超重要
    • ユーザー数ではなく利用(アクティブ数)を計測する
    • 速度重要
    • Less is more(少ないことはよいこと)
    • 怠けない
      • フォームの入力値は寛容に
    • 複雑さを隠す
    • ユーザーの意見を直接聞く
    • 見下さない
      • ユーザーには常に敬意を払う
    • 我慢する
      • 多くのユーザーは問題をうまく表現できない
      • 何を意図しているかを理解することが重要なスキル
    • 信頼は最も大切なリソース
  • ユーザーのことを忘れない
    • ソフトウェアを書く理由
      • 自分、チーム、会社のためではない
      • ユーザーの生活を豊かにするため

所感

そろそろ就職活動をしなければいけないということもあり、一緒に働くことになる人たちの考え方やビジネスなどについて学びたいと思い、最近いろいろな本を読んでいる。

プログラミングに直接関係ない本も多いが、だんだん共通点が見えるようになってきた!面白い。

『Team Geek』のHRTは、チームで働く上で大事なことだ。確かに、今までの自分を振り返ってみても、謙虚(Humility)・尊敬(Respect)・信頼(Trust)の3つを忘れずに行動すれば、人間関係についての多くの問題は起こらなかった気がする。

コードを批判されても、自分の性格や人間としての価値が攻撃されたと思わないこと

少し前に教えてもらった「認知行動療法」っぽい考え方かなと思った。認知行動療法についてはまだよく知らないので、今度そういう本を読んでみたいと思っている。

“ユーザーに集中すれば、他のことはすべてついてくる” というのは覚えやすくてうれしい。

ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくフィードバックループを回さなければ、“ソフトウェアは死んでしまう”。「死んでしまう」とまで強い言い方になっていたのが印象的だった。

『アジャイルサムライ』にも書いてあったが、ユーザーの声に真摯に耳を傾け、改良していくループを回し続けることが大事で、それがユーザーの幸せにつながる。

自分の仕事が誰かの幸せにつながるなんて素晴らしい。

仕事を始めたら読み直したい本。就活しなきゃ…