　ソフトウェアの品質、複雑性、生産性などを具体的な数値で測るのが「ソフトウェア・メトリクス」ですが、何をどう計測し、計測値をどう使えばよいかという根本的な問題はいまだに解決されていません。本コラムでは、ソフトウェア・メトリクスの歴史をひもときながら、ソフトウェア・メトリクスの本質に迫ります。

　本コラムでは、図1のようにソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」「成熟・定着期」に分割し、前回活動期の後半と反抗期の前半を取り上げました。今回は、反抗期の後半と成熟・定着期について述べます。

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

復習：メトリクスの空中分解

　ソフトウェア・メトリクス推進派は反対派が激突して、活動期になだれ込み、4つの大きなテーマを検討しました。

メトリクスの実地適用
コーディングが終わってメトリクスを適用し、悪い値が出たら、作ったものを捨てて、作り直すのか？それなら、メトリクスは、受け入れテストでは使えるが、新規開発では役に立たないと反対派からたたかれました。
メトリクスの相関関係の研究
メトリクスの計算値とソフトウェア開発での実際の値の間には“相関関係がない”か、“負の相関関係がある”ことが判かりました。
メトリクスの意味の見直し
「メトリクスは、ソースコードの複雑度を表している」から出発し、「複雑度ではなく、ソフトウェアの品質を計測したい」との要求が出たのですが、品質計測は研究対象として大き過ぎて、挫折してしまいました。
メトリクスの計測時期の検討
ソフトウェア開発の開発途中で計測し、「計器飛行」を目指したのですが、それには仕様を形式的記述言語で表現したり、モデル化したりする必要があります。とても面倒なため、この議論は立ち消えになりました。

　メトリクスの研究は、ソフトウェア技術者の大きな期待を背中に受けてはじまったのですが、以上の4つのテーマに対する大論争を経て大混乱した後、空中分解してしまいました。

　次に待っていたのは、「メトリクスは役に立たない」という反抗期でした。今回は、反抗期（の後半）から成熟・定着期について解説します。

反抗期

　メトリクスは、あれほど熱烈なラブコールを送られていたのに、花が大きく開いて実を結ぶことはありませんでした。高校野球の花形ピッチャーが、大きな期待と高給で迎えられてプロへ行ったのですが、結局、1軍のマウンドに上がれず戦力外通告を出されたようなものです。

　活動期では、多くのソフトウェア技術者がメトリクスを実際に測ったのですが、最も意外だったのは、「計測には予想外の時間とコストが掛かる」ことでしょう。例えば、NASAゴダード宇宙センター（Goddard Space Flight Center）の調査によりますと、データの収集にはプロジェクトの全コストの3％、また、データの処理には4～6％のコストが掛かり、メトリクスに必要なコストは、開発総コストの7～9％にもなるそうです。その割に効果が出ませんでした（正確には、「メトリクスをどう活用してよいか分からなかった」でしょう）。

　ホットなトピックスとして推進派による熱狂的な支持を受けた「ソフトウェア・サイエンス」ですが、複雑怪奇な数式で計算した値と、プロジェクトで実際に開発したソフトウェアの実測値の間には、相関関係がないか、負の相関関係があることが判明して、その魔力が消えました。そして、中には“魔女狩り”のような過激な反応をした技術者もいたそうです。

　ソフトウェア・メトリクスへの熱くて大き過ぎた期待が萎み、現実的になりました。結局、計測する項目は、昔ながらの「ソースコードの行数（LOC）」と「発生バグ数」に回帰したのです。

成熟・定着期

　1990年代の前半から、ソフトウェア・メトリクスは成熟・定着期に入り、現在へ至っています。40年前の混乱期に戻った感がありますが、一部の組織ではメトリクスが定着しました。この状況は、日本での“スイーツの流行”に似ています。

　これまで日本ではやったスイーツとして有名なのが、1990年代のはじめに流行したティラミスでしょう。以降、クリーム・ブリュレ、ナタ・デ・ココ、パンナ・コッタ、カヌレ、ベルギー・ワッフルを経て、いまはマカロンがブームだそうです。スイーツは、数年のサイクルで盛衰を迎えていますが、ブームが去った後も一部の人達の間で定着し、スイーツ文化の一部となったのです。

