「ソフトウェア・サイエンス」とは一体何ぞや？：山浦恒央の“くみこみ”な話（25）

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

　ソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」「成熟・定着期」に分割し、前回「人類初のソフトウェア・メトリクスをめぐる熱い論争」では胎動期を取り上げ、McCabeの「Cyclomatic Number（循環的複雑度）」の概要や課題、その怪しさについて述べました。今回は、循環的複雑度より、もっと怪しい（？）「ソフトウェア・サイエンス」について解説します。

1．「循環的複雑度」の復習

　ソフトウェア工学関係の学会誌で圧倒的に権威が高いIEEEの「Transactions on Software Engineering（通称、IEEE TSE）」に、Thomas McCabeが「A Complexity Measure」と題した論文を発表しました。これが、世界で最も有名なソフトウェア・メトリクスの論文です。ソースコードやフロー・チャートのアーク（矢印）の数、ノード（結節）の数、プログラムの数から、プログラムの複雑度（循環的複雑度）を計算するというものです。

　循環的複雑度の計算は非常に簡単ですが、問題はその計算法ではなく、“意味”にあります。「循環的複雑度の定義」をめぐって、当時のソフトウェア工学の学会は大紛糾しました。IEEE TSEに発表した論文には、「循環的複雑度とは何か？」や「複雑性の定義」についてどこにも記されていないのです。「このように計算すると、ソースコードの循環的複雑度を計算できる」としか書いてありません。McCabeの循環的複雑度が発表された当時、「素晴らしい考えだ！」と無条件に信じた人と、「科学的根拠がない！」と懐疑的な態度を取る人たちに二分されました。

2．「ソフトウェア・サイエンス」の登場

　Maurice H. Halsteadが1977年に発表したのが、「Elements of Software Science」という論文です（注1）。これは、プログラムをコーディングするときに使うオペレータ（＋、−、＊など）やオペランド（Data01、8のような変数や、定数）の種類や数に注目したメトリクスです。要は「幼稚園児用の絵本は、語彙（ごい）の種類や数が少ないので読みやすく、理解しやすいけれど、科学技術の専門書は、その反対なのでものすごく読みにくいし、理解が難しい」ということを数式化したもの（らしい）です。

　具体的な計算法を図1に示します。この数式を見て、平均的なソフトウェア技術者が感じることは、「えっ、何この複雑な式は？ 何をどう計算しているの？」でしょう。数学嫌いの理科系と、なぞなぞが好きな文科系が大集合するソフトウェア業界では、少し複雑な数式が出てくると、死んだふりをする人が多いので、ごく自然な反応だと思います。

図1　ソフトウェア・サイエンスでの計算法

3．「ソフトウェア・サイエンス」の憂鬱（ゆううつ）

　McCabeの循環的複雑度が発表された翌年に、Halsteadのソフトウェア・サイエンスが出現し、大きな話題となりました。

　まずは、その名前です。たかだか、ソフトウェアの複雑性の計測なのに、“ソフトウェア・サイエンス”とは、大風呂敷を広げた感が否めません。名前から受ける印象は、「ソフトウェア工学」の片割れみたいに雄大で巨大なものです。そのため当時、この名前に惑わされたり、反発したりする人は多かったようです。

　ソフトウェア・サイエンスでの算出式を見ると、オペレータの種類と数、オペランドの種類と数が分かると、プログラムがメモリ上に占める大きさやプログラム開発に必要な時間まで計算できることになります。しかも、その根拠は、どこにも示されていません。このあたりの事情は、循環的複雑度と同じです。循環的複雑度と同様、「信ずる者は救われる」という考え方です。「科学的根拠がない！」と反発する人は、循環的複雑度とソフトウェア・サイエンスをまとめて攻撃しましたし、一方の信奉者は、両方を庇護（ひご）しました。

　ソフトウェア・メトリクスの歴史は、混乱期、胎動期、活動期を経て、反抗期へ移行するのですが、反抗期では、メトリクスが中世の「魔女狩り」のようなバッシングを受けました。バッシングにおいて、循環的複雑度とソフトウェア・サイエンスを比べると、大風呂敷を広げ、開発時間まで計算できると大見得を切ったためか、ソフトウェア・サイエンスに対する風当たりが圧倒的に強く、かつてソフトウェア・サイエンスを熱心に適用していたエンジニアや研究者までが、手の平を返したように攻撃側に回ったこともあったようです。

　これで、循環的複雑度とソフトウェア・サイエンスという“ソフトウェア・メトリクス劇場”の2人の主演俳優がそろいました。そこへ、ソースコード行数（LOC：Lines of Code）も含めて、三つどもえになって活動期へ移行し、世界中で計測大会がはじまるのです……。次回は、活動期について解説します。（次回に続く）

補足：筆者よりおわびと補足・訂正

　これまで、ソフトウェア・メトリクス関連のコラムを書いてきましたが、今回、ある読者の方から、間違いの指摘や貴重なコメントをいただきました。ここでおわびの意味も込め、指摘の詳細な内容と、それに対する回答を記します（なお、以下指摘個所に対する修正は対応済みです）。

指摘1：連載第21回「ソフトウェアの定量的測定の甘いワナ」

指摘2：連載第22回「構造化プログラミングの苦難の歴史」

指摘3：連載第24回「人類初のソフトウェア・メトリクスをめぐる熱い論争」