ソフトウェアレビューのメリットは？

ソフトウェア開発でのレビューといえばソフトウェアに含まれる不具合や矛盾を早期に発見しようとする作業やその承認作業をさす。ソフトウェアに含まれる不具合や矛盾は早い段階で修正されればされるほど、その修正にかかる工数が小さくなることがいくつかの事例で確認されており、また多くの方に直感的/経験的に感じられているだろう。レビューは実際にプログラムを実行しながらテストをする前に実施できるので、テストよりも早く不具合や矛盾を抽出できることがあり、修正工数の低減に寄与する。

レビューの対象は多岐にわたる。ソフトウェア開発の成果物、中間成果物のほとんどはレビューの対象とできるだろう（効率的であるかどうかは別として）。要求仕様、外部設計仕様、ソースコードはもちろんのこと、テスト仕様（テスト設計）、テストケースもその対象といえるだろう。レビューの対象としてポピュラーなのは設計書やソースコードだろう。

レビューの効果の1つは不具合や矛盾の早期発見だ。ただし参加メンバの類似プロジェクトにおける経験、対象成果物の品質に依存することが多く、現実には常に期待どおりの効果を得られるとは限らない。しかしながらレビューには副次的効果も多く、他のメンバの担当部分の理解（往々にしてその理解が未然に不具合や矛盾を防ぐことが多いと思う）、OJT的な教育の側面が挙げられる。

一般には、対象プロジェクトの内容がよくわかっているメンバでレビューすることが多いが、プロジェクトの内容はそれほどわかっていなくても効率的に指摘ができるレビュー専門部隊により実施されることもある。たとえばセキュリティに関するレビューだったりユーザビリティに関するレビューは対象プロジェクトの深い知識はなくとも実施できることが多い。

レビューの問題点はモチベーションの維持ではないかと思う。効果があることが経験的にわかっていながらも忙しくなるとなかなか実施できなかったりする。また、レビューでは不具合や矛盾の指摘に重点を置き、修正方法についての検討は優先順位が低い。指摘に重点を置くことがレビューの効率性を維持している理由の1つだが、実際には修正方法も一緒に考えなければ効果が得られない場合もある。そのような選択の難しさがレビューに対するモチベーションを下げてしまっている場合がある。

成果物の矛盾や不具合の指摘に集中できるかどうかもレビューが成功するカギだと思う。属人的な指摘ばかりになったりお互いにけん制するための場となったりすると期待する効果は出にくいだろう。