読書感想 - 2024年末からこれまでに読んだ本

2025-02-22
読書

Table of Contents

最近、読んだ本についてまとめて書きます(技術書もそれ以外も含めて)

突然ですが、今年の目標は読書熱を1年間持ち続けること

キッカケは転職で、半年前から新しい職場になって仕事のレベルが上がり、良い意味で刺激を受けていて実力不足と説得力不足を感じる場面が増え始めたからです。

  • 実力不足 良い方法が分からず目の前の問題に対処できない。
  • 説得力不足 自分の感覚としては「この方法が良い」と分かっているのだが、それを他人に説明する言葉が出てこない。

僕はこれまで、あまり役割に囚われず会社に今あるミッションを遂行することを意識して働いてきました(事業がうまくいくことが大切だし、使ってもらえるサービスを作って運営することが楽しい!)。であるが故に、「バックエンド」「プラットフォーム」「SRE」など、技術専門領域に特化した技術課題を解くような働き方を求められた時、実力不足と説得力不足が露呈してしまうことがあります。

僕は今のところ、バックエンドエンジニア、プラットフォームエンジニア、の方向で技術専門領域を強めたいと思っています。とはいえ「役割に囚われない働き方」が嫌いになったわけではなく、むしろこれからもそうありたいと思っています。今の僕は広く浅くの何でも屋だから、バックエンド(またはプラットフォーム)に強みのある広く浅くの何でも屋としてグレードアップしたい!という感じすかね(ただ正直言って今後のキャリアにはかなり迷っており、現職の役割なども加味して変わることはあり得る)

TL;DR

  • 読んだ本と感想
    • 7冊でした。面白かった順に並べてます
  • (おまけ)本を読めば生存者バイアスを補正できるかも
    • なんで技術書を読むんだっけ?について個人的に思うことを殴り書きしてみた

読んだ本と感想

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント(2019/11、マーティ・ケーガン)

https://www.amazon.jp/dp/4820727508

この本はめちゃんこ面白かった。

プロダクトマネージャー(PdM)向けの書籍ですが、ソフトウェア開発に従事する人であれば、一度は読んでみる事を強くおすすめします。その理由は

  • PdMはプロダクト開発における指揮者です。各ステークホルダーは指揮者が何を考えているのか?を把握しておくと、余計な衝突が減るため。
  • この本にはPdM目線から「アジャイルで進める理由」が書いてあるため。
  • 「発見」「価値のリスク」という概念について学べるため。

本書を読んでて思ったことは、エンジニアは「価値のリスクに対して無警戒になりがちだよね」ってこと。エンジニアであれば「アジャイルによって技術や納期やQAへのリスクを軽減できるよね」とは普通に思えるのですが、「価値のリスクを軽減できるよね」と思える人はあまりいない。というか、多くのエンジニアは「価値の発見」についてはPdMとデザイナーの仕事だと考えている。しかしながら、0->1開発などにおいては、「価値の発見」について理解のないエンジニアは、たとえ技術力が高くても判断を誤ってしまうかもな、と。

その判断を誤ったエンジニアの1人は僕であり、僕も長年エンジニアをやっているため、誰からも使われない機能を何度か作ったことがあります。性能や保守性を考えてアーキテクチャを作り込んでも意味がないときって実はかなり多くて、むしろアーキテクチャ以前の発見とか要求・要件定義の部分でミスると、エンジニアリングではもうどうやっても立て直せない。←のようなことを漠然と理解しており言語化できていなかったのですが、本書がうまく言語化してくれました。

ただ、この本に書かれているようにプロダクトを開発できると良いな、と思いつつ、なかなかこの通りにはいかない、とも思います。おそらくは一番の難所となるのは、INSPIREDに書かれているプロダクト開発の進め方をやります!という方針を組織的に浸透させることができるかどうか。そして、組織的に取り組みの練度を向上させることができるかどうか、かな。

エリック・エヴァンスのドメイン駆動設計(2013/11、エリック・エヴァンス)

https://www.amazon.jp/dp/4798121967

DDDの原典。「複雑なドメインをどのようにしてモデル化しソースコードへ落とし込むか」というテーマについて語っている本。

1部の主題は、DDDの根底にある思想、ユビキタス言語。 2部の主題は、ドメインモデルの作り方、ドメインモデルをどうプログラムとして表現するか。UML、オブジェクト指向プログラミング、レイヤードアーキテクチャ、ファウラーのアーキテクチャ論、デザインパターン、などの考え方を応用し、DDDを進める。 3部の主題は、規模の大きい(より複雑な)ドメインを、どうやってコンテキストへ分割するか。境界づけられたコンテキストごとに、ドメインモデル、ユビキタス言語が存在している。コンテキストを不用意に混ぜてはいけない。

