検査といわれればするのに、インスペクションといわれた途端にやる気がなくなる現場がある。なぜかはわからない。自己査定は許容水準だった。自分では、この点よりよくするつもりはありません。これ以上やると無駄が増え、改善を阻害しそうだと感じるからです。大規模組織で、大規模開発の場合と、小規模組織で、小規模開発の場合での違いがあるかどうかが課題だと考えています。

以下は自己査定の回答例です。
(1)　通常する
（２）通常する
（３）ときどき
（４）通常する
（５）ときどき
（６）ときどき
（７）通常する
（８）ときどき
（９）通常する
（１０）まったくしていない
（１１）通常する
（１２）通常する
（１３）通常する
（１４）通常する
（１５）ときどきする

インスペクションとは上流工程からの成果物(機能仕様書、テスト仕様書など）に対して一定の判定基準を元に内容を精査するプロセスのことです。

ソフトウェア開発プロセスの品質改善とプロセス自体の改善を目指したものであり、そのために本書ではデータの収集と分析を非常に重んじています。

どちらかといえば形式的なところを重んじていますが、それによる問題も同時に取り上げています。

正直な感想としては、内容に重量級のボリュームがあり、すぐに実践できるかというと、「それは無理」と感じます。
何度か実経験を踏んだ上で、さらに何をどうしたらよいか考える再に、非常に示唆に富んだ提言がかかれていると思いました。

実際の成功例・失敗例などもリアルに書かれているので、インスペクションは成功すれば成果はすごいが、そんなに容易でもないということを分からせてくれます。

分量的な面から言っても、あまりイントロダクションとしてはふさわしくないです。
インスペクション初心者には Karl E. Wiegers の「ピアレビュー」と併読することを勧めます。
「ピアレビュー」は大変良い書物ですし、内容の割には薄い本なので初心者にはもってこいなのです。
その上で本書を読むことにより、インスペクションを実施していくための理論的基礎の強化ができると思います。