今年読んで良かった本まとめ 2025｜設計・ML・研究まで幅広く紹介

2025年も残り1ヶ月となりました。少し早いですが、今年読んで面白かった本をまとめます。 今年は技術書を多めに読み、仕事で強化学習を扱う機会もあったため、機械学習関連の本にも手を伸ばしました。

ソフトウェア開発

Tidy First? 個人で実践する経験主義的ソフトウェア設計

Tidy First? ―個人で実践する経験主義的ソフトウェア設計

コードが読みにくく、1箇所を変えると他も直さないといけない――そんな現場のつらさを、「整頓」というワークフローで解決しようとする本です。

タイトルの “Tidy” は「整頓」と訳されています。整頓はリファクタリングの一部ですが、後者のように大がかりになりすぎず、自分の作業範囲で毎日続けられる改善手法として位置づけられています。本書は、この整頓を「いつ・どう・なぜ行うのか」を明快に示します。

私自身、リファクタリングは開発を止めてまとめて行うものだと思い込んでいました。日々の小さな改善として積み重ねる、という発想は新鮮で、紹介されるテクニックも扱いやすいと感じました。短い本なので、すぐ読めてすぐ実践できます。

パターン、Wiki、XP ―― 時を超えた創造の原則

パターン、Wiki、XP ―― 時を超えた創造の原則 WEB+DB PRESS plus

自然界や人の営みには繰り返し現れる形があり、ソフトウェアで言えばデザインパターンがその例です。アーキテクチャがソフトウェアの方向性を決めますが、コンウェイの法則は組織構造がソフトウェアの構造と密接な関係があることを示します。そう考えると、「良いパターンとは何か」 という原点に立ち返ることが、良いソフトウェア設計や組織づくりにつながるのではないかと思い、本書を手に取りました。

本書は、建築家クリストファー・アレグザンダーがまとめた「パターン」「パターンランゲージ」、そしてそれがケント・ベックのXPやウォード・カニンガムのWikiにどう影響したかを解説しています。これらの思想の共通点を理解できたのは大きな収穫でした。

一方で、アレグザンダーにとってパターンは六つの原理の一つに過ぎないこともわかります。ソフトウェアではパターンに注目しすぎると視野が狭くなると感じ、むしろ彼の「良い設計とは何か」という広い原則に興味が向きました。建築とソフトウェアをつなぐ貴重な一冊です。

単体テストの考え方/使い方

単体テストの考え方/使い方

今年の当たり本その1。多くの書籍がテスト手法を解説する中、本書は「良いテストとは何か」を深掘りしています。テスト観が大きく変わりました。

詳しくは以前のエントリーを参照してください。

niwanoniwatori.hateblo.jp

センスの良いSQLを書く技術　達人エンジニアが実践している３５の原則

センスの良いSQLを書く技術　達人エンジニアが実践している３５の原則

データベースの成り立ちを踏まえ、なぜそのSQLが良いのかを歴史と実例から解説する本です。

著者の「演繹的な考察は天才でなくてもできる」という姿勢が印象的で、MySQL・PostgreSQL・Oracleを比較しながら設計思想の違いがつかめました。実務での判断基準がはっきりします。

関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう

関数型ドメインモデリング　ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう (アスキードワンゴ)

「単体テストの考え方/使い方」で純関数の扱いやすさを知り、関数型プログラミングを学びたくなって読みました。

関数型の基礎から、型でドメインを表現する方法、そしてDDDとの融合まで丁寧に説明されています。実務ではすべてを関数型にできないため、永続化など現実的な問題への向き合い方も具体的です。関数型を試してみたくなる一冊でした。

ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則

ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 (impress top gearシリーズ)

今年の当たり本その2。避けられない「結合」をどう扱うかに焦点を当てた本で、強度・距離・変動性という3つの軸で整理するアプローチが非常に明快です。

詳しくは以前のエントリーを参照してください。

niwanoniwatori.hateblo.jp

機械学習

ゼロから作る Deep Learning ❹ 強化学習編

ゼロから作るDeep Learning ❹ ―強化学習編

強化学習の基礎を急いで身につける必要があり、置いていかれにくい解説書を探して本書を選びました。タイトル通り、幅広い概念を数式とコードで手を動かしつつゼロから理解できる構成です。

詳しくは以前のエントリーを参照してください。

niwanoniwatori.hateblo.jp

