幡ヶ谷亭直吉ブログ

娘のここねと格闘するエンジニア。

『Team Geek』を読んで ~ チーム開発におけるリーダーシップを学ぶ

読書メモ。2025年59冊目。
『Team Geek』を読んでの感想となります。(2025/8/13記載)

本の概要

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

引用:

www.oreilly.co.jp

動機

  • HRTの原則の出典ということからずっと読みたいと思っていた。
  • SHIFT Agile FESでのクリエーションライン安田さんのお話から読まねばと決意。

    hiliteeternal.hatenablog.com

  • さらに、プログラミングするパンダさんの書籍に背中を押され、ようやく着手しました。

    hiliteeternal.hatenablog.com

本書からの学び

まず、2013年7月に発行された書籍ということに驚きました。
『リーダブルコード』が2012年6月、『SQLアンチパターン』が2013年1月ということを考えると、当時は暗黙知だったエンジニアに求められる素養が、形式知として表に出てきた時期だったのではないかと想像します。

12年前の自分がいたシステム開発の現場は、アジャイルスクラムといった文化からは遠い場所でした。その頃に読んでいたら、きっと遠い世界の話に思える部分が多かったと思います。
12年経った今では、エンジニアリング組織として標準化されつつある知見も多く感じますが、その中でもリーダーシップに関する記述からは多くの学びがありました。

おそらく、従来の管理型マネジメントから、チーム開発においてマネージャーがどう関わるべきかという自分の関心と重なったからだと思います。
今の時代のチーム開発においても、大切にしたい知見が数多くありました。

忘れたくないメモ

本書で特に印象に残ったポイントを振り返ります。

HRTの原則

人間関係を円滑にするだけでなく、健全な対話とコラボレーションの基盤となるものだ。
謙虚(Humility)
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
尊敬(Respect)
一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
信頼(Trust)
自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
この3つを合わせて「HRT」と呼びたい。読み方は「ハート」だ。痛みを軽減するものだから、苦痛の「hurt」ではなく、心の「heart」である。ぼくたちの主張は、この三本柱で成り立っている。

本書を読みたくなったそもそものきっかけ。
HRTはいつでも心に刻んでおきたい。

リスクを取ること

過去に失敗したことがなかったら、それは革新的でないか、リスクをとっていない証拠である。失敗は次回のために学んで改善する絶好のチャンスだ。

個人に対してだけではなく、チームに対しても意識しておきたい。
経験は何よりも重要な財産になる。

設計文書のレビュー

設計文書は、通常は1人の人間が所持するものである。それを大勢の人たちがレビューして、2~3人の人間が承認する。プロジェクトの未来を描いたハイレベルの青写真だが、何をどうしたいのかを低コストでチームに伝える手段でもある。コードを書いていないので、容易に批判を受け入れることができる。それが優れたプロダクトや実装につながっていく。設計文書があれば、プロジェクトの計画やタスク分割にも使える。ただし、コーディングを開始したあとは、「生きた文書」として扱うべきだ。設計文書は石に刻まれたものではない。プロジェクトが進むにしたがって、更新するべきである。まあ、言うのは簡単だけどね。ほとんどのチームは文書を書いていない。残りのチームは短期的な素晴らしい文書と、更新していない長期的な文書を持っている。

「包括的なドキュメントよりも動くソフトウェアを」に対して、「動き続けるソフトウェアのために抽象化されたドキュメントでチームでのシステム理解を」というのがあると思っています。
手を動かす単位次第だけど、プログラムソースよりもプロダクト理解を容易にするドキュメントはあった方が良いと思う。

チーム成長のためのコードレビュー

コードレビューをすれば品質が高くなるだけでなく、品質に対するチームの誇りを育むこともできる

デプロイされるコードのためだけのレビューではなく、
チーム成長のためのコードレビューを意識したい。

チーム全体のエゴやアイデンティティを育む

