はじめに
- 筆者は非情報系出身でIT企業に入社し、気づけば3年が経ちました。
- 情報系出身でない人がIT業界に入ると、技術的なスキル以前に躓くポイントがあります。
- プログラミング言語の文法やGitの操作方法といった、「目に見えるスキル」を習得しようと本を読んだりUdemyを見たりするのが、よくある勉強法だと思います。
- しかし実際には、そういった個別のスキル以上に、ソフトウェアエンジニア(以下、「エンジニア」)が無意識のうちに共有している「不文律」ともいえる世界観や設計思想を理解していないことが、大きな壁になることがあります。
- 4月は新卒入社する方が多い季節ということで、同じような壁にぶつかっている後輩エンジニアに向けて、その「不文律」を言語化してくれた本を3冊紹介したいと思います。
エンジニアの「不文律」とは
エンジニアの世界には、ドキュメントに明示されているわけではないけれど、経験者の間では当たり前のように共有されている考え方や設計思想があります。
「なぜプログラムはモジュールに分割するのか」「なぜAPIという概念が存在するのか」「オブジェクト指向の何が嬉しいのか」——こういった問いに対して、多くのエンジニアは「そういうもの」として自然に体得しています。
しかし、情報系の専攻ではない筆者は、この「そういうもの」の感覚がなかなか掴めませんでした。コードは書けても、なぜその設計をするのかの「理由」が見えないという状態です。
今回紹介する3冊は、その「理由」を言語化してくれた本たちです。
3冊の紹介
① UNIXという考え方
どんな本か
UNIX文化に根ざした設計思想・哲学を、9つの「定理」に整理して解説した本です。「小さな部品を組み合わせる」「一つのことをうまくやる」「すべてのプログラムはフィルタである」といった定理を、一章ずつ丁寧に解説してくれます。
読む前と読んだ後
- 読む前：「なぜプログラムをモジュールに分割するのか」「パイプはなんのために使うのか」という疑問が漠然とあった
- 読んだ後：プログラムの出力を人間だけでなく別のプログラムが受け取るという世界観、一つのことに集中した小さなプログラムを組み合わせるという設計思想が腑に落ちた
総評
「なんとなくそういうもの」だと思っていたエンジニアの習慣に、ちゃんと「理由」があることを教えてくれる本です。薄くて読みやすいのもポイントです。
また、本書はコードやコマンドがほとんど登場しないため、プログラミングの予備知識がほぼゼロでも読み進められます。3冊の中で最初に読んでほしい一冊です。
② ふつうのLinuxプログラミング 第2版
どんな本か
「ファイルシステム・プロセス・ストリーム」の3概念を軸に、LinuxのプログラミングをCで学ぶ本です。第1部で基礎概念を整理し、第2部でAPIを使った実装、第3部でHTTPサーバ構築へと発展していく構成です。
本書は「Linuxはこの3つで構成されている」と冒頭で明言しているのも印象的で、Linuxのシンプルさを重んじる設計思想を感じ取ることができました。
読む前と読んだ後
- 読む前：「APIといえばWeb APIのことだと思っていた」「OSが何をやっているのか、ぼんやりとしか分かっていなかった」
- 読んだ後：「OSのAPIを呼ぶ」という概念を初めて理解できた。ハードウェアごとに異なるマシン語の差分をOSが吸収してくれているという構造が分かり、「なぜOSというものが存在するのか」が腑に落ちた
総評
Cのコードは登場しますが、分量はそこまで多くなく、丁寧な解説がついているので安心して読み進められます。仮にコードが完全に理解できなくても、OSの動作原理や構造についての解説は十分に追えます。
また、「こうなっている」という事実だけでなく、「なぜそうなっているのか」という根底の考え方もセットで説明してくれるので、納得しながら読み進められる (＝知識として定着しやすい)のも本書の美点です。
第3部のHTTPサーバの部分はちょっと難しいですが、最初の内は読み飛ばしてしまっても良いかもしれません。
[謝辞]
本書は私のメンターである先輩からお勧めいただいた1冊です。
当初は紙の書籍をお借りして読んでいたのですが、内容が本当に素晴らしく、「常に手元に置いていつでも読み返したい」と感じ、読了後に思わず電子版を自分で購入してしまいました。
本書との出会いはもちろんのこと、日頃から多くの学びの機会を与えてくださった先輩に、この場を借りて深く感謝申し上げます。
③ オブジェクト指向でなぜつくるのか 第3版
どんな本か
機械語・アセンブリからはじまり、プログラミング言語の歴史を辿ることで「オブジェクト指向がなぜ生まれたのか」を解き明かす本です。クラス・継承・ポリモーフィズムといった概念だけでなく、デザインパターンやUML、アジャイル開発まで幅広くカバーされています。
読む前と読んだ後
- 読む前：
- 「プログラミングの勉強＝文法を覚えること・コマンドを覚えること」だと思っており、設計やデザインパターンという領域があること自体知らなかった
- プログラミング言語については、静的/動的型付けの違いや「オブジェクト指向言語」「関数型言語」といった名前は知っていたものの、それぞれのパラダイムが何を意味するのか、なぜそういう考え方が生まれたのかは全く分かっていなかった
- 読んだ後：
- プログラミング言語のパラダイムが機械語・アセンブリから構造化プログラミング、オブジェクト指向、関数型へとどのように変遷してきたか、そして各パラダイムがどんな課題・需要に応えて生まれたものなのかが分かった
- 名前だけ知っていた概念に文脈が生まれ、プログラミングの世界に「設計」「デザインパターン」「UML」という領域が存在することも含め、自分の「知識の地図」が大きく広がった
総評
「なぜオブジェクト指向で作るのか」という問いに正面から答えてくれる本です。
「オブジェクト指向」「関数型」といった言葉は入社前から知っていたものの、本書を読むまではそれぞれが何を意味し、なぜ生まれたのかを全く理解できていませんでした。
機械語・アセンブリから構造化プログラミング、オブジェクト指向、関数型へという言語パラダイムの変遷を歴史の流れで追えるため、名前だけ知っていた概念に文脈が生まれ「なんとなく使っているけど本質が分かっていない」という感覚が解消されます。
設計・デザインパターン・UMLといった領域の存在を知るきっかけにもなるので、知識の地図を広げるという意味でも読んでおいて損のない一冊です。
[謝辞]
本書は、職場の後輩が勧めてくれた1冊です。
私は情報系出身ではないことに少なからず不安を感じていたのですが、そんな私の状況や課題感にぴったりと寄り添う、まさに求めていた内容でした。
私の悩みを汲み取り、的確な良書を教えてくれた後輩に心から感謝しています。
『リーダブルコード』や『プリンシプルオブプログラミング』じゃないの？
新卒エンジニア向けのおすすめ本として、 『リーダブルコード』 や 『プリンシプル オブ プログラミング』 がよく挙がるのを見かけます。どちらも良書ですが、個人的には今回紹介した3冊の方が、プログラミングの経験に乏しい新入社員にとっては優先度が高いと思っています。
理由は、リーダブルコードやプリンシプルオブプログラミングは「実際にコードを書く」ことが前提の本だからです。変数の命名規則、関数の設計、コードの読みやすさ……これらは日々コードを書いている中で初めて「確かに」と腑に落ちる内容です。
一方、今回紹介した3冊が扱っているのは、そのさらに手前にある「エンジニアの世界の見方」そのものです。この土台となる考え方を理解してからこそ、コードの書き方の話が活きてくると思っています。
4月・5月の研修中や業務開始直後は、まだ日常的にコードを書く機会も少ない時期だと思われます。そういった時期にこそ、今回の3冊のような「Why」を扱った本を読んでおくのが、個人的なおすすめです。
おわりに
今回紹介した3冊に共通しているのは、技術の「How（どうやるか）」よりも「Why（なぜそうなっているのか）」を教えてくれるという点です。
プログラミングの経験に乏しい状態でIT業界に入ると、最初はどうしても「どうやればできるか」に目が向きがちです。しかし、業界に漂う暗黙知を理解するためには、「なぜそうなっているのか」という問いに向き合うことが近道だと、3年間で実感しました。
生成AIをはじめIT業界における技術の移り変わりはめまぐるしく、新しい言語、新しいフレームワーク、新しいツールなどの「How」を追い続けることはエンジニアとして避けられません。
しかし、「Why」から得た知恵は、表面的な技術の変化に左右されず長く使い続けられると思っています。根底にある考え方を掴んでおくと、新しい技術に出会ったときの理解の速さも変わってきます。
「How」は後からでも追いつけますが、「Why」を問う習慣は早い段階で身につけておいて損はないと考えています。
4月に入社したばかりの方には、本記事で紹介したような「Why」を学ぶ本を手に取る時間を作ってみてほしいです。
(2026/05/02 更新)
本記事の公開後、内容に一部不正確な点があるとのご指摘をいただき、該当箇所の加筆・修正を行いました。
貴重なご指摘・フィードバックをくださった方に厚く御礼申し上げます。