2025年に読んだ、ITエンジニアに関する本まとめ
2025年に読んだITエンジニアに関する本のうちの何冊かについて、紹介と感想を雑に書いていきます。
読んだもの
マネジメントは嫌いですけど
開発がやりたくてITエンジニアになったが、実績を積んでいった結果、リーダーやマネージャーに昇格し、マネジメント業務を本格的にやる必要が出てきた… そういう人、私も含めて世の中にそこそこいると思います。 この本には、エンジニアからマネージャーになった人が、今後マネージャーとして生き残っていくための様々なノウハウが書かれています。
世の中、「良いリーダーやマネージャーになるための本」は無限に存在します。 しかし、「エンジニアがある日突然マネージャーになり、マネジメントについて何も分からない中、それでも何とか生き残る方法」について書かれたマネジメント本は、これを除けば恐らくなかなか見つかりません。
他にも、ギークが疎かにしがちな(気がする)人材育成や組織の中の金勘定の話についてもしっかり書かれているので、「開発がやりたい」というモチベだけでエンジニアをやってきた人は全員読んだ方が良い本ですね。
この本に書かれている様々なトピックを、一部抜粋して私の感想を交えて紹介します。
マネージャーって本当に要るの？
Googleは、2002年に実験としてすべてのマネージャーを廃止し、管理職のいない組織を作りました。実験の結果、2008年に「やっぱマネージャー要るなぁ」という結論に達し。この実験を終了しました。
ということで、マネージャーは必要だそうです。ですよねぇ。
チームのアウトプットは60%の力でやろう
眼の前の成果物を完成させることだけにチーム全員が100%の力を注いでいたら、属人化が発生したり個々人のスキルアップに繋がらなくなったりする。 ということで、
- 60%を成果物の完成に使う
- 20%を技術の底上げ、訓練に使う
- 20%を情報共有に使う
とするとバランスが良いらしい。確かに良さそう。
緊急時の難しい問題に対応させる担当を「現時点で最も能力の高い技術者」にしない
これ、結構直感と反する考え方だなぁと思いながら読んだのですが、「緊急時の難しい問題は、スキルアップさせたい人」に任せられるような体制を作ったほうが良いそうです。 シンプルにベテランが解決してしまうより、中長期的にはそっちのがチームのスキルの底上げに繋がるからだとか。 これ、確かにそうなんですが、緊急度の高い問題は、できる人が最速で片付けた方が良いのでは、とも思います。 「難しいけど緊急度は高くない問題」あたりをスキルアップさせたい人に任せる、とかなら無理なくできそうですかね？
マネージャーの責任の中には会社が潰れた時にも食べていけるようにしてあげることも含まれる
マネージャーはプロジェクトの進行にだけ責任を持つのではなく、会社が潰れた後もチームのメンバーが食べていけるようにちゃんと育てなければならないそうです。 エンジニアが高いスキルを身につけられるかどうかは、最終的には個々人の努力で決まるものかなと思っているのですが、 確かにマネージャーとしては、スキルアップのチャンスぐらいはどうにかメンバーに与えていけた方が良いかなと思います。
センスの良いSQLを書く技術 達人エンジニアが実践している３５の原則
データベースをそこそこ触り慣れてる人が、データベースをより深く理解するための本です。
SAPPORO ENGINEER BASE #5で話した発表資料があるのでこちらをご参照ください。
達人に学ぶDB設計徹底指南書 第2版
データベース設計の「なぜその設計にするのか」を体系的に学べる一冊です。
正規化の理論から始まり、論理設計・物理設計の実践的なノウハウ、さらにはアンチパターンまで幅広くカバーされています。 「とりあえず動きはするテーブル設計」から「保守性が高く、パフォーマンスも考慮された設計」ができるようになるためのスキルアップに使える良書です。
ある概念の必要性を考えるコツ
この本では、概念スキーマの必要性が、「概念スキーマが無くなると何が困るのか」に置き換えて書かれていました。 ちなみに何が困るのかというと、「変更に弱くなる」ということです。
これ、他のあらゆる概念について学ぶときも同じ考え方でいけそうですよね。 「この概念がなぜ必要なのか」を考えるときは、「この概念がなくなると何が困るのか」を考えるとわかりやすくなる。
正規化
この本、正規化についての説明が今まで読んだどの本よりもわかりやすかった。 （正規化についての説明は割愛します）
データ構造の重要性
フレデリックは、人月の神話で「テーブルを見せてもらえるならフローチャートは不要」と言った。 しかもデータベースという概念がまだそれほど一般的でない1975年に。 つまりこの時点で、システム開発において最も重要なのはデータ構造ということは自明。
確かに実装難度ってDBが良い設計になっているかどうかにかなり左右される気がしますね。
技術の波に乗り遅れない!すべてのITエンジニアのための「一生モノの学び方」
技術の変化の激しいIT業界で長く生き抜くための考え方や学び方を体系的にまとめた一冊です。
タイトルの通り、技術そのものの説明は比較的少なめで、
- 「いつ」「どんな」技術を学ぶべきか
- 「どうやって」技術を学んだら良いか
という話が多めです。
標準的な技術を使う理由
- さまざまなシステムと連携しやすい
- 自分で考えなくても堅牢な物が作れる
- 応用範囲が広く、一度習得すれば自分の技術力につながる
だそうです。わかる。 ちなみに、学び方の話からは外れるんですが、標準的な技術を使っといた方が「それを使える人を探しやすい」というメリットもあります。
コラム - よくある質問
この本、良いコラムが随所に散りばめられています。特に良かったのは「よくある質問」のコラムで、以下のような質問に対して著者が回答しています。
- 最初に学ぶべきプログラミング言語は？
- 独学と専門スクール、どちらが良いか
- 資格は取ったほうが良いか
- プログラミングが苦手でもIT業界で活躍できるか
- 生成AIの登場でプログラマーが不要になるか
優れたエンジニアがコミュニティの中でしていること
この本には、「ITエンジニアはコミュニティに参加した方が良いぞ」とか「コミュニティに参加したらこういうことをやったら良いぞ」といった話がつらつらと書かれています。 また、章の合間に、実際にエンジニアとして様々なコミュニティや会社で活躍している人にインタビューした内容を事例として載せているため、自分のキャリアを考える上でも将来像がイメージしやすくて良い本です。
コミュニティに参加したらやってみるべきこと
コミュニティの中に入っていくのが苦手で、参加したけどなんとなく見ているだけになってしまっている人ってわりといますよね。 そんな人がコミュニティに溶け込めるようになるには、以下のようなことをやっていくと良いらしいです。
- 1.興味のあるトピックの投稿に一言返信してみよう
- 2.気になる「あの人」と1on1をしてみよう
…これ、確かにそのとおりではあるんですが、2のハードルが高すぎる気がしないでもないです。 1と2の間に、もっと色々できることがあるのでは？と思いました。例えば
- 自ら投稿して話題提供してみる
- LT会とかがあるなら1回登壇してみる
とか。
コミュニティに参加するメリット
色々あるそうです。例えばこういうの。
- 「この場だからこそ話せる」リアルな知見や経験談が数多く共有される
- 何なら競合他社だったとしてもざっくばらんに意見交換されたりする
- 登壇経験が積める
- 自分の居場所が増える
- 師匠が見つかるかも
- (自分から企画立てたりして動けば)リーダーの経験が積める
- 失敗しても許される
- 場合によっては、会社内より高い評価を受ける
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
Java Doの【札幌10/4】増田 亨さんと設計の実践的な考え方を学ぼう！というイベントで、この本の著者の話を聞いた影響で買った本です。
コードの見通しを良くしたり、変更に強い設計をできるようになるためのノウハウがまとめられた本です。
この本、ドメイン駆動設計の入門書として読んでも良いかもしれません。 私はドメイン駆動設計についてはあまり詳しくないんですが、それでも本の内容はすんなり入ってきました。
データクラス
データクラス(DTO)ってありますよね。DBやクライアントから渡されたパラメータ群などを入れておくためだけのクラス。 これを多用すると、業務ロジックの見通しが悪くなるので良くないそうです。 持っているデータをただ取り出せるようにするのではなく、そこに本来必要になる固有の業務ロジックを組み込んだりしたほうが、データと業務ロジックの関係がわかりやすくなります。
ちなみに、現代の現場でもデータクラスがよく使われるのは、かつてCOBOLやCの開発で使われていた設計の考え方が、 そのまま現代の設計にも適用されてしまっているかららしい。
「分かった！」と思わせる説明の技術 知識ゼロの相手にも伝わるようになる本
これは「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典の管理人が書かれた本です。
必要な事柄を必要な相手にわかりやすく伝えられるようになるためのノウハウが書かれています。 この本は、あくまで「わかりやすい説明をする方法」についての本なので、厳密にはITエンジニアの本ではなく一般的なビジネス書です。人に何かを説明する機会がある人であれば、誰が読んでも良い学びを得られると思います。
説明の定義
本書によると、説明とは「自分のもつ情報を相手にコピーすること」だそうです。
しかし、通常私たちが想像する「コピー」とは異なり、「説明」はそのままのデータを渡すのではなく、
- 話し手による加工
- 聞き手による解釈
を経由して相手に伝わります。そのため、
- 情報を簡潔に伝わるように加工できるか？
- 相手がこれを正しく解釈できるのか？（相手の理解度に合わせた説明にできるか？）
という点を考えて説明の仕方を工夫する必要があります。
正確な説明は諦める
本来難しい概念について説明するときは特に、正確な説明は諦めましょう。わかりやすさと、正確性はしばしばトレードオフになります。 難しいことは、「簡単に説明できないようになっている」からこそ難しいのです。
わかりやすさを重視した説明をしたいなら、
- ややこしいところは端折る
- 例外パターンは捨てる
みたいなことをして、まぁ7～8割合ってるぐらいのものにしましょう。
これ、ゆるコンピュータ科学ラジオでもあるなぁ。 色んな概念について説明する時に、「今回、わかりやすくするために正確性を結構犠牲にしています」みたいなやり取りがよく出る。
おまけ 読んでる最中のもの
今読んでるのはこのあたり。