機械学習を解釈する技術 予測力と説明力を両立する実践テクニック

機械学習を解釈する技術〜予測力と説明力を両立する実践テクニック

機械学習の解釈可能性、いわゆるXAIの入門書です。PFI・PD・ICE・SHAP などの代表的な手法を、数式は最小限に抑え、実装例と図でわかりやすく説明しています。

特に、複雑になりがちなSHAPを単純なケースに落とし込んで説明しており、「結局何をしている手法なのか」を理解する助けになります。

その他

バッタを倒すぜ　アフリカで

バッタを倒すぜ　アフリカで バッタを倒しにアフリカへ (光文社新書)

前作『バッタを倒しにアフリカへ』で強烈な印象を残した著者が、前作では語れなかった研究内容を本書で存分に紹介しています。

サバクトビバッタの集団別居仮説を、フィールドワークと目視カウントというローテクで検証し切った執念に圧倒されました。研究への情熱が伝わってきて、読み物としても学術書としても面白い。研究者の熱意は読者のモチベーションをも上げてくれます。強くおすすめです。

みんなが読みたがる文章

みんなが読みたがる文章

「読まれる文章の書き方」をまとめた一冊です。 ここ数年、知識の定着のために本のまとめを書いていますが、どうせ書くならもっと読みやすくしたいと思い、Xで見かけた感想をきっかけに購入しました。

本書では「短く簡潔に書く」など12のテクニックを紹介しており、特にこの「短く、簡潔に」は繰り返し強調されています。今後の書評を書く際にも大いに役立ちそうです。

【書評】ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則

ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 (impress top gearシリーズ)

どんな本？

ソフトウェア設計では、モジュール間の結合をどれだけ適切に設計できるかが重要である。
本書は、この「ソフトウェアの結合設計」というテーマを深く掘り下げた一冊だ。

著者は『ドメイン駆動設計をはじめよう』の著者、Vlad Khononov氏。
前著では、ドメイン駆動設計の考え方を具体例とともに非常にわかりやすく解説している。
その書籍については、別の記事で感想をまとめている。

niwanoniwatori.hateblo.jp

内容の要約

ソフトウェア設計では、結合をなるべく減らす「疎結合」が推奨される。では、結合は本当に悪なのだろうか。

本書は、結合を悪と断じない。要はバランスである。結合とはコンポーネント間の相互作用だ。システムは複数のコンポーネントの組み合わせで成り立つ。相互作用がなければシステムは動かない。だから重要なのは「結合をなくすこと」ではなく、「どの程度の結合に収めるか」という見極めだ。

では、何を物差しにバランスを取るのか。本書は三つの次元を示す。強度・距離・変動性である。結合の強度が高いものは近くに置き、低いものは遠くに置く。強度が高いのに距離が遠い関係はバランスが悪い。ただし、変動性が低いなら、必ずしも直ちに是正する必要はない。

この三つの次元に至るまでの道筋で、本書は抽象化の要点を解きほぐす。複雑性から出発し、モジュール設計、コナーセンス、結合の諸論点をたどって考察を深め、最終的に強度・距離・変動性へと収束させる。読後に残るのは、この三語のインデックスだ。その導出過程自体が、抽象化の良い手本になっている。

思考実験

本書で学んだ知識を、自分の身の回りのケースに当てはめ、思考実験として実践してみる。

プロジェクト背景

ある企業向けにWEBアプリケーションを開発している。その中の一部に、特に複雑な機能があり、これを2つのチームで分担して開発している。
全体の規模が大きいこと、また対象機能に専門的な知識が必要であることから、「専門知識が不要なチーム」と「専門知識が必要なチーム」に分けて機能を割り当てている。ここでは仮にそれぞれをAチーム、Bチームとする。

Aチーム

主にフロントエンドを担当。ユーザーに入力画面を提供し、バリデーションチェックを行ったのち、データを共有データベースのテーブルに登録する。

Bチーム

バックエンドを担当。Aチームがデータベースに書き込んだことをトリガーに、テーブルからデータを取得して複雑な処理を実行する。

問題

この2つのチームは、共有データベースを介してデータをやり取りしている。そのため、このデータベースに対する変更コストが非常に高くなっている。
たとえば、Aチーム側の都合でテーブル構造を変更しようとしても、Bチームの処理に影響が及んでしまう。これは、フロントエンド側が対象の複雑な機能とは直接関係がないにもかかわらず発生している問題である。

