2024年に1日1冊読んだ中でよかった技術関係の本トップ10

2024年読んだ本まとめ

## 気づけば1日1冊(以上)本を読んでいた
割合読書中毒で本を読む方なのですが毎年読む本を減らそう減らそうと思うたびに増えていく呪いにかかっており今年はとうとう1年で365冊以上、1日1冊以上読んでいたようです。技術書と技術書以外で半々といった感じでしょうか。

その中でもざっくり技術関係で読んだ中でよかった本を独断と偏見に基づきトップ10を紹介したいと思います。

## 10. [今日から始めるSolrベクトル検索](https://techbookfest.org/product/wSCmsmFye1bL6xDWRT6vVK?productVariantID=k23bJJdV1bg5bWWvdKwbFq)
技術書典14で購入し積んでいた本。300ページ越えの大作。

最近はElasticsearchの方が人気気味でSolrの案件は未経験だがElasticsearchの本、Solrの本とってもAPIの解説にフォーカスしている本が多い。

この本はベクトル検索というユースケースに対して深いレベルでまとまっており、付録などではCLIPやHugging Faceなど最近の機械学習系のトピックまで触れており濃度が高い。Solrに限らずベクトル検索について学べるという意味でよかった。

## 9. [マイクラで作るエニグマ暗号機](https://techbookfest.org/product/pWUKmiSWKFxGiAEPPAEaKp?productVariantID=qSke4kdVa58jvpDcQ6EQq3)
技術書典16で購入した本。タイトルの通りマインクラフトでエニグマ暗号機を作る本。

城とかフリップフロップ回路を作っているのは見たことがあるけれどそんなのまで作れるんだと思い購入。

同じく技術書典には似たような濃さでカタンで遊ぶ数理最適化も刺さる人には刺さりそうで良きでした。自分にはガチ数学すぎて難しすぎたので再チャレンジしたいです。

## 8. [CFO思考 日本企業最大の「欠落」とその処方箋](https://www.amazon.co.jp/dp/B0C232Q7QG/)
IT企業であるミクシィの元社長である朝倉さんの番組をVoicyでよく聞いているんですが、その朝倉さんがすすめていたので購入。元IT企業の社長がすすめていたのでざっくり言えば技術書(暴論)。

CFOはCEO、COOともにCスイートの一角。歴史的にはピケティの法則r > gにより投資リターンが賃金伸び率を上回っており、投資先に選んでもらうのがCFOの仕事。

統計的にROEが8%を超えるまではPBRが上がらず市場から資本コスト上、投資対象として見られていない。

