はじめに

業務特性上、先行的な調査や設計フェーズのプロジェクトであり、
検査で品質を担保するのではなく、
レビューで品質担保をする必要があるプロジェクトに関わることが多いです。
レビューがうまくいかず、コストがかかりすぎることはプロジェクトの失敗に直結してしまいます。

ぼくの経験上、以下のような困りごとがありました。

複数いるレビュワーの考え方が違い、方針が決まらない
レビュワー毎に言うことが違う
見て欲しいところと違う指摘でレビューが終わらない
あとになって、「そんなの見てない」と言われる
計画時にどれくらいのレビュー時間を計上すれば良いかわからない

レビュイーはレビューしてもらっているつもりになっていても、
レビュワーは忙しい人が多く、すべてチェックするのは不可能です。

どうやったら品質を落とさず全員から承認いただいて、円滑にプロジェクトを進めることができるか、
調べた結果を残します。

参考文献などにあるレビューの種類、基礎知識は割愛します。
大事だと感じた部分を抜粋していますので、正確な情報は参考文献を参照ください。
また、ここでいうレビューとは、プロジェクト管理を目的にするレビューではなく、
作業成果物の品質に主眼を置いたデザインレビューのことを指します。

参考文献

ソフトウェア・レビュー技術〜基礎から実践までのノウハウ〜

レビューの主目的、効果的なレビュー実施

レビューの主目的は 「不良を早期に発見し、手戻り工数およびデバッグ工数等の削減を図る」 ことです。
それ以外の副次的な効果も色々挙げられていますが、
この目的をレビュイー、レビュワーと共有してレビューに臨む必要があります。

効果的なレビュー実施のための施策例：

必要な資料を事前に配布、レビュワーは事前検討を行い、必ず肯定的意見と否定的意見を持ち寄る

レビュワーの時間制約もあるので、現実的にはこの施策は難しいかもしれませんが、
仕様、プログラムの説明会になっていないか？
目的を達成できるようなレビューが実施できているか？
というのは、振り返った方が良いと思いました。

レビューの副次的な効果：

仕様やプログラムの理解者を複数人にする
要員の弱点の早期発見と指導を可能とする
担当者間でのコミュニケーションの補助手段となる
仕様やプログラムを読むことによる教育効果を図る
プロジェクトの進捗状況を把握し、当該工程の完了度合いを把握する
当該工程の品質状態を分析し、今後の改善施策へフィードバックする

ソフトウェアレビュー戦略

レビューの前提条件：

①レビュワーが共有されたプロジェクトにおけるビジョンを確認できるように、各プロジェクトのビジネスゴールを定義し、伝達すること
②達成可能な品質目標が設定できるように、製品品質に対する顧客の期待を定義すること
③レビューおよびその他の品質向上作業が、チームの品質目標達成にどのように貢献するか理解すること
④レビューとは何か、なぜやる価値があるのか、誰が参加すべきか、どう実施するかについて、開発組織内の関係者と意識を共有化すること
⑤組織のレビュープロセスの定義と管理、参加者のトレーニング、レビューの実施、レビューデータの収集と評価などのスタッフ業務に必要な時間を確保すること

①〜⑤のうち、特に②と④ができてないと思いました。
何を目標としていて、目標達成のためにレビュワーをどう設定し、どう実施していくか決めて関係者と合意しておく必要があります。

バグ摘出目標、定量的目標
全摘出バグのどれくらいを上位工程でのバグ摘出目標として設定するか？ですが、
ひとつの例として70%〜80%をレビューで摘出し、残りをテストで摘出するという考え方があります。
これはプロジェクトのレビュワースキルなどにも関係するので、プロジェクト毎に目標を設定しましょう。
テストで目標より多くのバグが発見されたら
以前に実施したレビュー観点に弱点が見つかったと認識し、その観点んでレビューを再度実施、同様の原因のバグを早期に修正、品質を高めていく。
こうやって常にテストでの発見確率を20%未満に保つ状態にすることが大事です。

レビュー実施観点

基本設計、機能設計時のレビュー観点

正直ここはどんなプロジェクトかによって、全然見る観点が違うと思います。
一般的には、要求品質達成度観点、実現方式観点、標準化観点などがあり、
もう少し具体的に言うと、ソフトウェア品質特性毎の観点から確認していく方法が例として挙げられていました。
（ソフトウェア品質特性_ISO9126）

あとは、チェックリストをプロジェクト毎に更新していくことくらいですかね。
プロジェクト毎に違う部分であり、一番困るところでもありましたが一般化して定義するのは難しいですね。。

詳細設計、コーディングの観点は割愛します。

レビュー管理技術

レビューで摘出する欠陥数の見積モデル：

総欠陥数 = 開発規模(新規+改造規模) × 開発難易度補正係数 × 開発者スキル補正係数

このモデルは過去のプロジェクトのデータを使って予測するので、
工程別に予実を確認し、フィードバックをかけていく必要があります。

横：レビュー工数/規模、縦：バグ件数/規模	予定 > 実績	予定 == 実績	予定 < 実績
予定 > 実績	品質を判断する時期ではない	作り込み品質が予定よりも良い→バグ予測値を下方修正	作り込み品質が予定よりも良い→バグ予測値を下方修正
予定 == 実績	作り込み品質が予定よりも悪い→バグ予測値を上方修正	見直しの必要なし	見直しの必要なし
予定 < 実績	作り込み品質が予定よりも悪い→バグ予測値を上方修正	作り込み品質が予定よりも悪い→バグ予測値を上方修正	作り込み品質が予定よりも悪い→バグ予測値を上方修正

書籍には上記のような記載となっていましたが、
2行目の一番右の場合もケースも見直しが必要なのではないかと思いました。
レビュー工数が予定より多くかかったが、バグ件数は予定通りだったというケースなので、
レビュー工数の上方修正、もしくはレビュー実施方法の見直しなど。
実績のあるプロジェクトか、新しいプロジェクトなのかによっても変わるとは思いますが。
大事なのは、分析した結果を、フィードバックしていくことです。

まとめ

参考にした資料には、例題があり、レビュー結果をどう分析すれば良いかも記載されていたので分かりやすかったです。
QC7つ道具を使って分析することや、分析できるようにデータを残しておくことが大事です。
また、分析した結果を横展開し、組織的な取り組みをしていくことも大事です。

正直、計画時に総欠陥数の見積はいままで出したことなかったので、
過去のデータを使ってまずは現状の品質レベルを把握するところからのスタートになりそうです。

成熟した組織であればそこまで決められているんだろうか。
資料の中でも「6. レビューを組織的に促進する」という章で語られていましたが、
みなさんの組織はどうですか？
そこまできっちりやっているプロジェクトはあまりないのではないでしょうか？？

キーワード：CMMI