　このような目標値は、組織データとして蓄積していかなければなりません。プロジェクトの開発規模、製品特性、難易度などのパラメータから、過去のデータを参照して目標値を設定します。当然、初期段階では組織データが少ないので、適切な目標値を設定できなく、実績値が外れることが多いかと思います。そのような場合は、

目標値＝実績値＋差分の理由

を明確にすることで判断してみるとよいでしょう。このようにして、再レビューの実施、成果物の見直し、工程移行の判断、以降の工程の計画変更などの判断に活用してみてください。

　また、データの測定に関しては、以下のような意見もありました。


			見積もり精度の向上には役に立つが、レビューの品質にはつながらないのでは？


			プロジェクトごとに製品がまったく異なるので、単純に比べるわけにはいかない

　短期的に見ると急激にレビューの品質が上がることは期待できないでしょう。しかし、数値データとともに各レビューでの特徴を明確にして、数値データと併せて蓄積できれば、上記の意見に対しても改善していけると思います。

　例えば、目標に比べて数値データが良かった／悪かった（良い指摘ができた／できなかった）場合に、「利用者を想定したから」「XX機能に対して、YYスキルを持った要員を参加させたので」「新人をOJTのため2名参加させたので」などの要因を、レビュー参加者でディスカッションします。ここでは目標値と比較することがポイントです。これらは「レビュー振り返りシート」へ記録し、改善情報として蓄積していきます。そして、その情報がレビューの進め方やチェックリスト、記録方法などの改善につながっていきます。

　レビューを実施したことで確認することが望ましい項目に、対象成果物の品質とレビュー自体の品質があります。

　対象成果物の品質に関しては、“指摘不具合数”と“レビュー時間”の関係を、等号／不等号（＝、＜、＞）でマトリクスを作成し判断してみてください。また、レビュー自体の品質に関しては、以下の点でレビューデータを蓄積し、状況を確認するといいでしょう。

レビュー効率	1個の不具合を発見するのにかけた時間
エラー検出率	プロジェクト規模に対して、そのレビューで検出できた不具合の件数
バグ持ち越し率	当該工程が原因の不具合の総数に対する、そのレビューで発見できた不具合の件数
自工程発見率	不具合の総数に対する、見つけるべき個所で見つけた不具合の件数

　レビューも改善活動の対象になります。改善の効果を高いレベルで発揮するには、直感だけではなく、定量的データに基づいた論理的根拠を示して、改善活動を実施することが必要不可欠です。

まとめ

　前回と今回の2回に分けて紹介した“レビュー”は、比較的身近なテーマかと思います。

　レビューは、ソフトウェアの品質を向上させるために必要な活動だということは、古くから認識されています。しかし、今回の議論を通じ、あらためてレビュー品質を向上させることは簡単ではなく、まだまだ発展の余地があるということを強く感じました。開発手法を含め、技術面の向上だけでは、昨今の複雑化したソフトウェアの品質を保証することは困難です。つまり、レビューが品質向上に貢献する大きな手段であることは間違いありません。

　レビューで適切に指摘できるスキルを持った要員を育てることは当然必要ですが、さらに、レビューに関する定量的・定性的なデータを蓄積し、それに基づいて、レビュー品質、さらには成果物品質を向上していただけたらと思います。（次回に続く）

筆者プロフィール

横河ディジタルコンピュータ株式会社
組込みプロセスシステム事業部（EPS事業部）コンサルティング企画部
清水祐樹（しみずゆうき）

金融機関におけるエンタープライズ系開発で、長らくプログラマ、システムエンジニアとして活動後、通信計測器メーカーにてハードウェア・ソフトウェアが連携した開発に従事。現在はCMMIの視点から、組み込みソフトウェア開発、ハードウェアを操作するためのフロントエンドGUI開発などの顧客に対して、プロセス改善の支援に従事。

▼組込みソフト開発現場が抱える課題の解決を考える勉強会
http://www.yokogawa-digital.com/eSPITS/seminar.html