初版から10年たった「なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー」第3版 - 加筆、変更したところと私の気づき
拙著「間違いだらけの設計レビュー」日経BP, 初版2013年9月、改訂版2015年9月を加筆、修正し、第3版となりました。2023年11月下旬くらいから配本が始まるそうです。通常、紙の書籍は売れ行きに応じて書店からなくなることがあるのですが、大きな書店では10年間置いていただいています。初版3刷、改訂版2刷となっています。こうした本の中ではロングセラーの部類に入ると思います。
https://bookplus.nikkei.com/atcl/catalog/23/11/07/01094/
このブログエントリでは、第3版で改訂版にどういう点を追加、変更したかを紹介します。また、10年で(変わっていってほしいけれど)変わってないことがあると感じたので、それも紹介します。
別のブログエントリで、初版、改訂版ともに、まだ読んでない方向けにどういう本かを説明します。また、初版を読んでいただいた方向けのブログエントリを別途公開します。
- AIを技術要素とするシステムでのレビュー (4.4節)
AIを技術要素に使ったシステムでの設計レビューの方針を2パターンに分けて、12ページ分で解説しています。ここでのAIは深層学習のようなモデル構築後の入力データ(予測用データ)と出力データ(予測結果)に関係が明瞭でなく、学習データ以外でその関係をコントロールしづらいものを指しています。 - レビューのノウハウをアジャイルに応用する方法(4.5節)
設計レビューでのノウハウをアジャイル開発に活かすためにウォータフォールでのレビューとアジャイルの活動に流用／応用できる点を12ページ分で説明しています。本書で説明している内容との共通点として、マインドや第三者によるチェック、必要な工数と得られるメリットに応じて合理的に活動を決めること、システムの価値も品質と捉えることを挙げています。応用できる点として、ドキュメントでどこをチェックするかを開発のどの活動でチェックするかを探す方法と例を紹介しています。 - 修正コストの低減効果以外の視点でのレビューシナリオ(4.1節)
また、本書の多くの部分はレビューで見逃してテストで検出すると修正する工数が大きくなるような欠陥を特定して、それをレビューで検出することを基本方針としています。しかし、これ以外にも運用の視点や要求の視点から見るとこれら以外にも重要な欠陥があります。それらをみつけるためのレビューシナリオの選定方法を8ページで解説しています。 - レビューシナリオの選定手順の説明の見直し(2章)
改訂版で追記した指針となるレビューシナリオの手順の部分を手入れしました。初版、改訂版ではトップダウン、ボトムアップと呼んでいた方法を、「見つけたい問題や欠陥を直接選定する方法(D)」と「システムの価値を考えそれを損なう問題種別を選定する方法(I)」としました。Dのほうは「こういう問題や欠陥を見つけたい」と問題や欠陥を直接指定する方法です。一般的なレビューでも身近なやり方だと思います。Iのほうは、まず「こういう価値を提供したい」を考えて「その価値を損なってしまうような問題や欠陥を見つける」やり方です。
システムの品質を高めるためには、バグが少ないだけでは不十分で、システムの価値が提供できていることも重要であるためその二つを分けて考えられるようにしています。
これらの章、節以外にもいくつか細かい部分を変更しています。
書籍冒頭の「はじめに」にも書いたのですが、改めて読み直してみて私が感じたことは次のとおりです。
本書では、おもにレビューで見逃すと後続の開発活動で大きな手戻りが発生するものをうまく選び、検出する方法を手順を追って説明しています。これは10年前から思っていて、今もやったほうがよいことだと思っています。アジャイル開発のように「レビューで見逃す」「後続の開発活動」が明確でないものに関しても同様です。具体的には「こういう欠陥を防ぎたい／検出したい」「だからXXという方法で防ぐ／見つける」という組合わせを考えて後者を工夫するというのは、あまり浸透していないように思います。
テストでも同様で「境界値分析」という手法が目立ちすぎていて、「仕様をもとにプログラムを書くと不等号等の条件分岐や条件の組み合わせを間違えてミスしがち」という境界値あたりにミスが入りやすい」という「こういう欠陥を防ぎたい」が明確になっていない場合が多いように感じています。すべてを挙げることはできないのですが、境界値分析に関しては比較的明確なのではないかと思います。ただ、そのことは感覚的には明らかになっているけれど、意識されていたり明示されていたりすることはないように思います。