レビュー指摘件数密度

ソフトウェア開発の現場では、品質を高めることを目的に品質レビューが行われている。
ウォーターフォール型の開発では、品質レビューは開発工程の各フェーズの終盤で行われるのが一般的である。要件定義工程の終わりに実施する要件定義レビュー、基本設計工程の終わりに実施する基本設計レビュー、製造工程の終わりに実施するソースコード・レビューや単体テスト仕様書レビュー・・・といった具合である。
フェーズの終わりで成果物をレビューし、そこで指摘された誤りを修正して成果物の品質を確保する。
品質レビューは、「当該フェーズの完了を確認し、後工程で発生する手戻りを防止する」という意味で、ウォーターフォール型の開発では重要な位置付けにある。

品質レビューは、誰がレビューを行うかによって、社内レビューと社外レビューに分けることが出来る。
社内レビューとは、ソフトウェア開発を請け負ったベンダー内のレビューであり、レビューアーはチームリーダーであったり、社内の有識者であったり、あるいは品質管理部門であったりと、ソフトウェアの開発規模やベンダーの態勢、レビューを行う工程やレビューの位置付けなどで変わる。
社外レビューは、主に発注社側（顧客の側）がベンダーの成果物に対してレビューを行うものであり、成果物を検収するための条件となる。これは成果物が発注側の意図したものと相違ないかを確認するものであり、齟齬がある場合にはベンダー側に修正を要求する。
社外レビューも、後工程での手戻りを防止するという点は内部レビューと同じである。

品質レビューは、共通フレーム2013（SLCP-JCF 2013）では「共同レビュープロセス」として定義されている。
共同レビュープロセスの目的は「合意目標に対する進捗、及び利害関係者を満足させる製品の開発を確実にするために実施が望ましいことについて、利害関係者と共通理解を維持すること」であるとし、さらに
「共同レビューは、プロジェクト管理レベル及び技術レベルの双方で行われ、プロジェクトが存在する間実施されている」としている。

品質レビューには幾つかの観点がある。
例えば、基本設計書のレビューであれば、要求事項に対する機能に漏れがないか、機能の定義は正しいか、画面設計のUI、UXがプロジェクトの標準やガイドラインに適合しているか、などである。
特に要求仕様に対して漏れがないか、機能が正しいか（機能の正当性）は、ベンダーでは判定できない場合が多々あるから、ユーザー側のレビューが不可欠だと言える。
ウォーターフォール型の開発では、テスト工程に入ってから「出来上がったものがユーザーが要求したものと違う」という問題が起こりがちであるから、このようなリスクを軽減するためにもユーザーにしっかりとレビューしてもらうことが重要である。（このためには、ユーザー側でも理解できる成果物、具体的には正しい日本語の文章で記述された設計書が必要だ）

品質レビューに関連して、レビュー指摘件数密度という品質メトリクスがある。
これは、品質レビューにおける指摘事項の数を、ドキュメントのページ数や、ソフトウェアの開発ボリュームなどで除した数値である。
IPAのソフトウェアデータ白書（2014-2015）にも、一応数値が出ている。例えば、基本設計書レビューのページあたり指摘件数は以下のとおりである。

※　「ソフトウェアデータ白書(2016-2017）の数値を併記する。

①ドキュメントの記載粒度
ドキュメントの記載粒度が粗いと指摘件数は少なく、ドキュメントの記載粒度が細かくなると（すなわちより具体的に記載されるほど）指摘件数は多くなると想像できる。
では、適正な記載粒度とはどのレベルか？　基本設計書なら、詳細設計に落とせるレベルになっているかで判断する（このように書くと抽象的だが）。
ドキュメントの種類と記載粒度は、採用する開発手法に依存するところが多いから、計画段階で定義して関係者と認識を合わせておくよう留意したい。

②レビューアーの態勢
誰がレビューアーかによって、レビューの観点と指摘件数が変わることが予想される。ユーザーがレビューアーの場合は、要求仕様の漏れや、機能の正当性の観点を重点的にレビューするであろう。一方、ベンダー側のレビューでは、非機能要件や処理方式などに重点が置かれる可能性がある。さらに、品質管理部門では標準化や規約との適合性を中心にレビューが行われるかもしれない。
レビューの観点とレビューアーの所属部門との間には向き不向きがある。全ての観点から網羅的にレビューできることが望ましいが、全てのプロジェクトでこれが出来るとは限らない。
プロジェクトの制約で網羅的にレビューできない場合には、レビュー密度が低下するリスクがある。

③指摘件数をカウントする際の基準の問題
指摘事項を類型化すると幾つかのカテゴリーに分かれるはずだ。
●機能の漏れや誤りなど後工程の品質に影響するもの
●ユーザー要望に基づくもの（例えば、画面項目の表示位置）
●規約やガイドラインに違反しているもの
●文章表現の改善（例えば受動態の表現を能動態に変更する）
●誤字脱字、文法上の誤り
どのレベルまでを指摘件数としてカウントするかは、事前にプロジェクトで決めておくべきである。文章表現の改善や誤字脱字の類まで指摘件数にカウントすると指摘件数密度が過度に大きくなる可能性がある。