ソフトウェア開発の、特に個人レベルで実施するプログラミングにおける品質改善の方法が示されている。考え方は、コーディング・レビュー・テストの各工程の所要時間・発見欠陥数をきちんと記録すると、より前工程で欠陥を発見した方が開発全体の所要時間を短縮でき、経済的で高品質なソフトウェアを開発できるということ。ソフトウェア工学の世界では極めて当たり前に言われていることだが、この本ではそれを方法論として具体的に取り上げ、実際にどのように計測していくかに重点が置かれている。
 実際に一人一人がこのような方法を使ってプログラミングを行えば必ず高品質なソフトウェアが開発できるというのは理解できるが、このプロセスを実施できる人を確保するのは極めて困難では無いかという印象を受けた。プログラミングの担当者にこの方法を実施してもらおうとすると、一人一人の生産性をはかって評価する為にやっていると見なされて、データを改竄してしまうと思う。趣旨を理解させて、実際にここまで手順をまとめたとしても、几帳面にこれだけの内容を記録してもらうこともかなり難しいだろう。ここまで几帳面に記録・分析できる人であれば、すぐにプログラミングよりも上流の仕事にシフトしてしまうだろう(本人が望まなくとも、まわりがシフトさせてしまうだろう)。と考えると、趣味のプログラマーに適用することになるのだろうか。趣味のレベルでここまで?と私は思ってしまった。
 と、ここまで「使えない」という様な事ばかりを考えてしまったが、このような考え方は他の事にも応用できそうだ。またこの本は、どのように実施するかが具体的に示されているので、適用イメージを想像しやすく、考え方もスムーズに理解できた。