技術書の読み方を変えた話｜積読ゼロ・課題起点・月1冊で回す方法
SES 1年目の終わりごろ、本棚に積読が4冊並んでいた。
「リーダブルコード」「Webを支える技術」「Clean Architecture」。それと、もう表紙も思い出せない薄い入門書。全部、1章か2章まで読んで止まっていた。
「読んでいない本がある」という後ろめたさが、常に頭の片隅にあった。次の本を買うたびに罪悪感も一緒に積んでいた。なのに、また別の本を注文していた。
本を読みたいという気持ちは本物だった。でも、読み方を知らなかった。
本棚に「後ろめたさ」だけが積まれていた時期
当時の読み方はシンプルだった。「1ページ目から順番に読む」。本とはそういうものだと思っていたし、途中でやめるのは「挫折」だという認識があった。
問題は、技術書の多くが「1章から順番に読まれること」を前提に作られていないということだ。特にリファレンス系・辞書的な技術書は、必要なときに必要な箇所を引くための本だ。前から順番に読んでいくと、途中で関係のないトピックが延々と続き、自然と飽きる。
そして飽きた本は積まれる。
もうひとつの失敗パターンが「目的なしに買う」だ。話題になっているから、レビューが高いから、先輩が持っていたから。そういう理由で買った本は、手元に届いた瞬間に「積読予備軍」になる。自分が今抱えている課題との接点がないから、開いても頭に入らない。ページをめくってはいるが、読んでいない状態になる。
この2つのパターンで、当時の本棚は純粋に「お金の無駄遣い記録」になっていた。あの頃に積んだ本を買い直す費用を計算したくない。
「1章から全部読む」が失敗しやすい理由
なぜ「1章から全部読む」が失敗しやすいのか、今ならわかる。
技術書の1章はたいてい「概要・背景・なぜこの技術が生まれたか」という内容だ。これは読み終えたあとの理解を深めるための章であって、初読では抽象度が高くて掴みにくい。それを頑張って読み進め、2章・3章と進むうちに「自分が読みたかった箇所」にたどり着く前に失速する。
400ページある本を最初から読もうとすれば、目的地にたどり着く前に疲れる。これは当然のことで、本の構成が悪いわけでも読者の根気がないわけでもない。ただ、読み方が合っていなかっただけだ。
正直に言うと、あのころの読み方は「勉強している感」を得るための行為だったのかもしれない。本を買って開いて読む、という動作を「学習」と混同していた。
本を読んだかどうかより、それが仕事や思考に影響を与えたかどうかのほうが本質だ。そこに気づくまでに、かなり時間がかかった。
買う前に「1つの問いを立てる」
読み方が変わったきっかけは、シンプルなルールを1つ設けたことだ。
本を買う前に「自分はこの本で何を解決したいか」を言語化する。
Amazon のカートに入れる前に、そのタイトルで検索して目次を確認する。「第5章：○○の設計パターン」が読みたいなら、その本を買う理由がある。目次を読んでも刺さるページが1〜2章分もなければ、その本は今の自分には必要ない。
これを始めてから、衝動買いが劇的に減った。代わりに、買った本はほぼ確実に「目的の箇所」を読むようになった。
X やテックブログで「この本が良かった」という投稿を見て欲しくなることは今もある。でも、その本が「今の自分の課題」に当てはまるかを一度立ち止まって考える。刺さらないならブックマークだけして保留にする。1〜2ヶ月後に見返して、そのときの課題と合っていたら買う。
この「保留リスト運用」に変えてから、積読はほぼゼロになった。
気になる章だけ読む、という「罪悪感」を手放す
「本は最初から最後まで読むべき」という感覚は、けっこう長く残っていた。
今の読み方は「目次を読んで、気になる章に直接飛ぶ」だ。前後の脈絡なしに気になる章だけ読む。理解が浅いと感じたら前後の章を補足で読む。最後まで読まなくても「この本から得たいものは得た」と判断したら終わりにする。
最初はどこか「ずるい読み方」をしている感覚があった。でも考えてみれば、これは普通のことだ。ネットの記事も気になるセクションにスクロールして読む。技術ドキュメントも必要な箇所だけ読む。なぜ本だけ「1ページ目から」にこだわっていたのか、今となっては謎だ。
この読み方に変えてから、1冊あたりに使う時間が大幅に減った。代わりに得る密度は上がった。飽きる前に「得るべきものを得た」状態で終われるので、途中で投げることもほぼなくなった。
月1冊・課題起点のサイクル
今の読み方のルールはシンプルだ。
月1冊。仕事で出てきた課題を解決する本を読む。
1ヶ月エンジニアとして仕事をすれば、必ず「ここをもっと理解したい」「このやり方に自信がない」という箇所が出てくる。コードレビューで指摘された設計の観点、チームで議論になったアーキテクチャの判断、うまく言語化できなかったトレードオフの話。
そのタイミングで「今月の1冊」を選ぶ。課題が先にあって、本が後から来る。
このサイクルで回すと、本の内容と実務がリンクするため記憶への定着が全然違う。「あのプロジェクトで詰まったときに読んだ本」という文脈が付くと、内容を思い出しやすい。数年後に同じ課題が出てきたとき、本の具体的な章まで頭に浮かぶことがある。
逆に「今は特に課題がない」という月は、無理に本を探さない。課題がないなら、本を読んでも吸収率が下がる。そういう月は積読を消化するか、技術以外の本を読む。
月1冊という制約も、あえて設けている。「今月は2冊読もう」と思うと、選ぶ本の基準が甘くなる。「1冊だけ」という制約が、選書の精度を上げる。
あ、余談だが。「月1冊なんて少なすぎる」と言う人もいる。速読を活用して月10冊読む、という人にも会ったことがある。やり方は人それぞれだと思う。ただ、冊数よりも「読んだあとに何か変わったか」のほうが自分には重要で、月1冊でもその本が実際に仕事に影響したなら十分だと割り切っている。
印象に残っている3冊
読んだ本の中で、今でも思い出すものが3冊ある。3冊とも、技術書ではない。
金持ち父さん・貧乏父さん
エンジニアとして働き始めてから数年間、「お金の仕組み」をまともに考えたことがなかった。給料は毎月決まった額が入り、そこから使って残れば少し貯まる、という程度の認識だった。
この本を読んで、自分がどれだけ「お金の使い方・増やし方」について考えていなかったかを実感した。フリーランスになってから iDeCo・NISA・小規模企業共済を組み合わせて資産形成しているのも、この本が金融リテラシーを引き上げてくれた影響が大きい。
エンジニアが読むべき本として「技術書のみ」を考えていた時期が、正直もったいなかった。
エンジニアのためのマネジメントキャリアパス
SES で働いていた時期、「このままエンジニアを続けるとどうなるのか」「マネジメントに進むべきか、スペシャリストでいくべきか」という漠然とした不安があった。キャリアについて考えようとするたびに、比較対象も道標もなくて頭の中がぐるぐるするだけだった。
この本を読んで、キャリアの選択肢が「地図として」頭に入った。テックリード・エンジニアリングマネージャー・スタッフエンジニアという役割の違いが整理されて、不安の正体が「道が見えていなかっただけ」だと気づいた。全部解決したわけではないが、悩みの解像度が上がった。それだけで気持ちが楽になった。
7つの習慣
同僚に「これは絶対読んだほうがいい」と渡された本だ。軽い気持ちで受け取ったが、読んでみると確かに重かった。内容の抽象度が高く、最初は半分も頭に入らなかった。
先に漫画版を読んだ。漫画で全体像を掴んでから、改めて本編を読んだらすんなり入ってきた。あの「漫画版 → 本編」というルートは、難解な本を読む方法として今も使っている。難しそうな本は、まず入門書や要約版で全体像を把握してから本編に入るほうが吸収率が高い。
余談だが。同じ同僚から「行動経済学の本も読んでみろ」と言われた。正直、これは当時の自分には刺さらなかった。同じ人間が勧めた本でも、タイミングや課題感によって全然響き方が違う。本との相性は「今の自分の文脈」で決まる。合わなかった本を読んだことは無駄ではないが、それより「今の課題に合った本」を選んだほうが費用対効果は高い。
技術書以外も読む理由
エンジニアが読む本として「技術書」しか選択肢に入っていない人は、少し損をしていると思っている。
実際に今でも印象に残っている本は全部、非技術系だった。お金・キャリア・習慣。これらは技術と切り離せない課題だ。コードは書けても自分のキャリアを設計できない、仕事は速くても収入の管理が雑、そういう状態のエンジニアは珍しくない。
技術的な課題には技術書が有効だ。でも「技術以外の課題」を技術書で解決しようとしても無理がある。
課題起点で本を選ぶ、というルールを徹底すると、自然と技術書以外も手に取るようになる。「今の自分の課題は何か」を先に考えるからだ。
体系的なスキル習得では、本と並行して Udemy のコースも活用している。本では補えない「動いているコードを見ながら学ぶ」体験ができる点が強みだ。特に新しいツールや言語の入門には、本よりも短期間で全体像が掴める。セールのタイミングで気になるコースをまとめて購入し、課題が出てきたタイミングで見る、というやり方が合っている。 ※本リンクはアフィリエイトリンクです
よくある質問
Q. 技術書を読んでも忘れてしまいます。どうすればいいですか？
忘れるのは、課題と本がずれているときに起きやすいです。
「話題だから」「評価が高いから」という理由で読んだ本は、自分の仕事・思考との接点が薄いため定着しにくい。逆に、今抱えている具体的な課題と直結した本は、内容と実務のリンクができるため記憶に残りやすくなります。
読む前に「この本で○○の課題を解決する」という目的を1つ決めると、読みながら自然と「あの場面に使える」という紐付けが起きます。それだけで忘れにくくなります。
Q. 積読が大量にあります。全部読むべきですか？
全部読む必要はないです。積読は「今の自分に必要ではない本」として割り切ってしまうのが楽です。
目次を改めて読んで、今の課題と合っていれば読む。合っていなければ保管か売却。「いつか読む」という積読は永遠に読まれません。今の課題に合っていないなら、今読んでも吸収率は低いです。
課題が出てきたタイミングで、改めて同じテーマの本を探したほうが効率的なことも多いです。積読に罪悪感を持つより、「今の課題に合った本を1冊選ぶ」ことに集中するほうが前に進みます。
積読を繰り返していた自分に伝えたいこと
SES 時代の本棚に積まれた4冊は、今も手元にある。あのとき全部読み切れなかったことを後悔しているわけではない。ただ、読み方を知らなかったのは確かだった。1年目から2年目にかけて積んだお金と時間を、もっと効率よく使えたはずだとは思っている。
「1章から全部読む」をやめた。「目的なしに買う」をやめた。代わりに「課題起点で買う」「気になる章だけ読む」「月1冊に絞る」を始めた。それだけで積読がほぼゼロになり、読んだ本が実際に仕事に影響するようになった。
本の読み方に正解はない。ただ、自分が「なぜこの本を読むのか」を言語化できているかどうかで、同じ本でも得られるものが変わる。
技術書だけが「エンジニアが読むべき本」ではない。お金・キャリア・習慣。それらの課題に向き合う本も、エンジニアとして伸びるための1冊になりえる。
→ 【2026年版】クラウドエンジニアへの最短学習ロードマップ → GitHub Actions 実践ガイド｜CI/CDをゼロから構築する学習ステップ → フリーランスエンジニアの iDeCo・NISA 完全ガイド