分析

ここでは、本書で紹介された「強度・距離・変動性」、そしてそれらを統合した「均衡度」の観点からこの状況を分析する。

強度

AチームとBチームは、テーブルを介して相互作用している。ロジックを共有していないため、これはモデル結合に該当する。
モデル結合は、結合強度の中ではそれほど強くはないが、コントラクト結合ほど弱くもない。

距離

2つの機能を別々のチームが担当しており、開発上の距離は遠い。

変動性

両チームが担当する機能は、システム全体の中でもコアサブドメインにあたる。そのため変動性は高い。

均衡度

本書で示された均衡度の式、

均衡度 = (強度 XOR 距離) OR NOT 変動性

に当てはめると、
均衡度 = (高 XOR 高) OR NOT 高 となる。
均衡度のバランスは悪く、見直しを検討する余地がある。

改善案

強度・距離・変動性の各観点から、改善策を考えてみる。

強度

現在、2チームはテーブルを介して結合しているが、Bチームが実際には参照していないカラムも含まれている。
つまり、不要な情報まで共有してしまっている。
Aチームが必要なデータだけを抽出して提供するAPIを作成し、Bチームがそれを利用するようにすれば、共有情報を最小限に絞れる。
これにより、モデル結合からコントラクト結合へと移行でき、結合強度を下げられる。

距離

AチームとBチームの役割分担を整理し、対象の複雑な機能に特化した新チームを設ける。
同じチーム内で開発を進められるようにすれば、距離を縮められる。

変動性

コアサブドメインである以上、変動性そのものを下げることは難しい。
しかし、変動性を引き上げている要因である「複雑性」を減らすことは可能である。
複雑性には、専門知識が不可欠な本質的複雑性と、連携情報の多さなどによって生じる偶有的複雑性がある。
共有モデルの利用機能やタイミングを整理し、インタフェースや機能を分割することで、偶有的複雑性を低下させられる。

振り返り

これは思考実験であるため、最終的にどのアプローチを採用するかはここでは論じない。
ただし、本書を読む前に私が考えていた改善策は、チームを統合するという「距離」に関するものだけであった。
本書を通じて、結合のバランスをとるための複数の次元から問題を考えられるようになり、追加の2つの改善策を導き出せた。
強度・距離・変動性という考え方は、ソフトウェア設計における結合バランスを考察するうえで非常に実践的なツールであると実感した。

最後に

本書を通して、ソフトウェア設計では「結合バランスの調整」がいかに重要かを学んだ。
そのバランスを構成する次元は、強度・距離・変動性の3つである。
この3次元の視点から設計を見直すことで、より均衡のとれたソフトウェア構造に近づける。

【書評】ゼロから作る Deep Learning ❹ 強化学習編

ゼロから作るDeep Learning ❹ ―強化学習編

急ぎ教科学習の基礎を身につける必要があり入門書を探していた。他の強化学習本で置いてかれてしまって、わかりやすいと評判の本書を手に取った。まさにゼロから作る、というタイトルにふさわしい。強化学習について幅広く、数式も追いつつ、実装例も学ぶことができる。

• 抽象から具体の説明がとても丁寧。とくに具体の方は必ずシンプルな例で説明してくれる。
• 提示されているコードの説明が豊富、また必要なところを絞って説明した後にそれらを統合した全体像を見せてくれるので、必要なコードに集中できる。
• 今までの復習を何度も入れてくれるので、アレなんだっけ、っていうのが先回りして対策してあるため前のページを読み返すことなく読み進められる

【書評】人工衛星の“なぜ”を科学する

NECの衛星を中心に衛星開発の概要がまとめられている。軌道制御の話などは非常にわかりやすかった。2025年に改訂版が出て内容が新しくなっています。

改訂新版　人工衛星の“なぜ”を科学する

【書評】This is Lean | ソフトウェア開発現場の改善のヒント

This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント

会社でみんなが残業して頑張っているのに、なかなか成果が出ない状況が続いています。そんなときに出会ったのが「リソース効率」と「フロー効率」という考え方。この本を読んで、いまの開発のやり方を見直すきっかけになったので、感想とともに自分の体験を交えてまとめてみます。

---

リソース効率とフロー効率の違い

本書では、まずこの2つの効率について病院の例を挙げて説明しています。