　メトリクスもこのスイーツと同じ道をたどりました。メトリクスに夢破れた会社が多かったのですが、流行していた間にメトリクスの意義や効果に目覚め、自社内に定着させたところも少なからずありました。そんな会社では、ソースコードの行数（LOC）と発生バグ数を軸に、各社独自のメトリクスを開拓して、ソフトウェア開発に役立てているのです。独自メトリクスの例として、以下のものがあります。

バグ密度
ソースコード1000ステップ当たりのバグ数。少ないほど良い。通常値は、4～5。
テスト項目密度
ソースコード1000ステップ当たり、何件のテスト項目を設計したかをモジュール単位で測定した値。通常値は100前後。多過ぎると効率の悪いテスト項目を設計している可能性があり、少な過ぎると設計者がモジュールの機能を理解していない可能性があります。
バグの重要度分析
モジュールや機能ごとに、重要度の大きいバグがどの程度分布しているかを表した値。摘出したバグが少なくても、高重要度のバグの比率が多いと品質的には成熟していないと判断できます。
残存バグ数
デバッグ中のモジュールに、いくつのバグが残っているかの推定値。サンプリングによる推定や、独立した2つのテストチームが同じプログラムをテストして、共通のバグの個数からバグ総数を推定したりするなど、企業により、いろいろな測定方法があります。
保守フェイズでの規模見積もり
既存のソフトウェアの一部を削除し、追加・変更するのが保守作業ですが、新規開発と違い、工数見積もりや規模見積もりが簡単ではありません。100ステップのモジュールの中の10ステップを変更するケースと、100万ステップの中の10ステップを変更するケースでは、保守に必要な工数は大きく違います。これをメトリクスとして、どのように反映させ、計測するかは非常に大きなテーマです。各企業は独自の“保守メトリクス”を持っていますが、公開されることはまずありません。
生産性のメトリクス
企業にとって、最重要値の1つが生産性です。これをどのように測るかで各社が苦労しています。自社の開発スタイルに適した計測法、より精度の高い測定方式を求めて、常にチューニングしています。開発担当者の能力ごとに、投入した時間を計測している企業もあります。この測定方法も公開されることはありません。
流用時の生産性
ソフトウェアの生産性は、過去40年ほとんど進歩していませんし、これから40年たっても変わらないでしょう。そんな“生産性の渋滞”の切り札が、“既存ソフトウェアの再利用”です。再利用してソフトウェアを開発する場合、生産性をどのようにカウントすればよいのか？これを測定するのは簡単ではありませんが、コスト計算の大きな要素ですので測定しないわけにはいきません。各企業ではいろいろなメトリクスを持っています。

　どの企業でどんな値を計測して、それをどのように活用しているかは、非常に興味のある点ですが、それらが表に出ることはほとんどありません。ほとんどのメトリクスは、ソフトウェアの品質、生産性、コストに関するものであり、最大の企業秘密であるため、一般のソフトウェア技術者の目に触れる機会はほとんどありません。また、経験則による独自の計測方法を適用している会社では、メトリクスの測定法を公表すると、「科学的な根拠がない」とたたかれることを恐れたりします。どこか勇気のある企業が、業界全体の進歩のために公表してくれたらと思います。また、国が積極的に研究し、その成果を発表してくれたらと思います（大きな効果が期待できるでしょう）。アメリカでは、航空宇宙局や国防総省のように、高品質ソフトウェアを大量に開発しなければならない政府機関がメトリクスの研究も進め、その結果を公表しています。うらやましい限りです。

　以上、全8シリーズでお届けした“ソフトウェア・メトリクスの栄光と没落”は終わります。次回からは、ソフトウェア・メトリクスの種類、測定値としてタチの良いデータ、悪いデータなどについて解説します。企業で独自のメトリクスを編み出す場合、役に立つ値を計測する必要があります。どんな値をどのように加工すればよいかを判断するときに役に立つと思います。（次回に続く）

【筆者紹介】

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

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

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