即活用！「レビューの質チェック票」

レビューの価値（予防した修正規模）の定量化

　修正規模をシステムの修正範囲と発見工程との2軸でとらえ、概念的にその2つを掛け算した面積が修正規模と考えた。なぜならば、ソフトウエア開発における修正作業は、修正範囲が影響するのはもちろんであるが、不具合の発見工程が後になるほど手戻りが大きくなり、規模が膨らむからである。そして修正範囲と発見工程による手戻りを不具合修正費用の相対値でポイント化することにした。

　修正範囲はレビューの指摘内容から予測される修正のレベルを「大：システム全体」「中：複数モジュール」「小：単一モジュール」と評価する。ここで言う修正とはレビュー文書自体の修正ではなく、もしもこの指摘がレビュー時点で発見されず、後工程のテストで発覚した場合にシステムのどの範囲まで修正が及ぶかという意味である。

　発見工程は、テストよりも前の工程ということで、要求定義、設計、コーディング、とした。

　修正範囲と発見工程の違いによる予防した不具合修正コストの相対値を図2内の表1、表2のようにポイント化した。ポイントを定義するにあたり、図2の「工程ごとの誤り修正の相対費用グラフ」を参考にした。

　図2は、コーディングにおける欠陥の修正費用を約1.0とした場合、同じ欠陥を設計で発見すると約0.5に減少することを示している。同様に、要求定義での修正費用は、約0.2となる。

　その結果、各工程の修正費用の相対関係は、｢コーディング：設計：要求定義＝1.0：0.5：0.2」であることが分かる。よって、欠陥をレビューで未然に防いだ効果としては、その逆数を取り、「コーディング：設計：要求定義＝1：2：5」とした。

　ソフトウエア開発は工程が進むごとに、システム → サブシステム → モジュールという具合に末広がりに粒度が細かくなっていくことから修正範囲の大中小の相対関係も同様とした。

　ポイントから費用に換算するにあたって1ポイント当たりの修正作業時間が必要となる。1ポイントに相当する作業時間とは、修正範囲が「小」で、発見工程が「コーディング」となる不具合、つまり1モジュールの修正で済むコーディングエラーを下流のテスト工程で発見した場合の平均的な修正工数となり、この値は各社で設定すれば良い。

　これまでの内容から、以下の式を考案した。ポイント化した修正規模に対して、1ポイントに相当する作業時間と時間単価を掛けることで、金額効果を算出した。

予防した修正規模の金額効果（単位：円）＝
修正範囲（ポイント）×発見工程（ポイント）×1ポイント当たり修正工数（時間）×時間単価（円）

レビューの価値（予防したユーザーインパクト）の定量化

　ユーザーインパクトのメトリクスとは、レビューの指摘内容が、仮にテストでも検出できずにリリース後に発覚した場合を想定した被害を金額に換算したものである。

　レビューの指摘内容から予測される「ユーザーインパクト」を表3のように分類した。

　ランクと金額については、対象となる製品やシステムの特性を考慮し、各社の実態に合わせて設定すればよく、表3は一例である。

　レビューの指摘内容が、表3のどのランクに該当するかを判断することで、未然に防止した被害を金額によって表現した。

ユーザーインパクトの金額効果（単位：円）＝表3のランクで設定した被害予想額目安（単位：円）

　続いて、レビュー価値の算出方法を具体的な例をあげて説明しよう。