最近読み終えた「継続的デリバリーのソフトウェア工学」が面白かったのでたまにはざっくり感想を書いてみます。
https://bookplus.nikkei.com/atcl/catalog/22/12/01/00531/

第1部「ソフトウェア工学とは何か」

この本ではソフトウェア工学を「ソフトウェアの現実的な問題に対する効率的、経験的な会を見つけるための経験的、科学的なアプローチの応用のことである」(1.2より)と定義しています。多くの技術書で触れられているような高品質なソフトウェアを作る方法のことをこの本では「工芸」とし、高品質かつ大規模なソフトウェアを作る方法である工学と区別して論じています。全15章の内の最初の第1部(第1章から第3章)にて、本来の意味から意味が変わってしまった「ソフトウェア工学」を意味を改めて説明し直していますが、読み物として一番面白いのはこの部分とも思いました。実際、「本書は、ソフトウェア工学に工学を取り戻す試みです。」(はじめにより)とも書いてあります。

第2部「学びの最適化」

仕様をはじめから決定し切ることや実装前に理解し切ることが非現実的であるという前提に立ち、漸近的・反復的な開発により徐々に仕様と実装の完成に近付ける手法について、第2部で説明しています。つまり、ウォーターフォール手法を否定し、アジャイルへの復帰及び継続的デリバリーを推奨しています。継続的デリバリーとは、「小さな変更を加えるたびにそれをリリースできるようにすること(一日に複数回)を目標に」(4.1より)することです。そしてそれを実現するためのTDD(テスト駆動開発)の説明と推奨も記されています。

第3部「複雑さ管理の最適化」

主題である「ソフトウェア工学」の実現のために重要な複雑性の管理については第3部で述べられています。目次を見ればわかるように、ここではモジュラー性・凝集度・関心の分離・抽象化・カップリングなどのトピックについて触れられています。ここまでこの本にはコード例が登場しなかったので、このまま例無しで終わるのかしらんとも思っていましたが、10章から悪いコードと良いコードの対比で各概念の説明し、どのように改善すべきかについて論じています。いずれのトピックについての章でも、最後には「改善するためにはテスト駆動が必須である」と説得されるので、読んでいて暴れん坊将軍やドラえもんを見ているかのような予定調和的な流れを感じさせてちょっと面白かったです。(これは読書感想文です。) 各トピックについての改善点とその説明には納得できる一方で、それを実現するにはまずTDDの環境が必要であり、実際に仕事にこれを適用させるにはTDDの導入が一番のハードルかもなぁとも思ったりしました。

まとめ

あらゆるソフトウェア開発現場で即座にこれを実現できるかと言えばNoなのですが、本書で得られた知識を元に現場の改善を行うのは非常に有益であるとは言えます。例えTDDの導入が困難な現場であっても、第3部のトピックを断片的にでも導入することで高品質化は可能でしょうし、新たに開発するモジュールに対してTDDを導入することでの高品質化も可能かも知れません。
小さいソフトウェアを短期間で工芸的に作成するのみならず、中長期の開発期間である程度の規模を持ったソフトウェアを開発するために知っておいた方が良い知識が本書で得られることでしょう。