2026年時点で、自分がおすすめする書籍を、6つのカテゴリで分けてみました。
実際に読んでみて、自分が再読するものをピックアップしました。
このリストの前提
- アーキテクチャやインフラの設計論・クラウド構成のハウツーは載せていない
- プログラムの書き方やクラウド構成の詳細より、プロダクトと組織 の話を先に読みたい人
- 『世界はシステムで動く』のように「構造で見る」話が好きな人
- プロダクトに AI エージェントを入れたい、チームの進め方を知りたい人
- ツールの使い方より、なぜうまくいく／いかないか を知りたい人
- アジャイルで進めたいが、スプリントの速度だけ では価値が見えないと感じている人
- AI で実装が速くなっても、出す量と顧客への価値 を混同したくない人
6つのカテゴリ
おすすめ書籍は13冊をピックアップして6つのカテゴリに分けています。
関心が「組織」寄りなら組織とチームから、「プロダクト」寄りならプロダクトマネジメントから入っても構いません。
| 分類 | 本 | 掴むこと |
|---|---|---|
| システム思考 | 『システム思考の世界へ』 | メドウズの続き。現場へのフィードバックと構造 |
| 技術組織と戦略 | 『エンジニアリング戦略の作り方』『統括責任者の手引き』 | 技術側の意思決定と組織の回し方 |
| プロダクトマネジメント | プロダクトマネジメント、UX 実践者の PM 入門、『プロダクトマネージャーのしごと』、EBM 実践ガイド | 何を作るか、誰が担うか、どう回すか、何で測るか |
| プロダクトの現場 | 『プログラムは技術だけでは動かない』、Aligned、BUILD | 開発とのすり合わせ、ステークホルダー、プロダクト判断 |
| 組織とチーム | 『人が増えても速くならない』、『チームトポロジー』 | 進め方、チームの切り方と連携 |
| AI エージェント | 『AI エージェント 人類と協働する機械』 | エージェント時代の俯瞰 |
システム思考〜昨今のAIエージェントの書籍までをまとめました。
AIエージェントなどの書籍は、自分もまだ読んでるものがたくさんあり、ここではまとめきれていないのが現状です。
また、AI系の書籍は物によっては読みにくいものもたくさんある印象を受けているので、実際に書店などで手にとってみるほうが良いと思っています。
タイトル買いで失敗したなと思う書籍もたくさんありました。
システム思考
『システム思考の世界へ』
Diana Montalion 著のこの本は、2026 年 4 月に邦訳されたばかりです。副題は「複雑化する時代で考え続けるソフトウェア技術者のために」ですが、クラウド構成やアーキテクチャパターンの教科書ではありません。
メドウズの本で得たストックやフィードバックの感覚を、人・組織・技術が絡む現場に落とし込む一冊だと理解しています。変更はコードの中だけで完結せず、判断や行動として現れる。だから障害や遅れは、単体のバグではなく相互作用として見る、という話です。
目次を見ると、思考のシステム、自己認識、チームでの論拠付け、フィードバックループの設計、モデリング、システム的リーダーシップまで並んでいます。AI エージェントをプロダクトへ組み込む話でも、「どこにループを入れるか」「理由を共有できるか」はそのまま効きそうです。
オライリーの紹介 でも、個々を切り分けて最適化するだけでなく、全体が健全に機能するよう考えて働きかける、と書かれています。アーキテクチャをガッツリ避けたい読者には、ソフトウェアの文脈でシステム思考を続ける入口として、いちばん相性がよさそうだと感じました。
技術組織と戦略
『エンジニアリング戦略の作り方』
Will Larson 著のこの本は、私が読み終えたばかりの一冊です。まだ読書メモや記事にはまとめていません。記事にまとめたい、と感じたので、ここでは印象だけ書きます。
オライリーの紹介 にある通り、「うちにエンジニアリング戦略なんてない」と思いがちです。実際には存在しないのではなく、言語化・共有されていないことが多い、という話から入ります。何十人ものエンジニアの時間が、本来避けられた混乱に費やされている、という指摘も刺さりました。
Stripe や Uber などでの事例をもとに、制約の把握、診断、方針策定、運用まで、戦略を作るプロセスが段階的に書かれています。Wardley マッピングやシステムモデリングといった技法も出てきますが、モジュール設計やクラウド構成のハウツー本ではありません。戦略を「絵に描いた餅」から「実行される計画」へ寄せる、意思決定の本だと受け取りました。
AI エージェント、プロダクト、システム思考の文脈とも接続しやすいです。エージェントを足す前に、「うちは何を優先し、何をやらないか」を言葉にできるか。生成が速くなるほど、その問いの比重は上がるはずです。
Larson 氏の『エレガントパズル』『スタッフエンジニア』を読んだ人なら、著者の文体にも馴染みやすいでしょう。次の『エンジニアリング統括責任者の手引き』とあわせて読むと、戦略の「中身」と組織での「回し方」の両方が見えてきます。
『エンジニアリング統括責任者の手引き』
同じ Will Larson 著で、こちらも大事だと感じているのが『エンジニアリング統括責任者の手引き』です。私は読了済みです。『エンジニアリング戦略の作り方』とセットで勧めたい一冊です。
CTO や VP of Engineering を目指す人向けに見えますが、実際には開発組織がどう動き、技術側の意思決定がどこでつまずくかを知りたい人にも効きます。プロダクトやビジネス寄りの立場から、エンジニアリング組織と対話するときの地図になります。
本書で印象に残っているのは、エンジニアリング戦略が文書化されていないことがよくあるアンチパターンだ、という話です。戦略本が「戦略をどう作るか」なら、手引きは統括責任者として組織をどう回すかの話です。入社後の最初の 90 日、信頼関係の構築、採用、計画、経営との接続など、現場のリーダーシップに踏み込んでいます。
AI 導入で実装が速くなっても、組織の優先順位やリソース配分の話は別です。「技術戦略がほしい」と言われたとき、何を指しているのかを読み解く助けにもなります。アーキテクチャパターンの本ではなく、技術組織のマネジメントの本です。
プロダクトマネジメント
この分類の 4 冊は、なぜ作るか → 誰が担うか → どう回すか → 何で測るかの順で読むとつながりやすいです。
『プロダクトマネジメント』（ビルドトラップ）
Melissa Perri 著の『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』は、AI の話をプロダクトの文脈に落とすうえで、いま特に勧めたい一冊です。
本書の中心概念はビルドトラップです。アウトプット（出した量、リリース回数、機能の数）を追い、アウトカム（顧客の課題が解けたか）から目が離れる状態を指します。スケジュール優先で不要な機能を積み上げ、顧客のニーズより「作ること」自体が目的化する。わかっているのに抜け出せない、という構造の話です。
AI エージェントや生成系ツールで実装は速くなった。だからこそ、ビルドトラップのリスクも上がる、と私は感じています。早ければよいわけではない。出せば出すほど正しい、にも見えやすい。本書は、その錯覚に名前をつけてくれます。
プロダクトマネージャー向けの本ですが、PdM の手順書というより、WHY（なぜ作るか）に責任を持つという視点の本だと受け取りました。知識のギャップ、アラインメントのギャップ、効果のギャップ。戦略とは計画表ではなく、意思決定のフレームワーク、という整理も、システム思考、プロダクト、AI の文脈と重なります。
この本は 何を作り続けるべきか／作るべきでないか の話です。続く 2 冊（UX 入門、『プロダクトマネージャーのしごと』）とあわせると、価値のズレ、ユーザー視点、日々の進め方が揃います。EBM はそのあとで「証拠にもとづく計測」の話として足せます。アーキテクチャの深掘りは不要で、プロダクトの本質に近い位置づけです。
『UX実践者のためのプロダクトマネジメント入門』
クリスチャン・クラムリッシュ 著、及川卓也・ヤナガワ智予訳の『UX実践者のためのプロダクトマネジメント入門』は、タイトルどおり UX デザイナーが PM へ進むための本です。ビジネス寄りでプロダクトの全体像を掴みたい人にも、かなり読みやすい一冊だと感じています。
出版社の紹介 にある通り、プロダクトマネジメントとは価値に責任を持つことです。プロジェクトマネージャーやプロダクトオーナーと、役割がどう違うかを最初に切り分けてくれるので、「誰が何を決めるのか」が曖昧な現場の地図になります。PM の 1 日の過ごし方、仮説検証、収益モデルや PMF、エンジニアとの協働まで、実装の深掘りなしにプロダクト開発の流れが追えます。
『プロダクトマネジメント』（ビルドトラップ）が「出す量と価値のズレ」に名前をつける本なら、こちらはユーザーとビジネスの両方から価値を設計する入り口です。UX の専門用語は出てきますが、図や対比表が多く、エピソード調の章立ても読みやすい印象です。AI 機能を足す前に、「誰のどんな課題に、どう検証するか」を議論するときの共通言語にもなります。
「デザインの話の前に、プロダクトとして何に責任を持つか」を揃えたいときに手に取りたい一冊です。
『プロダクトマネージャーのしごと』 第2版
Matt LeMay 著の『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド』は、プロダクトマネジメントの日々の業務に焦点を当てた実践書です。オライリーの紹介 でも、ツールやフレームワークだけでは解けない課題に向き合う本、と位置づけられています。
本書の骨格は、コミュニケーション・組織力・リサーチ・実行の 4 つ、いわゆるCORE スキルです。キャリア論や手法カタログというより、「PM の 1 日に何が起き、どう振る舞うか」が中心です。「よさそう」「いいですね」で止まる合意の危うさ、ステークホルダーとの調整、ベストプラクティスを盲信しない割り切り。現場の曖昧さに向き合う章が多い印象です。
『プロダクトマネジメント』（ビルドトラップ）がなぜ作るか、『UX 実践者のためのプロダクトマネジメント入門』が誰が何に責任を持つかなら、こちらはどう回すかの本です。付録の読書リストではビルドトラップも挙がっており、3 冊は意図的に並べた組み合わせです。
AI で実装が速くなっても、優先順位づけや関係者との合意形成は別問題です。エージェントをプロダクトに入れるプロジェクトほど、「機能は増えたが、みんな同じ理解か」が問われます。ビジネス寄りの立場から開発と対話するとき、PM の仕事の輪郭を掴むのに向いていると感じています。
『EBM実践ガイド』
アジャイルの進め方として、証拠にもとづく意思決定の本です。読む順では、組織とチームの 2 冊のあと（おわりにの 12 番目）がおすすめです。
Patricia Kong 著の『EBM実践ガイド』（Evidence-Based Management、エビデンスベースドマネジメント）は、Scrum.org が提唱するフレームワークの実践書です。スクラムの儀式の解説本ではなく、証拠と学びにもとづいて意思決定するための考え方が中心です。
「この機能、本当にユーザーに価値を届けているのか」。リリース後に立ち止まらず、次のスプリントへ走り続けてしまう。そんな場面に、EBM は効きます。偉い人の意見（HiPPO）より、計測と仮説検証を優先する、という話です。
本の構成は、目的の明確化、経験主義、計測指標、プロダクト・ポートフォリオ・組織の各レベルへの適用まで段階的に進みます。私は別途、EBM の概要をまとめた読書メモも書いていますが、このリストでは実践ガイド本体を挙げています。
『人が増えても速くならない』が「人月と進め方」の話なら、EBM は 何をもって成功と呼ぶか、どう学びを回すか の話です。AI をプロダクトに入れたあと、「出した量」ではなく「価値が動いたか」を議論する言葉としても使えます。
プロダクトの現場
『プログラムは技術だけでは動かない』
小俣 光之さんのこの本は、かなり前の著作です。2026 年の自分が読み返しても、まだ効くと感じています。
「技術力はあるのに、仕事がうまくいかない」という話から始まります。依頼者が本当に求めていること、チームの中での進め方、理想と現実のすり合わせ。プロダクトやプロジェクトの話を、コードの外側から見直す本です。
AI エージェントを組み込む話でも同じで、実装ができても、課題が解けていなければ意味が薄い、という感覚は変わりません。むしろ生成が速くなるほど、「何を解く仕事か」の解像度が問われると感じています。
エンジニア向けに見えますが、文章はエピソード中心で、専門用語の壁はそれほど高くない印象です。プロダクト側の人が「開発チームと何を話すべきか」を考えるときの補助線にもなります。
『Aligned』
ステークホルダーとの関係が、プロダクトの成否を分ける。そう感じているなら、こちらです。
本書はストーリー形式で、異なる立場の人たちが信頼関係を築き、プロダクトに向かって協働していく過程が描かれています。組織図に載らない影響力、意見が割れたときの向き合い方、CEO の腹心のような存在。現場っぽい話が多いです。
AI を入れるプロジェクトほど、エンジニアだけで完結しません。法務、営業、現場、経営。誰を巻き込み、何を揃えるか。Kubernetes を選ぶ話の前に、**Aligned（同じ方向を向いている状態）**をどう作るかは、これからより重要になるはずです。
『BUILD』（『世界を変えるプロダクトの極意』）
トニー・ファデル著の BUILD（邦題『世界を変えるプロダクトの極意』）は、iPod や iPhone の開発エピソードが中心のプロダクト本です。
成功の法則を並べる薄い本ではなく、いつ出すかや何を先に出すか、誰と作るかといった生々しい判断が書かれています。戦略と結果がずれたときに舵を切る話もあります。プロダクトに「あるべき姿」があるという話も印象的でした。私は「誰と作るか」がプロダクトの質を変える、という部分に何度も引っかかります。
AI エージェントを機能として足す話と、プロダクトとしての一貫性は別物です。エージェントを入れたい人ほど、何を削らないか まで含めてプロダクトを考える本として勧めたいです。
組織とチーム
『人が増えても速くならない』
倉貫義人さんのこの本は、人月の神話を崩しにいく本です。「人を増やせば早くなる」という幻想に、データと現場の感覚の両方から切り込みます。
『世界はシステムで動く』が現象の構造なら、こちらは開発組織というシステムに近いです。リリース後に改善が始まる、納品型ではなく協働型で進める、といった話は、AI 時代のプロダクト開発とも重なります。
同じ著者の『「納品」をなくせばうまくいく』も、続編として読むとつながりがはっきりします。AI エージェントで実装が速くなっても、チームとしての進め方は別問題、という感覚を持っておくのに役立ちます。
『チームトポロジー』
組織の話として、こちらも大事だと感じているのが、マシュー・スケルトンとマニュエル・パイス著の『チームトポロジー ―価値あるソフトウェアをすばやく届ける適応型組織設計』です（邦訳は吉羽龍太郎 氏ほか）。
タイトルの「トポロジー」は、ネットワーク構成図のようなインフラの設計図ではありません。チームの組み合わせ方と連携の仕方の設計です。コンウェイの法則（組織のコミュニケーション構造がシステムに映る）を踏まえ、望ましい形から逆算してチームを組む、いわゆる逆コンウェイ戦略の話です。
4つのチームタイプが整理されています。
- ストリームアラインドチーム … 価値の流れに沿って End-to-End で届ける中心チーム
- プラットフォームチーム … 共通基盤をセルフサービスで提供し、認知負荷を下げる
- イネイブリングチーム … スキルや考え方を補い、自走したら離れる
- コンプリケイテッド・サブシステムチーム … 本当に必要なときだけ切り出す専門チーム
AI エージェントを入れると、個人の生産性は上がっても、チームの境界が曖昧になることがあります。誰が顧客価値に責任を持つのか。プラットフォームとプロダクトの境目はどこか。チームトポロジーは、その議論の語彙を与えてくれます。
『エンジニアリング統括責任者の手引き』が統括層の視点、『人が増えても速くならない』が人月と進め方の視点なら、チームトポロジーは誰と誰がどうつながるかの視点です。プロダクトに AI を組み込む話でも、組織設計は避けて通れません。
AIエージェント
『AIエージェント 人類と協働する機械』
広木大地さんの新著は、私も読み進めているところです。一通り読み切れているわけではないので、紹介は控えめに書きます。
エージェント、生産性、何を作る価値があるか——いまの関心にそのまま刺さる構成だと感じています。エージェントの登場をどう捉えるか、組織論、知識創造、未来の生き方まで、部立てが広い本です。
実装ハウツーというより、「エージェント時代に、人間は何を担うか」 を考えるための地図として手に取る価値がありそうです。読み終えたら、また別の記事で感想を書きたいです。
アーキテクチャ・インフラの本は、今回は外してる
今回は、アーキテクチャなどの本は除外しています。
私自身は、アーキテクチャ入門系の本も読んでいて、別途記事にまとめてる予定です。
次のような本は、エンジニアには定番でも、今回のリストには入れていません。
- ソフトウェアアーキテクチャの設計論（パターン、境界、モジュール分割の深掘り）
- クラウドネイティブ、SRE、Kubernetes、AWS 構成の入門から実践まで
- 「まず設計を学べ」系のプログラマ向けアーキテクチャ入門
- ドメイン駆動
AI をプロダクトに入れる話は、いつかインフラや非機能要件の議論に触れる場面も出てきます。
そのときは改めて、AIエージェント開発や生成AIのデザインパターンなどを手にとって理解を深めていくのが良いと感じています。
おわりに
最後に、カテゴリに分けたリストになります。
| 順 | 分類 | 本 |
|---|---|---|
| 1 | システム思考 | 『システム思考の世界へ』 |
| 2 | 技術組織と戦略 | 『エンジニアリング戦略の作り方』 |
| 3 | 技術組織と戦略 | 『エンジニアリング統括責任者の手引き』 |
| 4 | プロダクトマネジメント | 『プロダクトマネジメント』（ビルドトラップ） |
| 5 | プロダクトマネジメント | 『UX実践者のためのプロダクトマネジメント入門』 |
| 6 | プロダクトマネジメント | 『プロダクトマネージャーのしごと』第2版 |
| 7 | プロダクトの現場 | 『プログラムは技術だけでは動かない』 |
| 8 | プロダクトの現場 | 『Aligned』 |
| 9 | プロダクトの現場 | 『BUILD』（『世界を変えるプロダクトの極意』） |
| 10 | 組織とチーム | 『人が増えても速くならない』 |
| 11 | 組織とチーム | 『チームトポロジー』 |
| 12 | プロダクトマネジメント | 『EBM実践ガイド』 |
| 13 | AI エージェント | 『AI エージェント 人類と協働する機械』 |