はじめに
AIは、あなたが聞いたことにしか答えない。
聞かなかったことは、永遠に教えてくれない。あなたが何を知らないのか、AIは知らない。
2026年だ。AIに聞けば何でも教えてくれる。コードを書いてもらい、設計を相談し、ドキュメントを要約させる。便利だ。では、なぜ本を読むのか。300ページもある本を、最初から最後まで読む必要があるのか。
本は違う。本は、聞いていないことを語りかけてくる。知らなかった世界を見せてくる。持っていなかった問いを、手渡してくる。「そんなこと、考えたこともなかった」。そういう瞬間が、本にはある。AIとの対話では、たぶん起きない。
AIは効率的だ。知りたいことに、最短距離でたどり着ける。でも、最短距離で歩いていると、道の脇にあるものが見えない。著者が失敗した話、遠回りした話、「今思えば間違いだった」という告白。そういう「寄り道」が、不思議と頭に残る。正解は忘れる。でも、誰かの失敗談は覚えている。たぶん、人間の脳は感情を伴う記憶を優先的に保持するからだ。著者の後悔や苦労を読むとき、読者は追体験している。その感情が、記憶を定着させる。AIに「失敗談を教えて」と聞けば、一般化された失敗談が返ってくる。でも、それは「誰かの」失敗ではない。固有名詞のない失敗談には、感情が宿らない。
もう1つ。若者や学生は、そもそも問いを持っていない。何を聞けばいいか分からない。だから、AIに質問もできない。何が分からないのかも分からない。本を読めと言われても、何を読めばいいか分からない。本屋の技術書コーナーに行けば、棚一面に並ぶ背表紙の圧に押しつぶされそうになる。結局、何も買わずに帰る。
本は、そういう人に問いをくれる。「あ、これが分からなかったのか」。読み終わって初めて、自分が何を知らなかったのかが分かる。問いを持たない人間に、問いを渡す。それが、本にしかできないことなのだと思う。
そういう人のために、10冊を選んだ。
「若者にオススメ」と書いておきながら、自分もまだ若い方なのだと思う。少なくとも、将来の自分から見れば若い。ただ、激動の時代だ。技術だけ磨いていればいい時代は、終わりかけているのかもしれない。あるいは、もう終わっているのかもしれない。だから、技術以外の本も混ぜて紹介することにした。
先に断っておく。私はバックエンドエンジニアやインフラエンジニアからキャリアをスタートさせた人間だ。だから、フロントエンドやネイティブアプリに関しては、ほぼ紹介しない。偏っている。偏っているが、自分が読んでいない領域の本を勧めることはできない。プログラミング言語個別の書籍も紹介しない。どの言語を学ぶかは人によって違う。だから、言語に依存しない本を中心に選んだ。
この10冊が良い10冊かどうかは、分からない。私が良いと思った本が、誰にとっても良いとは限らない。だから、この記事を「正解」として読まなくていい。「こういう本があるんだな」という参考程度に。それでいいのだと思う。
それから、もう1つ。本を買うお金がないなら、図書館で借りればいい。技術書は高い。1冊3000円、4000円は当たり前だ。まず読む。金は後でいい。読んで、良かったら、いつか買えばいい。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
では、本題に入る。
技術の土台を作る
まずは土台だ。プログラミングを始める前に、あるいは始めたばかりの頃に、IT業界で使われる言葉を知っておく必要がある。語彙がなければ、技術書も読めない。先輩の話も分からない。AIに質問もできない。
1冊目：情報処理技術者試験の参考書（どれでもいい）
1冊目から、いきなり「どれでもいい」と言うのは無責任に聞こえるかもしれない。でも、本当にそうなのだ。
ITパスポートでも、基本情報技術者試験でも、応用情報技術者試験でも、高度試験でも。自分のレベルに合ったものを選べ。本屋で立ち読みして、7割くらい分かるやつを買え。分からなすぎると挫折する。簡単すぎると意味がない。
誤解しないでほしい。資格を取れと言っているわけではない。
「資格なんて意味ない」「資格より実務経験だ」——そういう声があるのは知っている。半分は正しい。資格を持っているだけでは、コードは1行も書けない。試験に受かっても、現場で即戦力にはなれない。それは分かっている。
もっと言えば、試験に受からなくてもいい。俺は全然受からないのに優秀なソフトウェアエンジニアを死ぬほど知っている。資格の有無と実力は、必ずしも一致しない。
でも、勉強するなら、頭に入った方がいいだろう。頭に入れるなら、試験を受けた方がいい。締め切りがあると、人は勉強する。試験日という締め切りがなければ、参考書は積読になる。金を払って申し込んで、日程を押さえて、会場に行く。その「仕組み」を使え。
なぜ資格試験を勧めるのか。語彙が手に入るからだ。
現場に出ると、専門用語が飛び交う。「スループットが落ちてる」「レイテンシがネックになってる」「冗長構成にしないと」「SLAどうする？」——こういう会話が、当たり前のように行われる。プログラミングはできるのに、この語彙がなくて会話に入れない。コードは書ける。でも、技術的な議論ができない。語彙がないと、会話にすら入れない。これは、よくある話だ。
試験勉強を通じて、開発特有の語彙が頭に入る。ネットワーク、データベース、セキュリティ、プロジェクトマネジメント。知識として知っているだけで、会話の輪に入れる。「あ、それ試験で出たな」という感覚で、先輩の話が理解できる。試験の内容を全部覚えている必要はない。語彙が残ればいい。それだけで、現場での学習速度が全然違う。
ここで正直に言う。実務経験の方が大事だというのは、その通りだと思う。本を読むより、コードを書いた方がいい。知識を詰め込むより、実際にシステムを動かした方がいい。2026年の今なら、分からないことはAIに聞けばいい。AIに疑問をぶつければ、理解も早く進む。
でも、経験がなければ、疑問も生まれない。
これは「経験を積め」という精神論ではない。構造の問題だ。語彙がなければ問いが立たず、問いがなければ経験を言語化できず、言語化できなければ次の学習に繋がらない。この悪循環を断ち切るには、どこかで語彙を入れるしかない。
何を聞けばいいか分からなければ、AIも使いこなせない。「スループット」という言葉を知らなければ、「スループットが落ちている原因は何ですか」とは聞けない。「処理が遅い」と「スループットが低い」は、同じ現象を指しているように見えるが、後者の方が解決策にたどり着きやすい。なぜなら、「スループット」という言葉には、それを改善するための知識体系が紐づいているからだ。語彙は、学習の入り口だ。入り口がなければ、どんなに優秀なAIがあっても、中に入れない。
IPA（情報処理推進機構）の試験は、日本のIT業界における共通言語を学ぶのに最も効率がいい。ネットワーク、データベース、セキュリティ、プロジェクトマネジメント、システム設計。全部、体系的にまとまっている。しかも、過去問が無料で公開されている。金がないなら、参考書すら買わなくていい。過去問だけで受かる人もいる。
2026年度から、応用情報技術者試験や高度試験がCBT（Computer Based Testing）方式に移行する。これまで年2回、決まった日に会場に足を運ばなければならなかったのが、自分の都合に合わせて受験できるようになる。受験のハードルは確実に下がった。
どの参考書がいいかは、正直、好みだ。キタミ式が好きな人もいれば、技術評論社の「合格教本」シリーズが好きな人もいる。Amazonのレビューを見て、自分に合いそうなのを選べばいい。図書館にあることも多い。
もう1つ言っておく。ITに興味があるけど、プログラミングには興味がない。そういう若者は多いと思う。「エンジニアになりたいけど、コードを書くのはちょっと……」という人。そういう人こそ、まず資格を取れ。プログラミングができなくても、ITの世界で活躍する道はいくらでもある。インフラ、セキュリティ、プロジェクトマネジメント、ITコンサル。そのすべてにおいて、資格で得た知識と語彙は武器になる。
繰り返す。資格を取ることが目的ではない。語彙を入れることが目的だ。語彙があれば、AIにも質問できる。語彙があれば、技術書も読める。語彙があれば、先輩の話も分かる。
入り口を作れ。話はそれからだ。
システムの基盤を理解する
コードを書けるようになっても、それだけではシステムは動かない。サーバー、ネットワーク、データベース、OS。アプリケーションの下にあるレイヤーを理解しなければ、本番環境で動くものは作れない。ここでは、システムを支える基盤技術について学ぶ本を4冊紹介する。
2冊目：バックエンドエンジニアのためのインフラ・クラウド大全
コードを書けるようになった。アプリケーションが動くようになった。でも、本番環境にデプロイしようとすると、急に分からないことだらけになる。サーバーって何？ネットワークって何？クラウドって何？
アプリだけ書けても、本番では動かせない。
この本は、そのギャップを埋めてくれる。バックエンドエンジニアに求められるインフラ・クラウド領域の基礎知識が、1冊にまとまっている。情報システムの基礎から、可用性、キャパシティ、パフォーマンス、監視、セキュリティ、DevOps、SRE。現場で必要になる知識が、体系的に整理されている。全23章、544ページ。分厚いが、それだけの価値がある。
「基礎知識」と聞くと、簡単そうに思えるかもしれない。でも、違う。基礎とは、簡単という意味ではない。基礎とは、すべての土台になるという意味だ。なぜこの混同が起きるのか。学校教育のせいだろう。教科書は「基礎→応用」の順に並んでいて、基礎は最初に習う、つまり簡単なものだと刷り込まれる。でも、実際には逆だ。基礎は最後に理解できる。応用を経験して初めて、基礎の意味が分かる。この本に書かれていることは、10年後も20年後も変わらない原則ばかりだ。最初は分からなくていい。分からないまま読み進めて、5年後に読み返したとき、「ああ、これはこういう意味だったのか」と分かる。それが基礎だ。
構成も良い。分野ごとに解説がまとまっているが、章末で「あわせて読みたい」範囲が紹介されている。1つの章を読み終わると、「次はこっちも読んでみるか」となる。ちょっとだけ調べるつもりが1時間経っている。そういう本だ。
クラウドネイティブな環境では、アプリケーションとインフラの境界が曖昧になっている。コンテナ、Kubernetes、オブザーバビリティ。これらを理解せずに、本番環境で動くシステムは作れない。「俺はアプリ側だから」では通用しない時代だ。
この本は、その橋渡しをしてくれる。
以前、自分が書いたアプリケーションを本番環境にデプロイしたとき、ローカルでは動いていたのに、本番では動かなかった。原因を調べるのに丸1日かかった。ネットワークの設定だった。そのとき、「アプリを書けるだけでは、本番では戦えない」と痛感した。この本があの頃の自分にあったら、もう少し早く原因にたどり着けたかもしれない。
3冊目：SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策
データベースは、難しい。
でも、難しいのに、簡単にできてしまう。ORMを使えば、SQLを書かなくてもデータを取得できる。CREATE TABLE文を書けば、テーブルが作れる。動く。動いてしまう。
だから、問題に気づくのが遅れる。
テーブル設計の失敗は、ソースコードの失敗よりもリファクタリングが難しい。データが入ってしまってからでは、修正のコストが跳ね上がる。だから、最初から正しい設計を知っておく必要がある。
この本は、データベースプログラミングで陥りがちな失敗（アンチパターン）を体系的にまとめた本だ。カンマ区切りで値を格納する「ジェイウォーク」。外部キーを張らない「キーレスエントリ」。1つのカラムに複数の意味を持たせる「マルチカラムアトリビュート」。NULLの扱いを間違える「アンビギュアスグループ」。名前を聞いただけで「あ、やったことある」と思う人は多いはずだ。
第2版では、新規書き下ろしの章と15のミニ・アンチパターンが加わった。特にミニ・アンチパターンは実務的な内容が多く、「自分もこの問題にハマった」「こうやって解決した」と思える内容が詰まっている。
それなりにエンジニアをやっていると、多くのアンチパターンは踏んだことがある。でも、それを他者に体系的に伝えるのは難しい。自分の設計がシステムにどのような影響を与えていくかを経験として学習する機会は、意外と少ない。だからこそ、この本で先人の失敗を学んでおく価値がある。
不思議なことがある。ベストプラクティスを調べて実装しても、想定通りにならないことが多い。環境が違う、前提が違う、規模が違う。でも、アンチパターンは違う。アンチパターンを実装すると、想定通りに困る。なぜか。アンチパターンは「制約違反」だからだ。リレーショナルデータベースには設計原則がある。その原則を破れば、必ず不整合やパフォーマンス問題が起きる。ベストプラクティスは「この文脈では有効」という条件付きだが、アンチパターンは「どの文脈でも有害」という普遍性を持つ。だから、何をすべきかより、何をすべきでないかを学ぶ方が、確実に役に立つ。
4冊目：モダンオペレーティングシステム 第5版（上・下）
データベースの次は、さらに下のレイヤーだ。OSの話をする。
OSの中身を知りたければ、この本を読め。
プロセスとスレッド、メモリ管理、ファイルシステム、入出力、デッドロック、仮想化とクラウド、マルチプロセッサシステム、セキュリティ。OSを構成する要素が、網羅的に解説されている。上下巻合わせて1000ページ超。分厚いが、それだけの価値がある。
コンピュータ・サイエンスの分野で世界的な定番となっている教科書だ。21年ぶりに日本語版が復活した。第5版では、Windows 11やSSDなど、最新のトピックまで詳しく解説されている。セキュリティの章は大部分が書き直された。
各章末には585題もの演習問題がある。基礎知識の確認から、プログラミングや計算、さまざまな状況への対応まで。問題に取り組むことで、その章で学んだことの理解が深まる。
上下巻で1万円を超える。学生には厳しい価格だ。だから言う。図書館で借りろ。大学の図書館には、たいてい置いてある。この本自体がなくても、類書は置いてある。
以前、というかかなり昔にマルチスレッドのバグで丸2日を溶かしたことがある。ログを見ても再現しない。デバッガをつけると動く。原因はスレッド間のレースコンディションだった。そのとき、「なぜプロセスとスレッドが分かれているのか」「なぜロックが必要なのか」を、初めて本当に理解した。この本を先に読んでいたら、もう少し早く気づけたかもしれない。この辺はパタヘネ本など他にも良書があるのでそれらでもよい。
5冊目：データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理
OSの次は、分散システムだ。現代のアプリケーションは、1台のサーバーでは動かない。
分散システム設計のあらゆるトピックを660ページに渡って網羅する、百科事典のような書籍。バックエンドエンジニアなら、いつかは読むべき本。
データベース、レプリケーション、パーティショニング、トランザクション、分散システムの課題、バッチ処理、ストリーム処理。データを扱うシステムを設計する上で知っておくべき知識が、体系的に整理されている。
この本の特徴は、何ができるか（WHAT）だけでなく、なぜそうなっているか（WHY）まで説明されていることだ。「なぜレプリケーションが難しいのか」「なぜ書き込み性能が高いマルチリーダーではなくシングルリーダーが広く使われているのか」。そういった「なぜ」を知ることができる。
正直、難しい。分散システムに関わっていないと、なかなかピンとこない部分もある。入門として読む本ではない。でも、大規模でデータ量が多いアプリケーションを設計するときには、必ず役に立つ。
2026年2月に原著の第2版が出版される予定だ。翻訳版も出てほしい。というか、出てくれ。頼む。この記事を定期的に更新するつもりなので、第2版が出たら差し替える。
プログラマーとしての姿勢を学ぶ
ここまで、技術の土台とシステムの基盤について紹介してきた。ここからは、少し違う話をする。何を学ぶかではなく、どう向き合うかの話だ。
技術は日々変わる。でも、変わらないものもある。良いコードを書くための考え方、問題に向き合う姿勢、キャリアを築くためのマインドセット。ここでは、プログラマーとしての「あり方」を教えてくれる本を紹介する。
6冊目：達人プログラマー（第2版）熟達に向けたあなたの旅
1999年に出版されて以来、世界中のプログラマーに読まれ続けている名著。2019年に20周年記念版として大幅に改訂され、第2版が出た。
原題は「The Pragmatic Programmer」。Pragmaticとは、実用本位、実践的という意味だ。理論だけではなく、現場で使える知恵が詰まっている。
この本の特徴は、コーディング技法だけでなく、エンジニアとしてのものの見方を教えてくれることだ。DRY原則、ETC原則（Easier To Change）、凝集度と疎結合。そういった技術的な話もあるが、それだけではない。開発の進め方、コミュニケーションの取り方、キャリアの考え方。プログラマーとして生きていくための姿勢が書かれている。
「割れた窓」の話は有名だ。悪い設計、誤った意思決定、質の悪いコード。それを放置すると、ネガティブな考えが伝染する。だから、最初の「割れた窓」を見つけたら、すぐに直せ。自分もつい、割れた窓のようなコードを書いてしまったことがある。その後に若いプログラマに保守を任せたとき、いい書き方になっていなかった。元がよくない書き方だから、指摘するのも躊躇してしまう。
「石のスープ」の話も印象的だ。大きな変化を一度に起こそうとすると、周囲は萎縮する。だから、小さく始めて、少しずつ巻き込んでいく。未来を少し垣間見せるだけで、みんな集まってくる。
読み直すたびに、新しい発見がある。入門者には手引きとなり、ベテランでも読み返すたびに得るものがある。年に1回は読み返し、達人プログラマーを志していきたい。そういう本だ。
20年以上読み継がれてきたからこそ、普遍的な価値がある。古い本だから読まなくていい、ということはない。
7冊目：プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則
KISS、DRY、YAGNI、SOLID。プログラミングの世界には、先人たちが積み上げてきた原理原則がある。でも、それらを体系的に学ぶ機会は意外と少ない。現場で「DRYって何？」と聞かれて、ちゃんと説明できるだろうか。
この本は、そういった原理原則を101個集めて、1冊にまとめたものだ。
「3年目までに身につけたい」という副題がついているが、3年目以降の人が読んでも学びがある。むしろ、色々な現場を経験した人の方が、それぞれの原理原則の含蓄を感じられる。「あのとき、これを知っていれば……」と思うことが、きっとある。
この本の特徴は、各項目に「なぜそれが必要か」が明確に説明されていることだ。Howだけでなく、Whyが書かれている。だから、抽象的な情報でありながら、実際に使える知識になる。「How to本」ならぬ「Why本」だ。
もう1つの特徴は、各項目に出典書籍と関連書籍が記載されていることだ。「達人プログラマー」「アジャイルソフトウェア開発の奥義」「プログラマが知るべき97のこと」など、名著への参照がちりばめられている。次に読む本を選ぶときの索引としても使える。
具体的なコード例がないことを不満に思う人もいるかもしれない。でも、それは意図的だ。言語に依存しないからこそ、どんな言語でプログラミングしていても適用できる。抽象度が高い分、適用範囲は果てしなく広い。
本書で「抽象」を押さえたら、「具象」も押さえたい。コードの書き方を扱った本では、『リーダブルコード』（Dustin Boswell、Trevor Foucher著、2012年）が定番として挙げられることが多い。変数名の付け方、コメントの書き方、制御フローの整理。確かに実践的な内容だ。でも、私のおすすめは『ルールズ・オブ・プログラミング』（Chris Zimmerman著、2023年）の方だ。
『ルールズ・オブ・プログラミング』は、『Ghost of Tsushima』を開発したSucker Punch Productionsで実際に使われている21のルールをまとめた本だ。「最適化の前に単純化せよ」「コードを制約で囲め」「プログラマーの時間はCPUの時間より貴重」。ゲーム開発という、パフォーマンスと保守性の両方が求められる過酷な現場で磨かれたルールには、説得力がある。
もし「リーダブルコードを読め」と勧めてくる人がいたら、「ルールズ・オブ・プログラミングは読みましたか？」と聞いてみてほしい。読んだ上でリーダブルコードを勧めているなら、それは信頼できる。読んでいないなら、まず読んでもらってから、改めて話を聞けばいい。
技術以外のスキルを身につける
プログラミングができればエンジニアとして成功できる。そう思っていた時期が、私にもあった。でも、現実は違う。
あるプロジェクトで、技術的には正しい提案をしたことがある。でも、通らなかった。別のエンジニアの、技術的にはやや劣る提案が採用された。理由は「あいつの方が話しやすい」「あいつの言うことなら安心できる」だった。悔しかった。でも、それが現実だった。
技術力だけでは、キャリアは伸びない。なぜか。2つの構造的理由がある。1つは、評価の非対称性だ。あなたの技術力を正しく評価できる人は、組織の中に何人いるか。CTOと数人の先輩エンジニアくらいだろう。でも、あなたのコミュニケーション力は、同僚全員が評価できる。評価が多数決に近い以上、「多くの人に見えるスキル」を持つ人が有利になる。もう1つは、レバレッジの問題だ。自分一人の技術力には限界がある。でも、他者を巻き込む力は、レバレッジが効く。10人を動かせる人は、自分1人で10倍の成果を出す人より、組織では重宝される。これが良いことかどうかは別として、構造としてそうなっている。だから、技術以外のスキルも身につける必要がある。
8冊目：SOFT SKILLS ソフトウェア開発者の人生マニュアル 第2版
技術書ではない。でも、エンジニアにとって必読の1冊だ。
この本のサブタイトルは「ソフトウェア開発者の人生マニュアル」。技術習得法やキャリア構築法だけでなく、セルフマーケティング、生産性、資産形成、フィットネス、マインドセット。人生全般をより良く生きる方法が書かれている。
「技術者の地位は技術力の高さではなく、他者の評価で決まってしまう」。これは厳しい現実だ。でも、現実を直視した上で、どうすればいいかを教えてくれる。キャリアをビジネスとして捉え、自分自身をマーケティングする。そういう視点を持つことの重要性が説かれている。
正直に言うと、後半の資産形成やフィットネスの章は、ソフトウェア開発者に特化した話題ではない。不動産投資や筋トレの話がかなり詳しく書かれていて、「それ、この本でそこまで書く必要がある？」と思う人もいるだろう。私もそう思った。読む人を選ぶ本、という感想もある。
でも、前半のキャリア、セルフマーケティング、学習、生産性の章は、間違いなく読む価値がある。技術力だけでは生き残れない時代に、何を身につけるべきか。その指針を与えてくれる。既に読者が若手ソフトウェアエンジニアの場合にはソフトウェアエンジニアガイドブック―世界基準エンジニアの成功戦略ロードマップも合わせておすすめしたい。
設計とアーキテクチャを深める
技術以外のスキルも大事だ。でも、技術を疎かにしていいわけではない。むしろ、技術力があってこそ、それ以外のスキルが活きる。
コードが書けるようになったら、次は設計だ。どうやってモジュールを分けるか。どうやってシステム全体を構成するか。設計の良し悪しが、システムの保守性を決める。ここでは、設計とアーキテクチャについて学ぶ本を2冊紹介する。
9冊目：アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築
「アーキテクトになりたい」「アーキテクトとして成長したい」。そう思ったとき、何から始めればいいのか分からない人は多い。相談できる先輩や上司が身近にいないこともある。
この本は、アーキテクティングという世界を探検するにあたっての「地図」となる本だ。アーキテクトの「最初の1冊」として、これ以上のものはない。
第2章「ソフトウェア設計」では、V字モデル、4つの抽象（アーキテクチャ設計、モジュール設計、コンポーネント設計、クラス設計）、SOLID原則、設計パターンと、設計を語っていく上での基本概念が密度高く語られる。この章だけでも読んでおけば、設計の話をするときに「何を言っているのか分からない」という状態にはならない。
オライリーの『ソフトウェアアーキテクチャの基礎』も良書だが、どこかアカデミックさがあり、ある程度の前提知識が要求される。それに比べて本書は、初学者にも分かりやすく書かれている。ユースケースに沿った解説があるのでおすすめである。
第6章「アーキテクトとしての学習と成長」も見逃せない。普段のプロジェクトの中で表立って取り上げられることの少ないテーマだ。「自分がアーキテクトになっていくためにどんな心構えが必要なのか」と悩んでいる人には、とても学びの多い内容になっている。
10冊目：ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則
「疎結合にしろ」「密結合は悪だ」。そういうスローガンは、現場でよく聞く。でも、疎結合とは、具体的にどの程度が「疎」なのか。それを説明できる人は、意外と少ない。
この本は、「結合」という概念を徹底的に掘り下げた本だ。本書の主張は明快だ。結合をゼロにすることは不可能であり、むしろ適切な結合を選択することが重要。「疎結合至上主義」ではなく、「結合の均衡化（Balancing Coupling）」という視点を提示している。
構造化設計におけるモジュール結合、オブジェクト指向におけるコナーセンス。それらを一通り説明した後、独自の「統合強度」モデルが導入される。強度・距離・変動性の関係性を解き明かし、実際の設計においてそれらをどう均衡化するのかが、具体例を用いて示される。
印象的だったのは、結合の「距離」という概念だ。同じ強度の結合でも、それが文レベル、メソッドレベル、オブジェクトレベル、サービスレベルのどこに存在するかによって、変更のコストが大きく異なる。マイクロサービスアーキテクチャの設計において、この視点は特に重要だ。
この本は手順書でもルールブックでもない。この本に書かれている通りにモジュール設計をすれば自然とバランスの良い設計になる、という話ではない。でも、方針決定やレビュー時に迷ったとき、この本に書かれているような発想をインプットに意思決定すると、判断の精度が上がる。
おわりに
10冊を紹介した。
この記事を読んだからといって、明日から何かが変わるわけではない。たぶん来週も、再来週も、同じような日々が続く。10冊すべてを読む必要もない。というか、いきなり10冊読み終わることなんてない。自分も、速読で済ませようとしたことがある。でも、身につかなかった。1冊読んで、合わなければ閉じればいい。それでいい。
派手な近道はない。地味な積み重ねだけがある。常に今の自分で戦うしかない。
1つだけ、注意しておきたいことがある。誰かを冷笑したり、バカにしたりするのは楽だ。でも、その道に未来はない。他人をバカにしない唯一の方法は、自分が自分の枠の中で精一杯頑張ることだ。精一杯やっている人間は、他人を笑っている暇がない。
私も、達人と呼ばれたい者の1人だ。まだ諦めているわけではない。諦めているわけではないが、達人になれるかどうかは分からない。分からないまま、コードを書いている。本を読んでいる。
冒頭で、本は問いをくれると書いた。知らなかった世界を見せてくれると書いた。
10冊のうち、どれか1冊でも手に取ってもらえたら、と思う。読み終わったとき、新しい問いが生まれているかもしれない。「あ、これが分からなかったのか」。そう思えたら、その本は、あなたにとって正解だったのだと思う。
本との出会いは、計画だけでは起きない。本屋に行くと、紹介した本の隣に、もっと自分に合った本が置いてあるかもしれない。図書館で棚を眺めていると、別の本が目に入るかもしれない。そういう出会いは、検索では起きない。AIにも、たぶん見つけられない。
だから、本屋に行ってみてもいいかもしれない。図書館に寄ってみてもいいかもしれない。棚の前に立ってみる。それだけでいい。
何かが始まるかどうかは、分からない。分からないが、始まるとしたら、たぶんそこからだ。
