テックリードが読むべき本まとめ|疑問別に選ぶ8冊

テックリードが読むべき本まとめ|疑問別に選ぶ8冊

テックリードについて調べ始めると、すぐに「おすすめの本」の一覧に行き着きます。

ところが一覧を眺めても、どの本がどの疑問に答えてくれるのかは書名からは分かりません。

マネジメントの本、アーキテクチャの本、組織設計の本が同じ列に並んでいて、どこから手を付けるかで迷いがちです。

本は「何の疑問を抱えているか」から逆に選ぶと、必要な 1 冊にたどり着きやすくなります。

私もテックリードを目指して学んでいる途中なので、ここでは疑問ごとに本を分け、各書籍が扱う範囲を出版社の紹介と目次で確かめられる範囲で並べました。

本は抱えている疑問から選ぶ

テックリードの仕事は、技術の判断、チームの進め方、周りとの調整にまたがります。

そのため「テックリードの本」と一言で言っても、答えてくれる疑問はかなり違います。

ここでは疑問を次の 5 つに分けました。

  • テックリードとは何をする役割なのか
  • 技術の判断を何を根拠に下すのか
  • 開発の成果をどう測るのか
  • チームや組織の形をどう考えるのか
  • テックリードの先にどんな道があるのか

全部を順に読むより、いま詰まっている疑問の棚から 1 冊を選ぶほうが読み切れます。

書誌は出版社の公式ページで確かめたものだけを載せています。

役割を知りたいときの3冊

最初の疑問は「テックリードは何をする人なのか」です。

この疑問には、テックリードという役割そのものを扱う本が向いています。

Talking with Tech Leads

Patrick Kua による『Talking with Tech Leads』は、2015 年に刊行された英語の本です。

Thoughtworks の紹介ページによると、新しくテックリードになった人向けの部と、経験を積んだ実践者向けの部の 2 部に分かれています。

Talking with Tech Leads(Thoughtworks)

Talking with Tech Leads | Thoughtworks United States

同じページでは、テックリードのやり方に唯一の正解は無いという趣旨の結論が紹介されています。

役割の定義が会社ごとに揺れる理由を知りたい人には、この本が入口になります。

邦訳は確認できなかったので、読むなら英語版になります。

Googleのソフトウェアエンジニアリング

『Googleのソフトウェアエンジニアリング』は、Titus Winters ほか編、オライリー・ジャパンから 2021 年に出た邦訳です。

全体は 600 ページを超える厚い本ですが、テックリードの役割に直接関わるのは 5 章「チームリーダー入門」と 6 章「スケールするリーダー」です。

