定量データに基づくインスペクション

品質定量測定の本質＝「ばらつきの測定」という説

　品質測定の本質は「ばらつきの測定」であるという意見があります。これは何らかの指標を用いて品質管理対象を測定し、測定データ群の母集団からの乖離（かいり）度合いによって品質上問題のある標本を取り除くことで、均質化を目指すアプローチです。これは確かに製品品質管理では王道の考え方であり非常に重要なのですが、「何を測定して」ばらつきを抑えるかが一意に決定されていません。

　ITの歴史上も、「この値だけを測れば確実に品質がわかる！」と唯一無二のメトリクスを見つけようとする研究は数え切れぬほど存在します。ただし、それら研究の多くは品質を表現するためのメトリクス（＝代替指標）を計測しただけで。単なる定量化にとどまっています。具体的にそのメトリクス値を通じて具体的にどのように品質を向上させるか、という議論が歴史上あまりなされていないのです。

　ここで少し話は飛びますが、ソフトウエアの見積もりでは定番となっている定量メトリクスである「プログラム行数」についてその歴史を振り返って見ましょう。1950年代中ごろには、見積もりの世界では次のような内容が常識だったそうです。

　「まずプログラム行数を数えること。知りたいことは何でもそこから導出できる」

　つまり品質もプログラム行数で計れるとちまたでは信じられていたそうです。しかし60年代中期になりこの「プログラム行数」というメトリクスは、各種の研究を経てあっさりと否定されました。

・ソフトウエア開発コストはプログラムの行数という単純なものとは直接何の関係もない要因などに大きく依存する
・コスト予測は、開発（プロジェクトの）サイズに依存する

　その後、品質を示すメトリクスとしてプログラム行数が用いることができないか、という研究も70年代に入ってなされてきました。最終的には「プログラム行数と欠陥発生の間に顕著な相関関係はない」という研究まで発表されました。

定量測定のあるべき姿

　さて、皆さんは上記のプログラム行数に関する議論をどのように感じますか？もしも皆さんが参画したプロジェクトで「プログラム群の中に行数が極端に大きいプログラムが内包されている」事実が計測されたとしたら、どのような行動を起こしますか？理論に基づき無視しますか？それとも「この『計測結果の数値』は許されないことだから」と妄信的に設計された機能を見直しプログラムを分割し、個々のプログラム行数を減らしますか？

　そうです。大切なことは品質定量測定の対象となる唯一無二のメトリクスを探すことではなく、測定してどう行動するか、何をするかが大切なのです。

　筆者は品質レビュー専門家として働く日常業務の中に、定量メトリクスのばらつきに基づくインスペクションを実施するようにしています。理由は、ばらつきは定量メトリクスとして測定しやすく、さまざまな複数の数値を組み合わせて活用するとインスペクションという集団行動に客観性と合理性が生まれるからです。例えば次の3ステップをお勧めします。

ステップ1：まず何でも測定してみる
ステップ2：測定結果のデータに対して洞察力を働かせて仮説立案する
ステップ3：その品質面の仮説を用いて実際の品質向上活動の入力に用いる

　繰り返しになりますが、メトリクスはそれ自体を「測定すること」が目的ではなく、測定結果を用いて何をするかが重要です。ステップ3の品質向上活動（例えば、レビューやウォークスルー）などに役立てることができて初めてそのメトリクスは「品質の定量化メトリクス」として意味を成すのです。