　本コラムの「ソフトウェア・メトリクスの栄光と没落」シリーズ（連載第21回～）では、ソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」「成熟・定着期」に分割し（図1）、ソフトウェア・メトリクスの歴史をひもときながら、ソフトウェア・メトリクスの本質に迫りました。

　今回は、“番外編”の第2弾として、「新しいアプローチのメトリクス」について述べたいと思います。

図1　ソフトウェア・メトリクスの歴史

従来のメトリクス

　大昔のソフトウェア開発では、ソースコードの行数、摘出バグ数を計測していましたが、もっといろいろな数値を計測して開発をより良い方向へ導きたいとの要望が出て、さまざまなメトリクスが提案されました。その結果、世界中で“計測大会”が繰り広げられましたが……、思ったほどの効果が出ず、結局、元のソースコードの行数、摘出バグ数に戻った感があります。

　ソフトウェア開発業界全体で共通的に使用しているメトリクスは、この2つ（ソースコードの行数、摘出バグ数）でしょうが、各組織では、独自に工夫したメトリクスを適用し、それなりの効果を上げています。

　では、自分の組織で、どんなメトリクスを適用すれば効果が期待できるのか？ そのヒントになるものを以下で紹介します。

ヒント1：マルチ・メトリクス（Multiple Metrics）

　癌（がん）の特効薬を探す方法として、「全件チェック方式」があります。医薬品に限らず、あらゆる物質を試し、癌に効くかどうかを試験する方法です。エジソンが電球を発明したとき、電球のフィラメントとして、どんな材料が最適かを見つけるときに、この方法を使ったと筆者は記憶しています（最適だったのが、京都の竹から作った炭素線だったそうです）。この雄大な発想は、アメリカならではのものでしょう。

　さて、この全件チェックと同じ発想のメトリクスが「マルチ・メトリクス（Multiple Metrics）」です。このメトリクスは、正確には計測法を提案したものではなく、“既存のメトリクスの適用法を論じたもの”です。以下に、マルチ・メトリクスの具体的な方法を挙げます。

ステップ1　
要求仕様定義フェーズなど、ソフトウェア開発の初期から、いろいろなメトリクスを適用して計測する。適用するメトリクスに科学的根拠があるかどうかは問わない
ステップ2　
評価したい特性と計測値の相関関係を分析する
ステップ3　
最も高い相関関係を示したメトリクスを以降の開発フェーズで適用する

　不適切な例かもしれませんが、例えば、“競馬の必勝法”として、以下の方法を聞いたことがあります。まず、入手可能なあらゆる予想紙を買い、競馬をよく知っている友人や予想屋さんの意見も集め、第1レースから第6レースまでの前半を見（“けん”と読む。ギャンブル用語で「馬券を買わずレースを見るだけ」のこと）します。第1レースから6レースの結果と、予想紙や友人のアドバイスを比較し、その中で最も的中率の高い予想に従って、後半の第7レースから最終の第12レースまでで馬券を買うというものです。この“競馬の必勝法と、マルチ・メトリクスはよく似ています”。

　ギャンブルでは、不確定な要素があまりに多いため、この必勝法を採用しても、もうかる保証は全くありませんが、ソフトウェア開発では、計測したい特性と測定値の間に、ある程度の因果関係があるため、競馬の必勝法よりも、高い確率で予想が的中すると思われます。

　評価したい特性とメトリクスに、どの程度の相関関係や精度があるかは、以下に挙げる各プロジェクトの固有の事情に依存する場合が少なくありません。

開発するソフトウェアの特性　
開発対象プログラムの特性や難易度。例えば、プロセスの実行順序が毎回同じになるバッチ系の単純なプログラムか、プロセスに優先順位が付き、プロセスの追い越しが発生する複雑なリアルタイム系のプログラムか
開発手法　
例えば、古典的なウォーターフォール・モデルに基づいた開発法を採用しているか、XP（Extreme Programming）などのアジャイル手法を適用しているか、あるいは、従来のように制御中心の設計をするか、データ中心のオブジェクト指向を採用するのか
新規開発・保守・再利用　
新規にソフトウェアを開発するのか、第1バージョンに対する保守（機能の変更、追加、新ハードウェアの実装など）か、既存のプログラムを再利用して、別のソフトウェアを作るのか
構成人員　
開発技術者の経験、知識、および人数など
プロジェクトの余裕　
スケジュール、コスト、品質で、どの程度の余裕があるか。最も厳しいリソースは時間なので、スケジュールの余裕が非常に重要

　マルチ・メトリクスは、このような各プロジェクトの固有の事情に最も適したメトリクスを見つける上で、効果があるものと思います。

ヒント2：スペクトラム・メトリクス（Spectrum Metrics）

　従来のメトリクスは、大部分が単一の数値で評価対象を表現していました。代表的な例が、ソフトウェアの複雑度を計測するMcCabeの「循環的複雑度（Cyclomatic Number）」です。

　「スペクトラム・メトリクス（Spectrum Metrics）」は、これとは反対のアプローチを取り、複数の値で評価対象を表現する方式です。例えば、あるプログラム・モジュールの複雑度を表現する場合、ソースコード行数、取り得るパス数、ローカル変数の数、グローバル変数の数、発生バグ数、コメントの充実度などを計測し、これらの数値を加減乗除せず、そのまま見せるという方式です。すなわち、いろいろな魚の肉をすり身にして混ぜ、蒲鉾（かまぼこ）に加工するのではなく、刺身でそのまま食べるようなものです。

　スペクトラム・メトリクスでは、測定値を加工しませんので、値には単位が残ります。また、数値の意味は、それを使用する側が任意に解釈して、ソフトウェア開発の制御で使用します。

　長期間お届けしてきた「ソフトウェア・メトリクスの栄光と没落」シリーズは、以上で終了となります。

　次回からは、新シリーズとして、「見積もり」を取り上げる予定です。ソフトウェア開発技術者としての最高の能力といわれるのが、“見積もり能力”です。

　なぜ、見積もりが必要か、簡単で高精度の見積もり法はあるのか、人員数、生産性、開発期間、開発規模の間にどんな関係があるのか、見積もりのベースになった値が変化したとき、それがコスト、人月、スケジュールにどのように影響するのか、などを具体的に検討します。お楽しみに！（次回に続く）

【筆者紹介】

山浦恒央（やまうらつねお）
東海大学大学院組込み技術研究科助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」（Academic Press社、共著）、「ピープルウエア第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。