最近読んだビジネス書/技術書

最近読んだビジネス書/技術書を備忘録として書いていく。

気づけば1年以上更新できていなかったので、最近と書いたものの2025年〜今までに読んだ本をピックアップする。

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

• 会社の輪読会で何を読むか迷っていたときにタイミングよく出版されたためチームメンバーと読んだ
• リファクタリングを構造の変更と振る舞いの変更にわけ、まず1人で簡単に始められる構造の変更をTidyingとして紹介しており、そのプラクティスを書いている本
• オプションという金融の考え方を引用しながら、変化の激しい状況だからこそ、小さいコストでより幅広い選択肢を取れる状況に整頓しておくことの価値が書かれていたのが目から鱗だった

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

• 職能横断チームを新しく組閣して開発を進めるにあたって、開発ではない職種のメンバーにもアジャイルの考え方やプラクティスを実践していきたいと考えて読んだ

ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ

• 現代のソフトウェアテストの考え方や、シフトレフトを実践するためにどういう取り組みができると良いのか学ぶために読んだ本
• 扱うトピックが広く読んでも咀嚼しきれていないので、改めて業務でテストに触れるタイミングで参照したい

経営×人材の超プロが教える人を選ぶ技術

• 採用や育成に関わるタイミングだったため、自分の中での観点を作るために読んだ
• すぐに実践するのが難しいが、「経験・知識・スキル」->「コンピテンシー」->「ポテンシャル」->「ソースオブエナジー」という逆三角形のモデルを描きながら、それぞれの階層について具体的なエピソードから深掘りをしていくということは取り入れたい

ストリートコーダー

• この本もTidy First?と同じく会社の輪読会で読んだ
• タイトルや表紙からネタ感が強かったが、文章もジョーク多めで著者自身の経験からTipsを紹介している本だった

チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計

• 組織体制を考える機会が増え、どんな軸や考え方で組織設計をしているのかに興味を持っていたタイミングだったので読んだ
• 様々な論文や書籍の内容を引用しながら、組織のアンチパターンを紹介している本
  • 例えばプロジェクトのたびにチームを解散/組閣する「共有リソースプール」
• なぜそのパターンが問題なのか？どのように対応していけば良いのかの説明の根拠が明確で納得感を持って読めた

ソフトウェアエンジニアガイドブック ―世界基準エンジニアの成功戦略ロードマップ

• 今の自分の役割や業務内容を俯瞰してみたかったため、エンジニアのキャリアについて書いているこの本を読んだ
• 本の著者は、 Gergely Orosz | Substack 「The Pragmatic Engineer」というニュースレターの著者で、元々はUberやMicrosoftでソフトウェアエンジニアとして働いていた方
• 約570ページあり一度まとまった時間で読むというよりも、今後定期的にキャリアを考えるタイミングで読み直す形で参照したい

作る、試す、正す。　アジャイルなモノづくりのための全体戦略

• AIを活用した開発プロセスを考えていく中で、適切なシステムやドメインに対しては、要求を捉えて仕様を考えるところに開発者が入っていきたいという気持ちがあり、そこをどう進めるべきか何かヒントになるものがないか知りたいと思い手に取った本 *「考えてから作る」のではなく、「作りながら考える」

ベクトル検索実践入門

• キーワード検索は馴染みがあったが、べクトル検索についての理解が浅かったため読んだ
• アプリケーションエンジニアがベクトル検索を扱うために必要な基本的な用語や裏側の仕組みの概要を知るにはとても良い本だった

【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？

• AIが前提となった開発プロセスにおいて、要求や仕様をどう扱うかということを考えていたので、昔の本だが周囲で勧める人が多いこの本を読んだ
• 理由、要求、仕様、という3つの組 「理由」なぜ実現したいか？ 「要求」実現したいこと *「仕様」要求を満たすための振る舞い
• 要求は階層構造になるため、要件定義では要求あるいは仕様をもとに、理由を明確にして抽象と具体を行き来しながら親や子の要求とそれに紐づく仕様を明確にしていくことが重要(意訳)

プアジャパン――インフレ世界を生き抜く資本戦略