ベンチャーだと作ったものが必ずしも売り上げに繋がらないこともあって、そういった時に開発生産性が悪いと言われがちな案件も過去ありました。そういった時に開発生産性が悪いのか、作っているものの筋がわるいのか切り分けしたくて[rails statsベースに投資効率を探る独自手法](https://ja.algonote.com/entry/rails-stats-valuation-2)の精度を今年はあげたんですが、職位が上がると技術者でも投下資本に対する効率の説明責任が生じる時もあるかなと。

## 7. [マンガでわかる イーロン・マスクの起業と経営](https://www.amazon.co.jp/dp/B0BMKNXSPY/)
今年はBlueskyの一般開放やmixi2の登場などXの代替としてのSNSが話題になりました。

Xを買収し、SpaceX、Neuralink、OpenAIなどに関わったイーロン・マスクがどんな人かそういえばわかっていないと思い購入(Amazonプライム会員なら読み放題)。

マンガベースにすらすらイーロン・マスクの伝記が知れてよかったです。

## 6. [単体テストの考え方/使い方](https://www.amazon.co.jp/dp/B0BLTG8Z9K/)
GraphQLのテストとかgRPCのテストとかそういう特殊なスタックのテストの書き方なら本あっても面白いとは思うものの単体テスト単体で語るところあるのか読む前は懐疑的でした。

読んだ後はモック、スタブ、テストダブルといった用語の定義をこの本の主張だとこれこれと言える様になったり、ロンドン派と古典派の違いをスラスラ言える様になったので読んでよかったです。

## 5. [イノベーションはなぜ途絶えたか: 科学立国日本の危機](https://www.amazon.co.jp/dp/B01NCLV8Z2/)
たまたま読んだ[日本の研究力低迷問題の原因と解決方法](https://docswell.com/s/YoshiyukiOhtsubo/57DD8Z-2022-07-12-094602)というスライドがよかったので類書も読みたいと思い手に取りました。

スタートアップの資金調達的SBIR制度による段階的な研究費供与など知らなかったコンセプトが知れてよかったです。影響を受けて[日本の研究力が衰えた原因と挽回策についてもまとめました](https://ja.algonote.com/entry/research-under-peace)。

## 4. [中国的経営イン・デジタル 中国企業の強さと弱さ](https://www.amazon.co.jp/dp/B0BSW8TD5J/)
[阿里巴巴B2B电商算法实战を読んだ時](https://ja.algonote.com/entry/alibaba-e-commerce)も規模の大きな話が多く、中国だからというより日本のIT企業が次のフェーズでぶつかる問題の解法が載っているのがおもしろポイントでした。

中国的経営イン・デジタルも中国だからというよりファーウェイ、小米、アリババといった大企業の制度設計、事件についてまとめてあってよかったです。日本の制度はアメリカと中国の間くらいと思っているので洋書の翻訳だけでなく中国関係の知見もあるとバランスがいいかなと。

大企業における持ち株制度やプロダクトマネジメント、取締役会の構造など知れてよかったです。

## 3. [SAML入門](https://www.amazon.co.jp/dp/B0B5GLN2YH/)
ALL STAR SAAS PODCASTで聞いた話だとシステムのSaaS化が進んでくるとSaaS自体の開発よりもSaaS自体を繋げるアグリゲーションの様な仕事が増えるそうで、実際米国ではシステム開発のうち連携部分の開発が増えているそうです。

シングルサインオンもそういった流れの中で要求されることがあり、その一つの手法であるSAMLの本を読みました。

インプレスで本を出した人はオーサーズ通信という著者限定のメルマガが購読できるのですが、このSAMLの本はユニーク性が高いのかいつも売り上げ上位におり人気の本ですね。

## 2. [プログラマのためのSQLグラフ原論: リレーショナルデータベースで木と階層構造を扱うために](https://www.amazon.co.jp/dp/B01LWTQFDN/)
RDBで木構造を作ることに特化したニッチな本。

色々なWebサービスを作っているととあるタイミングでとある概念のディレクトリ構造を作りたいと要望されることがよくあります。

個人的にはPdMサイドの判断ブレというかグループウェアでないサービスに劣化版グループウェア作ってもグループウェアには負けると思っているので、本当にそれがコアバリューかを確認してから着手する様にはしているのですが、要求されることが多いので読みました。いくつかのパターンについてメリットデメリットがわかりよかったです。

[SQL Serverだと階層構造用の組み込みsyntaxがあります](https://learn.microsoft.com/ja-jp/sql/t-sql/data-types/hierarchyid-data-type-method-reference?view=sql-server-ver16)ね。[TypeORMにも組み込みのTree Entities](https://orkhan.gitbook.io/typeorm/docs/tree-entities)があります。

ORMの進化でサポートされる方向性は感じつつも結構データ構造によって操作の計算量が変わってくるので、自由度ゼロで任せられる方向にもならないと思っており難しいところです。

## 1. [セキュア・バイ・デザイン 安全なソフトウェア設計](https://www.amazon.co.jp/dp/B09F697K2V/)
ここ数年、アーキテクチャー関係の本や勉強会が増えた印象があります。去年読んだ本ではソフトウェアアーキテクチャの基礎が一番でした。

今年も何冊かアーキテクチャーの本を読んだのですが、振り返るときはエンタープライズアプリケーションアーキテクチャパターンを読むのが多かったのと新規に出た本もそこまで腑落ちしなかったです。

外資系に勤めている人が同僚のレベルが高くて最高と言っているのを観測することがあるのですが、フリーランスに来る案件は何らかのつらみ要素を持っていることも多く、最高ではないというと語弊があるのですが時には何らかの制約、例えばバックエンドで採用された人にフロントエンドを書いてもらっているだったり何かしらのつらみ要素があることがあります。

適材適所の人材雇った方が速いと思う場面はあるものの、フリーランスのEMのような立場だと必ずしも適材適所でないスキル人材を使ってプロダクト開発のアウトプットを最大化してほしい(意訳)みたいな要望も多く、セキュア・バイ・デザインはそう言った既存人材でどうにかするしかない状況でコード上の仕組みで防げるものは防ぐといった概念と相性がよく学びがありました。

## 所感
以上です。

毎年言っていてオオカミ少年になっているのですが来年はインプットを減らしてアウトプットを増やしたいです。