ソフトウェア・サイエンス推進派と反対派
の正面衝突
〜ソフトウェア・メトリクスの栄光と没落：その6〜

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

　本コラムでは、図1のようにソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」「成熟・定着期」に分割し、連載第24、25回では胎動期を取り上げ、McCabeの「Cyclomatic Number（循環的複雑度）」と、Halsteadの「ソフトウェア・サイエンス」を紹介しました。今回は、その続きとして活動期について述べます。

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

1．「胎動期」の復習

　ソフトウェア・メトリクス史上、最も有名なのが循環的複雑度とソフトウェア・サイエンスです。当時、この2つのメトリクスは、3位以下を30ゲーム以上引き離して、ぶっちぎりのトップを走っていた感があります。

　循環的複雑度は、ソースコード（あるいは、フローチャート）の制御の流れを有向グラフと見なし、グラフの線が作る閉領域の数をカウントしたものです。循環的複雑度というおどろおどろしい字面とは逆に、2、3秒もあれば目でカウントできてしまいます。

　ソフトウェア・サイエンスもソースコードに注目したメトリクスで、オペレータの種類と数、オペランドの種類と数が分かると、プログラムがメモリ上に占める大きさや、プログラム開発に必要な時間まで計算できるという壮大なメトリクスです。ただし、その根拠は、どこにも示されていません。この辺りの事情は、循環的複雑度も同じです。

　胎動期で、循環的複雑度とソフトウェア・サイエンスというソフトウェア・メトリクス劇場の2人の“主演俳優”がそろいました。そこへ、「ソースコード行数（LOC：Lines of Code）」という“永遠のアイドル”が加わり、三つどもえになって活動期へなだれ込み、世界中で計測大会がはじまりました……。

2．推進派と反対派の激突：活動期

　胎動期において、循環的複雑度とソフトウェア・サイエンスという「2大メトリクス」が相次いで発表され、業界から大きな注目を浴びたのですが、両方とも、科学的な根拠が示されていないのがツラいところです。このため、循環的複雑度とソフトウェア・サイエンスに対する研究者やソフトウェア技術者の反応は、図2のように真っ二つに分かれました。

図2　推進派と反対派の大激突

　推進派（経験則派）のいい分は、「実際に役に立つのなら、理屈抜きに使おう。理論は後からついてくる」です。中世のフランスでの話ですが、繊維を巨大な鉄釜で染めるとき、大きなヘラでかき回したそうです。当時、ヘラが釜の底に当たってガラガラと大きな音が出るほど色素の定着がよいと信じられており、染色の職人たちは音の大きさを競ったといいます。後に、科学が進歩して、鉄釜の鉄分が触媒になって着色がよくなることが分かったのですが、「メトリクス推進派」も、これと同じといいたいのでしょう。ソフトウェア工学は、数学や物理学のように厳密な学問ではなく、「職人の知恵」の集大成といえます（医師や弁護士も、ある意味で「職人の知恵」を駆使しています）。メトリクス推進派の「実際に効果があるのなら、まず使おう」は、ソフトウェア工学の考え方と同じ方向を向いています。

　一方、反対派（科学性重視派）のいい分は、「科学的な裏付けがないものは、“まやかし”と同じ」です。いきなり、「この霊験あらたかな水を毎日飲むと、健康になる。ご利益がある。いいから黙って飲みなさい」といわれると、中世の黒魔術のようなうさんくささを感じます。反対派のいい分もよく分かります。

　当時、世界各国で開催されたソフトウェア工学関係の国際学会では、ソフトウェア・メトリクスが非常にホットなトピックスでした。循環的複雑度とソフトウェア・サイエンスを推進する一派と、反対派が激突し、時には、本当に殴り合いになるのではないかと思うほど、感情的になり激しい口調で互いを非難しました。

　推進派と反対派の激突により、次の4つの流れが生まれました。

（1）メトリクスの実地適用
（2）メトリクス間の相関関係の研究
（3）メトリクスの意味の見直し
（4）メトリクスの計測時期の検討

　それぞれの流れの概要と、どのように推移したかについて、以下に記します。

（1）メトリクスの実地適用

　循環的複雑度とソフトウェア・サイエンスを計測するのは難しくありません。ツールを使えば、あっという間に自動計算できます。かくして、日ごろからソフトウェアの生産性や品質に大きな関心を持っていた「ソフトウェア開発の優等生的な組織」は率先して、自分たちが作ったプログラムの循環的複雑度とソフトウェア・サイエンスを計測しました。しかし、測定結果を出してはみたものの、「はて？ この値をどう使えばイイんだろう？」と大いに悩んだのです。

（2）メトリクス間の相関関係の研究

　当時のソフトウェア工学の研究者の王道的なテーマが、メトリクス間の相関関係でした。循環的複雑度とソフトウェア・サイエンスの2大メトリクスと、古典的メトリクスであるLOCの3つを同じプログラムに適用し、三者の相関関係を求める研究が盛んになりました。結果は、予想とは異なるものとなりました。

（3）メトリクスの意味の見直し

　ソフトウェア・メトリクスの意味は何なのか？ 計測した値は何を表しているのか？ これについても、いろんな人が議論をしました。

　まず、「循環的複雑度とソフトウェア・サイエンスは、プログラム・モジュールの複雑性を表している」というところからスタートし、「ソフトウェア全体の複雑度を求めるには、すべての構成モジュールの複雑度の総和を計算すればよい」と進みました。ここから、「複雑度とは何か？」という議論が生まれ、さらに「複雑度ではなく、ソフトウェアの品質そのものを計測したい」との要望が出ました。これが紛糾のもとになったのです。

（4）メトリクスの計測時期の検討

　「いつ、計測すべきか？」の議論です。メトリクスを計測時期で分類すると、「metrics after the fact」と「metrics before the fact」に分かれます。

　metrics after the factは、出来上がった製品やソースコードに対して適用するメトリクスで、循環的複雑度とソフトウェア・サイエンスはこの代表です。一方、metrics before the factは、開発途中の中間成果物に適用するメトリクスです。

　この議論は、「metrics after the factとmetrics before the factは、どちらがエラいか」という論争にはじまり、「ソフトウェア開発において、メトリクスをどのように使うべきか」という根本的なテーマにまで発展しました。議論は収束するどころか、発散の一途をたどったのです……。

　循環的複雑度とソフトウェア・サイエンスを推進する一派と、反対派が激突して生まれたこの4つの流れは、前述のとおり、意外な結果となり、予想外の方向に進みました。これが、混乱を呼び、衰退へとつながるのです。詳細は、次回紹介する反抗期で述べます。（次回に続く）

＞＞そのほかの「組み込みコラム」をチェックする