一般書編の続きです。
毎年恒例ですが、本を横に置きつつもまあまあ記憶に頼って書いている箇所があります。なので、事実誤認は少なからず含まれる可能性が高いです。また、Amazonアソシエイトリンクが付与されているので、苦手な方はご自身で再度URLを編集するか検索し直してください。
印象に残った技術書
といっても、個別具体の技術を今年一年はあまり深められませんでした。というのもなんだか組織や人をリードするようになってしまい、技術を掘る時間が減ったためです。来年はそういうのは全部人に任せて監督するだけにし、自分はコードを書きたい所存です。よろしくお願いします。
スタッフエンジニアへの道
仕事の方でスタッフエンジニア相当の職務をこなす必要があると考えていたものの、実際そのポジションの人たちがどう立ち回るべきかについては未定義な部分が多く、年の半分くらいは自分たちの職務定義をしていました。私自身は外資系での勤務経験があるのでなんとなくどのくらいからがシニアで、どのくらいからがスタッフかの違いは感覚があるといえばあったのですが、同僚に伝える際の共通言語をきちんと作っていった方がよいだろうと思っていました。その整理のさいにとても役に立った一冊でした。
内容が非常に多岐にわたるのと、この書籍がなければ職務定義が終わりきらなかっただろうなという気持ちもあり、後日ちゃんと書評を書きたいと思っています。とくに印象に残っているのは3章の技術戦略に関する箇所、7章の自分がロールモデルであるという箇所、そして最後のいい影響の広げ方の箇所でした。
スタッフエンジニアの任命を考えている組織や、実際にスタッフエンジニアになったみなさんにおすすめの一冊だと思います。たまにジュニアなエンジニアが読んでいるのを見るし薦めているのを見るのですが、老婆心ながらちょっと体感が湧かず、内容が難しいかもしれません。もちろん読んでみるのはいいことだとは思うのですが。（それより職場の先輩をちゃんと見た方がいいですね！）
エンジニアリング統括責任者の手引き
こちらはどちらかというと技術戦略の策定をどうやるのかなと思って紐解いた一冊でした。たぶんCTOとかVPoE（大組織だとグループヘッドくらいのレイヤーでそうしたポジションに就くことがあるとは思いますが）が想定読者だと思うのですが、そうしたポジションに就いた人向けに書かれている一冊です。
3章の技術戦略の章が非常に参考になりました。リチャード・ルメルトの『良い戦略、悪い戦略』を少しアレンジしたフレームワークを使って技術戦略を策定する方法が示されます。「戦略」というのは非常に難しい単語で、人によって解釈が変わりますし策定の仕方も変わりますが、ルメルトのやり方は理にかなっており私も参考にしました。2026年はおそらく、技術戦略の立て方を周りのスタッフエンジニアに伝えていくのが次のフェーズになるのですが、そのときに共通言語として使えるフレームワークなり用語があると非常に役立ちそうに思っています。
加えて11章の「社内コミュニケーション」はすでにVPoEやチーフアーキテクト（プリンシパルエンジニア相当？）が試行錯誤しながらもやっているのを目の当たりにしていたのですが、改めてこれにはプラクティスがあるのかというのも勉強になりました。またそういうポジションになったら読み返したいですね。
戦略の立て方については、さらに下記の書籍で詳しく指南されています。技術戦略の立案に苦労されている方はぜひ。
ソフトウェアアーキテクトのための意思決定術
こちらに感想を書きました。
ソフトウェアアーキテクトという仕事は、システムデザインのようなアーキテクチャリングはもちろんのこと、多くの時間を意思決定に使っていることが多いです。システムデザインに関する情報は巷にたくさん流れていますが、意思決定の仕方について指南した書籍は少ないのでは？というのが本書の書かれた動機でした。
とくに卓越性に関する話は、今過去に書いた感想を読んでいて改めて大事だと思いました。簡単にいうと制作物の手を抜かないといったような話で、ついつい「トレードオフ」という言葉を並べて何かを諦めようとしてしまいがちな開発作業を諫める良い言葉だと思っています。アーキテクトやスタッフエンジニアはバーレイザーであるべきなのです。もちろん、無理強いをしてはいけないのですが。
Managing Technical Debt
技術的負債という言葉をかなり詳細に分析した一冊です。技術的負債という言葉の定義から、技術的負債を返済するための過去のプロジェクト参加者へのヒアリングの仕方まで、実践的な内容がいろいろと書かれているように思いました。
この本を読んでから、技術的負債という言葉の使い方に気をつけるようになりました。単なる手抜きと技術的負債は明確に異なった概念で、手抜きは手抜きなのできちんと指摘しなきゃなと思うようになりました。本書では技術的負債は下記の9原則あると説明されます。
- Principle 1: Technical debt reifies an abstract concept.
- Principle 2: If you do not incur any form of interest, then you probably do not have actual technical debt.
- Principle 3: All systems have technical debt.
- Principle 4: Technical debt must trace to the system.
- Principle 5: Technical debt is not synonymous with bad quality.
- Principle 6: Architecture technical debt has the highest cost of ownership.
- Principle 7: All code matters!
- Principle 8: Technical debt has no absolute measure—neither for principal nor interest.
- Principle 9: Technical debt depends on the future evolution of the system.
技術的負債の議論を見ると、結構アプリケーション側のコードベースに閉じた議論が多いなと思うことがあります。本書によれば技術的負債は全部のコードが議論の対象です。つまりCIのコードやIaCのコードもこれに含まれます。システム全体として、どこでどう負債を借りたかを分析して対処するのが、本当の意味での技術的負債の返済なのだなと思いました。
ちなみにですが中身が結構重厚で消化しきれていないので、またどこかの機会でノートにまとめなおして頭の中を整理したいです。
APIデザインパターン
だいぶ積んでたんですが、使い勝手のいいAPIを作る必要のあるプロジェクトに入ることになって、「いいAPIとはなんだろう？」と思い読み始めました。実はまだ途中なんですが、読んでなかなかよかったのでリストアップしておきます。
APIデザインで悩むポイントはたとえばページネーションであるとか命名の仕方であるとか、はたまたどうやってユーザーに処理の結果を伝えるのがベストなのかであるとか、そういったところが多いと思います。かなり体系的に理由とともに説明してくれるため、非常に勉強になりました。この辺りの知識は若干職人芸であったり口伝的なところがあり、私もそのようにして先輩から教わってきた節があります。それではいざ人に勘所を教える際に困ってしまうので、こうして書籍の形にまとまっているのがよいことだと思っています。
あくまでデザインパターンであり、ベストプラクティスであるとかこうしなさいという類の話ではない点にも注意だと思います。各社さまざまな慣習ややり方はあるのでそれを踏襲しつつも、闇雲に踏襲するのではなく、本書で説明された「こうする理由」を用いながら、「ほんとうにこれでいいんだっけ」を議論するといいと思います。
達人に学ぶSQL徹底指南書
SQLに弱い自信があったので読みました。私はNoSQLのキャリアが正直長く、SQLは正直まったく詳しくなかったです。新卒研修の頃にSQLの研修があって、そこで覚えたもの＋ネットで調べて得た知識を駆使してがんばっていました。
ウィンドウ関数など「おーこれは便利」となるSQLもいくつか紹介されていました。結果EXISTS句しか今のところ業務で使ったことはないのですが。一旦「知っていて、とりあえず本書を参照すればあとはわかる」と思えたのがよかったのかなと思っています。読書とはそういうものですしね。
個人的に本書のおもしろポイントは後半13章からはじまる著者のSQL外の蘊蓄部分だと思っています。めちゃくちゃおもしろくてむしろこっちの内容ばかり頭に入ってきました。ありがとうございました。NULLは撲滅しよう（違）。
NewSQL徹底入門
これは直近感想を書いたので、記事で代えさせてください。
原論文から解き明かす生成AI
『サム・アルトマン』を読んで、今のLLMの流れがどのようにできたかを知りたいなと思ったので、実際に論文をあたりながら読める本書が最適だろうと思って手に取りました。2025年らしい一冊だったと思います。
本書のすばらしいところは、もちろん本書を読んでLLMの内部理解が深まる点にもあるのですが、論文を読むことに長けた人が実際にどのように論文を読んでいっているか体感できるところにあると思いました。私は正直本書の評価に詳しくなく、また学部卒なのでそこまで論文を読むことに長けていない自覚があり、本書の節々で語られる情報は非常に有益でした。すぐに論文を漁る生活をする予定はないのですが、たとえばR&Dの方に「これ読んできて」と言われた時でも対応できる…かもしれない…本書と一緒なら…と思える一冊でした。
ちなみに内容は普通に高度で、ChatGPTといろいろお話をしながらようやく追いつけたかな…という感じです。もうちょっと時間をとって理解できていないところを理解したいですね。
積んでるけど紹介したいもの
直近で関心を持っているトピックを紹介します。
ドメイン駆動設計と結合
実のところ私はドメイン駆動設計を採用するかどうかはどちらでもいいと思っているのですが、採用するとまず開発者間での共通言語ができ、イベントストーミングのようなコミュニティの育てた開発のプラクティスを利用できるようになるという点でメリットがあると思っています。一方で、共通言語の定義づけが甘いと人によって言っていることが違ってきてしまい、結果どちらでもよいような議論にエネルギーを費やしてしまう可能性が高いというデメリットもあります。残念ながら私の見立てではDDDは定義づけの甘い部類で、これにより自転車置き場の議論を多々業務中に見ることも多かったように思います。原因は、共通言語として利用できる体系的に知識をまとめた書籍や資料があまりに重厚で、読んでもらう・読むにはハードルが高く躊躇する人が多かったからではないかと考えています。
そういうわけで『ドメイン駆動設計をはじめよう』は良い書籍だと思っています。この書籍のすばらしいところは、DDDに行き着くまでのさまざまな手法をすべて排斥するのではなく、最初に出てくる業務分類のフレームにしたがって、「このケースであればこう使うとよいだろう」と整理している点にあります。DDDの原著は正直なところ哲学的というか叙述的な[*1]書かれ方をしている部分が多く、意味を掴みにくいのが正直なところです。Eric Evansの講演を聴くとそもそも彼がそのような語り口をすることが多く、そういう文体を持つ人なのだと思って読む必要がありそうなのですが、大半の読者にとってそれは関係ないことです。LDDD本はEric Evansの意思を汲みながら彼の主張を再編成し、かつ著者独自のフレームにしたがって再解釈しながら議論を進めています。現代的にアップデートされているなと感じる箇所も多く、今からDDDをはじめる場合にはぜひこの本から、と思っています。
そして同じ著者が書いた『ソフトウェア設計の結合バランス』も合わせて読むとよいと思いました。結合バランス本もやはり、疎結合や密結合などさまざまあるが、まず結合バランスは状況によって使い分けられるべき。さらに新しい概念を投入して、結合度の分析をできるようにするといった内容が含まれています。Findy社が11月に主催していたアーキテクチャカンファレンスに参加し、著者の基調講演に参加したのですが、LDDD本とこの結合バランス本をミックスしたような講演になっていました。両者は地続きなのだと思っています。なので、両方とも読んで理解した方がよいのではと考えています。
単に積んでる
うーんやりたいです。今年こそは。
まとめ
O'Reillyのサブスクを今年から契約し始めたのですが、本当におすすめです！
一般書編もよろしくお願いします！
