お気に入りの技術書を紹介します

# お気に入りの技術書を紹介します

このエントリは「[Timee Advent Calendar 2023](https://qiita.com/advent-calendar/2023/timee)」の12月17日分のエントリです。

# はじめに

こんにちは。タイミーでバックエンドエンジニアをしている柴田です。社内でアドベントカレンダーを書くことになったので、自分も参加してみました。アドベントカレンダーの題材に悩んだのですが、本を読むのが好きなのでお気に入りの本を紹介することにしました。今回は技術書やビジネス書をメインで選定しています。本を選ぶ時の参考の1つにしてもらえると嬉しいです。

注: あくまでも個人の感想なのと、読んでから時間が経ったものも含まれているため、実際の内容とずれているかもしれません。できるだけ気をつけていますが、ご了承ください。

# [データ指向アプリケーションデザイン](https://www.amazon.co.jp/%E3%83%87%E3%83%BC%E3%82%BF%E6%8C%87%E5%90%91%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3-%E2%80%95%E4%BF%A1%E9%A0%BC%E6%80%A7%E3%80%81%E6%8B%A1%E5%BC%B5%E6%80%A7%E3%80%81%E4%BF%9D%E5%AE%88%E6%80%A7%E3%81%AE%E9%AB%98%E3%81%84%E5%88%86%E6%95%A3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E8%A8%AD%E8%A8%88%E3%81%AE%E5%8E%9F%E7%90%86-Martin-Kleppmann/dp/4873118700)

ビッグデータというワードが出て久しいですが、特にバックエンドエンジニアの方は、大量のデータと格闘することが日常的になっているのではないでしょうか。そして、その大量のデータを処理したり保存する方法の豊富さに圧倒されることも少なくないと思います。

この本では、そのような大規模なデータを扱うための様々な技術を体系的に解説してくれています。第一部から第三部まで分かれており、ざっくり以下のような内容になっています。

- データシステムに共通する基本的な概念（インデックス、ストレージの仕組みなど）
- 分散システム固有の問題（レプリケーション、パーティショニング、トランザクションなど）
- 複数の異なるデータシステムを統合する場合の問題（バッチ処理、ストリーム処理など）

この本では、特定の課題に対して読者が最適な技術を選択できるところを目指しているそうで、1つ1つの技術に対してその原理やトレードオフが丁寧に説明されています。その分、660ページと重厚な内容になっていますが、この本を読み終わる頃には様々なトレードオフを考慮した技術的な意思決定ができる強いエンジニアになれるはずです※。

※ そうは言いましたが自分はまだまだできていないです。強くなりたい。。

## おすすめする読者

- NoSQL、NewSQL、メッセージングキュー、シャーディングなどのワードが出る度に「それってなんだっけ？」となる方
- 大規模なデータを持つアプリケーションに携わるエンジニア
- （特にデータシステムの）トレードオフを理解した上で技術的な意思決定を行いたい or 行わなければならない方

# [A PHILOSOPHY OF SOFTWARE DESIGN](https://www.amazon.co.jp/-/en/John-Ousterhout/dp/1732102201)

この本は前職の輪読会で読んだ本で、自分は参加しませんでしたがタイミーでも輪読会が開かれていました。そのため、エンジニア界隈では最近よく読まれている本の1つという印象があります。

この本のテーマはずばり「ソフトウェアの複雑性」で、主に以下の3つの話題を取り扱っています。

- ソフトウェアの複雑性とは何か？
- ソフトウェアが複雑だと何が問題なのか？
- 複雑性を避けるためにはどうしたら良いのか？

この本の面白いところは、これまで良いとされてきた設計に対するアンチテーゼが盛り込まれているところです。例えば、書籍では deep module と呼ばれるインターフェースがシンプルで機能が豊富なモジュールが良いとされています。例えば、ガベージコレクションはインターフェースを持っていません。そのため、開発者がガベージコレクションを意識することは多くないですが、未使用のメモリを回収するという重要な機能を果たしています。逆に、Javaではファイルの読み込みに複数のクラスを組み合わせる必要があり、開発者の認知負荷を増やしてしまいます。書籍ではこのようなモジュールを shallow module と呼んでおり、ソフトウェアの複雑性を上げるよくない設計とされています。もちろん、JavaにはJavaの設計思想があるため、私自身はJavaの設計が悪いとは思いませんし、むしろJavaのようにクラスは小さく設計することがクラス設計の主流だと思います。この本の価値はそのような今までの価値観を見直したり、新しい価値観に気づけることだと思います。

また、deep module や shallow module のような秀逸なワードがたくさん定義されているので、開発者間の認識を揃えることにも一役買ってくれます。

## おすすめする読者

- オブジェクト指向はだいたい分かってきたかなーって人
- ソフトウェアの設計に興味がある人

# [世界一流エンジニアの思考法](https://www.amazon.co.jp/%E4%B8%96%E7%95%8C%E4%B8%80%E6%B5%81%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E6%80%9D%E8%80%83%E6%B3%95-%E7%89%9B%E5%B0%BE-%E5%89%9B/dp/4163917683)

一流のエンジニアは、普通のエンジニアに比べて10倍、100倍の生産性を持つと聞いたことがありませんか？私もどこかでそんな話を聞いたことがありますし、タイミーにも11人くらいいるのではないか？と思うようなエンジニアがいます。

この本では、マイクロソフトで働く筆者が世界一流のエンジニア達と働くことによって見えてきた彼らに高い生産性をもたらしている思考法を紹介してくれています。

この本を読むまでは、一流のエンジニアは搭載しているCPUが違うのだろうとか、人生20周目くらいなんだろうとか考えていましたが、思考法に差があったというのは驚きでした。

この本の中で特に重視されているのが、脳の使い方です※1。例えば、エンジニアの生産性は細かい技術の積み重ねによって生まれるため、獲得した知識を如何に脳に定着させるかが重要だそうです。何も調べずにコードを完成させられるエンジニアと都度ググるエンジニアの生産性の違いを考えるとイメージしやすいと思います※1。そのため、学習よりも成果を重視する仕事のスタイルはエンジニアと相性が悪いとのことです。自分自身、早く仕事を終わらせたい力学が働きがちで学習を蔑ろにすることが多々あったため、この辺りの話は血が出るくらい刺さりました。

私と同じようにここに書いたことが刺さった方には間違いなくオススメできる一冊です。買うかどうか迷った方は [fukabori.fm](https://fukabori.fm/episode/108) に筆者が出演されているので視聴してみると良いかもしれません※2。

※1 この辺りは[プログラマー脳](https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E8%84%B3-%EF%BD%9E%E5%84%AA%E3%82%8C%E3%81%9F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E8%AA%8D%E7%9F%A5%E7%A7%91%E5%AD%A6%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%8F%E3%82%A2%E3%83%97%E3%83%AD%E3%83%BC%E3%83%81-Felienne-Hermans/dp/4798068535)にも書かれているため、興味がある方は一読してみてください

※2 ちなみに、A PHILOSOPHY OF SOFTWARE DESIGN も [fukabori.fm](https://fukabori.fm/episode/100) で3回にわたって取り上げられています

## おすすめする読者

- 一流エンジニアになりたいけど、一流エンジニアは雲の上の存在だと感じている方
- 開発の生産性を上げたい方
- ここに書いた内容が刺さった方

# 最後に

あと2冊くらい書こうと思っていましたが、気力が足らず3冊で断念しました…

お気に入りの本はたくさんあるのでまた機会があれば紹介したいと思います。