エンジニアとして今の自分を形成した本を5冊紹介する
エンジニアとして今の自分を形成した本5冊
エンジニアとして働くにあたって自分が大きく影響を受けた本を考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。
- Clean Coder（クリーンコーダー）
- Team Geek
- Clean Architecture（クリーンアーキテクチャ）
- テスト駆動開発
- LeanとDevOpsの科学
この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している（かつての自分がそうだった）。
特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験がある人が読んで、本に書いてあることを実践すると自分の成長を実感するだろう。
「Clean Coder」、「Team Geek」はともにエンジニアとしてのマインドセットの本。「Clean Architecture」「テスト駆動開発」は、コーディングの原則と実践の本。「LeanとDevOpsの科学」はチームを超えた組織としてアウトプットを最大化するための本だ。
それぞれについて簡単に紹介していく。
Clean Coder（クリーンコーダー）
クリーンアーキテクチャで有名なボブおじさんの本。
「仕事でコードを書いたなら、あなたはもうプロフェッショナルである」としてエンジニアの職人魂を軽快な語り口で解説した本。プロならTDDやデザインパターンを知ってて当たり前でしょ？と目線を上げてくれる。
「達成できない期限は約束しない」とか「見積もりは確率の3点見積もりをする」とか「自分が発言しない会議はそっと退席しよう」とも書かれてる。
Clean Coder で Craftmanship について書かれているので、個人的には今年に邦訳が発売される予定の Clean Craftmanship との違いが気になる。出版されたらそちらも読んでみたい。
Team Geek
HRT（謙虚・信頼・尊敬）の標語で有名。Google勤務の著者がチームで働くために重要なソフトスキルを教えてくれる本。
「コードはあなたではない。レビューで指摘されても落ち込まないように」「チーム文化はパンの酵母のようなもの。悪い文化（酵母）が入ってくるとすぐに壊れるので、大切に育てよう」など有用なアドバイスがたくさんある。
いいなと思ったのは、採用の際にカルチャーマッチを重視するという話だ。「スキルがずば抜けているが、人当たりがよくなくチーム開発に向かないエンジニアを採用すべきか」という問いにこの本ははっきり No と答えている。
スキルは習得できるが、壊れた文化を立て直すには骨が折れるからだそうだ。ここで文化が壊れるというのは、「人間関係がギスギスする」「自慢しあって褒め合わない」「人に攻撃的な態度を取る」「嫌なヤツが褒められて昇進する」とか、端的に書くとこんな職場で働きたくないと誰もが思う状況を指す。
この本から「組織カルチャー」や謙虚さ、尊敬と信頼（時にはハンロンの剃刀を持たないといけない）の重要さを知ることができた。
人を排除するのではなく、態度・振る舞いを排除するという話もためになる。嫌なことをする人を別のチームに追いやるのではなく、率直に（時にはマネージャーを通じて）「その行為はやめてください」と伝えようということだ。その人も嫌がらせをしようと思ってやってるわけではなく、単に自分の行為が人に与える印象に気づいていない可能性があるためだ。この辺りは HRT の T、信頼が鍵になる。
Clean Architecture（クリーンアーキテクチャ）
クリーンアーキテクチャ本。同心円の図も大切だが、それよりも手続型/オブジェクト指向型/関数型言語のそれぞれの意義と差異や、OOPで有用なSOLID原則を簡潔にまとめているのが重要。
方針と詳細を分けて、インターフェースに依存せよ力説している。方針は抽象、詳細は具体（具象）であり、インターフェースは抽象的な方針。この辺りがわかると OOP のポリモーフィズムや Dependency Injection（依存性注入）/ Dependency Inversion（依存性逆転）について語れる。
著者のボブおじさんはプログラミング歴50年以上で経験が豊富。昔のプログラミング経験の話も面白い。フロッピーディスクとか出てくる。彼はかの有名なアジャイルマニフェスト（アジャイルソフトウェア開発宣言）の署名者の一人。上記で挙げた Clean Coder もボブおじさんの著書。
テスト駆動開発
TDD本。実装を書いてからテストを書いても通ることわかってるから意味ないよなって思っていた時に出会った。テストを先に実装を後に書くのが目から鱗。第3部にはテストあるあるが全部書いてるので、TDDを実践している今も読み返す度に学びがある。
以前、TDDの勉強会（TDDBC）に参加して感銘を受け、学んだことを忘れないように TDDの実践方法をブログに書いたら、TDD特集で Software Designに寄稿することになった ので個人的には思い入れが強い本。
TDD で注意すべきことは、TDD で書くテストは testing というよりは checking なので本番でバグが出ないわけではないことだ。テスト技法というより設計技法なのである。
TDD/ATDD/BDD などをまとめて Example-Guided Test と呼ぶ向きもあり、言い得て妙だ。エッジケースや仕様の考慮漏れなど入力値の例が足りなければバグる可能性がある。しかし、TDD で書くテストは CIでの自動テストやリファクタリングの強力な基礎になる。ただ、このテストはソフトウェアをバグから守る鉄壁の守護神ではないという点だけ覚えていてほしい。
著者の Kent Beck もアジャイルマニフェストの署名者の一人でXP（エクストリーム・プログラミング）の考案者。ちなみに、上記とは別のTDD勉強会で Kent Beck とペアプロをしたことがある人とペアプロをしたことがある人とペアプロをしたことがあるので自分の Kent Beck数は3。
LeanとDevOpsの科学
アクセラレイト本。先人たちが「こうすれば開発はうまくいく」としてきたプラクティスや組織カルチャーの有用性を、大小様々な会社で統計学的に調査。結果、ハイパフォーマンスなプラクティスとそれらの関係性を洗い出して紹介した実用的な本。
書籍が出版された後に、ハイパフォーマーよりもパフォーマンスがいいエリートという区分が設けられた。上位プレーヤーはさらにパフォーマンスが高くなり、それ以外のプレーヤーとの差は年々広がるばかりとのことだ。
実はGoogle Cloudのドキュメントから無料で似たような内容を読むことができるが、個人的には本の方が頭に入りやすいので書籍をオススメした。
これらの本の内容はソフトウェア開発における発展的な取り組みの基礎になる
Clean Coder はプロとしての誇りについて、Team Geek はチームでうまくやろうという話をしてくれる。Clean Architecture で OOP の勘所を掴んだ後は、TDD で実装していく。コードを書いたらCD/CIを整備して、デプロイ回数を増やしてハイパフォーマーを目指しつつ、運用も人に投げずにやっていく（DevOps）。それぞれ異なるテーマであるようでいて、互いに重なる部分はかなり大きい。
ここで紹介した本を読み込むと「心理的安全性」「ペアプログラミング・モブプログラミング」「オブジェクト指向プログラミング（OOP）」「SOLID原則」「TDD」「ユニットテスト」「継続的デプロイ（CD）」「DevOps」などのキーワードについて語れるようになる。
さらに、アジャイル開発の流派であるXP（エクストリーム・プログラミング）やスクラム、Go や TypeScript など OOP 以外の言語での開発でも底通する普遍的な原則、受け入れテストやシステムテストなどユニットテスト以外の様々な種類のテスト、CD/CIや本番でのモニタリングといった発展的な内容に踏み込む足がかりとなる。読書のROI がとても良い本たちだ。
ちなみに、エンジニア向けに「10冊選んでくれ」と言われたら以下の5冊を追加する。
ソフトウェア開発以外の本をと言われたら、この5冊を挙げる。
これらの書籍についてもいつか詳しく紹介するかもしれない。
変更
(7/24) ソフトウェア開発以外の本のうち 武器としての交渉思考 を「失敗学のすすめ」に変更。
Happy Coding 🎉