• 金利や物価が上がっている日本で暮らす中で、自分の資産を守り子供に引き継ぐためになにができるのか？今やっていることの見直しをする機会としてこの本を読んだ。
• 後半は自分のスタイルと離れた打ち手であるためパラっと読んだだけだが、本の中心である前半部分を読んだ結果目新しいことは特になく、今の自分がやっていることや考え方が大きくずれていないことを確認できたので、そこは良かった。

誤解だらけの開発生産性【リフロー型】 ストーリーでわかる重圧とペインの乗り越え方

• Findy社のAI DevEx Conference 2026 に参加した直後だったため、組織やチームの開発生産性にモチベーションがあったため読んだ
• 職種や役割によって開発生産性としてみている指標や定義が違うという前提をまず知ることが重要で、その前提を踏まえて各職種や役割の人がコミュニケーションを取って開発生産性に対して共通の認識を作っていく、という内容がとても印象に残った

シンプリシティ ―持続可能かつ人間的で効果的なソフトウェア開発

• 達人プログラマーの著者の1人であるDave Thomasが書いた本ということで気になって読んだ
• ソフトウェア開発をシンプルにするために著者の経験に基づいたTipsを紹介している本
• 目新しい内容がたくさんあるわけではないが、改めて自分を取り巻く仕事の見直しをしてシンプルにしたくなる本だった

• asdf は知らなかったので触りたい

fzfでも厳密な検索をしたい

https://github.com/junegunn/fzf を使っているが、コマンドのhistoryを検索するときにあいまい検索が有効になっていると、検索結果にノイズが多く表示されて使いづらいケースがある。

例えば「npm」と検索をした場合は、以下のようにしたい。

• 「npm xxx」や「xxxxnpm」といった文字列は検索結果に表示させたい
• 「npx xxx」や「xxxn xxxp xxxm」といった文字列はノイズになるので表示させたくない

fzfでは、'や^などいくつかの記号を使って検索をすることで厳密な検索を実現できる。 (https://github.com/junegunn/fzf#search-syntax にサポートしている厳密な検索がまとまっている)

ただ、こういった記号を覚えて毎回検索するときにつけるのは面倒。

fzfではコマンドオプションとして--exactが用意されており、これを使うことで常に厳密な検索結果を表示させることができる。

デフォルトで有効にしたいので自分は以下のように設定している。

export FZF_DEFAULT_OPTS="--exact --reverse --no-sort --no-hscroll --preview-window=down"

Spring FrameworkのRestClientを使ってみる

Spring FrameworkのRestClientに慣れていないので、勉強として使ってみる。

前提

• Spring Framework 6.2.5
• Kotlin 1.9.25

RestClientとは

RestClient はSpring Framework6.1から提供されている、HTTPリクエストを実行するためのクライアント。

RestClient (Spring Framework 6.2.12 API)

以前はRestTemplateを使うことが一般的だったが、Spring Framework 5.1からメンテナンスモードになっているため、今は同期的なリクエスト処理であればRestClient, 非同期的なリクエスト処理であればWebClientを使う形が良い。

RestTemplateとは異なりfluentAPIを採用しているため、WebClientと同様メソッドチェーンを使って処理を簡潔に書くことができる。

使い方

RestClientインスタンスの生成

RestClient用のBuilderが提供されているので、それを使ってインスタンスを生成する。

// デフォルトのRestClient
val defaultClient = RestClient.create()

// カスタマイズしたRestClient
val customClient = RestClient.builder()
    .requestFactory(HttpComponentsClientHttpRequestFactory()) // HTTPライブラリを指定
    .messageConverters { converters -> converters.add(MyCustomMessageConverter()) } // MessageConverter を追加
    .baseUrl("https://example.com") // ベースURL
    .defaultUriVariables(mapOf("variable" to "foo")) // デフォルトのURI変数
    .defaultHeader("My-Header", "Foo") // デフォルトのヘッダ
    .defaultCookie("My-Cookie", "Bar") // デフォルトのCookie
    .requestInterceptor(MyCustomInterceptor()) // RequestInterceptor を登録
    .requestInitializer(MyCustomInitializer()) // RequestInitializer を登録
    .build()

