設計レビューをどうはかるか
設計ドキュメントのレビューの効率や効果を測りたいが、どうやってはかればよいかわからない。という質問を受ける。最初はレビュー指摘件数やドキュメント量で指摘数を割り算したレビュー密度として定量化するのが一般的ではないだろうか。現実には、指摘の内容が誤字脱字の指摘だけだったり、参加すべきメンバが参加していないレビュー等、このメトリクスだけでは頼りない。
自分の開発経験も含めて、以下を勧めている。理由は説明が比較的簡単であることと、それなりの効果が出そうに思うからである。（残念ながらエンピリカルな検証は計画段階にあり未実施である）
- レビュー前に実施しておくべき作業の定義と実施の有無
- レビューのperspective数（役割分担数）とperspectiveに沿った指摘の数
- 指摘重要度の分類（軽微、重大、どちらでもない）
- 指摘内容の分類（正常系、異常系、非機能）
- 指摘対象機能/サブシステム
1は、まずレビューをはじめる前に実施しておくべき内容がある程度定義されているかどうかである。たとえば、レビューの範囲をきちんと定義しているかどうか、フォーマットに従って書かれているか、用語の統一はできているか、コミュニケーションルールに従って作成されているかどうか、未確定の仕様に対する懸案事項は列挙されているか、が含まれるだろう。
2は、参加者毎に観点(perspective)を決め、それどおりの指摘ができているかを記録する。たとえば、パフォーマンス、メモリリーク、セキュリティ、業務フロー、ハードウェア、ノイズ、運用フロー、導入/移行、ユーザビリティ等の観点から設計の不備を指摘をする。複数人でやれば、だいたいどのようなレビューでもある程度の役割分担がなされているはずである。経験者は自分が参加するレビューに思い当たるフシがあると思う。それを明示的に実施し、計測する。
3は、いわゆる分類である。軽微なものばかりであったり、重大なものばかりであったりするとそのレビューの品質には少し注意する必要があるかもしれない。
4は、手動テストをするならば、どの類のテストで検出されるものなのかを記録する。異常系が多く指摘できるということは、正常系についてはある程度固まったものがあることを示す可能性がある。正常系ばかりであれば、指摘反映後に、異常系や非機能に関するレビューを再度実施する必要があるかもしれない。
5は、時間、コストに制限がある中で、もっとも優先して製造、テスト/リリース、レビューすべき機能を選択する際の判断基準になる。指摘が十分であるものは、早めに次の工程に移ることができるだろうし、最低限、再レビューが必要なものがどれかを決める判断基準にもなるだろう。