ソフトウェアレビューは特にプロジェクトに合わせて変えなければならないという話
どのような開発作業であれ、対象ソフトウェアに応じてやり方を変えなければならないということは開発経験があれば誰もが感じているはずです。類似のソフトウェアや同一のソフトウェアのバージョンアップを中心にしていると、毎回同じでいいんじゃないかと思いがちですが、それでもソフトウェアに求められるものは毎バージョン変わりますし、類似のソフトウェアであっても求められるものが変わるとやり方を変える必要があります。
たとえば、要求をブレークダウンしていく際に、ユーザが自分自身でよく理解できているものを対象としてブレークダウンする場合と自身でもうまく説明ができないものの場合では、方法を変えなければなりません。テストでも、機能面で期待どおり動くことを中心にテストする場合もあれば、性能面で期待どおり動くことをテストする場合もあります。
本エントリのタイトルのとおり、もちろんレビューでもやり方を変える必要があります。では、どんなふうに変えればよいでしょうか。1つはレビューの参加メンバに合わせて検出すべき欠陥をコントロールします。プロジェクトに新しく参加したばかりのメンバに、いきなり性能問題を発見してほしいというのは難しいでしょう。メンバの経験やスキルに合わせて、発見できる欠陥は変わります。それを積極的に利用すべきでしょう。
もう1つはテストでの修正の難しさによって検出する欠陥を変えます。過去の実績データからレビューで発見できずにテストで見つかった際に修正に時間がかかるものを特定し、それを重点的に検出します。他にも、そのプロジェクトにとってリスクの高い欠陥の検出等、どのような欠陥を検出するかを変えます。
7/31(日)に開催されるプロジェクトマネージメントフォーラムの私の講演では、このあたりのことを具体的なデータを参照し、プロジェクトやソフトウェアにあわせてレビューを変えていかなければならない理由を紹介します。講演タイトルは「コンテキストを考慮したソフトウェアレビュー」。詳細はこちら。