難しい本でした。たぶん、この本に書いてあることを真に理解するためには、それなりの前提知識とそこそこ大きい規模のソフトウェアを開発した経験が必要となります。初心者にはおすすめできない良書です(原典と言われるだけあって聖書っぽいというか読む人によって解釈が分かれそうな記述も多かったりね)。

現場で役立つシステム設計の原則(2017/07、増田亨)

https://www.amazon.jp/dp/477419087X

高凝集、疎結合なプログラムを書く方法の大切さが強調され、具体的なソースコードとして提示されるため、わかりやすかった。とても読み易いです。リーダブルコードと合わせて、初学者にもおすすめできる良書。この書籍のベースにある考え方はDDDらしいです。

スタッフエンジニアの道 ―優れた技術専門職になるためのガイド(2024/08、Tanya Reilly)

https://www.amazon.jp/dp/4814400861

日本では「スタッフエンジニア」という役割はまだ少ないので「読む必要あるのか?」ですが、本書には技術専門のエンジニアが目指すべきエンジニア像が書かれていますので、とても参考になると思います(むしろ、今まで上級エンジニアに対して求められることが言語化されていなかっただけであり、言語化してスタッフエンジニアと名付けたというだけ)。

スタッフエンジニアとは、シニアエンジニアの上、CTOの下ぐらいにある、エンジニアリングマネージャーなどのマネジメント職種とは異なるキャリアです。

それ故に、スタッフエンジニアへ求められる成果のレベルは高いです。この本は、内容はそこまで難しくないですが、この本に書かれていることを実践して成果を得ることは、難易度の高いタスクとなります。それだけハードルの高いことが書かれてます。技術だけやってれば良いということは全くなく、社内で主導権を得るための立ち回りも自分でする必要があるし、やるべきこと自体も自分で見つける必要があります。

スタッフエンジニアになるのはけっこう大変そう。でも目指すべきはここ。あなたが技術専門のエンジニアでありたいなら。

[改訂新版]プログラマのための文字コード技術入門(2018/12、矢野啓介)

https://www.amazon.jp/dp/4297102919

わかりやすかったです。文字コードについての仕組みをざっくりと理解できました。あと、ユニコード、UTF-8、UTF-16、UTF-32の違いがわかりました。漢字とかShift-JISとかEUC-JPとか、わりと読み飛ばしました。必要になったらこの本を読み直すかも。

エンジニアが一生困らない ドキュメント作成の基本(2024/09、仲田尚央)

https://amzn.asia/d/0FODkiM

ドキュメントを書くことも仕事のうちのひとつです。きれいなドキュメントを書きましょう!そのための方法が書いてあります。

「みんな」って誰?ー災間と過疎をのびのび生きる(2024/10、宮本匠)

https://www.amazon.jp/dp/4790717941

過疎地域をどう建て直すか?ということが書いてありました。ないもの探しをして悲観するのではなく、あるものに気づいて良い感じの雰囲気を取り戻そう!という、発想の転換が大切とのこと。印象的でした。中盤で読むことを挫折。後半は何が書いてあったんだろう?

(おまけ)本を読めば生存者バイアスを補正できるかも

この記事を書くときに色々考えたこと。

僕は技術書を読むことはほとんどありませんでした(学生時代や新卒3年目ぐらいまではそれなりに技術書を読んでいましたが、、、)

僕が本を読まない理由1 退屈だから。プログラミング、、、というか、昔から物書きが好きな性分で、基本的に、人が恣意的に書いた本を読んだり、人の話を聞いたりすることは苦手。

僕が本を読まない理由2 実戦に勝る学びはないという信念があるから。新卒にて、何もわからない状態からいきなりサーバーの保守運用をすることになったわけですが、その時の育成方針は「崖から突き落として生き残ったものをエースとして育てる」というスパルタでした。そこで生き残ってきたという成功体験。

本を読まないことにはデメリットがあります。それは自分の実戦経験以上には技術の幅広さ、奥深さを得られないことです。当然ながら仕事ですから、多くの人は自分では仕事を選べません。毎回良い実戦が経験できるわけではありません。泥試合や負け戦をさせられることもあります。自分の知識は「自分が経験したことだけから学べるもの」に限定されてしまいます。

要するに生存者バイアスに陥ってしまうということです。技術書を読むことで、自分の経験した以外の知識も学べるようになるため、生存者バイアスを補正することができます。