確かに謙虚になることと犠牲になることの境界線はあいまいだ。しかし、謙虚は自信がないこととは違う。エゴがなくても自信を持って意見を主張することはできる。個人のエゴはチームでは対応しきれない。チームリーダーのエゴは特にそうだ。個人のエゴではなく、チーム全体のエゴやアイデンティティを育むべきである。

エンジニアに求められるスキルの領域が多岐にわたる中、一番心に持っておきたい言葉。

リーダーは何ができるか

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

伝統的なマネジメントとの切り分けを意識したい。
メンバーを管理するのではなく、メンバーが活躍できる場を作っていくのがリーダーの仕事。
意識しないとエゴで管理に偏っていく。

チームの自己組織化

リーダーの仕事はチームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきことだ。こうすることで、プロダクトの当事者意識を植えつけるだけでなく、成功(と失敗!)の説明責任と最終責任を与えることができる。優秀なチームがいて、仕事の品質や評価に高い基準を設ければ、ニンジンとムチを使って監督するよりもはるかに多くのことを成し遂げられるのだ。

あくまでリーダーがやるべきことは支援であって決定ではない。
自分の自己実現を図るのではなく、チームの自己組織化をサポートしていく。

問題解決するのを手伝う

チームメンバーがアドバイスを求めてきたら、問題解決のチャンスだ!問題解決ならリーダーになる前に何年もやってきたので、すぐに問題解決モードに突入してしまいそうだが、それはダメだ。エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決するのを手伝ってほしいからだ。そのためには、彼に質問をすればいい。何もマジック8ボールの代わりになれと言っているわけではない。それでは役に立たないし、イライラさせるだけだ。そうではなく、問題を整理したり調査したりすることで、彼が自分で問題解決できるように支援するのである。そうすれば、彼の答えが見つかる。このことは、本章でも説明した当事者意識や責任の話と関連する。

このことも忘れがちです。
答えるのではなく、手伝うことが重要。
分からないことでも諦めないことが重要と思っています。

ユーザーからのフィードバック

ソフトウェア開発プロセスとは、プロダクトを壁越しに投げたら終わりではない。ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくことだ。このフィードバックループの方法を身につけなければ、ソフトウェアは死んでしまう。

ソフトウェアが死んでしまうという表現が好き。
ソフトウェアは作っておしまいの時代は終わっている。
(もしくは、そんな時代はそもそもなかったのかも知れない)

プロダクトの利用

利用の計測方法も考えておくべきだ。インストール数やユーザー登録数ではなく利用だ。プロダクトはダウンロードではなく、利用されなければいけない。

どう利用されているかを理解した上で、プロダクトを適用していくことが重要。

汎用的な機能の罠

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

汎用的な機能は結局使いづらい。
個別課題を解決する。その課題がどれだけ関心を持たれているかが重要。

プログラマーの美徳

怠惰の罠には気を付けよう。怠惰は作業の自動化につながるので、プログラマの美徳だと言う人もいる。しかし、怠惰のせいでユーザーを不便にするコードを書いてしまう可能性もある。ユーザーにとって使いやすいソフトウェアは、プログラマにとって作るのが面倒なこともある。コードを書く側の都合ではなく、ユーザーに集中しよう。コードを書くのが大変になったとしても、愚痴を言わずにやるべきだ。

『闘うプログラマー』も読みたい。

bookplus.nikkei.com

ソフトウェアの血液

そのソフトウェアは君のためではない。チームのためではない。会社のためではない。ユーザーの生活を豊かにするためである。ユーザーがプロダクトについて何を考えているか、何を言っているか、何を体験しているかに注目することが、長期的に重要なことになる。ユーザーはソフトウェアの成功に欠かせない血液だ。自分でやったことは、すべては自分に返ってくる。

今としてはあたりまえになっている気がするけど、常に念頭に置いておきたい。

追記

著者動画

NotebookLMで解説してもらいました。興味深かったです。
「事前に許可を得るより、あとで許してもらうほうが楽」も意識したい。

youtu.be