Googleのソフトウェアエンジニアリング(O'Reilly Japan)

Googleのソフトウェアエンジニアリング

同じ本には 9 章「コードレビュー」もあり、チームの開発ルールを決める立場から読むこともできます。

テックリードと EM(エンジニアリングマネージャー=人の管理を担う役職)の違いをこの本の整理から追った記事は、下のカードから読めます。

テックリードとは何か?EM・アーキテクトとの違いを整理

エンジニアのためのマネジメントキャリアパス

Camille Fournier の『エンジニアのためのマネジメントキャリアパス』は、オライリー・ジャパンから 2018 年に出た邦訳です。

副題は「テックリードからCTOまでマネジメントスキル向上ガイド」で、目次は 1 章「マネジメントの基本」のあと、メンタリング、テックリード、人の管理、チームの管理、経営幹部へと立場の順に進みます。

エンジニアのためのマネジメントキャリアパス(O'Reilly Japan)

エンジニアのためのマネジメントキャリアパス

3 章がそのまま「テックリード」なので、役割の位置づけを前後の立場と比べながらつかめます。

技術の判断と成果の測り方を学ぶ2冊

テックリードはチームの技術判断に責任を持ちます。

判断の根拠と、判断の結果をどう測るかを扱う本がこの棚です。

ソフトウェアアーキテクチャの基礎

Mark Richards と Neal Ford による『ソフトウェアアーキテクチャの基礎』は、オライリー・ジャパンから 2022 年に出た邦訳です。

目次は、アーキテクチャ特性の洗い出し方を扱う第 I 部、レイヤードやマイクロサービスなどのスタイルを並べる第 II 部、決定やリスク分析と交渉を扱う第 III 部に分かれています。

ソフトウェアアーキテクチャの基礎(O'Reilly Japan)

ソフトウェアアーキテクチャの基礎

第 III 部には「アーキテクチャ決定」「効果的なチームにする」「交渉とリーダーシップのスキル」の章があります。

技術の本でありながら、決め方と伝え方まで扱っている点が、テックリードの読み物としても使える理由です。

LeanとDevOpsの科学

Nicole Forsgren、Jez Humble、Gene Kim による『LeanとDevOpsの科学[Accelerate]』は、インプレスから 2018 年に出た邦訳です。

インプレスの紹介では、数年にわたる調査研究をもとに、開発組織を改善するための仕組みを解説する本とされています。

LeanとDevOpsの科学[Accelerate](インプレスブックス)

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する - インプレスブックス

目次には「開発組織のパフォーマンスを計測」や「組織文化のモデル化と測定、改善の方法」が並びます。

チームの改善が効いているかを数字で説明したい場面で、根拠をたどる先になります。

チームと組織の形を考える2冊

チームが大きくなると、誰がどこを持つかという組織の形が技術の判断にも響いてきます。

この棚の 2 冊は、チームの外側を見るための本です。

チームトポロジー

Matthew Skelton と Manuel Pais による『チームトポロジー』は、日本能率協会マネジメントセンターから 2021 年に出た邦訳です。

4 つのチームタイプと 3 つのインタラクションモードという型で、チームの役割と関係を整理するのが特徴です。

チームトポロジー(日本能率協会マネジメントセンター)

チームトポロジー - JMAM 日本能率協会マネジメントセンター 「人・組織・経営の変化」を支援するJMAMの書籍

自分のチームが他のチームとどう関わるのが自然かを考えるときの、共通の言葉を手に入れられます。

エレガントパズル

Will Larson による『エレガントパズル』は、原書が Stripe Press から出ており、日経BPから 2024 年に邦訳が出ました。

日経BPの紹介では、チーム構成、キャリア開発、組織文化、技術的負債の扱いなどがエンジニアリングマネジメントの論点として挙げられています。

エレガントパズル(日経BP)

<6/3新刊>『エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか』

主な読者はマネージャーなので、テックリードが読むなら「マネージャーが何に悩んでいるか」を知る本として読むのが合っています。

隣で組織を見ている人の視点が分かると、EM との分担の話がしやすくなります。

テックリードの先を考える1冊

テックリードを務めたあとの道は、マネージャーだけではありません。

技術の専門職として上の等級を目指す道もあり、そこを扱う本がこの棚です。

スタッフエンジニアの道

Tanya Reilly の『スタッフエンジニアの道』は、オライリー・ジャパンから 2024 年に出た邦訳です。

目次は「大局的な思考」「実行」「レベルアップ」の 3 部で、5 章が「大規模プロジェクトをリードする」です。

スタッフエンジニアの道(O'Reilly Japan)

スタッフエンジニアの道

マネージャーにならずに影響範囲を広げる働き方が具体的に分かるので、キャリアの選択肢を比べる材料になります。

Staff エンジニアとテックリードの関係は、下の記事で別に整理しています。

Staffエンジニアとは?テックリードとの関係を整理する

読むときの落とし穴

本を選ぶときに気をつけたい点が 2 つあります。

1 つ目は、本ごとにテックリードの定義が違うことです。

マネジメントの本ではテックリードが管理職への入口として書かれ、専門職の本では技術を軸にした役割として書かれます。

どちらが正しいかではなく、自分の会社がどちらに近いかを照らし合わせる材料として読むと混乱しません。

2 つ目は、原書の刊行から時間がたった本があることです。

例えば『LeanとDevOpsの科学』の原書は 2018 年の刊行ですが、DORA の公式サイトには 2025 年までの年次レポートが並んでいます。

DORA Research

DORA | Research

数字や指標を使うときは、本の内容に加えて最新の公開資料も確かめておくと安心です。

最後に

テックリード向けの本は、役割、技術判断と測り方、チームと組織、その先のキャリアという疑問ごとに棚が分かれます。

いま一番困っている疑問の棚から 1 冊を選び、必要な章から読むのが続けやすい読み方です。

この連載の記事でも、ここで挙げた本のうち何冊かを出典にしてきました。

以上です。