詰めレビュー

時間制約がある中でのレビューでは指摘できるエラー数にもおのずと上限ができる。たとえば、30分で1万件の指摘はほぼ不可能だろう。また、次のような状況で、インパクトのないエラー指摘を網羅的に実施すれば、重要でない指摘ばかりですぐに時間オーバになって（指摘件数の上限に達して）しまうだろう。

• レビューは通常複数人で実施し、開発作業の手を止めて実施する。
• 4人、5人と集まれば、参加人数分の工数が削減できるような指摘をしなければ意味がなくなる。
• 網羅的なレビューが現実的には難しい規模のソフトウェアが増えつつある。

そこで、与えられた指摘件数内、もしくは最も少ない指摘件数で、レビュー時に指摘することに意味のある指摘をいかに増やすかを考えることが大事になってくる。意味のある指摘とは、レビューで発見することにより、テストで見つかるよりも修正コストが小さくなる指摘のことだ。

その感覚を鍛えるために詰めレビュー（詰め将棋のイメージ）をしてはどうかと思う。インパクトの大きなエラーから順番にみつけていくことにより、実際のレビューでもインパクトがなるべく大きなエラーを発見できるようになることを目指す。

きっかけは、ある集まりの中で、コスト、納期を固定にしながらも最大の効果を得るためには、詰めテストのような演習があってもよいのでは？と提案したことにある。

以前にレビューの優先順位のつけかたの方法を提案した論文をここ（本ブログの過去エントリ）で紹介した。これも方法の1つだ。