【フェーズ2-4】 技術書を、血肉にする。読んで、作って、書き残す3拍子で身につける 【ITエンジニアの卵に贈る、就活の書】
この記事は「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。
エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。
ITエンジニアの卵に贈る、就活の書・フェーズ2-4の記事です。前回のフェーズ2-3では、学業で作ったものを履歴書に書ける成果物に育てる話をしました。今回はフェーズ2「作る」の実践各論11本のうちの2本目として、技術書を、血肉にするというお話です。
読むだけで終わらせない。読んで、作って、書き残す。この3拍子を回すことで、技術書は本棚に飾る紙束から、あなた自身のプロフェッションの土台に変わります。同時に、その過程で生まれた成果物は、そのままポートフォリオになります。
新卒の就活中の方はもちろん、第二新卒として他社の面接に臨む場面でも、この習慣はそのまま活きます。
1. 技術書を読む、ことのプロフェッション上の意味
序章-1で、私はエンジニアという職業を、生涯にわたる自己研鑽を義務とするプロフェッションとして位置づけました。IEEE-CS/ACMのソフトウェアエンジニア倫理綱領の8原則の最後には、自己という項目があります。この原則は、生涯にわたって学び続けることを、エンジニアの職業的責任として明示しています。
技術書を継続的に読むことは、この自己研鑽の中核的な習慣です。世界のエンジニアは、Netflix、Google、Meta、Anthropic、OpenAI、Vercel、Stripe、Figma、Databricks といったテックカンパニーのシニアエンジニアに至るまで、日常的に本を読み続けています。
新しいフレームワーク、分散システムの理論、機械学習の最新論文、セキュリティの脅威モデル、テストと品質保証の手法、プロダクトマネジメントの考え方。読むことをやめた瞬間から、プロフェッションとしての鮮度は落ちていきます。
学生時代のみなさんにお伝えしたいのは、技術書を読むという習慣そのものが、就活の場面で強い評価軸になるということです。序章-2で語った世界基準のエンジニアが並ぶ選考の場に立つとき、あなたが日常的に技術書を読み、その内容を血肉にしているかどうかは、面接の対話の解像度に、そのまま表れます。
2. 「読むだけ」で終わる技術書は、本棚を飾るだけの紙束
実際のところ、正直にお伝えします。読むだけの技術書は、多くの場合、身につきません。
学生さんから相談を受けるとき、私がよく聞くのは「オライリー本を積んで読んだけど、内容が頭から抜けていく」という声です。原因はシンプルで、読むことと、実践することと、言語化することの3つが揃わないと、技術書の内容は身体化されないからです。
自転車の乗り方を、100冊の本で読んで理解しても、乗れるようにはなりません。実際にペダルを踏んで、転んで、また踏んで、初めて乗れるようになります。技術書も同じ構造を持っています。読んだだけで身につくと思うのは、そもそもの前提が違います。
そこで、本記事で提案するのが、読んで、作って、書き残すの3拍子です。この3つを1冊の技術書に対して回すと、その本の内容は、あなたの手足の一部として動くようになります。同時に、その過程で生まれた成果物が、ポートフォリオに蓄積されていきます。
3. 3拍子1：読む
まず、読むです。技術書の読み方には、いくつかの型があります。
3-1. 目的を持って読む
技術書は、小説のように最初から順に読む必要はありません。なぜこの本を読もうと思ったのかを、読み始める前に1行だけ書き出しておくと、読み方が変わります。「Next.js の App Router を、業務で使える解像度で理解したい」「PostgreSQL の実行計画を EXPLAIN で読めるようになりたい」「Kubernetes の Pod、Deployment、Service の関係を、自分の言葉で説明できるようになりたい」。目的が明確なほど、読むスピードと定着の深さが上がります。
3-2. 技術書の3層構造を意識する
一般に、技術書には3つの層があります。概念層（なぜこの技術が生まれたか、どんな問題を解いているか）、構造層（アーキテクチャ、コンポーネント、抽象概念）、実装層（具体的なコード、コマンド、設定）。3層のうち、どれを重点的に読むかを決めると、時間の使い方が明確になります。読み終わったら、3層それぞれについて、自分の言葉で1〜2文の要約を書けるか確かめると、理解度がわかります。
3-3. 定番書と最新書を組み合わせる
技術の世界には、時代を超えて読み継がれる本と、いまの時代の実装を教えてくれる本があります。前者の例として、『Clean Code』『Refactoring』『Designing Data-Intensive Applications』『The Pragmatic Programmer』『Site Reliability Engineering』（Google SRE Book、無料公開）などが挙げられます。
後者の例として、Next.js、TypeScript、Rust、Go、Kubernetes、PyTorch、LangChain などの実装解説書があります。両方を組み合わせて読むと、原理原則と、いまの時代の道具の両方が身につきます。
4. 3拍子2：作る
読んだだけでは、技術書は本棚を飾るだけの紙束のままです。ここからが本題です。読んだ内容を、自分の手で作る。この一手間が、技術書を血肉に変えます。
4-1. 写経に、自分のアレンジを1つだけ加える
初心者向けの技術書には、多くの場合、サンプルコードが付いています。まずはサンプルをそのまま写経して、動かします。ここまでは、多くの学生さんがやっている作業です。
ここで一歩踏み込むのが、自分のアレンジを1つだけ加えるという工夫です。サンプルは Express で書かれているところを、Fastify や Hono で書き直す。データベースは SQLite ではなく PostgreSQL に載せ替える。デプロイ先を、Vercel、Cloudflare Workers、Fly.io のいずれかに置き換える。フロントエンドを、書籍のReactから、Svelte や Solid に書き直す。
そして、原本と何を、なぜ変えたかを、1〜2行で説明できる形にする。この一手間が、写経を成果物に変えます。
4-2. スクラッチ実装で、技術書の中身を再現する
もう一段深い作業として、技術書のコードを見ずに、自分の力でスクラッチ実装するという取り組みがあります。書籍を最後まで読み終わった後、章のタイトルだけを見返して、コードは自分で書いてみる。書けなくなったら、書籍に戻って該当箇所を読み直し、また閉じて書き続ける。この往復が、技術書の内容を、あなたの指先の記憶として定着させます。
4-3. 実装先を、世界基準のスタックで組む
技術書のサンプルコードは、書かれた時期によって、いまの世界標準から少し離れた道具立てで書かれていることがあります。学生時代のみなさんには、世界基準のスタックで組んでみることを勧めます。
具体的には、TypeScript + Next.js + Vercel、Rust + WebAssembly、Go + Kubernetes、Python + FastAPI + PostgreSQL + Docker、Swift + SwiftUI、Kotlin + Jetpack Compose、Elixir + Phoenix LiveView など、いま世界のプロダクトが実際に採用しているスタックです。
技術書で学んだ概念を、こうしたスタックの上で動く形にすると、その成果物はそのまま強いポートフォリオになります。フェーズ2-2で扱った第三者の目利きが働く場所（勉強会での発表、Advent Calendar、OSS への貢献、Zenn の Trending など）にも、乗せやすくなります。
4-4. AIコーディングアシスタントとの向き合い方
いまの学生さんにとって、GitHub Copilot、Cursor、Claude、ChatGPT といったAIコーディングアシスタントは、日常の道具です。技術書と組み合わせるとき、大切なのは順序です。まず自分で書いてみて、詰まったら AI に聞き、AI の答えを鵜呑みにせず理解して自分の言葉で説明できるかを確かめる。この順序を守れば、AIは学びの加速装置になります。順序を逆にして AIに書かせて動けば良し、では、技術書の内容は身につきません。
企業側も、この点をよく見ています。世界基準のテックカンパニーの選考では、AIを使いこなす学生を歓迎したうえで、AIの出力を自分の言葉で説明できるかを、面接で丁寧に確かめます。フェーズ4「確かめ合う」で扱う面接では、この点が重要な観点になります。
5. 3拍子3：書き残す
読んで、作った。ここで終わっても身につくのですが、もう一手間で、成果物が世界に開きます。書き残すという手間です。
5-1. 学びを、技術ブログに1本書く
技術書1冊を読み、手を動かした後で、その本から得た学びを技術記事に書き残します。プラットフォームは、Zenn、Qiita、はてなブログ、Medium、独自ドメインなど、フェーズ2-2で扱った公開の3条件を満たせる場所です。
書き方は、書評形式でも構いませんし、書籍で扱われた特定の概念を、初学者向けに解説し直す形でも構いません。「Designing Data-Intensive Applications を読んで、CAP定理を実装例で理解し直した」「Site Reliability Engineering の SLI/SLO/エラーバジェットを、個人開発に適用してみた」「Rust の所有権を、GoとPythonのメモリモデルと比較して整理した」。1冊の本から、複数の記事が生まれることもあります。
書くことは、読んだ内容を、自分の言葉に翻訳する作業です。他人に説明できる形になった知識だけが、あなた自身の血肉になります。フェーズ2-8「技術ブログで、学びを言語化する」で、書き方の詳細を丁寧に扱います。
5-2. コードは、GitHub に置く
技術書と一緒に書いたコードは、GitHub の Public リポジトリに整理して置くのが基本形です。フェーズ2-5「GitHubを、公開の場のハブとして育てる」でこの記事を含むフェーズ2各論の成果物すべてを束ねるハブとしてのGitHubの育て方を扱っています。
「◯◯本を読みながら書いたコード」というリポジトリを、READMEに書籍のタイトル、章立て、自分がアレンジしたポイントを添えて公開します。書籍の内容そのままを転載することは著作権の関係で避け、自分の手で書き直した実装と、その意図を残します。
5-3. 勉強会で、5分だけ話す
書き残しの最終形として、勉強会や技術イベントで、5分だけ発表するという選択肢があります。「◯◯本を読んで学んだ3つのこと」というテーマで、LT（Lightning Talk、短時間発表）に登壇する。connpass や Doorkeeper で「学生LT歓迎」の勉強会を探せば、学部生でも登壇できる場が多くあります。
登壇の実績は、イベントページの登壇者欄、Speaker Deck の主催アカウントの発表一覧、Twitter/X のイベント公式ハッシュタグに、あなたの名前として残ります。これは、フェーズ2-2で扱った第三者の目利きが働く場所への、最も入りやすい入口の一つです。
フェーズ2-9「技術イベントや勉強会で、発表する」で、この道の歩き方を丁寧に扱います。
6. 学生時代に読んでおきたい技術書の系統
具体的にどの本を読むか、については、志望する技術ドメインによって変わります。ここでは、系統として押さえておきたい種類を紹介します。個別の書名は、書店や社外の書評、社会人になってから同僚のおすすめで積み上がっていきます。
プログラミング言語の入門書（自分が最初に深めたい言語1冊）
アルゴリズムとデータ構造（1冊）
コンピュータアーキテクチャ、OS、ネットワーク、データベースの基礎（各1冊）
ソフトウェア工学の全体像を扱う体系書（例：『実践ソフトウェアエンジニアリング』。要求分析から設計、テスト、プロジェクトマネジメントまでを一冊で網羅する、海外の情報系大学で教科書として採用されてきた定番書）
ソフトウェア設計の古典（『Clean Code』『Refactoring』『The Pragmatic Programmer』のいずれか）
分散システム、SRE、大規模システム（『Designing Data-Intensive Applications』『Site Reliability Engineering』）
ソフトウェアテストと品質保証（例：『［改訂新版］マインドマップから始めるソフトウェアテスト』、ISTQB Foundation Level シラバス）
セキュリティの基礎（1冊）
プロダクトマネジメント、ソフトウェア開発プロセス（アジャイル、スクラム、リーン系のいずれか）
志望ドメインに応じた実装解説書（Web、モバイル、AI/ML、インフラ、ゲーム、組込みなど）
このなかで、とくに意識してほしいのが、ソフトウェアテストと品質保証です。多くの情報系のカリキュラムでは、テストや品質保証を独立した科目として深くは扱いません。ところが、実際に就職してみると、テストと品質は現場でもっとも重視される要素の一つになります。バグを作らないことよりも、バグを早く見つけて直せる仕組みを持っていることのほうが、プロフェッションとしては評価されます。学生のうちに、この分野の基礎を1冊、押さえておく価値があります。
シラバスを読むだけでなく、JSTQB Foundation Level試験を実際に受験してみるという選択肢もあります。この試験には受験資格の制限がなく、学歴を問わず学生でも受けられます（出典：JSTQB公式サイト）。
ただし、ここで大切なのは資格そのものではありません。情報処理技術者試験のような国家資格は、エンジニア志向の強い会社では評価に直結しないことが多く、資格の名前を並べるより、テストという領域を体系的に学び、実際に手を動かした経験を自分の言葉で語れることのほうが、面接では雄弁に語ってくれます。受験は、その理解を確かめる一つの機会として位置づけてください。
これらを4年間で全部読み切る必要はありません。学期に1〜2冊のペースで、3拍子を回しながら丁寧に。それが、技術書の血肉化のペースです。
7. 新卒エンジニアが、学生時代に触れておくと良い15冊
系統だけでなく、具体的な書名も知りたいという声を、学生さんから何度もいただきます。ここでは、私自身が25年の実務で繰り返し戻ってきた15冊を、分野別に紹介します。すべてを読む必要はありません。志望領域に合うものを3〜5冊選び、3拍子で丁寧に回すのが現実的な目安です。
7-1. 全エンジニア共通（4冊）
『Clean Code アジャイルソフトウェア達人の技』（Robert C. Martin）：可読性の高いコードとは何かを、具体的な悪例と良例で教えてくれる古典。実務のコードレビューの言葉が、この本から来ています
『The Pragmatic Programmer 20周年記念版』（David Thomas、Andrew Hunt）：エンジニアとしての姿勢と実践を、100項目の短い章で解説。学生時代に読んでおくと、社会人になってからの伸びが変わります
『Software Engineering at Google』（Titus Winters ほか、日本語訳あり）：Googleの実務から生まれたソフトウェアエンジニアリングの実践書。SWEBOKの理論とGoogleの実務が、この1冊で繋がります
『情熱プログラマー』（Chad Fowler）：キャリア論の古典。プロフェッションとしてのエンジニアの姿勢を、若手の視座で描く
7-2. Web志望（3冊）
『Real World HTTP』（渋川よしき）：HTTPの仕様と実務を、日本語で丁寧に解説。Web系エンジニアなら学生時代に1回は通読しておきたい
『改訂新版 JavaScript本格入門』（山田祥寛）：JavaScript/TypeScriptの言語仕様を体系的に押さえる定番書
『Webを支える技術』（山本陽平）：REST、HTTP、URI、HTMLの基本を、思想レベルから理解する
7-3. 組込み・システム志望（2冊）
『詳解 Linuxカーネル』（Daniel P. Bovet、Marco Cesati）：OSの中身を、Linuxの実装で理解する古典
『プログラマーのためのCPU入門』（Takenobu Tani）：CPUの内部動作を、プログラマーの視座で丁寧に解説
7-4. AI・データ志望（3冊）
『ゼロから作るDeep Learning』シリーズ（斎藤康毅）：機械学習の実装を、ライブラリに頼らずスクラッチで組む定番書。3拍子の「作る」を、この本で徹底的に体験できる
『データ指向アプリケーションデザイン』（Martin Kleppmann、日本語版）：大規模データ処理の理論と実装。分散システムとデータベースの本質を、1冊で押さえられる名著
『機械学習エンジニアリング』（Andriy Burkov、日本語版）：機械学習の実務プロセス全体（データ準備、モデル選定、評価、デプロイ、運用）を扱う
7-5. インフラ・SRE志望（3冊）
『Site Reliability Engineering』（Google SRE Team、無料公開）：GoogleのSRE実践の原典。SLO、エラーバジェット、ポストモーテムの考え方の一次資料
『Kubernetes完全ガイド』（青山真也）：日本語のKubernetes解説書の決定版。実務で使うレベルまで、丁寧に解説
『入門 監視』（Mike Julian、日本語版）：モニタリング、アラート、可観測性の基礎
7-6. 品質・テスト志望（3冊）
『Test-Driven Development: By Example』（Kent Beck、和田卓人氏訳）：テスト駆動開発の古典。テストを書きながら実装する感覚を、身体で覚える
『レガシーコード改善ガイド』（Michael Feathers）：既存の巨大なコードを、どう安全に改善していくか。実務の8割はレガシーコード改修という現実に、正面から向き合う
『[改訂新版] マインドマップから始めるソフトウェアテスト』（著者：池田暁ほか）：テスト設計の実践入門。手前味噌ですが、私が共著者の1人として関わった本です。学生時代にテスト設計技法の入口を知るのに、日本語で読みやすい1冊
番外編B6（新卒エンジニアが最初に触れる、品質文化・テスト文化）でも、テスト・品質分野の書籍と資料を体系的に整理しています。あわせてお読みください。
8. 著者が学生時代に読んで、いまも記憶に残っている書籍
最後に、私自身が学生時代に読んで、25年経ったいまも記憶に残っている書籍を、少しだけ紹介させてください。当時の書籍ですので、いまの学生さんの世代では手に入りにくいものも含まれますが、書名を並べておきます。
『達人プログラマー』（David Thomas、Andrew Hunt、初版）：学生時代に読んで、エンジニアという職業の姿勢に初めて触れた本。20周年記念版がいまも出版されていて、内容は色褪せていません
『デザインパターン』（Erich Gamma ほか、通称GoF本）：オブジェクト指向設計の古典。学生時代に読んだときは半分も理解できませんでしたが、実務を数年経てから読み直したときに、腹に落ちる感覚がありました
『実践的プログラム設計技法』（YourdonとConstantine、当時読んだのは日本語版）：構造化設計の古典。学生時代の私には難しすぎましたが、後にソフトウェア工学の授業で再会したときに、ようやく意味が分かりました
『ソフトウェアテスト293の鉄則』（Cem Kaner ほか、日本語版）：ソフトウェアテストの実務の姿を、300近い鉄則で描いた本。私が品質・テスト分野に進むきっかけの1冊
これらの本のすべてがいまの学生さんに合うわけではありません。ただ、25年後に振り返って「あの本を読んでおいてよかった」と思える1冊が、みなさんの学生時代にも、必ずあるはずです。その1冊を見つけるためには、まず、たくさん読んでみるしかありません。読んで合わなかった本は、無理に読み切らなくていい。読んで身体に馴染む本と出会ったら、その本と繰り返し会い直してください。
私が「あの本を読んでおいてよかった」と思う瞬間は、社会人になってからの1年目、5年目、10年目、15年目、20年目、そしていまと、何度も訪れました。学生時代の1冊は、これから何度も、みなさんの手元に戻ってきます。
9. プロフェッションとして育つ環境を持つ会社は、本を読む文化を持っている
シリーズ全体を貫く上位原則を、この記事でも一度確認しておきます。その会社は、エンジニアをプロフェッションとして育つ環境を持っているか。
プロフェッションとして育つ環境を持つ会社は、多くの場合、社員が本を読む文化と、その支援を持っています。書籍購入の会社負担、社内の輪読会、社員が読んだ本のブックリストの技術ブログでの公開、新入社員研修での書籍配布、有名なテックカンファレンスへの参加補助、Coursera、Udemy Business、O'Reilly Online Learning の会社契約。こうした制度が並んでいる会社は、技術書を血肉にする文化そのものを経営として支えています。
学び続ける姿勢は、経営層や部課長の言葉のなかに、いちばん正直に表れます。募集要項の「書籍購入補助」の1行、社員インタビューでの「最近読んで印象に残った本」の話、CTO のブログでの推薦書リスト。これらを合わせて読んだときに、その会社が本を読む文化を大切にしているかどうかが、じわりと見えてきます。
まとめ
本記事では、技術書を血肉にする3拍子のお話をしました。要点は次のとおりです。
読むだけの技術書は身につきません。読んで、作って、書き残すの3拍子を回すことで、初めて血肉になります。読むときは、目的を持ち、3層構造を意識し、定番書と最新書を組み合わせます。
作るときは、写経にアレンジを加える、スクラッチ実装で再現する、TypeScript・Next.js・Rust・Go・PyTorch・Kubernetesなど世界基準のスタックで組む、AIと正しい順序で向き合うといった方法があります。書き残すときは、技術ブログに1本書く、コードをGitHubに置く、勉強会で5分話すといった形にします。企業側の視座としては、世界基準の会社ほど、本を読む文化と支援を持っています。
次のフェーズ2-5では、この3拍子の中の「作る」と「書き残す」の中心舞台であり、フェーズ2各論の成果物を束ねる公開の場のハブでもある、GitHubを、公開の場のハブとして育てる話に進みます。
エンジニアの卵のみなさんへ、エール
技術書は、静かで気長な道具です。派手さはありません。ハッカソンで賞を取るわけでも、フォロワーが急に増えるわけでもありません。ただ、読み続けた学生さんと、読み続けなかった学生さんの5年後、10年後の育ちの差は、驚くほど大きいものになります。
正直、私自身、20代の若い頃に読んだ本の一節が、50代のいまも実務のなかで顔を出すことがあります。序章-1でお話ししたプロフェッションの生涯を支える土台は、そのかなりの部分が、学生時代と若手時代に読んだ本の中にあります。みなさんには、そのことを、いまのうちに知っておいてほしいのです。
今週、なにか一つ、始めてみてください。積んである本を1冊開く。目的を1行書き出す。読んだ内容から、小さな実装を1つ起こす。学びを Zenn に1本書く。どれか1つで、本記事の1歩目です。
一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。
次の記事はフェーズ2-5「GitHubを、公開の場のハブとして育てる。フェーズ2の成果物を束ねて、世界に見せる」です。
#エンジニア就活 #新卒エンジニア #技術書 #プロフェッション #エンジニアの卵に贈る就活の書
