ソフトウェアレビューで検出すべき問題をどう見つけ出すか

ソフトウェアレビューにはいくつかタイプがあり、十分に時間をかけて取り組むことができ、レビューで問題を見逃すことは許容されないものが一つ。時間が限られていてレビューで全ての問題を検出することが前提とはされていないタイプがもう一つです。現実には、時間は限られているのに問題を見逃すことが許容されていないという厳しい組み合わせが多いように思います。しかし、よくよく精査すると後者の時間の制約が厳しいものの全ての問題を検出することは求められていないものもあるでしょう。

この時間が限られていて問題を効率よく見つけることが前提となっているレビューでも見逃すと困る問題があります。それは見逃すと大きな手戻りにつながるものです。性能問題をはじめとして「レビューで検出しておいてよかった」という問題にいくつか心当たりがないでしょうか。振り返ってみると「このタイプを重点的にみつけていた」というものもあると思います。では、そうした検出すべき問題をどのようにして決めればよいでしょうか。

過去のレビューやテストで指摘された欠陥はその一つです。「これを勘違いしがち」「この部分を忘れがち」というものを一般化したものです。もう一つはソフトウェアの基本に立ち戻って「これがないと成立たない」というものが期待通り実現できているかどうかを調べます。要求として明示されていることもあれば、列挙されている要求の中に埋もれていることもあります。暗黙の要求として明示されていないこともあるでしょう。

レビューを始める前にそうした優先順位の高い問題はどのようなものであるかをレビューア間で合意しておく必要があります。たとえば、在庫管理システムであれば、在庫が正しくシステムにも反映され、複数の入庫通知や出庫指示が同時にあっても期待通り動作することです。また、倉庫の入庫、出庫がある時間帯はシステムも常に動いていることも当たり前ですが必要です。こうした期待通りの動作を阻害するような問題がないかどうかをレビューで確認します。

レビューで検出すべき問題をどのように確認するかを「シナリオ」として書いておき、レビューア間で合意してからレビューに臨むやり方と心構えを拙著「なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー」に書きました。2年前のことです。そして2015年9月に改訂版を発行することになりました。初版ではシナリオの例示にとどまっていた部分を改訂版では事例として加えました。事例は優先順位をつけてレビューされているレビューアから伺った話をもとにしています。認証システム、案件管理システムといった具体的なシステムを4件挙げて、どのようなシナリオを設定すべきか決める方法をパターンに分けて示しています。日経BPのオンライン書店ページはこちら。Amazonはこちら。

2015年10月16日(金)には、名古屋で改訂版に沿った内容で1日セミナーの機会をいただいています。通常、東京と同月開催が多いのですが、今回は名古屋を先にしていただいています。JR名古屋駅前なので、首都圏の方も関西の方もご検討ください。詳細はこちらから。9/18(金)までに申し込んでいただくと早期割引きになります。