大病院では各診療科がフル稼働していても、患者は診断まで長時間待たされる。これが「リソース効率は良いけど、フロー効率は悪い」状態。

これは、ウォーターフォール開発もまさに同じ構造だと感じました。
フェーズごとに人をかければリソース効率は高まりますが、ユーザはすべての工程が終わるまで成果物を確認できない。この構造が、現場が疲弊しているわりに顧客には良い価値を提供できていない温床になっていると改めて思いました。

---

改善のための3つの法則

本書では、以下の3つの法則をもとに改善方法が解説されていました。

1. リトルの法則

スループット時間＝プロセス内のフローユニット数×サイクル時間

リソース効率を高めるには一度にたくさんのフローユニットを抱え込んだ方が良い。しかしリトルの法則に当てはめるとこれがスループット時間を長くする原因になっている。フローユニット数を少なくすることでスループット時間が短縮でき、フロー効率を高めることができる。

---

2. ボトルネックの法則

プロセス内でサイクル時間の最も長いステージのせいで、プロセス全体のスループット時間が影響される

ボトルネックを特定し解消するアプローチはソフトウェア開発をやっていると自然に身につく考えです。例えば、ソフトウェアの性能改善の場面では処理ステップごとの時間を計測し、全体を俯瞰した際にいちばん時間のかかる部分から手を付けるのが定石。 ただし、作業プロセスの改善になると途端に見逃しがちになるのも事実かと思います。というのも、組織が細分化されて誰も作業の全体像を把握できていないためです。本書のTOYOTAの例のように、作業の可視化と共有が重要だと再認識しました。

---

3. プロセスに対する変動効果の法則

稼働率が高くなるとスループット時間が上がる、この相関は変動が高いほど強くなる

もし高速道路を走るすべての車が同じ速度で進むなら、渋滞が起こることはないだろう

これも実感があります。
スケジュールのズレが積み重なると、最後にしわ寄せがきて、いつも遅れるのは同じ部分。変動を抑えるために、作業を標準化したり変動しないように管理するなどの仕組みづくりが必要です。

---

一次ニーズと二次ニーズを整理する

本書のなかで特に印象に残ったのが「一次ニーズと二次ニーズ」の整理。

例えば、私の職場では設計は自社、コーディングとテストは協力会社に依存しています。
そのため詳細設計書をソースコードレベルで作り込むのですが、本来、設計と実装を同じ人がやるならもっとシンプルにできる作業。これは二次ニーズの典型だと思っています。

• 本当に必要な一次ニーズなのか？
• 構造上、発生してしまっている二次ニーズなのか？

この視点でプロセスを整理することが、無駄を減らし改善の第一歩になると感じました。
できるなら自社で手を動かす範囲を増やすか、協力会社に設計も任せるなど、無駄な境界線を減らしていきたいところです。

---

フロー効率改善の難しさと日本の開発構造

そして最後に、本書を読んで改めて感じたのがフロー効率改善の難しさです。

なぜなら、フロー効率を改善するには顧客と接点を持ち、プロセス全体をコントロールする主導権が必要だから。
今の日本のソフトウェア開発は多重請負構造になっていて、生産性が低いことで知られています。

この構造だとプロセス全体の問題意識の共有が難しくなる。
フロー効率を上げるには、下請けに丸投げせず、自分たちで手を動かしていくことも大事。これが簡単ではないけれど、現場で改善できるところから始めていきたいと思いました。

---

まとめ

『This is Lean』は、現場改善に悩むエンジニアにとって、具体的なヒントと改善の視点をくれる一冊でした。

• 一次ニーズと二次ニーズの整理
• ボトルネックの可視化と改善
• フロー効率を意識したタスク設計

こうした実践的な考え方を、少しずつ現場に取り入れていきたいと思います。

【書評】単体テストの考え方/使い方

単体テストの考え方/使い方

私のプロジェクトではテストコードがなく常に人手を介してテストを実施している。そこでテストコードを導入したいと考え、指針を探していた。世間には単体テストや結合テストの手法に関する書籍が多い中、本書は良いテストとは何かを深く掘り下げており、最適な内容だった。

著者はVladimir Khorikov氏。アメリカのソフトウェアエンジニアでPluralsightという学習サービスで講師も務めている。ブログも最近までは更新されているようだ。

enterprisecraftsmanship.com

