ソフトウェアの品質、大丈夫かな?
この疑問は開発者よりもマネージャの方が多く考えることではないでしょうか?
典型的なソフトウェア品質分析というと、レビュー記録の分析が挙げられます。
今回はそんなレビューが、効率良く実施できていますか?を分析してみます。
使う指標は単純で、
- レビュー工数(実施した人数×時間)
- レビュー指摘件数
- レビュー指摘効率(レビュー指摘件数÷レビュー工数)
です。
「レビュー指摘効率」は単位時間当たりに何件指摘できましたか?という指標です。
今回もサンプルデータを使用します。
ユニット名称 | 記録名称 | レビュー工数[人時] | 指摘件数[件] | レビュー指摘効率 |
ソフトウェアユニットA | 記録1 | 1 | 2 | 2.00 |
ソフトウェアユニットA | 記録2 | 1 | 2 | 2.00 |
ソフトウェアユニットA | 記録3 | 1.5 | 1 | 0.67 |
ソフトウェアユニットA | 記録4 | 2 | 3 | 1.50 |
ソフトウェアユニットA | 記録5 | 1.7 | 5 | 2.94 |
ソフトウェアユニットA | 記録6 | 1.8 | 4 | 2.22 |
ソフトウェアユニットB | 記録7 | 1.5 | 1 | 0.67 |
ソフトウェアユニットB | 記録8 | 1.6 | 4 | 2.50 |
ソフトウェアユニットB | 記録9 | 1 | 2 | 2.00 |
ソフトウェアユニットB | 記録10 | 0.9 | 0 | 0.00 |
表のまま眺めてみる
早速データを見てみます。
「ソフトウェアユニットA」「ソフトウェアユニットB」の二つの部位のデータのようです。
それぞれ何度かレビューした記録ですね。
レビュー指摘効率を見ると、一番効率が良い時は記録5の2.94、効率が悪い時は記録10の0.00だと分かります。
これだけだと、効率が良い時と悪い時がある、くらいしか分かりません。
時系列データとして見てみる
図1のように、レビュー指摘効率をユニット別に時系列にプロットしてみます。
今回のサンプルデータでは傾向が見えませんが、もしかしたら回数を重ねると効率が上がる・下がるなどの傾向が出るかもしれませんね。
箱ひげ図で見てみる
次は図2のように、レビュー指摘効率を箱ひげ図にしてみました。
箱ひげ図の作り方や、読み方はたくさん紹介されているページがあるので省略します。
(このページとか)
×印が中央値なので、ソフトウェアユニットAの方が効率が良いことが分かります。
箱ひげ図だと、最大値・最小値もプロットされているので、比較しやすいですね。
箱ひげ図で見ると、バラつきが一目で分かります。
このサンプルデータだと、ソフトウェアユニットBの方がバラついていることが分かります。

おわりに
今回はレビュー記録を元に、レビュー指摘効率を計算しました。
その結果を、
- 表のまま分析する
- 時系列グラフにして分析する
- 箱ひげ図にして分析する
をやってみました。
いかがだったでしょうか?
サンプルデータだとあまり分からなかったかもしれませんが、表とグラフが如何に強力なツールなのか、少しでも伝わっていると嬉しいです。
コメント