ソフトウェアレビューの読みすすめ方、方針はありますか？ @IT記事から

@ITにソフトウェアレビューの読み進めかたの記事を寄稿した。型にはまっていただくのではなく、ご自身の普段のレビューを整理、明文化するために役立てていただきたいと思う。

レビューの読み進め方を決めていない場合、エラー指摘が特定の部分や種別に集中してしまうことが多い。たとえば、あるレビューアが「エラー処理」について指摘するとそれと類似する指摘が連鎖的に集中した経験は誰にでもあるのではないだろうか。また、「ユーザの操作誤り」、「通信ネットワーク経由の意図しない返答」等、類似指摘が集中する項目は多い。

結果として、もっと指摘が必要な部分や網羅的なチェックができないままレビューを終えてしまうこともあるだろう。

その解決策としてレビューの進行役による舵取り、読み方の方針等がある。記事では、読み方の方針として4種類のリーディング技法を紹介している。

• チェックリスト： レビューアによらず、安定した結果を得たい場合
• ユーセージベースドリーディング: 対象ソフトウェアにまだ経験が少ない場合
• ディフェクトベースドリーディング： 発見したいエラー種別が比較的明確な場合
• パースペクティブベースドリーディング： 複数の視点からの網羅的な指摘が必要な場合

チェックリストを使っていることは比較的多いが、それ以外についても特にそれと意識することなくやっていることが多い。これを明文化することによって、新たな発見や新しいメンバへの共有が簡単にできるようになる。

ご自身のレビューはどうだろうか？レビューア毎に一定の役割分担がなされているようであれば、それはリーディング技法で言われていることを暗黙的に実施している可能性が高い。明文化のためにも一読をお勧めしたい。記事のURLはこちら。