定量データに基づくインスペクション
品質定量測定のコツ
品質定量測定のコツは、部分を計って全体を断定してはならないという点です。換言すれば「複数メトリクスを組み合わせて検証する」ことに尽きます。複数のメトリクスを組み合わせて測定することで、全体をさまざまな角度で観察し、冒頭で示したとおり「不安を軽減する」ための品質活動につなげることができるのではないかと筆者は考えます。
例えば、複雑度はCyclomaticComplexityに代表される「プログラム1本あたりの複雑度」などは大学課程でも教える一般的なメトリクスです。しかし、複雑度はプログラム内部の複雑度を示すものだけではなく、プログラム同士の結びつきや、他モジュールとのインタラクションの複雑度（例えばHenry-Kafuraの提唱したInter-Module Complexity）なども存在します。
ということは、全プログラムが単純な構造を持っていれば必ずシンプルなシステム構造になるというわけではなく、シンプルな設計／複雑な要件をいかに整理したかという「全開発フェーズのトータルな複雑度軽減」に注力度が重要なのです。
ほかにも、技術的な正しさ（＝正しいものを作っているか）だけ計っても十分ではないという例があります。筆者は、プロセスや管理の正当性（＝正しく作っているか）も定量測定対象に含めるべきと考えます。俗に品質検査の領域ではV&V（Validation & Verification）と呼ばれる考え方です。実は定量測定の領域では「正しく作っているか」の計測、つまりプロセスや管理の妥当性／正当性測定はあまり行われていない場合が少なくありません。
一般的にプロジェクト管理上の測定は、生産性の計測や規模の計測といった「プロジェクトの見積もり」に用いられている場合が散見されます。しかしこの計測活動には「未来のプロジェクトのためになぜ私のプロジェクトの予算を費やして、測定／計測を行うのか？」という心理が働き、必ずしも有効なデータが得られていないとも言われています。
開発途中のプロジェクトが自らの開発活動上の「品質不安を軽減するために行う測定」が、今最も求められている「定量測定のあるべき姿」だと筆者は考えます。
ゴールドリブンの定量化指標の選定とエンピリカルアプローチ
では、次に測定したものをどう活用するかを考えてみましょう。
計測活動に対してに「プロジェクトの見積値を精密化したい！」といった目標を設定し、その目標を計測指標（＝メトリクス）に分解するアプローチをゴールドリブンのメトリクス活動と言います。
これは「ソフトウエア測定プロセスに関する規格（ISO/IEC 15939）」というISO規格で定義されているような、ゴール指向・目的指向型の計測です。ただし、このゴールドリブンのアプローチの欠点はコストと時間を消費する点です。一般の書籍に紹介された例では、計測コストは実にプロジェクト総コストの5％から9％にも上るという事例があります。
実際にこの測定負荷を考慮すると、一定以上の大企業や大規模プロジェクトしか適用できないものであるため、もっとカジュアルに品質測定を行うことはできないか、という意見があります。
この意見に対して、比較的測定や観察の容易な値を組み合わせ、洞察力を働かせることで見えない品質を可視化する「エンピリカル・アプローチ」があります。これは世界的に注目されている我が国が誇る考え方であり、日本も米、独、豪と並ぶ世界4大拠点の1つとなっています。例えばバージョン管理ツールへのソースチェックイン／チェックアウトのログから修正変更の偏在性を観察することで個々のコードの品質安定度を測るなど、おおよそ考え付くだけの測定可能対象を組み合わせて品質を定量化するアイデアの総体です。
筆者もエンピリカル・アプローチの研究者に対する敬意を表しつつ、さまざまなメトリクス測定にいそしんでいます。例えばファイルの更新日付や、プログラムコード内に記述された変数名の平均文字数などから、どんな経緯で作られた仕様書やコードなのかを推定する手法などは思いつき、実際の品質コンサルタントや品質レビュー専門家としての業務で適用しています。Webや一般書籍などあらゆる媒体から情報が得られるので皆さんもぜひ調べてみてください。
これは私見ですが、エンピリカル・アプローチ、特に品質定量化や測定について最も重要な要素は「問題意識」だと思っています。何とかして品質を向上させたい、欠陥をひとつでも多く検出したいという「アツい思い」は、プロジェクトの種類や規模に関係なく適用できるエンジニアリング（＝現場でうまく仕事を回す工夫のことだと筆者は考えます）そのものです。その意味では、品質を「かっこよく」向上させるエレガントな理論や科学なんかいらない、とすら思ってしまいます。
プロジェクト現場でもがきながら現実の制約に苦しんだ結果生み出された「エンジニアリング」はおそらくどんな学問的知識よりも輝かしく、エレガントな理論にはない「粋でイナセな」エンジニアのソリッドな武器として伝承されるべき世界ではないかと思っています。
