指標は具体的な事象に対する間接表現だ
こんにちは。てぃろです。
とあるプロジェクトでアプリの品質向上を担当することになったので、指標を使ってソフトウェアの品質を定量的に表そうと考えた。
特に顧客から受注したプロジェクトにおいては、その品質を証明するために様々な指標を使うことがあるからだ。
・テスト件数
・レビュー件数
・テスト密度（=テスト件数 / コード行数）
・バグ密度（=バグ発見数 / テスト件数）
・コードカバレッジ
・lint警告数
…などがよく使われるソフトウェア品質を表す指標だ。
これらの指標を使うことによって、ソフトウェアの品質を分析し品質の問題はないと判断をしてリリースが承認される。
ただ、改めて指標の定義（計算方法）を思い出すと、指標とはある事象を数値で表現し客観的に状況を把握するために使用するもの、ということがわかる。
つまり、指標とはそれぞれの具体的な事象そのものを直接示すことはない。あくまで間接表現なのだ。
ただし、ソフトウェア開発でいう上記のような指標が品質をうまくあらわさないと言っているわけではない。むしろ、品質を様々な角度から分析することに大いに役立てることができる素晴らしいものだ。
言いたいのは、指標がすべて目標範囲内 ≠ 品質がよい、ということだ。
例えば、lint警告数を考えると、これはlinterで定義された問題のある書き方をしている箇所の数を示しているが、逆に言えば問題と定義されていない書き方は何でも許されてしまう。そのため、意図的に警告を回避する変な書き方もできてしまう。そういう場合は大抵可読性が低い最低なコードになる。
コードカバレッジは、そのコードがテストを実行され機能が証明されたことを示す指標だが、そのためのテストがきちんと機能を検証するためのものになっていなければ、機能の正常性が証明されておらずバグが含まれている危険性を否定することができない。
このように指標そのものは問題ないとされても、中身の実情をみると指標が示す通りの品質ではない、という場合があるということなのだ。
それでもあらゆるすべての具体的な事象を一つ一つ細かく見ることは不可能なので、我々は指標を使って全体像を把握しようとするし、それがプロジェクトを統括するような立場であれば当然のことなのだ。
だからこそ、その指標を形作るもとになった具体的な事象については、あるべき姿を留めるように現場が最善を尽くさなければならないのだ。
技術ブログもやってます。開発のノウハウはこちら。
いつも記事を読んでいただいてありがとうございます。少しでもあなたの人生にプラスになる話ができているとうれしいです。