GETリクエスト(文字列で受け取る)

RestClientはfluentAPIが提供されているためメソッドをつなげて処理を書くことができる。

val result: String? = defaultClient.get() // GETリクエストの指定
    .uri("https://example.com") // URIの指定
    .retrieve() // レスポンスの取得
    .body(String::class.java) // レスポンスボディをString型に変換

GETリクエスト(オブジェクトで受け取る)

data class Pet(var id: Int = 0, var name: String = "")

val id = 123
val pet: Pet? = defaultClient.get()
    .uri("https://petclinic.example.com/pets/{id}", id) // URI変数をセット
    .accept(MediaType.APPLICATION_JSON) // Acceptヘッダをapplication/jsonに設定
    .retrieve()
    .body(Pet::class.java) // JSONレスポンスをPetオブジェクトに変換

POSTリクエスト(リクエストボディなし)

val responseEntity: ResponseEntity<String> = defaultClient.post()
    .uri("https://example.com")
    .retrieve()
    .toEntity(String::class.java) // レスポンス全体をResponseEntityとして取得

val statusCode: HttpStatusCode = responseEntity.statusCode
val headers: HttpHeaders = responseEntity.headers
val body: String? = responseEntity.body

POSTリクエスト(リクエストボディあり)

// 送信する Pet オブジェクト (例)
val newPet = Pet(name = "Buddy")

val postResponse: ResponseEntity<Void> = defaultClient.post() // POSTリクエストの指定
    .uri("https://petclinic.example.com/pets/new")
    .contentType(MediaType.APPLICATION_JSON) // Content-Typeヘッダをapplication/jsonに設定
    .body(newPet) // リクエストボディを設定
    .retrieve()
    .toBodilessEntity() // レスポンスボディなしの ResponseEntity を取得

エラーハンドリング

RestClientで4xx/5xxが返されるとデフォルトではRestClientExceptionという例外がthrowされる。

try {
    val errorResult: String? = defaultClient.get()
        .uri("https://example.com/this-url-does-not-exist")
        .retrieve()
        .body(String::class.java)
} catch (e: RestClientException) {
    System.err.println("エラーが発生しました: ${e.message}")
}

onStatus()というAPIで特定のエラーを対象に処理を書くことができる。

// 特定のステータスコードに対するハンドリング
val resultWithStatusHandler: String? = defaultClient.get()
    .uri("https://example.com/this-url-does-not-exist")
    .retrieve()
    .onStatus({ statusCode -> statusCode.is4xxClientError }, { request, response ->
        throw RuntimeException("クライアントエラーが発生しました: ${response.statusCode}")
    })
    .body(String::class.java)

リクエスト, レスポンスを使った柔軟な処理

exchange()というAPIを使うことで、リクエストとレスポンスを使ってより自由に処理を書くことができる。

val result: Pet? = defaultClient.get()
    .uri("https://petclinic.example.com/pets/{id}", id)
    .accept(MediaType.APPLICATION_JSON)
    .exchange { request, response -> 
        if (response.statusCode.is4xxClientError) { // 4xx クライアントエラーのチェック
            throw RuntimeException("クライアントエラーが発生しました: ${response.statusCode}")
        } else {
            // レスポンスボディを Pet オブジェクトに変換
            response.bodyTo(Pet::class.java)
        }
    }

参考資料

• REST Clients :: Spring Framework

• RestClient (Spring Framework 6.2.12 API)

2024年に読んだ技術書/ビジネス書

2025年も1ヶ月経ってしまったが、去年読んだ本のうち印象に残っているものを備忘録として残しておく。 (本当は年末年始に書きたいと思っていたが、年末にインフルエンザに罹ったので、このタイミングになってしまった)

Goならわかるシステムプログラミング

Goならわかるシステムプログラミング 第2版

以前ラムダノートのセールで安くなっていて何冊か購入し積読していた本。

育休中の夜中にコツコツ写経しながら読んでいたので、育児を思い出す思い出の本になった。

