バグ密度という指標が無駄なのは何故か？ - ソフトウェア品質の探求
ソフトウェア品質について様々な観点から考える記事群です。
品質関連の他の記事は「ソフトウェア品質の探求」からどうぞ。
はじめに
JTCでソフトウェア開発を行っているとプロジェクトの後半に「バグ密度」という物の提出を求められることがあります。
私はベテラン勢なので淡々と対応するのですが、この指標は現代のソフトウェア開発においてはほとんど無意味だと考えています。（この値の提出を要求する品質屋とわかりあえることを諦めている）
バグ密度とは何か？
まず、この記事におけるバグ密度(Defect Density)の定義は「単位ソース量あたりのバグ量」を表す指標とします。
単位ソース量としてはコメントを抜いたソース行数が用いられることが多いでしょう。
バグ密度 = バグ数 ÷ ソースコードの有効行数(KLOC)
バグ密度の問題点
バグ密度は以下のような問題があり、１つずつ解説していきます。
| No. | 問題の詳細 |
|---|---|
| 1 | コード量とバグ量の相関は弱い |
| 2 | 書かれていないことに気づけない |
| 3 | バグの影響度を加味できていない |
| 4 | バグのカウント基準の統一が難しい |
| 5 | コンテキストの違いを無視して評価しようとする |
| 6 | 導出値の解釈が結局恣意的である |
コード量とバグ量の相関は弱い
コード量とバグ量には弱い相関関係があるように思える。しかし、バグに強く影響するのは以下の要因ではないだろうか？これらの要因を無視した指標をを使うべきだろうか？
- アプリケーションアーキテクチャの出来栄え
- 適切な責務分離ができているか
- 依存関係が管理されているか
- 共通処理の量
- 重複コードが少なければ、バグの発生箇所も少ない
- 仕様の複雑さ
- ビジネスロジックの複雑度
- 分岐や条件組み合わせの多さ
- 要件(設計)のあいまいさ
- 不明確な要求仕様は実装ミスを招く
- 実装者のスキル
- 経験豊富な開発者と新人では品質が異なる
書かれていないことに気づけない
バグ密度は「存在するコード」に対する指標である。しかし、書かれるべきなのに書かれていないコードは測定できない。
例えば以下のようなクソコードでも「品質が高い」と評価されてしまう可能性があるのである。
- エラーハンドリングが全く実装されていないコード
- 入力値の検証が欠けている処理
- 必要なログ出力が無いロジック
バグの影響度を加味できていない
すべてのバグを同じ「1」として数えることは妥当なのだろうか？
- システム全体を停止させる重大なバグ
- ユーザーが気づかない軽微な表示崩れ
これらを同列に扱うのは明らかに不合理である。
重みをつけようという考えもあるが、その重みを客観的に決めることは難しいはずだ。そこまでしてバグ密度という指標を使う意味があるのだろうか？
バグのカウント基準の統一が難しい
そもそも「バグ1個」をどう定義するのだろうか？
- 1個の共通処理の間違いが5個の画面で表出している場合のバグの数は？
- バグは1個？5個？
- 開発中のどの時点からバグとして扱うのか？
- 実装中の気づき？
- コードレビューでの指摘？
- テスト工程での発見？
- このカウント方法は、あなたの組織のすべての開発者や案件で同一なのだろうか？
コンテキストの違いを無視して評価しようとする
「バグ密度」なるものが使われる現場では、多くの場合において言語ごとに基準値が設定されている。
しかし、同じ言語でも使用するフレームワークなど以下のような状況に応じてコード量は大きく異なるはずであり、言語などの一部のコンテキストが同じだからといって同一の基準値を適用するのは無理がある。
- ボイラープレートが多いフレームワーク vs 簡潔なフレームワーク
- コード生成ツールの有無
- DSL(ドメイン固有言語)の活用度
導出値の解釈が結局恣意的である
なんとか数字をひねり出したとして、バグ密度が低い場合、それは何を意味するのか？の解釈は正反対の２つが可能である。
- 品質が高い → 良い開発ができている
- テスト不足 → バグが発見されていないだけ
どちらの解釈が正しいかは、他のメトリクスと合わせて恣意的に判断される。だとすれば、バグ密度を計測する意味があるのだろうか。。。
バグ密度が有効に機能するケース
さんざんdisってきたが、バグ密度が有効な場面もゼロではない。以下のようなシチュエーションにおいては有効に機能すると考えられる。
- 大規模ウォーターフォール開発
- 同一粒度の機能を決められた方法で行う大量開発
- その案件の派生開発と保守
- 同一案件内での推移観察
おわりに
いにしえのシステム開発では、コンピューターで実現できることが少なく、どんなシステムも同じような作りにならざるを得なかったためバグ密度は有効に機能したであろうと思う。
しかし、現代のシステム開発は、同じアーキテクチャーで作ることは派生開発ぐらいであり、案件をまたいでバグ密度の指標値を横展開する意味はない。惰性で続けても現場に労力をかけるだけで、なにひとつ品質向上には寄与しないので早急に捨て去るべきだと心から思っている。
Discussion