この本は私のように、これからテストコードを書いていきたい人がぜひ読むべき一冊だ。本書では良い単体テストが備えるべき性質を4つ挙げており、それらの性質を備えるためにテストコードで考慮するべき事項を解説している。

• 退行に対する保護: テスト実行時になるべくたくさんのプロダクションコードを含めること
• リファクタリングへの耐性: 内部的なコードではなくテスト対象の実行結果をテストする
• 迅速なフィードバック: テストを速やかに行えるようにする（実行時間、準備の容易性）
• 保守のしやすさ: テストケースのサイズを小さく、プロセス外依存を少なく

また、単体テスト/結合テストで注力すべき点や目指す点についても説明しており、テストコードをプロジェクトに導入していく際にどこから取り組むべきなのかの指針を与えてくれる。

• 単体テストであれば、重要なビジネス・ロジックもしくはアルゴリズム
• 結合テストであれば、なるべく多くの外部プロセスを使う正常系（ハッピーパス）

本書で特に印象的だったのは、「コードもテストも負債である」という考え方だ。テストは多ければ多いほど良いと考えがちだが、実際にはコードもテストも増えるほどバグのリスクが高まり、保守コストも上がる。そのため、テストを資産ではなく負債と捉え、最小限で最大の価値を生むよう設計するべきだと説いている。

よくある誤解の一つが、テストの網羅率を100%にするべきという考えだ。網羅率を100%にすると、重要なロジックがない部分にもテストを書かなければならない。しかし、本書では「取るに足らないコードにはテストを書かず、重要なロジックに集中するべき」と述べている。

さまざまなロジックに対してどうテストを書くかというのはよく議論されるが、テストを書かなくてもよい点に言及しているのは他の書籍ではあまり見られない視点であり、コードとテストに対する考え方を見直すきっかけになった。

【書評】誕生 国産スパイ衛星 独自情報網と日米同盟

誕生国産スパイ衛星: 独自情報網と日米同盟

お正月に改めて読み返した。情報収集衛星が誕生する過程で、省内、アメリカ、国内メーカー、中国や北朝鮮などの隣国との関係と相対する動きについて綿密に記している。

2005年に書かれたもので少し古い本であるが、秘密の多い我が国の情報収集衛星についてこれでもかというくらい当時の内情を暴露（？）している。

防衛大臣になる前の石破茂氏（このころすでに軍事に関して一目置かれていた）や、当時の内閣総理大臣である森喜朗氏も出てきて少し懐かしい感じもあった。

以下、本書の概要をピックアップする。

• 情報収集の分野では当時米国が圧倒的な技術力を持っており、自国の衛星を持たない日本は米国からもたらされる情報への依存度が強かった。しかし、北朝鮮の弾道ミサイルの動きについて、米国が必ずしも即時に情報を提供していないことへの懸念が強まり、日本の情報インフラの独立性を担保する目的で情報収集衛星の機運が高まった。
• 当時の日本の技術力では要求性能を満たせない懸念があり、姿勢制御のための三軸リアクションホイールが実現できないなど技術的な壁があった。また米国の衛星を購入すれば半額で済むなど費用面での問題もあったが、自国の宇宙技術の向上と、部品をブラックボックス化させないために国産を前提として開発された。
• 情報収集衛星は宇宙の平和利用に抵触しないために災害対応も含めた多目的多機能衛星とされた。ただし、そのような一般化を進めることは、政府の調達ガイドラインに抵触し公開入札を適用しなければならない。そのため、情報収集衛星は「総合的な危機管理衛星」であり広い意味で日本の安全を確保する衛星であると解釈することでその、平和利用と調達ガイドラインをすり抜けることができた。
• メーカーでは当初は日本電気が先行して研究していたが、防衛省水増し請求問題により指名停止となっており、三菱電機が開発を受注した。
• 省内では当社は外務者や文科省が主導しており、画像分析能力のある防衛省は一歩引いた姿勢をとっていた。しかし、開発が本格化するにつれ防衛省の存在感が増し情報管理の仕組みは防衛省の考え方が浸透していった。
• 情報収集衛星は2003年に無事打ち上げられたが、最初期の二機体制では、2004年の中国潜水艦の領海侵入に対して有効な情報を得ることができず、執筆時点では目論見通りの役目を果たしているとは言い難い。これからの機数増による体制強化に期待。

---

宇宙関係の書評をまとめています。 よろしければ他の書評もどうぞ。

niwanoniwatori.hateblo.jp