本の内容がとてもわかり易く、かつGoに慣れていない読者でも読めるように書かれているので、普段Goを触っていなかったり、低レイヤにそこまで馴染みがなくても最後まで手を動かしながら読むことができた。

写経コードはGitHub - daisuzz/go-system-programming

失敗の科学 失敗から学習する組織、学習できない組織

失敗の科学

最近の自分の活動を振り返ったときにチャレンジをして失敗するという経験が少ないと感じていたので、失敗に対する意識をポジティブなものにしたいと思いこの本を読んだ。

本の中で、「失敗を恐れるあまり曖昧なゴール設定をしてしまう」、といったような内容が書かれていて、個人的にはこれが一番印象に残った。

「失敗」に関する具体的な事例も上げながら、わかりやすく「失敗」について分析している本なのでおすすめ。

問題解決の全体観

問題解決の全体観 上巻 ハード思考編

問題解決の全体観 下巻 ソフト思考編

Xで見かけて、改めて自分のスキルや考え方を矯正したいと思って育休中に読んだ本。 問題解決の型・型を実践するための道具・問題解決に取り組む際の考え方・具体的な問題解決の進め方について紹介されているので、若手はもちろん中堅も読むと自分の仕事を振り返りながら、参考にできる部分があると思っている。

CSS設計完全ガイド　～詳細解説＋実践的モジュール集

CSS設計完全ガイド　～詳細解説＋実践的モジュール集

CSS設計の考え方を理解したくてこの本を読んだ。 普段はBEMの思想で設計されたCSSを扱っているため、それ以外にどういう設計方法があり、どういう考え方から生まれたものなのかを知りたかったのでこの本を読んで、そこをある程度解消することができた。

CSS Architecture — Philip Walton を知ることができたのがよかった。

達人プログラマー 第2版 熟達に向けたあなたの旅

達人プログラマー ―熟達に向けたあなたの旅― 第2版

2024年一番読んで良かった本。ずっと読みたいと思っていたのでもっと早く読んでおけばよかった。 内容は色んな人が書いているので割愛するが、自分のエンジニアとしての人生を振り返りながら読んでいた。

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

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

ドメイン駆動設計について、対象領域をモデルに落とし込む作業と、モデルを実装に落とし込む作業で分けて説明しているので、ドメイン駆動設計の初学者が読んでもドメイン駆動設計がどういうものなのか理解しやすそう。

関数型のエッセンスとして、代数的データ型(直和と直積)をつかって型でドメイン知識を表現したり、関数を型で表現し、型を組み合わせてワークフローを表現する方法が紹介されているので、普段関数型に馴染みがない人こそ、読んだらすぐに練習/実践できる内容だと思う。(ただ、後者はできる言語が多くなさそう)

あとは、「Railway Oriented Programming」という考え方を知ることができたのが良かった。

Railway Oriented Programming | F# for fun and profit

GitHub CI/CD実践ガイド 持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用

GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用 エンジニア選書

業務では使わないが、GitHub Actionsを最低限扱えるようになっておきたいと思って読んだ本。

とにかくわかりやすくかつ詳細にGitHub Actionsの説明が書かれているので、写経をしながら読むことでかなりGitHub Actionsを扱う心理的ハードルは下げることができた。

その後業務でGitHub Actionsのワークフローを1から作る機会があったので、結果的にこの本で学んだことを活かすことができたのは良かった。

世界一流エンジニアの思考法

世界一流エンジニアの思考法 (文春e-book)

無闇矢鱈に行動するのではなく仮説を立ててから行動する、難しいものはちゃんと時間をかけて理解しようとしている、メンタルモデルを作る、普段から思考しておくことでとっさのときにすぐに意見を出すことができる、といった内容が印象的だった。

スタッフエンジニアの道 優れた技術専門職になるためのガイド

スタッフエンジニアの道 ―優れた技術専門職になるためのガイド

自分はスタッフエンジニアではないが、この本を読んで、自分は誰かのロールモデルになれているか？という問いを日頃意識するようになった。

