ソフトウェアレビュー／インスペクションで何を指摘すべきか

本来、レビュー／インスペクションでは全てのエラーを指摘すべきだが、実際には時間の制約があったり、かけられるコストにも上限がある。では、限られた時間やコストの中で特に何を指摘すべきか、以下の観点で紹介した記事が公開されている。（私がThinkITで書いたもの: 詳細はこちら）

• ユーザのユースケースの実行頻度の多いものから優先的に
• テスト工程での修正／確認テストの規模が大きいものから優先的に
• バグ票に含まれる修正時間の傾向をヒントに、修正時間の大きいものを優先的に

一般的なレビューであれば「テストでやるよりも効率的になるようにね」というくらいの合意が取られているのが一般的ではないかと思う。もう少し進んで、上述のような優先順位を検討すると、効率ががらっと変わってくるように思う。ご自身のレビュー／インスペクションにも活かせそうだろうか。ただし、コスト度外視で品質を極めて重視するソフトウェアやプロジェクトをはじめとして、一部のソフトウェア、プロジェクトでは対象外になるだろう。

3月はThinkITで特集「インスペクションの世界」を企画する機会をいただいた。先週分のThinkITインスペクション特集の記事は次のとおり。

• インスペクションで何を指摘するべきか（森崎 奈良先端科学技術大学院大学）
  上のとおり
• すぐに使える！レビュー効果向上の秘訣（安達氏 HBA）
  複数種類のレビューを実施し、その結果を比較している。キーマン主導、静かなレビュー、ワイワイガヤガヤ、結果として一番欠陥指摘が多かったのは？
• インスペクタはこんなところをみている（細川氏 日本IBM）
  仕様書の句読点の数、プログラム中の変数の長さ、担当者の机の上のペットボトルの数。。通常の開発担当が実施するレビューでは考えられない点ばかり。
• FMEAシートの活用事例（山科氏 日本ユニシス）
  難しいと言われているソフトウェアへのFMEA（故障モード影響解析）を4,500KLOCという巨大なソフトウェアに対して実施した事例が紹介されている。
• 刻み込め！ピアレビューの心得（小笠原氏 東芝）
  ピアレビュー成功のための十か条、レビュー後の振り返り会議。よいとわかっていても、なかなかできないのが実情だが、実施しやすくするための工夫やコツが紹介されている。