コラムColumn

　このコラムでは、拙著「なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー」で解説している内容を端的にまとめて、その意図を説明します。

■前提
　ソフトウェアが社会の隅々に行き渡り、すべてのソフトウェアを画一的に扱うことは難しくなってきています。医療機器、宇宙航空、自動車、プラント、鉄道のように開発プロセスに規制や標準を設けて厳格に品質を管理する分野もあれば、軽微なバグが残っている可能性があってもリリースしなければならないようなスピード競争の激しい分野もあります。前者で正しいとされる考え方が後者にもあてはまるとは限りません。逆もあります。
　このコラムでは、二つの中間くらいで、ある程度のスピード感(開発コスト制約)を持ちながら品質にも配慮が必要な分野を想定したソフトウェアレビューを前提としています。こうした分野でスピード(開発コスト)と品質のバランスに困っておられる印象を持っており、ボリューム的にも多いためです。

■レビューの効果が出にくい原因
　多くの現場でレビューが「実施されてはいるが、機能していない」という問題意識をお持ちではないでしょうか。設計書のレビュー会議が開かれ、指摘もあり、議事録も残ります。しかし出てくる指摘は誤字脱字や表記の揺れ、体裁の不備といった軽微なものに偏り、本当に怖い問題―後工程やリリース後に見つかると大きな手戻りやリリース後だと障害につながる問題―はレビューで見逃されてしまいます。結果として、レビューは実施したのに重大な問題がテストやリリース後に見つかるということが起こります。私はこの原因をレビューアーの能力不足や努力不足ではなく、レビューの進め方そのものと捉えています。

■重大な問題の検出にレビュー工数を使う
　レビューの目的を重大な問題を検出することと定め、割り当てるレビュー工数に濃淡をつけることをお勧めしています。ここでいう重大な問題とは、レビュー実施後に見つかると修正工数(手戻り工数)が膨らむ問題、運用時に障害や重大なトラブルとして顕在化する問題を指します。問題と呼んでいるのは、レビューで指摘されるものは欠陥（バグ）だけではなく、保守性を下げるものや曖昧さのように直接欠陥につながるものではないけれど、修正しておくことで新たな欠陥の未然防止につながるものも含まれるためです。
　レビューは自由度の高い活動なので、先述の重大な問題以外にも誤解につながらない誤字脱字のようなレビューで見つけてもそれ以降の開発活動で見つけても修正工数がほとんど変わらないものもあります。そこで、レビュー以降の開発活動で修正しても修正工数が大きくならないものは、限られたレビュー時間を割く対象として優先度を下げます。
　下の図はその例として、レビューで検出して修正するよりもテストで検出して修正するほうが大きく工数が増加する「性能低下」とレビューで検出して修正してもテストで検出して修正してもそれほど修正工数がかわらない「エラーメッセージの誤字」の修正工数を示しています。このようなときには、テストで検出、修正しても修正工数が増えない「エラーメッセージの誤字」の検出の優先度を下げます。

図 レビューで検出、修正した場合の工数と見逃してテストで検出、修正した場合の工数

　どのようなソフトウェア開発においても、レビューに使える工数は有限です。検出できる問題を網羅的にすべて検出しようとすれば、レビュー工数が大きくなります。また、レビューアーの注意力は分散し、目につきやすい表面的な問題が検出されやすくなります。この「レビューで何を見つけるべきか」を絞り込めば、同じ工数を使っても重大な問題を見つけられる可能性が高まります。
　レビューは万能の品質保証活動ではなく、目的を定めないと効果が出にくくなる活動です。ソフトウェアテストにおいてはこうした考えは理解されていますが、レビューではまだ足りていないように感じます。具体的には、10万件のテストケースを実行したので問題ないといった件数だけではテストの効果は必ずしも期待できず、網羅的にテストを実施したつもりでも漏れがあるということは理解されつつありますが、レビューではとにかく時間をかけて問題をさがすことで効果が上がり、検出対象を限定しようとすると手抜きであると誤解されることがあります。

■目的を定めたレビュー
　レビューが場当たり的な読み合わせにならないように、簡単なレビューの手順を導入することをお勧めしています。具体的には、目的を定めたレビューを実施するために、検出すべき重大な問題とそのチェックのしかたを対にしたものを問題検出シナリオとして準備しておき、レビューアーはそれに沿って問題を検出します。検出すべき問題を決めるために、レビューに先立って「このレビューで検出すべき重大な問題は何か」を考えます。
　レビューにかけられるコスト、ソフトウェアに求められる品質、過去に発生したバグ、要求される品質特性(性能、信頼性、保守性など)、レビュー後に修正するとレビューでみつけて修正するよりも工数が多く必要になる問題のタイプや箇所などを手がかりに、検出する問題を具体化しておきます。これが決まっていないレビューは、レビューアーの経験や関心に依存した問題を指摘しやすくなります。
　レビューの成否はこの準備段階でも大きく決まります。このとき、ソフトウェアに求められる品質やかけられる工数に応じて「問題がないことを確認すること自体もレビューの重要な役割」と位置づけることもお勧めしています。指摘件数が少ないことで再レビューを実施したり無理矢理指摘を増やしてレビューの十分性を示したりしなくてよくなるからです。
　
　次回は、問題検出シナリオの作り方、生成AIを使ったレビューを紹介します。

※このコラムは全2回を予定しています。