エンジニアチームの生産性の高め方 〜開発効率を向上させて、人を育てる仕組みを作る

エンジニアチームの生産性の高め方 〜開発効率を向上させて、人を育てる仕組みを作る

この本を見つけたときは、プロジェクトの開発リーダーをしており、チームのアウトプット/アウトカムをどうやって最大化するかを考えながら仕事をしていたため、タイトルを見てなにか取り入れるものがないか知りたく手にとって読んだ本。

全体的に各著者の経験談を踏まえた内容が記述されているため、事例紹介という位置づけでこの本を読むのが良いと思った。

PRDはWhyとWhatを記述したドキュメントで、いわば要求や要件が書かれているドキュメント。各関係者の認識を揃えるために、PRDを一緒に作っていくという考え方は、ぜひ真似したいと思った。

ブランチ/リリース戦略は、Stacked Diffsという戦略が紹介されていたのが印象的だった。戦略自体は自分もやったことがあるものだったが、それにStacked Diffsという名前がついているのは知らなかった。

社内への告知と社外への貢献の両輪を回すことで、1つの取組みの成果から、効率的に他の開発者へ影響を与えることができるという考え方は、自分も取り入れたい。

ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法

ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法

会社の有志の輪読会で読んだ本。 ドメイン駆動設計に関する書籍を今までいくつか読んできたが、ドメイン駆動設計の中心となる考え方を一番日本語でわかりやすく説明している本だと感じた。 この本を読んで、自分がいわゆる戦略的設計をちゃんと理解できていなかったことを知ることができた。

現場のプロから学ぶ　SEO技術バイブル

現場のプロから学ぶ　SEO技術バイブル

業務でSEOを扱う必要があったため、同じチームのマーケティング担当に聞いて、おすすめしてもらった本。 出版してから時間が経っているので最新の状況を知ることはできないが、SEOについてマーケティング観点, 技術観点それぞれの基礎を学ぶことができる良い本だった。

読めていないが↓の本も気になっている。

強いSEO　“SEOおたく”が1000のサイトを検証してわかった成果を上げるルール

開発環境のアップデートをした

今まで使ってきた開発で使うツールをアップデートしてみたので、備忘録として書いておく。

iTerm2→Ghostty

ターミナルエミュレータとしてiTerm2を利用していたが、去年の年末に1.0がリリースされたGhosttyに切り替えた。

このブログを書いている段階では↓のIssueにあるように検索機能は実装中だが、それ以外は特に困らなさそうなのでしばらく使ってみることにした。

Search scrollback · Issue #189 · ghostty-org/ghostty · GitHub

zero configurationを掲げて作られているようなので必要最低限以外はデフォルトの設定を利用している。

カスタマイズしている点は以下のみ。

• ウインドウの表示/非表示を切り替える
• 背景を透明
• ウインドウサイズを最大幅/最大高さに変更
• デフォルトのフォントであるJetbrains Monoの合字を無効

設定ファイルの内容は以下。

keybind = global:cmd+space=toggle_visibility
background-opacity = 0.85
window-height=510
window-width=1640
font-feature = -dlig

ウインドウサイズは公式ドキュメントに記載されている以下を参考に設定した。

https://ghostty.org/docs/config/reference#window-height

Sizes larger than the screen size will be clamped to the screen size. This can be used to create a maximized-by-default window size.

chezmoi

chezmoi - chezmoi を使ってdotfilesを管理するようにした。

https://www.chezmoi.io/#what-does-chezmoi-do

With chezmoi, pronounced /ʃeɪ mwa/ (shay-mwa), you can install chezmoi and your dotfiles from your GitHub dotfiles repo on a new, empty machine with a single command.

フランス語らしく「しぇもわ」と発音するらしい。

peco→fzf

特に変える大きな理由はなかったが、触ってみたかったのでpecoからfzfを使うように変えてみた。

今まではコマンドの履歴に対してファジー検索することしかしていなかったが、この機会にブランチ名の検索もできるようにした。

↓の記事で紹介されていたスクリプトを使って検索できるようにしてみたところ、かなり快適に検索ができるようになった。

www.mizdra.net