インフラエンジニアの自分が買ってよかったと思う書籍10選

# **はじめに**

インフラエンジニアとして働き始めて約3年が経ちましたが、その間の経験を踏まえ、 **買ってよかったな** と思った書籍をまとめていきます。
買ってよかった本自体はたくさんあるのですが、そのうち **インフラエンジニアの後輩がいたらオススメしたい** と思えるような極力人を選ばない書籍をここにまとめています。
あくまで **現時点での10選** なので今後も時間とともに変わっていくと思います。多分随時更新します。
なお、特に順番にランキング要素はありません。

(2016/10/16追記)
改めて一覧を見直して思いましたが、あまりインフラエンジニアだから、という書籍があまりないですね。アプリエンジニアがそうでない、と言うつもりは毛頭ないですが、感覚的には「 **色々な人と関わり、折衝することが多い** インフラエンジニアだからこそ読んでおきたい」みたいなところも含む感じです。

# **買ってよかった書籍10選**

## **人月の神話【新装版】**

**[人月の神話【新装版】](http://www.amazon.co.jp/dp/4621066080)**

おそらくこの業界における古典と呼ばれるものの中で、最も有名な部類に入る本だと思います。
IT業界における、作業規模を人月で換算する風習に対して "**神話**" という言葉を使ってでも、筆者が目にしてきた現実と経験に基づく知見をまとめたものです。
大規模なシステムであるほど一般的に関係者の数が増え、それゆえに個人の能力を源泉とするシステム開発特有の問題が出てくるわけですが、そのシステムの規模を "**人月**" という言葉で一括りにする難しさがあります。

「100人月のシステムは100人が1ヶ月働くか、1人が100ヶ月働くことで完成する」

これが **人月の神話** です。

また、 新装版として16章からの「**銀の弾などない**」が追加されています。
この業界ではたまに「これが銀の弾だ！」「しかし、これは銀の弾ではない」などとスラング的に言われることがありますが、この本がその元ネタです。銀の弾とは何の象徴であって、そしてそれがなぜ存在しないのかについては知る価値があると思います。

最近ではこの人月ビジネスの限界がきている、というような文脈で **[システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?](http://www.amazon.co.jp/dp/4774165220)** という本が出ています。
システムの価値や対価というものを人月以外で測ることについて述べられています。

## **ザ・ゴール ― 企業の究極の目的とは何か**

**[ザ・ゴール ― 企業の究極の目的とは何か](http://www.amazon.co.jp/dp/4478420408)**

こちらはIT業界の内容を取り扱った本ではありませんが、おそらくビジネス書籍の中でも非常に有名なものだと思います。
この手の「社会人が読んでおくべき～」などのリストには必ずと言っていいほど出てくる本です。

私自身も社会人1年目の時、先輩にオススメの本を聞いたら真っ先にこの本を挙げられました。
当時はなんとなく気が進まずに結局最近読んだばかりなのですが、「**組織で仕事をする**」上で本質的に考えるべきことは何かを考えることができ、もっと早く読んでおけばよかったなと思いました。
一方で、担当者としての立ち位置からチームリーダーという立ち位置に変わってきたこともあり、意外と今になって読んでよかったような気もしています。

「**ボトルネック**を排除し、組織全体の**スループット**を向上させる」

ザ・ゴールで象徴的に述べられているのはこのフレーズかと思いますが、これをIT業界的に読み替えた本として **[The DevOps 逆転だ!](http://www.amazon.co.jp/dp/4822285359)** という小説があります。
この本ではザ・ゴールの考え方が多分に引用されており、これだけでも随分学べるものがありますが、おそらく原典であるザ・ゴールを読んでおくとより楽しめるようになると思います。

## **UNIXという考え方―その設計思想と哲学**

**[UNIXという考え方―その設計思想と哲学](http://www.amazon.co.jp/dp/4274064069)**

150ページもない比較的薄い本ですが、その中で述べられるシンプルな考え方は非常に有用で、LinuxなりUNIX系OSが大きく広がった理由の1つではないかと思っています。
この本ではたびたび **UNIX哲学** と呼ばれる9つの考え方を取り上げ、それぞれの意味するところを解説しています。
その中でも、

「**小さいことはすばらしい**」 (Small is beautiful)
「**1つのことをうまくやれ**」 (Do one thing well)

ということはプログラミングにとどまらず、仕事のやり方自体にも有用な考え方だと思っています。

もうすぐ **[Unix考古学 Truth of the Legend](http://www.amazon.co.jp/dp/4048930508)** なる本が出るそうで、非常に気になっています。目次を見る限りは "考古学" の名にふさわしく、UNIX発展の歴史を時代ごとの背景に合わせて書いてありそうです。

## **サボタージュ・マニュアル: 諜報活動が照らす組織経営の本質**

**[サボタージュ・マニュアル: 諜報活動が照らす組織経営の本質](http://www.amazon.co.jp/dp/4762828998)**

サボタージュとは日本語で言う「**サボ**る」の語源となっている言葉ですが、元々はフランス語で

> **sabotage**
> 1 サボタージュ 労働争議中に労働者が機械・製品などに故意の損傷を加えること。
> ★【比較】 日本語の「サボタージュ」は「怠業、サボること」の意で用いられ、器物破壊の意はないが、英語の sabotage には「怠業」の意はない。
> 英語における「怠業」の意味には 《主に米国で用いられる》 slowdown，《主に英国で用いられる》 go‐slow を用いる。
> 2 妨害[破壊]行為.

のような意味を持ちます。そのため、サボタージュ・マニュアルと言えば、「**破壊活動マニュアル**」を意味することになります。
このサボタージュ・マニュアルはCIAの前身である組織が、「**どうやれば敵国の組織をダメにすることができるか**」をまとめたものになります。
なんだか仰々しいことを言っているように感じますが、無意識的にサボタージュ・マニュアルの教えを実践している人たちがきっと周囲にもいるはずです。

- 会議の場で全てを検討したがる人
- 些細な修正にも必ず再レビューを要求する人
- ネガティブなことを言うだけの人

組織運営のベストプラクティスなんてものは存在しませんが、アンチパターンはこうして色々まとめられているので、一度読んでみるとよいかと思います。

## **How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント**

**[How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント](http://www.amazon.co.jp/dp/4532319552)**

IT業界にその名を轟かせるGoogleですが、その内部には非常に優秀なエンジニアがたくさんいて、革新的な新しいものが日夜生み出されています。
しかし、優秀なエンジニアがたくさんいること以上に、Googleという組織それ自体が「新しいものを生み出す」「新しいものを成功に導く」力を持っている、そうした文化や考え方を有していることも知られています。

- 「イエス」の文化を醸成する
- "速い馬"はいらない
- 良い失敗をする

上記は一部ですが、Googleの強みは優秀なエンジニアがたくさんいることではなく、**優秀なエンジニアが離れていかない** ことなのではないかと思いました。

## **インフラエンジニアの教科書**

**[インフラエンジニアの教科書](http://www.amazon.co.jp/dp/4863541333)**

ようやくインフラエンジニアっぽい本になりましたが、この本はその名の通り、インフラエンジニアの入門書としては最適な本だと思います。
最近はAWSなどのクラウドが発達してきたおかげで、物理サーバを持たない会社、あるいは **物理サーバを見ずに仕事をするインフラエンジニア** も増えてきていると思います。
もちろん、「クラウドのみでやっていけるならわざわざ物理的なところまで踏み込まなくても」という考えもありますが、システムはどこまで行っても物理サーバの上で動くわけですから、最低限は知っておくべき内容が必ずあると思っています。

ITインフラは多種多様な部品で成り立っていますが、一通りの内容が200ページ足らずの厚さにまとめられており、内容がかなりわかりやすく入ってくるように思います。
インフラ技術面だけではなく、サーバ調達におけるベンダ交渉の話、データセンターファシリティの話など、意外と聞くまで考えたこともないような内容があったりするので、いい刺激が得られるのではないかと思っています。
これに似た内容で、より高度な部分に踏み込んでいるのが **[クラウドを支える技術](http://www.amazon.co.jp/dp/4774167304)** です。論理インフラがどのような技術によって物理インフラに展開されているのかをより深く知ることができます。

## **マイクロサービスアーキテクチャ**

**[マイクロサービスアーキテクチャ](http://www.amazon.co.jp/dp/4873117607)**

インフラっぽい本ができてきたと思ったら、次はどちらかと言えばアプリっぽい本です。

ネットビジネスが発達して、色々なサービスが生まれては消えていく中で、何が強いサービスかというと

- **すぐに**サービスが開始できる
- **すぐに**不具合を修正できる

など、様々なスピード感のあるサービスが強いと言われることがあります。
一方で、様々なシステムやアプリケーションと密に連携するようなサービスでは立ち上げも遅くなりますし、不具合に対する修正も容易ではありません。
そうした流れの中で「**マイクロサービス**」の考え方が生まれ、それを実現する仕組みや考え方についてまとめられたのがこの本です。

前半はアプリ方面の内容なので、ぱっと読んで理解するための知識がないように感じる部分も多々ありますが、インフラエンジニアとしてもアプリエンジニアがこういう世界観を見据えていることは知っておいて損はないと思っています。
また、後半に出てくるテスト、監視、セキュリティについての考え方はアプリだけはなく、インフラとの合わせ技が必要になってくる部分です。
この本の主題ではないため大きく取り上げられてはいませんが、この本で述べられる内容を俯瞰することで、アプリ/インフラの境界なく働くことができる **DevOps** エンジニアの一端を見ることができるかもしれません。

## **チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド**

**[チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド](http://www.amazon.co.jp/dp/4774164283)**

こちらの本ではスピード感ある開発のために、どういった **仕組み** が必要なのかという内容についてまとめられています。
Gitによるソースコード管理やCIツールによる継続的なテスト、デプロイ。
さらには、インフラ自体のコード管理を経て、インフラとアプリが一体となった継続的デリバリーに向かいます。

表紙にあるように、1冊の本としては多くのツールが取り上げられていますが、**全体の流れ**と**それぞれのツールが担う役割**をしっかりと捉えれば、意外と複雑な仕組みではないことがわかるかもしれません。
また、タイトルにもあるように "チーム開発" に主眼を置いており、複数のメンバと一緒に開発を行う際にどのようなトラブルが起こるかというところも押さえており、これも "**DevOps**" 的なエンジニアを目指すのであれば読んでおいて損はない1冊かと思います。

似た内容では **[Chef実践入門 ~コードによるインフラ構成の自動化](http://www.amazon.co.jp/dp/477416500X)**　があります。これもvagrantから始まりserverspecで自動テストをするような内容が含まれていますが、どちらかと言えばインフラ領域の詳細な解説をする本です。

## **リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック**

**[リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック](http://www.amazon.co.jp/dp/4873115655)**

インフラエンジニアとはいえ、この業界で働く上では多かれ少なかれ、何かしらの "コード" を目にしたり、書いたりすることかと思います。
CやJavaなど言語にとらわれずに、「**読みやすいコード**」とは何なのかを追求した1冊です。

メソッド分割などアイデアとしては **UNIX哲学** に似通っている部分もありますが、実践的なテクニックとして実例を交えて書かれているため、読んだ後すぐの納得感が得やすいように思いました。

コメントの書き方で単語の細かなニュアンスにも注意する的な話が出てきますが、その観点では **[アプリケーションをつくる英語](http://www.amazon.co.jp/dp/4844332848)** みたいな本も面白いかもしれません。
また、この本と並んでおすすめされることが多いのが **[達人プログラマー](http://www.amazon.co.jp/dp/4894712741)**, **[CODE COMPLETE](http://www.amazon.co.jp/dp/489100455X)** がありますが、まだ残念ながら読めていません。いつかはチャレンジしたいと思っています。

## **エンジニアのためのGitの教科書 実践で使える! バージョン管理とチーム開発手法**

**[エンジニアのためのGitの教科書 実践で使える! バージョン管理とチーム開発手法](http://www.amazon.co.jp/dp/4798143669)**

最近ではInfrastructure as Codeのような考え方もあり、インフラエンジニアだからといってコードに触れないなどと言っていられなくなりました。
そうした中でスピード感ある開発のために並行開発が行われ、並行開発を強力にバックアップするのがGitです。

Gitの使い方を理解するだけでも大変な勉強になりますので、実際の開発エピソードを交えて解説のあるこの本などで勉強をしてみるのがいいでしょう。
他のGit本であれば **[入門git](http://www.amazon.co.jp/dp/427406767X)** だったり、**[GitHub実践入門 ~Pull Requestによる開発の変革](http://www.amazon.co.jp/dp/477416366X)** などがいいでしょう。

# **選外**

好きな本なので10選にしようかと思ったけど、内容が被っていたりニッチだったりすることもあり10選に選ばなかったものです。

## **プログラミングコンテストチャレンジブック [第2版]　～問題解決のアルゴリズム活用力とコーディングテクニックを鍛える～**

**[プログラミングコンテストチャレンジブック [第2版]　～問題解決のアルゴリズム活用力とコーディングテクニックを鍛える～](http://www.amazon.co.jp/dp/4839941068)**

**選外理由: 個人的な趣味**

インフラの人間がプログラミングを学ぼうとするのは大変です(嘘)

「アプリの勉強をしたいけど、何をつくればよいのか...」
「なにかiOSなりAndroidアプリ作ればいいじゃない」
「何をつくればよいのか...」
「い、いや、Twitterクライアントとかなんでもええやん...」
「何をつくればよいのか...」

とまぁ、こんな風になんとなく作るもののイメージを持てない人間にはいい本だったのです。
今考えると **[CodeIQ](https://codeiq.jp/)** があるのでもはや本は不要かもしれないですね。

## **スーパーエンジニアへの道―技術リーダーシップの人間学**

**[スーパーエンジニアへの道―技術リーダーシップの人間学](http://www.amazon.co.jp/dp/4320025636)**

**選外理由: 古典枠の重複**

この本も人月の神話と同じように古典枠に入る本なのですが、まぁ2冊も古典入れるのはなぁと思ったため選外としました。

「物事を薦めるには **MOI** を整えてやればよい」

というメッセージがあるのですが、**MOI**とは

- どうしてやりたいのか　(**M**otivation)
- どうやって進めるのか　(**O**rganization)
- どうやったらできるのか (**I**dea)

の頭文字を取っていて、これらを満たしてやれば人は仕事をするし、これらを損なえば人は仕事ができなくなるというアイデアです。
リーダーの立場になってみると、これを感じることが多くなり、いい本だなと思いました。

## **プログラマが知るべき97のこと**

**[プログラマが知るべき97のこと](http://www.amazon.co.jp/dp/4873114799)**

**選外理由: 本としてのメッセージ性のなさ**

タイトルの通り、世界で活躍するプログラマ達が1,2ページずつ寄稿したエッセイ集です。
個々のエッセイからは目からウロコの考え方などもあるのですが、人それぞれの考え方があるため、エッセイ同士では矛盾したような内容も含まれていたりします。
もちろんエッセイですので色々な内容が含まれていて楽しく読めるのですが、本としての一貫したメッセージはないので選外としました。
肩の力を抜いて、色々な人の考えに触れられる点では非常に面白い本だと思います。

## **理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL**

**[理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL](http://www.amazon.co.jp/dp/4774171972)**

**選外理由: 内容がガチすぎる**

「データベース実践入門」「効率的なSQL」というタイトルを見て買ってしまった自分も悪いのですが、この本の中心はリレーショナルデータベースに関する**理論**にあり、当然のように**数学の集合論**が出てきます。
大学で数学をやっていたこともあり、読めないことはないのですが「集合論的に考えれば、null値なんて本来あり得ない」みたいな内容も含まれており、**人を選ぶ本**だなぁと思いながら読んでいました。
同様なテイストの本として、**[正規表現技術入門 ――最新エンジン実装と理論的背景](http://www.amazon.co.jp/dp/4774172707)**がありますが、こちらも「正規表現勉強しよう！」などという純粋な気持ちで臨んでは討ち死にしてしまうことでしょう。

## **Web制作者のためのSublime Textの教科書 今すぐ最高のエディタを使いこなすプロのノウハウ**

**[Web制作者のためのSublime Textの教科書 今すぐ最高のエディタを使いこなすプロのノウハウ](http://www.amazon.co.jp/dp/4844335677)**

**選外理由: 一般的でない**

働く中で、**色々なツールを使いこなして取るに足らないタスクにかかる時間を減らす**ことは重要だと思っています。
そういう意味でなんだかんだで使うことの多いエディタに関する本を選んでもよかったのですが、ツールを限定するような話でもないので選外にしました。

## **暗号解読―ロゼッタストーンから量子暗号まで**

**[暗号解読―ロゼッタストーンから量子暗号まで](http://www.amazon.co.jp//dp/4105393022)**

**選外理由: IT技術までの道のりが長い**

昨今セキュリティに関する意識が高まり、telnetよりもSSH、HTTPよりもHTTPSなど暗号技術はインフラエンジニアが無視できるものではなくなりました。
公開鍵暗号で必要になる公開鍵と秘密鍵について、それぞれがどういった役割を持っているのかは原理から知れば明らかで、どうして漏らしてはいけないのかなども分かるようになります。
ただし、この本では近代暗号だけでなく、古代エジプトのカエサル暗号から始まり、徐々に暗号が進化していく歴史を辿る体になっています。
それ故にインフラエンジニアとして知るべき公開鍵暗号などの近代暗号を知るには大げさだし、道のりが長いために選外としました。

ただし、この本、**とても面白い**です。
カエサル暗号くらいならすぐに解読できるであろうことが分かるのですが、第二次大戦で有名なエニグマ暗号などはその原理を知るに、およそ解読できるようなものではないと感じます。しかし、エニグマ暗号は解読されました。
暗号を考える側、暗号を解読する側。双方のせめぎあいの中で磨かれ、現在の近代暗号が発明されたことは知っておいて損はない内容だと思います。
なお、手っ取り早く暗号技術の具体的実装を知りたい場合、 **[暗号技術入門 第3版 秘密の国のアリス](https://www.amazon.co.jp/3/dp/4797382228)** という本がオススメです。