ソフトウェア開発ではデザインレビューが重要なことは言うまでもない。しかし、下記のようなレビュー体制により、心理的な要素も加わりレビューがうまくいかない例も多い。

　通常、レビューではレビュア(レビューを実施する人）とレビュイ（レビューを受ける人）がいる。品質面から考えると、レビュアは類似製品を担当している第三者が適任となる。ソフトウェアの実現手段には正解というものは無く、無限の実現手段があり、性能を優先した場合、メモリ使用量を優先した場合、保守性を優先した場合と実現手段はかわってくる。ソフトウェアの非機能要求の優先順位が不明確であると、特に実現手段の判断は曖昧になる。

　このような状況下では、レビュイは自分の実現手段が一番と思っており、せっかく時間をかけて検討し、設計が完了した内容をレビューでひっくりかえされてはたまらないという心理が働く。

　一方、レビュアはかなり完璧な内容だとしても、何も指摘しないと無能と思われるという心理から無理やり問題を指摘し、修正案を出すことも多い。例えば、この製品は寿命が長いから、保守性を考えた設計にすべきという具合だ。確かに、ある意味、指摘した修正案の方が優れていることもあるが、実際には５５対４５のような感じの場合も多い。

　レビュイからすると、このレベルで修正するのは非常に苦痛と感じるため、レビュー時に指摘されないように内容を極力隠そうとし、時間切れを狙うわけである。

　このようなレビューではいっこうに品質は向上しない。

　それでは、解決策はどうしたら良いだろうか？　ひとつには、レビュアからの指摘事項はすべて出してもらった上で、マネージャが日程・コストの面から本当に修正した方が良いかをジャッジするやり方である。これでは、日程が厳しいとマネージャ自身が強行突破する可能性もある。そこを考えると、品質保証部などの部署が最後のレビューのOK／NGの権限を持つ仕掛けが良いと思われる。