以前の記事で、「ねらいの品質」と「結果の品質」について書きましたが、プロジェクトにおける設計品質を上げるには、レビューの品質をあげるしかありません。
設計するSEの能力がとても高く、レビューがなくても最初から高い品質の設計ができれば言うことありませんが、そんな高スキルを持ったSEはそうそういませんね。
ですから、レビューを通して、品質をあげるしかないのです。
レビューを勘違いしているメンバーは以外と多い
「レビューに通るかどうか」ということを良く聞きます。
確かにレビューに通る=設計品質に合格するということを意味しますが、レビューを通すことが目的になってしまっている人が意外と多いようです。
レビューに通すために、その場を取り繕ったり、根拠もなく質問に回答したり、果ては、やってないことをやったとウソをついてしまうことも。。
レビューでは、様々な視点や角度から設計書を見てもらい、「抜けはないか」「漏れはないか」「矛盾している点はないか」などの指摘をもらい、品質を高めるのが目的です。
テストで、バグを出すのと一緒ですね。
テストに合格するために、バグがでないようなテスト仕様書を書いたり、テストデータを偽装したりする人はいませんよね。
だから、レビューも指摘をもらってはじめてレビューの価値があるのです。
レビューを記録し、分析することでPDCAを回す
レビューは、実施したら終わりで、効果は一度キリということではありません。
レビューの指摘事項や指摘事項に対する対応を記録し、その記録がある程度たまったところで、傾向を分析し、次からの設計に活かしたり、他の設計書は大丈夫かと横並びチェックをしたりすることで、設計の品質を上げていきます。
また、1回のレビューでも指摘事項に対応するだけでなく、その指摘を受けた原因は何か、どの作業に問題があったのかを追及することで、他の設計書の品質を再チェックしたり、これから作成する設計書へ反映させたりします。
レビューには、複数の人が参加し、工数(=コスト)もかかっていますので、コストをかけたなりの効果を得たいものです。
コメントを投稿
別ページに移動します