はじめに
「今年読んで良かった本」という記事を書こうとしている自分に、ふと気づく。また書くのか。毎年書いている。誰に頼まれたわけでもないのに、12月になると決まってこの作業を始めてしまう。習慣なのか、義務感なのか、それとも単なる自己顕示欲なのか。たぶん、全部だ。
100冊近く読んだ、と書こうとして手が止まる。この数字を出した瞬間、どこかで「すごいですね」と言われたい自分がいる。同時に、「いや、冊数なんて意味ないですから」と予防線を張りたがっている自分もいる。めんどくさい人間だ。でも正直に言えば、100冊読んだことより、1冊を血肉にできた人のほうがよほど偉いと本気で思っている。思っているのに、冊数を書いてしまう。そういう矛盾を抱えたまま、この文章を書いている。
AIに聞けば答えは返ってくる。2025年はそういう年だった。コードを書いてもらい、設計を相談し、ドキュメントを要約させた。便利だ。本当に便利だ。では、なぜ本を読むのか。300ページもある本を、わざわざ最初から最後まで読む必要があるのか。
たぶん、効率の悪さが必要なのだ。AIは正解を返してくれる。でも正解だけでは、何かが足りない。正解を得ることだけが目的なら、エンジニアをやっている意味がない。でも、そうじゃないはずだ。著者が失敗した話。遠回りした話。「今思えば、あれは間違いだった」という告白。そういう「ノイズ」が、不思議と頭に残る。正解は忘れる。でも、誰かの失敗談は覚えている。
本を読んでいる時間、私は著者と対話している。いや、対話というより、ほとんど独り言だ。「それはそうだろう」と頷いたり、「いや、それは違うんじゃないか」と反発したりする。声には出さないけれど、頭の中ではずっと喋っている。その過程で、借り物の知識が少しずつ自分の言葉に変わっていく。検索では得られないもの。それを「身体性」と呼ぶのは大げさかもしれないけれど、他に適切な言葉が見つからない。
読んだだけでは意味がない、と言われてきた。アウトプットしないと身につかない。実践しないと血肉にならない。わかっている。わかっているけれど、私は本を読むこと自体が好きなのだ。ページをめくる時間が好きだ。知らない概念や文脈に出会う瞬間が好きだ。だからブログを書き、登壇し、実務で試してきた。好きなことを正当化するために、アウトプットという免罪符を手に入れようとしていたのかもしれない。
以下に紹介する26冊は、今年の「ベスト」ではない。そんな客観的な評価ができるほど、私は公平な人間ではない。単に「私に刺さった本」を並べただけだ。他の人には響かないかもしれない。でも、この26冊との出会いが、私の2025年を形作った。それだけは確かなことだ。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
- はじめに
- 昨年以前に紹介した本
- 2025年に読んでよかった技術書
- Beyond Vibe Coding
- LLMOps
- Generative AI Design Patterns
- Building Applications with AI Agents
- Learning GitHub Copilot
- Terraform in Depth
- Argo CD: Up and Running
- Effective Platform Engineering
- Data Engineering Design Patterns
- ソフトウェア設計の結合バランス
- Facilitating Software Architecture
- Architecture Modernization
- Building Event-Driven Microservices, 2nd Edition
- Taming Your Dragon: Addressing Your Technical Debt
- Refactoring to Rust
- Just Use Postgres!
- The Software Engineer's Guidebook
- バックエンドエンジニアのためのインフラ・クラウド大全
- 作る、試す、正す。アジャイルなモノづくりのための全体戦略
- 良いコードの道しるべ
- Clean Code, 2nd Edition
- 型システムのしくみ
- Fundamentals of Software Engineering
- The Product-Minded Engineer
- The Engineering Leader
- "Looks Good to Me"
- おわりに
昨年以前に紹介した本
- 2022年 俺が愛した本たち 技術書編 - じゃあ、おうちで学べる
- 2023年 俺が愛した本たち 技術書編 - じゃあ、おうちで学べる
- 2023年 俺が愛した本たち 非技術書編 - じゃあ、おうちで学べる
- 2024年 俺が愛した本たち 技術書編 - じゃあ、おうちで学べる
- 2024年 俺が愛した本たち 非技術書編(物語を除く) - じゃあ、おうちで学べる
2025年に読んでよかった技術書
Beyond Vibe Coding
※日本語翻訳版が出版予定です。
AIツールの導入が進む現場で、私が感じていた違和感がありました。生産性は上がっている。コードは早く書ける。しかし、チームメンバーがAI生成コードについて質問されたとき、「なぜこう書いたのか」を説明できない場面が増えている。Google ChromeチームのAddy Osmani氏による本書は、この違和感に「Vibe Coding」という名前を与えてくれました。
Vibe Codingとは、AIが生成したコードを深く理解せずに受け入れてしまう傾向のことです。動くコードと、理解しているコードは違う——この区別は、個人の学習だけでなく、チームの品質管理にも直結します。レビューで「なぜこの実装なのか」と聞かれたとき、「AIがそう書いたから」では通らない。コードの責任は、書いた人間にある。
著者は、AIを「単独で使うツール」ではなく「ペアプログラマ」として捉えることを提唱しています。この主張には同意するが、同時に違和感もある。ペアプログラマは、隣に座って一緒に考える存在だ。しかしAIは、こちらが何を求めているか察してくれない。問いを投げなければ答えは返ってこない。つまり、AIを「ペア」として機能させるためには、人間の側に「何を聞くべきか」を知っている力が必要になる。結局、AIを活かせるかどうかは、使う側の問いの質で決まる。ペアプログラマという比喩は美しいが、その美しさに甘えてはいけない。
本書の終盤では、自律型コーディングエージェントがもたらす未来像が描かれています。テスト失敗時に自動で修正を試みたり、依存関係の更新PRを生成したりする世界。技術的には魅力的ですが、著者は冷静です。「AIが生成したコードの責任は、承認者にある」——この原則は変わらない。むしろ、エージェントが自律的に動くほど、人間による検証の重要性は高まる。この視点は、運用の現場を知っている人間には納得感があります。
AIは相棒であって、魔法使いではない。本書は、その現実を直視しながら、AIとの協働をチームに根付かせるための実践的な指針を提供してくれます。
LLMOps
LLM（Large Language Model、大規模言語モデル）を本番環境で運用し始めると、従来のMLOpsの知見だけでは対応できない課題に直面します。モデルの挙動が予測しにくい、コストが桁違いに高い、出力の品質をどう保証するか分からない——そんな困難にぶつかったとき、本書を手に取りました。
著者が掲げるLLMOpsの4つの目標——信頼性、スケーラビリティ、堅牢性、セキュリティ——を見たとき、既視感がありました。これは、システムを運用する人間が長年追求してきた目標と重なる。新しい技術領域でも、運用の本質は変わらない。これまで培ってきた原則は、LLMにも適用できる——その確信を得られたことは、本書を読んだ大きな収穫でした。
しかし、ここで私は立ち止まる。「従来の原則が適用できる」という安心感は、危うさも孕んでいる。LLMには従来のシステムにはない難しさがあるからだ。従来のMLモデルは、入力に対して比較的予測可能な出力を返す。しかしLLMは、同じプロンプトでも異なる応答を返すことがある。そもそも「正しい出力とは何か」が曖昧なのです。従来のシステムでは「期待する出力」を定義できた。LLMでは、それ自体が困難になる。この不確実性を前提に、どうSLO（Service Level Objective、サービスレベル目標）を設計し、どうモニタリングするか。本書はその実践的なアプローチを示してくれます。
コスト管理の章も現実的で良かった。LLMのAPI呼び出しは、従来のマイクロサービス呼び出しと比較して桁違いにコストがかかる。機能要件を満たすことと、コストを現実的な範囲に収めること。このトレードオフを意識した設計と運用の知見は、実務で即座に役立つものばかりです。
「正しい出力」が定義できないシステムを、どう運用するか。答えは、まだ業界全体で模索中です。正解がないから、難しい。正解がないから、面白い。本書はその議論の出発点として、LLMを本番で動かす人が押さえておくべき基盤を提供してくれます。
Generative AI Design Patterns
LLMを使ったアプリケーションを作り始めると、繰り返し同じような問題にぶつかります。ハルシネーション（AIが事実と異なる内容をもっともらしく生成してしまう現象）をどう防ぐか。長いコンテキストをどう扱うか。出力の品質をどう担保するか。これらの問題には、すでに先人たちが見つけた解決策がある。本書は、そうしたLLMの限界を克服するための32のデザインパターンを体系化した一冊です。
RAG（Retrieval-Augmented Generation、検索拡張生成）、Chain of Thought（思考の連鎖）、Guardrails（安全装置）といったパターンは、今やLLMアプリケーション開発の共通言語になりつつあります。これらのパターンを知っているかどうかで、設計の議論がスムーズになるし、チーム内での認識合わせも早くなる。本書の価値は、単にパターンを列挙していることにあるのではありません。各パターンがなぜ必要か、どのような問題を解決するのか、そしてどのようなトレードオフがあるのか——その背景まで丁寧に解説している点にあります。
例えば、RAGパターン。ハルシネーションの軽減策として有効なのは広く知られている。しかし本書は、RAGの導入がもたらす新たな課題も明確に指摘しています。ベクトルデータベースという新しいコンポーネントが加わり、監視対象と障害点が増える。検索の精度がLLMの出力品質を左右するため、検索システムの品質保証という新たな運用課題が生まれる。解決策は、新しい問題を連れてくる——技術選定の現場では、この現実を織り込んだ上で判断する必要があります。
Chain of Thoughtパターンも同様です。複雑な推論を段階的に行わせることで出力精度が向上する。しかし、精度を上げれば、コストも上がる。APIコールが複数回になり、レイテンシーとコストが増加する。プロダクトとして許容できるコストとレイテンシーの範囲内で、どこまで精度を追求するか。このトレードオフは、技術だけでなくビジネス要件との兼ね合いで決まります。
パターンを知っているかどうかで、設計の選択肢が変わる——本書は、パターンカタログとしても、チームでアーキテクチャを議論するための共通言語としても活用できます。
Building Applications with AI Agents
LLMを使ったアプリケーションの次のステップとして、AIエージェントへの関心が高まっています。単に質問に答えるだけでなく、タスクを自律的に実行するシステム。しかし、エージェントを本番環境に投入しようとすると、従来のシステム運用とは異なる課題に直面します。
従来のAPIは、リクエストを送れば決まった形式でレスポンスが返ってくる。処理時間もおおよそ予測できる。しかしエージェントは違う。どんな行動を取るか予測しにくい。タスクによって実行時間が大きく変わる。外部サービスへの呼び出しも、エージェント自身が判断して行う。従来のSLOの考え方が、そのままでは通用しない。では、どう運用設計するのか。
本書を読んで改めて考えさせられたのは、ガードレールの設計です。エージェントは自律的に動く。自律的に動くからこそ、想定外の行動を取る可能性がある。どこまで自律性を許し、どこで人間が介入するか。この境界線を曖昧にしたまま本番投入すると、インシデント時の対応が混乱します。自律的に動くものを、どこまで信頼するか。その答えを、運用設計の段階で明確にしておく必要がある。信頼の境界線を引くのは、AIではなく人間の仕事だ。本書はその設計指針を与えてくれます。
Learning GitHub Copilot
GitHub Copilotを使い始めたころ、私はこれを「賢いオートコンプリート」だと思っていました。しかし、最近のCopilotは違います。コード補完だけでなく、チャットで質問に答え、コードの説明を生成し、テストまで書いてくれる。開発ワークフロー全体を変革する可能性を持っている。その進化に追いつくために、本書を手に取りました。
インフラエンジニアとしても興味深い内容が多かった。IaC（Infrastructure as Code、インフラのコード化）の自動化、マニフェスト（Kubernetesなどの設定ファイル）の生成、パイプラインの構築。私自身、本書のテクニックが役立った場面は少なくありません。
ただ、便利になればなるほど、新しい課題も生まれます。AIが生成したコードを、誰がどうレビューするのか。生成されたコードにバグがあったとき、責任は誰にあるのか。「AIがそう書いたから」では済まされない。コードの責任は、承認した人間にある。便利さの代償は、新しい責任——その両面を理解した上でCopilotを活用していきます。楽になった分だけ、考える責任が増えた。
Terraform in Depth
インフラをコードで管理する。Infrastructure as Code（IaC）は、もはや当たり前の実践になりました。その中でもTerraformは、クラウドを問わず広く使われている。しかし、基本的な使い方を覚えた後、どう深めていくか。本書は、TerraformとOpenTofuの両方をカバーしている点に惹かれて手に取りました。HashiCorpのライセンス変更以降、OpenTofuへの移行を検討している組織も多いでしょう。どちらを選んでも、基本的な概念やスキルは共通しています。ライセンスが変わっても、スキルは変わらない——その安心感は大きいと感じました。
大規模環境でのTerraform運用では、ステート管理が最も頭を悩ませる課題の1つです。ステートとは、Terraformが管理するインフラの「現在の状態」を記録したファイルです。このファイルが壊れたり、実際のインフラと食い違ったりすると、意図しない変更が発生する危険がある。ステートが壊れたら、インフラが壊れる——この現実に正面から向き合う必要があります。
インフラの信頼性を高めるためには、IaCの品質向上が不可欠です。アプリケーションコードにはテストを書くのが当たり前になっていますが、インフラコードはどうでしょうか。インフラコードも、テストなしには信頼できない——私はこの原則を実践に落とし込むために、本書を読みました。
Argo CD: Up and Running
IaCでインフラを定義できるようになったら、次はデプロイをどう自動化するか。GitOps（Gitリポジトリを中心にインフラやアプリケーションのデプロイを管理する手法）は、その答えの1つです。Gitリポジトリを唯一の真実の源とし、インフラの状態を宣言的に管理する。そのGitOpsの標準ツールとなったArgo CDを深く理解したくて手に取りました。公式ドキュメントには書かれていない設計判断の背景を知ることで、ツールの使い方だけでなく、思想を理解できると感じています。実践者が書いた本には、公式ドキュメントにはない「なぜ」がある——それが技術書を読む理由の1つです。
大規模な環境でも管理可能なGitOpsワークフローを構築するためのテクニックを学べました。GitOpsの導入は、デプロイの信頼性を高めるだけではありません。変更管理の透明性が向上し、何か起きたときの原因追跡が容易になる。Gitを見れば、本番が分かる——宣言的なインフラ管理とGitによるバージョン管理の組み合わせは、チーム開発との相性が非常に良いと感じています。
Effective Platform Engineering
IaCやGitOpsを導入し、インフラの自動化が進むと、次の課題が見えてきます。これらのツールやプラクティスを、どうやって開発チーム全体に展開するか。個人が使いこなしていても、チーム全体のものにならなければ意味がない。プラットフォームエンジニアリングは、その課題に対するアプローチです。しかし、技術的に優れたプラットフォームを作っても、開発者に使ってもらえなければ意味がない。使われないプラットフォームは、存在しないのと同じ——この現実は、プラットフォームチームにいると身に染みてわかります。
本書が一貫して主張するのは、プラットフォームを「プロダクト」として扱うというマインドセットです。プラットフォームチームはインフラを提供するだけでなく、開発者体験を向上させる製品を開発している。開発者は顧客であり、彼らのフィードバックを受けて改善を続ける。インフラチームではなく、プロダクトチームである——この視点の転換は、チームの動き方を根本から変えます。
この主張には強く共感する一方で、現実の難しさも感じている。「開発者は顧客」と言うのは簡単だ。しかし、顧客である開発者の要望をすべて聞いていたら、プラットフォームは一貫性を失う。標準化と柔軟性のバランス。セキュリティと利便性のトレードオフ。「顧客の声を聞く」と「顧客の言いなりになる」は違う。プロダクトチームとして振る舞うなら、時には「それはできません」と言う勇気も必要になる。本書はその難しさにも触れているが、私はもっと掘り下げてほしかった。
開発者の認知負荷を下げながら、システムの信頼性を維持する。このバランスは、簡単ではありません。抽象化しすぎると、開発者がトラブルシューティングできなくなる。抽象化が足りないと、認知負荷が下がらない。プラットフォームの成功は、開発者の生産性で測る——この原則を軸に、どこまで抽象化するかを判断していく必要があります。
Data Engineering Design Patterns
プラットフォームを運用していると、アプリケーションだけでなくデータパイプラインの信頼性も課題になってきます。データはシステムの血液のようなもので、流れが止まれば、ビジネスも止まる。データエンジニアリングにおけるデザインパターンを学びたくて手に取りました。デザインパターンとは、繰り返し現れる問題に対する定石のようなものです。先人たちが試行錯誤の末にたどり着いた解決策が、パターンとして整理されている。パターンには、先人の失敗が詰まっている——だから学ぶ価値がある。
データパイプラインの信頼性、データ品質のモニタリング、レイテンシーの管理。これらの課題は、従来のアプリケーション開発とは異なるアプローチが必要です。
たとえば、データパイプラインでエラーが発生したとき、どう対処するか。エラーを無視すればデータ品質が下がる。かといって、パイプライン全体を停止させれば、正常なデータまで届かなくなる。本書が紹介するパターンの1つは、問題のあるレコードを別の場所に退避させて後から対処する、というものです。1件のエラーで、100万件を止めるな——このパターンを知っているかどうかで、障害発生時の影響範囲が大きく変わります。
また、データが届かないことも障害です。この視点も重要でした。アプリケーションの障害は目に見えやすいですが、データパイプラインの遅延や欠損は気づきにくい。データの品質をどう保証するか。本書から多くのヒントを得ました。
ソフトウェア設計の結合バランス
データパイプラインでもアプリケーションでも、システムを構成する要素間の「結合」は避けて通れない課題です。疎結合が良い、密結合は悪い——そう教わってきたけれど、本当にそれだけで設計できるのか。この疑問に答えてくれるのが本書です。Vlad Khononov著『Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems』の翻訳本です。島田浩二さんの翻訳が秀逸で、原著の概念を自然な日本語で読めることに感謝しています。
しかし本書は、その固定観念を覆します。結合がなければ、ソフトウェアはシステムになれない。結合は悪ではない。結合は、システムを成り立たせる力だ。
この主張を読んだとき、私は自分の設計判断を振り返った。「疎結合にしなければ」という呪縛に囚われて、過剰に分離したことはなかったか。分離した結果、かえって複雑になったことはなかったか。あった。確実にあった。マイクロサービスに分割したはいいが、サービス間の通信が増えて、障害の原因追跡が困難になった経験。本書の主張は、そうした失敗を言語化してくれた。
本書の価値は、「結合」という概念を多次元で捉え直すところにあります。結合の強さだけでなく、結合の距離、結合の揮発性——複数の軸で分析することで、設計の判断基準が明確になる。これは手順書でもルールブックでもない。設計の意思決定に迷ったとき、インプットとして参照するための本です。どこまで結合を許容し、どこで切り離すか。その判断を支える思考の枠組みを、本書は与えてくれます。
ある書評では「今後10年くらいの基礎知識になる」と評されていました。私も同感です。マイクロサービス、モジュラーモノリス、ドメイン駆動設計——どのアーキテクチャを選んでも、結合のバランスは避けて通れない。正解を教えてくれる本ではなく、正解を見つけるための視点をくれる本。そういう本こそ、長く手元に置いておきたい。
Facilitating Software Architecture
結合のバランスを考え、設計判断を重ねていく。しかし、その判断は誰がするのか。アーキテクトの役割が変わりつつあります。一人の天才が全てを決める時代から、チーム全体でアーキテクチャを育てていく時代へ。アーキテクトは、決める人から、決められるようにする人へ——この変化は、私自身の仕事のやり方にも影響を与えています。
本書が提唱するのは、決定の権限を分散しつつ、責任の所在を明確にするアプローチです。誰でもアーキテクチャに関する決定を下せる。しかし、その前に適切な人々から助言を求めなければならない。権限は分散されるが、責任は決定者に残る。このバランスが、スピードと品質のトレードオフを緩和してくれます。
実務で特に役立っているのは、ADR（Architecture Decision Records、アーキテクチャ決定記録）の考え方です。なぜその設計判断をしたのかを記録しておく。これは、将来のインシデント対応や技術的負債の評価において価値がある。なぜこのシステムはこうなっているのか。その説明ができる状態を維持することは、チームの意思決定の質を高め、運用の効率化にも直結する。決定を記録しないのは、忘れるためである——だから記録が重要なのです。
Architecture Modernization
設計判断を記録し、チームでアーキテクチャを育てる。しかし、既存のレガシーシステムはどうするのか。新規システムなら理想的なアーキテクチャを追求できるが、現実には10年、20年と動き続けているシステムがある。レガシーシステムのモダナイゼーションに関わった経験がある人なら、技術だけでは解決しない問題があることを知っているはずです。コードを書き直しても、組織構造や開発プロセスが同じままでは、また同じ問題が生まれる。コードだけを変えても、問題は戻ってくる——本書は、この現実を正面から扱っています。
全てのシステムが同じ重要度ではない。競争優位の源泉となる部分と、汎用的な部分を区別し、限られたリソースをどこに集中すべきかを判断する。全部は直せない。だから、どこを直すか決める——この優先順位付けの考え方は、経営層との対話でも役立ちます。「なぜこのシステムを優先するのか」を説明できるようになる。
システムだけを変えても、組織が変わらなければ意味がない——この全体像を把握することは、ソフトウェアに関わるすべての人にとって重要です。なぜこのシステムがこの設計になっているのか。なぜこのチームがこの範囲を担当しているのか。技術的な判断の背景には、組織の歴史や力学がある。それを理解することで、日々の判断もより適切になるし、関係者との対話もスムーズになります。
Building Event-Driven Microservices, 2nd Edition
マイクロサービスを設計するとき、私たちはつい「サービス間の通信をどうするか」という問いから始めてしまう。しかし本書を読んで、その問いの立て方自体が間違っていたのかもしれないと気づかされました。Adam Bellemare氏による本書の初版は2020年に出版され、イベント駆動型アーキテクチャの実践的な指針として多くのエンジニアに読まれてきました。この第2版では、その後の技術進化と実践知が大幅に加筆されています。
本書が冒頭で引用するマクルーハンの「媒体はメッセージである」という言葉が象徴的です。私たちがどのような通信手段を選ぶかが、システムの設計だけでなく、組織構造やチーム間のコミュニケーションまで規定してしまう。リクエスト・レスポンス型の同期通信を選べば、サービス間の密結合が生まれる。イベントストリームを選べば、疎結合と自律性が生まれる。技術選択は、組織の形を決める選択でもある——コンウェイの法則を逆手に取るような視点が、本書には一貫して流れています。
著者が強調するのは、データ通信構造（Data Communication Structure）という概念です。ビジネスコミュニケーション構造（チームの編成）と実装コミュニケーション構造（コードとAPI）は多くの組織で意識されている。しかし、データをどう流通させるかという構造は、往々にして後回しにされる。その結果、他チームのデータが必要になるたびに、場当たり的なAPI連携やデータコピーが生まれ、システムは複雑化していく。データ通信構造の欠如が、モノリスを肥大化させる——この指摘は、私自身の経験とも重なります。
イベント駆動型マイクロサービスの本質は、データを「イベント」として永続化し、それを組織全体で共有可能にすることにあります。プロデューサーはイベントを発行する責任だけを負い、コンシューマーは必要なイベントを自分のペースで消費して独自のデータモデルを構築する。この分離によって、サービス間の依存関係が劇的に減少する。データは、実装に閉じ込めるものではなく、流れるものである——この発想の転換が、本書の核心です。
ただし、私はこの主張を手放しで受け入れているわけではない。イベント駆動型アーキテクチャには、リクエスト・レスポンス型にはない複雑さがある。イベントの順序保証、べき等性の担保、結果整合性への対応。「疎結合になる」という美しい言葉の裏には、新たな運用課題が潜んでいる。本書はその課題にも誠実に向き合っているが、現場で直面する泥臭い問題——たとえば、イベントスキーマの進化をどう管理するか、障害時のリカバリをどう設計するか——については、もっと深掘りしてほしかった部分もある。
本書の価値は、イベント駆動型アーキテクチャの「なぜ」を丁寧に解説している点にあります。単にKafkaの使い方を説明するのではなく、なぜイベントストリームが必要なのか、なぜ従来のアプローチでは限界があるのかを、組織論まで含めて論じている。リクエスト・レスポンス型マイクロサービスの欠点——ポイントツーポイント結合、依存スケーリング、分散モノリス化——を明確に言語化してくれたことで、私自身が過去に経験した失敗の原因が腑に落ちました。
イベントは、サービス間の会話ではなく、組織の記憶である——本書を読んで、私はイベントストリームの捉え方が変わりました。データパイプラインやメッセージキューとしてではなく、ビジネスの出来事を永続化した「正典的な記録」として捉える。その視点があれば、新しいサービスを立ち上げるときも、過去のイベントを再生してデータモデルを構築できる。実装の寿命よりもデータの寿命のほうが長い——この現実を直視したアーキテクチャが、イベント駆動型マイクロサービスなのだと理解しました。
Taming Your Dragon: Addressing Your Technical Debt
システム開発で必ず直面するのが、技術的負債です。どこを優先的に直すかを判断するには、技術的負債の性質を理解する必要がある。技術的負債は「ドラゴン」のようなものです。放っておけば大きくなり、いつか手に負えなくなる。しかし、完全に倒すこともできない。なぜなら、技術的負債は開発を進める限り必ず生まれるものだからです。だから、敵として戦うのではなく、適切に付き合い、共存の道を探る。ドラゴンは殺せない。だから、飼い慣らす——この比喩が、私には刺さりました。
本書を読んで、技術的負債を単なる技術的問題ではなく、トレードオフの問題、組織の問題、経済の問題として捉える視点を得ました。「技術的負債」という言葉は、金融の「負債」から借りてきた比喩です。しかし、両者には決定的な違いがあります。金融的負債は明確な金額があり、返済計画を立てられる。しかし技術的負債は、その量を正確に測定することが困難であり、返済のコストも不確実です。借金は金額がわかる。技術的負債は、わからない——このアナロジーの限界を、私たちはもっと意識すべきだと感じています。
ここで著者の主張に、私は半分同意し、半分疑問を持つ。「ドラゴンを飼い慣らす」という比喩は美しい。しかし、飼い慣らせるドラゴンと、飼い慣らせないドラゴンがいるのではないか。ある種の技術的負債は、時間が経つほど返済コストが指数関数的に増大する。そういう負債は、早めに倒すべきだ。すべての負債を「共存する相手」として扱うのは、危険な楽観主義に陥る可能性がある。本書の比喩を鵜呑みにせず、「このドラゴンは飼い慣らせるのか、それとも早めに倒すべきなのか」を見極める目が必要だと、私は考える。
技術的負債がなぜ蓄積していくのか、なぜ返済が後回しにされるのか。本書はその構造的な原因を可視化してくれます。原因がわかれば、より効果的な介入点を見つけることができる。技術的負債は倒すものではなく、飼い慣らすもの——「なぜこの改善が必要なのか」を経営層に説明するための理論的基盤を、本書から得ました。
Refactoring to Rust
技術的負債に対処する具体的な手法の1つとして、言語の移行があります。既存のコードベースを一から書き直すのではなく、段階的にRustに置き換えていくアプローチに興味があって手に取りました。全面的な書き直しはリスクが高い。だから、パフォーマンスクリティカルな部分から少しずつ置き換える。全部を書き直すな、一部を置き換えろ——この原則は、私の考え方にも合っています。
「Rustを学ぶ」本ではなく、「Rustを実務で使う」本だと感じました。言語を学ぶのと、言語で仕事をするのは違う——その差を埋めてくれる本です。
パフォーマンスクリティカルな部分や、メモリ安全性が重要な部分をRustに置き換えることで、システム全体の信頼性を向上させる。全面的な書き換えのリスクを避けながら、段階的に改善を進める方法論は、運用中のシステムを改善する際の参考になるでしょう。
Just Use Postgres!
言語の選択、アーキテクチャの設計、技術的負債の返済——これまで見てきた本は、どれも「何を選ぶか」の判断を扱っていました。しかし、時には「選ばない」という選択が最良のこともある。「PostgreSQLだけで十分」という主張は、時に過激に聞こえるだろう。しかし本書を読んで、その主張にはしっかりとした根拠があることがわかりました。新しい技術スタックを追加することは、運用の複雑性を高める。だから、既存の技術でできることは、既存の技術で解決すべきです。新しいデータベースを導入する前に、Postgresでできないか考える。この姿勢が、私の技術選択の基準になっています。
PostgreSQLは、リレーショナルデータベースとしての堅実な機能に加え、JSON処理、全文検索、地理空間データ、時系列データ、ベクトル検索まで対応しています。Postgresは、データベースではなく、プラットフォームである——この主張には説得力があります。
ただし、この主張を額面通りに受け取るのは危険だとも思う。「Postgresで十分」という言葉が、技術的判断の放棄に使われることがある。本当にPostgresで十分なのか、それとも単に新しい技術を学ぶのが面倒なのか。その区別は、案外難しい。本書の価値は「Postgresを使え」という結論にあるのではなく、「なぜPostgresで十分なのか」を考えるフレームワークにある。シンプルさには価値がある。しかし、シンプルさを言い訳にして、必要な複雑さから逃げてはいけない。
データベースの種類を減らすことで、運用の複雑性が下がるというメリットがあります。監視対象が減り、バックアップ戦略が統一され、チームが習得すべき技術スタックがシンプルになる。もちろん、PostgreSQLが適さないケースもあります。万能ではないことを認めた上で、どこまで対応できるかを知る。複雑さを減らすことも、エンジニアリングである——その境界線を理解することが、適切な技術選択には重要です。
The Software Engineer's Guidebook
ここまで、技術的なトピックの本を紹介してきました。しかし、技術を身につけるだけでは、キャリアは作れない。ジュニアからシニア、そしてスタッフエンジニアへ。キャリアの各段階で求められるスキルは異なります。しかし、次の段階で何が必要になるかは、今の段階からは見えにくい。キャリアの次の段階で必要なスキルは、今の段階では見えない——本書は、その見通しを与えてくれます。
技術的なスキルだけではキャリアは作れない。これは、ある程度経験を積むと実感することです。コードレビューの仕方、技術的な意思決定への関わり方、メンタリングの方法、組織への影響力の広げ方。コードを書く力と、キャリアを作る力は別物——両方を意識的に伸ばす必要があります。技術力は武器になる。しかし、武器だけでは戦場を選べない。
ここで私は、本書の主張に対してある種の居心地の悪さを感じる。キャリアを「設計」するという発想自体に、違和感がある。私のキャリアは、計画通りに進んだことがない。偶然の出会い、予期せぬ異動、想定外のプロジェクト。そうした「偶然」の積み重ねが、今の自分を作っている。本書が示すロードマップは参考になる。しかし、ロードマップ通りに進むことが正解だとは思わない。計画を持つことと、計画に縛られることは違う。本書を読みながら、私は自分のキャリアを「設計」するのではなく、「振り返る」ことの方が多かった。
バックエンドエンジニアのためのインフラ・クラウド大全
キャリアを考えるとき、自分に影響を与えてくれた人の存在は大きい。尊敬するnetmarkjpさんの著書です。私がエンジニアとして仕事をする中で、netmarkjpさんから学んだことは数え切れません。その方が書いた本となれば、読まないわけにはいかなかった。
本書は「基礎知識」と銘打たれた23章から構成されています。可用性、キャパシティ、パフォーマンス、監視、セキュリティ、DevOps、SRE——インフラに関わるエンジニアが押さえるべき領域を網羅的にカバーしている。しかし、この本の価値は網羅性だけではありません。各章に、実務経験に裏打ちされた「なぜそうするのか」が詰まっている。基礎とは、簡単という意味ではない。基礎とは、すべての基盤になるという意味だ。
バックエンドエンジニアがインフラを理解することの意味は、年々大きくなっていると感じます。クラウドネイティブな環境では、アプリケーションとインフラの境界が曖昧になっている。コンテナ、Kubernetes、オブザーバビリティ——これらを理解せずに、本番環境で動くシステムは作れない。アプリだけ書けても、本番では動かせない。本書は、その橋渡しをしてくれる一冊です。
作る、試す、正す。アジャイルなモノづくりのための全体戦略
作る、試す、正す。 アジャイルなモノづくりのための全体戦略bnn.co.jp
技術の基礎を固め、システムを作る。しかし、作ったものが「正しいもの」かどうかは、また別の問題です。市谷聡啓さんの到達点とも言える一冊です。『カイゼン・ジャーニー』『正しいものを正しくつくる』を経て、20年以上の実践知が凝縮されています。
本書のタイトル「作る、試す、正す」は、ものづくりの本質を端的に表しています。作って終わりではない。試して、学んで、正す。その繰り返しの中で、少しずつ「正しさ」に近づいていく。完成形を目指すのではなく、動き続けることがゴールだという考え方です。
私がこの本で最も考えさせられたのは、「正しさ」の捉え方でした。最初から正しいものを作ろうとすると、動けなくなる。かといって、何も考えずに作り始めると、迷子になる。本書が提示するのは、その中間にある姿勢です。「正しさ」は最初から存在するものではなく、作り、試し、正す過程で立ち現れてくるもの。だから、完璧な計画を立てることより、素早く試して学ぶ仕組みを整えることのほうが大事だと言う。
この考え方は、ソフトウェア開発に限った話ではないと思います。仕事全般、もっと言えば生き方にも通じる。最初から「正解」を知っている人はいない。やってみて、失敗して、修正して——その繰り返しの中で、少しずつ「あるべき姿」が見えてくる。正しさを探すのではなく、正しくなる状況をつくる。本書のこの言葉は、私の仕事だけでなく、物事への向き合い方そのものを言語化してくれました。
良いコードの道しるべ
素早く適応しながら開発を進める。しかし、その過程で生まれるコードの品質はどう担保するか。この本を読んで、私は「説明の仕方」を学びました。
動くコードを書くことは、実はさほど難しくない。大事なのは、書いたコードを他の人や将来の自分が読んで正しく理解できること——本書の冒頭にあるこの一文が、すべてを言い表しています。
本書の内容自体は、経験を積んだエンジニアにとって目新しいものではありません。命名、コメント、関数やクラスの分割、依存関係の整理、自動化テスト。どれも「基本」と呼ばれるものばかりです。しかし、この本の価値は内容の新しさではなく、説明の丁寧さにあります。なぜその原則が有用なのか、どうしてそう書くべきなのか——「なぜ」を省略せずに解説している。
私がこの本を評価するのは、「人に説明するときの参考になる」からです。チームに若手が入ってきたとき、コードレビューで指摘するとき、「なぜこう書くべきか」を説明する必要がある。そのとき、自分の頭の中にある暗黙知を言語化するのは意外と難しい。本書は、その言語化の手本を見せてくれます。基本を、基本のまま、分かりやすく伝える。それは簡単なことではない。
Clean Code, 2nd Edition
良いコードの基本を学んだら、次はその原則を深く考えたい。Robert C. Martin（Uncle Bob）による『Clean Code』の第2版です。2008年に出版された初版から16年、全面的に書き直されました。
初版を読んだのは何年も前のことです。その後、私のコードは変わったのか。正直に言えば、変わった部分もあれば、変わらなかった部分もある。だからこそ、第2版を手に取りました。自分がどこまで成長したのか、どこで止まっているのか、確認したかった。
第2版で印象的だったのは、AI時代に対する著者の姿勢です。「コードはいずれなくなる」「AIがすべて書いてくれる」——そんな予測に対して、Uncle Bobは明確に反論しています。コードは要求の詳細を表現したものであり、その詳細は抽象化できない。AIがどれだけ賢くなっても、仕様を厳密に記述する行為——つまりプログラミング——はなくならない。コードは消えない。なぜなら、コードとは要求そのものだから。
この主張に私は強く共感する。そして驚いたのは、第2版がここまで大幅にアップデートされていたことだ。16年という歳月は、ソフトウェア開発の世界では永遠に等しい。にもかかわらず、Uncle Bobは単なる改訂ではなく、現代の開発環境——AI、クラウド、分散システム——を踏まえた上で原則を再構築している。初版の「良いコードとは何か」という問いは変わらないが、その答え方が2025年の文脈に合わせて書き直されている。古典を現代に蘇らせるとは、こういうことなのだと思った。
本書の核心は、タイトルの通り「クリーン」であることです。しかし、「クリーン」とは完璧を意味しない。住めない「ショーハウス」ではなく、住める「クリーンな家」を目指す。クリーンなコードとは、維持し、拡張し、進化させても、その住みやすさを損なわないコードのこと。完璧ではないが、手入れされている。クリーンとは、完璧ではなく、ケアされている状態だ。
もう1つ、心に残った言葉があります。「私たちは書くよりも読む時間の方が圧倒的に長い」——だからこそ、読みやすいコードを書くことが、結果として書きやすさにつながる。速く行きたければ、うまくやれ（The only way to go fast is to go well）。この原則は、初版から変わらない。そして、16年経っても色褪せない。
型システムのしくみ
型システムのしくみ ― TypeScriptで実装しながら学ぶ型とプログラミング言語www.lambdanote.com
クリーンなコードを書くための原則を学んだ。では、その原則を支える道具——型システム——はどう動いているのか。遠藤侑介さんの著書です。Rubyコミッタであり、TypeProfの開発者であり、『型システム入門』の訳者でもある。その方が「型システムを実装しながら学ぶ」本を書いた。読まないわけにはいかなかった。
現代の開発環境では、コードを書いている最中にエラーが判明し、文脈に適した補完候補が提示される。当たり前のように使っているこの機能、その裏側で何が起きているのか。本書は、TypeScriptのサブ言語に対する型検査器を実装しながら、その「しくみ」を解き明かしていきます。
型システムの理論を学ぶ方法は、数学的な教科書を読むことだけではない。実装を通じて理解する道がある——本書はその道を示してくれます。真偽値と数値の型から始まり、関数型、オブジェクト型、再帰型、ジェネリクスへと段階的に進んでいく構成が秀逸です。各章で型検査器を拡張しながら、「なぜこの機能が必要なのか」「どう実装するのか」を体験的に学べる。
私がこの本を読んで得たのは、型システムへの「畏れ」と「親しみ」の両方でした。型システムは魔法ではない。人間が設計し、実装したものだ。しかし、その設計には深い思慮がある。エディタが「このコードは間違っている」と教えてくれるとき、その背後には型検査器の地道な仕事がある。その仕事の中身を知ることで、型に対する見方が変わりました。型は、プログラムを制約するものではなく、プログラムを守るものだ。
Fundamentals of Software Engineering
型システム、クリーンコード、アーキテクチャ——ここまで個別の技術トピックを深掘りしてきました。しかし、それらを俯瞰的に捉える視点も必要です。ソフトウェアエンジニアリングの基礎を幅広くカバーしている一冊です。
流行のフレームワークは数年で入れ替わる。しかし、基礎的な原則は変わらない。フレームワークは変わる。基礎は変わらない——長くこの業界にいると、この事実を繰り返し実感します。
AIがコードを生成してくれる時代になって、基礎の重要性はむしろ高まっていると感じます。AIの出力をそのまま受け入れるのではなく、評価し、改善し、統合する。その判断ができるのは、基礎を理解している人間だけです。AIの出力を評価できるのは、基礎を知っている人だけ——特定の技術やフレームワークに依存しない普遍的な原則を、改めて確認するために本書を読みました。
The Product-Minded Engineer
基礎を学び、技術を深め、システムを作る。しかし、技術的に正しいものを作ることと、ユーザーに価値を届けることは、必ずしも同じではありません。エンジニアとして長く仕事をしていると、技術的に正しいことと、ビジネスとして正しいことが一致しない場面に何度も遭遇します。コードが動くだけでは十分ではない。そのコードが、ユーザーにどんな価値を届けているのか。コードを書くことと、価値を届けることは違う——この違いを理解することは、プロダクトに関わるエンジニアにとって必須のスキルです。
エンジニアとして仕事をしていると、「ユーザーにとっての価値」と「技術的な正しさ」の間にギャップがあることに気づきます。たとえば、99.9%の可用性は技術者にとっては誇らしい成果でしょう。しかし、99.9%を裏返すと0.1%のダウンタイム。年間に換算すると約8時間の停止を意味する。ユーザーにとって、その8時間がどれだけ痛いか。99.9%は、ユーザーにとっては年間8時間の停止を意味する——技術的な数値をビジネスインパクトに翻訳できること。それがプロダクト思考の1つの形であり、本書はその視点を養う上で役立ちました。
The Engineering Leader
プロダクト思考を身につけ、技術とビジネスの両方を見られるようになる。すると、次に見えてくるのはリーダーシップの課題です。リーダーシップについて書かれた本は多いですが、本書は地に足のついた実践的なアドバイスが詰まっています。
誰かがキャリアを設計してくれるわけではない。自分で考え、自分で動く必要がある。自分のキャリアの責任者は、自分である——ある程度経験を積むと、この現実を受け入れざるを得なくなります。本書は、その受け入れた後に何をすべきかを具体的に示してくれます。
自分自身を導くこと、他者を導くこと、チームを導くこと、そしてチームを超えて導くこと。まず自分を導けないなら、他者は導けない——この順序は重要です。自己管理ができていない人間が、チームをまとめられるはずがない。
「マネージャーになる」ことだけがリーダーシップではない。ポジションに関係なく、チームに良い影響を与えることはできる。リーダーシップは、ポジションではなく行動である——この考え方は、IC（Individual Contributor）としてのキャリアを続ける上でも指針になっています。
"Looks Good to Me"
リーダーシップを発揮する場面は、会議室だけではありません。日々の開発で最も頻繁に行われるコミュニケーションの1つが、コードレビューです。コードレビューは、品質保証の手段であると同時に、チームの学習機会でもある。バグを見つけるだけがレビューの役割ではない。知識を共有し、コードの意図を確認し、チーム全体の理解を揃える。レビューは、コードのためではなく、チームのためにある——この視点で見ると、レビューの仕方が変わってきます。
コードレビューを「チームスポーツ」として捉える考え方に共感しました。個人の技術力を競う場ではなく、チーム全体の品質とスキルを向上させるための協働の場として位置づける。レビューコメントは、批判ではなく、贈り物である——この姿勢を持てるかどうかで、チームの雰囲気は大きく変わります。
しかし、私はこの「贈り物」という表現に、少しだけ引っかかる。贈り物は、受け取る側が喜ぶものだ。しかしコードレビューのコメントは、時に厳しいことも言わなければならない。「ここは根本的に設計を見直すべきだ」と指摘することは、贈り物というより、苦い薬に近い。「贈り物」という美しい比喩に逃げて、言うべきことを言わなくなるのは本末転倒だ。本書の主張は正しいが、その比喩を鵜呑みにすると、レビューが馴れ合いになる危険がある。厳しさと敬意は両立できる。そのバランスこそが、本当の意味での「贈り物」なのだと思う。
最後に「LGTM」と承認するのは人間です。その承認は、コードへの同意であると同時に、チームメンバーへの信頼の表明でもある。LGTMは、チームの信頼の証である——この認識を共有できているチームは、レビューが建設的になるし、心理的安全性も高まります。
おわりに
26冊。感想文を書き終えて、その数字を見つめている。多いのか少ないのか、正直わからない。まぁ多いか。「今年もたくさん読みましたね」と言われれば悪い気はしないし、「それだけ？」と言われればちょっとへこむ。結局、他人の評価を気にしている。読書量なんて自己満足だと言いながら、どこかで認めてほしがっている。
振り返ると、今年の本には共通点があった。
『Beyond Vibe Coding』は、AIに頼りすぎている自分を突きつけてきた。『LLMOps』は、正解が定義できないシステムの難しさを教えてくれた。『ソフトウェア設計の結合バランス』は、疎結合という呪縛から解放してくれた。『Taming Your Dragon』は、技術的負債と共存する道を示してくれた。どの本も、私に「それでいいのか」と問いかけてきた。
『Terraform in Depth』を読んだ夜のことを思い出す。ステート管理のベストプラクティスなんて、AIに聞けば30秒で返ってくる。でも私は、著者が過去にやらかした失敗談のほうを覚えている。「これで痛い目を見た」という告白。公式ドキュメントには絶対に載らない、その生々しさ。なぜか、そっちのほうが頭に残る。正解より失敗のほうが記憶に焼きつくのは、私という人間の性質なのかもしれない。
『Beyond Vibe Coding』を読んだとき、嫌な気持ちになった。自分のことを書かれている気がしたからだ。AIに聞いて、答えをもらって、なんとなくわかった気になる。その繰り返し。「なぜ」を考えなくなっていた。本を読むという行為は、その怠惰な自分への処方箋だったのかもしれない。ページをめくる時間だけ、「なぜ」を考え続けることができる。
本は答えをくれない。くれるのは「そうだろうか」という違和感だ。著者の主張に首をかしげる。その違和感を言語化しようとする。そうやって、自分の考えが少しずつ形になっていく。AIは答えを返してくれる。でも「そうだろうか」とは返してくれない。たぶん、そこが決定的に違う。
今年は、AI/LLMの運用が本格化した年だった。プラットフォームエンジニアリングが変わり、組織の話が増えた。技術だけ見ていればよかった時代は、とっくに終わっている。その変化に追いつこうとして、本を読んだ。読んで、ブログを書いて、登壇した。アウトプットしないと身につかない。言い聞かせるように、繰り返してきた。
でも、本当のことを言えば、追いつこうとしていたわけではないのかもしれない。変化の中で、自分が何者であるかを確かめたかった。AIがコードを書いてくれる時代に、なぜ私はエンジニアをやっているのか。答えは出ていない。出ていないけれど、本を読むたびに、その輪郭が少しだけ見えてくる気がする。
2025年はまだ3週間ほど残っている。年末年始に読んだ本は、来年の記事で。毎年同じことを書いている気がする。でも来年も、たぶんまた書くのだろう。誰に頼まれたわけでもないのに、12月になると、この作業を始めてしまう。
本を読むことに意味があるのか。正直、わからない。わからないけれど、やめられない。AIがどれだけ賢くなっても、300ページを読み通した時間は消えない。その時間が、自分を少しだけ変えてくれたような気がする。気がするだけかもしれない。でも、その「気がする」を信じて、来年も本を開くのだと思う。
正解を得ることだけが目的なら、エンジニアをやっている意味がない。はじめにで書いたこの言葉が、25冊の感想文を書き終えた今、少しだけ違って聞こえる。正解がないから難しい。正解がないから面白い。正解がないから、エンジニアを続ける価値がある。本を読む意味がある。来年もきっと、答えの出ない本を読み続けるのだろう。そして、また12月になったら、この記事を書く。それでいい。それがいい。
