ソースコードやテストケースのレビュー指摘件数とステップ数の関係を見てみましょう。
20件/KLOC
で1000ステップ数につき20カ所修正するべき部分がレビューで見つかったという事になります。
レビューの指摘件数と開発したアプリケーションの品質にはあまり相関関係はありません。たとえば想定20件のところで40件の指摘が見つかったとしてレビュー前のアプリケーションの品質が悪かったということはわかるのですがしっかりレビューされていて問題が改修されていると見る事もできます。そのため指摘件数を指標にアプリケーションの品質を確認する事は困難です。では指摘件数を数える事に意味は無いのでしょうか。指摘件数でわかるのは実はアプリケーションの品質ではなく作成した人の品質です。
新人等のまだスキルレベルが低いプログラマが作成したソースでは平均値の約２倍程度の指摘件数になり、逆に何年も場数を踏んでいる優秀なプログラマが作成したソースの指摘件数は平均の半分以下になります。つまりレビューの指摘件数を見ればそのプログラマが現在どのくらいのスキルレベルかをある程度定量的に判断する事ができます。また逆に、レビューを行う側の指標としても有効です。とても丁寧にレビューを行う人はその指摘件数が相対的に多くなりますし、逆にあまり細かくレビューしない人は相対的に指摘件数が少なくなります。
発注側と受注側のような関係では発注側は納品物に対しての評価は行いますが作成した人に対しての評価をすることは無いのでレビューの指摘件数を求められる事はまず無いと思います。しかし社内で人員配置を行う際に利用するような場合は価値がある指標となります。例えば難易度の高い部分の開発にはスキルレベルの低いプログラマに丁寧にレビューしないような人を組み合わせて配置しないような配慮をする事が出来るようになるわけです。
そんな指標を使わなくても出来る人と出来ない人くらい見ればわかるよと思えばこのような指標は不要ですが、自分のスキルレベルが定量的に見れるようになるので今度は指摘が少なくなるように頑張ろうというモチベーションになる場合も多いです。
Next >> ステップ数は本当に役に立たないのか
