大き過ぎた“4つ”のテーマ：山浦恒央の“くみこみ”な話（27）
「ソフトウェア・メトリクスの栄光と没落」シリーズ第7弾。今回は、「活動期」の後半から「反抗期」の前半までを紹介する
ソフトウェアの品質、複雑性、生産性などを具体的な数値で測るのが「ソフトウェア・メトリクス」ですが、何をどう計測し、計測値をどう使えばよいかという根本的な問題は、いまだに解決されていません。本コラムでは、ソフトウェア・メトリクスの歴史をひもときながら、ソフトウェア・メトリクスの本質に迫ります。
本コラムでは、図1のようにソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」「成熟・定着期」に分割し、前回の内容で胎動期と活動期の前半を取り上げました。今回は、その続きとして活動期の後半と、反抗期の前半について述べます。
活動期の前半の復習：メトリクス推進派と反対派の激突
ソフトウェア・メトリクスの胎動期において、「循環的複雑度」と「ソフトウェア・サイエンス」という「2大メトリクス」が相次いで発表されました。業界から大きな注目を浴びたのですが、両方とも科学的な根拠が示されていないのがツラいところです。このため、循環的複雑度とソフトウェア・サイエンスに対する研究者やソフトウェア技術者の反応は、真っ二つに分かれました。
推進派（経験則派）のいい分は、「実際に役に立つのなら、とにかく使おう。理論は後からついてくる」であり、反対派（科学性重視派）のいい分は、「科学的な裏付けがないものは、“まやかし”と同じだ」です。
当時、世界各国で開催されたソフトウェア工学関係の国際学会では、ソフトウェア・メトリクスが非常にホットなトピックスでした。循環的複雑度とソフトウェア・サイエンスを推進する一派と、反対派が正面から激突し、時には感情的になって激しい口調で互いを非難し合いました。
活動期では、次の4つのテーマが検討されました。推進派と反対派は、これらテーマについて議論・激突し、反抗期へとなだれ込んでいったのです……。
- メトリクスの実地適用
- メトリクスの相関関係の研究
- メトリクスの意味の見直し
- メトリクスの計測時期の検討
前回のコラム「ソフトウェア・サイエンス推進派と反対派の正面衝突」は、この4つのテーマの概要を記しただけにとどまりましたが、今回は4つのテーマを基にした議論の流れを詳しく述べます。活動期から反抗期へ“ねじれ”ていく様子を感じていただければ幸いです。
テーマ その1：メトリクスの実地適用
もともと、メトリクスは、計測の大家、ケルヴィン卿の「測定できないものは制御できない」という有名な言葉を「（ソフトウェアを）測定できれば（ソフトウェア開発を）制御できる」といい換えたところから発生しています。
循環的複雑度とソフトウェア・サイエンスが発表され、メトリクスがソフトウェア工学における非常にホットなトピックスになったころ、この2つのメトリクスを計測するツールがあちこちで作られました。そして、皆がツールを使って測定結果を出したのですが、“その測定値をどう使うか”で悩みました……。手段（測定）に一生懸命になり、目的（システマチックなソフトウェア開発）を忘れていたのです。
メトリクス懐疑派から循環的複雑度に対し、以下の2つの意見が出ました。
- コーディングが終わって循環的複雑度を計測し、大きな値が出たら作り直すのか？
- 循環的複雑度は、受け入れテストでは使えるが、新規開発では使えない！
循環的複雑度の提案者であるMcCabeは、「循環的複雑度で大きな値が出たら、作り直すのか？」に対して、「新規開発は1度だけだが、保守は何度も実施する。保守のときに循環的複雑度を計測し、もし複雑度が大きければ注意して保守を実施しなければならない」と反論しました。保守での有用性を強調したということは、“新規開発では使えない”ことの裏返しといえます。
現代のソフトウェア開発のライフサイクル（ソフトウェアの誕生から消滅までの一生）では、保守にかけるコストや時間は全体の3分の2を超え、新規開発は3分の1以下にすぎません。いまは保守の比重が圧倒的に高いので、McCabeの意見も納得できるのですが、保守に対する当時の考え方は、「顧客に出荷した後の製品に潜んでいるバグを修正すること」であり、一種の必要悪というのが主流でした。そのころは、おまけ的な要素の高い“保守”ではなく、最も重要なプロセスである“新規開発”を何とか成功させたいと考えるソフトウェア開発者がほとんどだったのです。
当時の技術者たちは、「作ってから計測するのではなく、開発しながら計測して、開発プロセスをより良い方向に導いてほしい」との願いを持っていました。皆、「メトリクスによるソフトウェア開発の計器飛行」を夢見ていたのです。そんな技術者には、循環的複雑度の考え方は不評で、「循環的複雑度は新規開発では使えない」と考える人が多く、さらにもう一歩進んで、「循環的複雑度は、ソフトウェア開発では使えない」と変化していきました。
この「メトリクスの実地適用」というトピックスは、さらに、「いつ計測するか？ 開発後か、開発途中か？」というテーマに発展しました。この詳細は「テーマ その4：メトリクスの計測時期の検討」を参照してください。
テーマ その2：メトリクスの相関関係
当時のソフトウェア工学の研究者の王道的なテーマが「メトリクスと実際のデータの相関関係」でした。このテーマの主役となったのがソフトウェア・サイエンスです。実際のデータと比較して、ソフトウェア・サイエンスの正当性を立証しようとしたのです。
ソフトウェア・サイエンスのいろいろな算出式を見ると、ソースプログラム中の演算子の種類と数、変数や定数の種類と数が分かれば、プログラムがメモリ上に占める大きさや、プログラム開発に必要な時間まで計算できることになっています。多くの研究者が、半信半疑で（あるいは、怖いもの見たさ？ で）ソースプログラムをベースにして、ソフトウェア・サイエンスのデータを測定しました。その結果は、「ほとんど相関関係はない」でした。
ソフトウェア工学の研究者、ロバート. L. グラスは、著書「Facts and Fallacies of Software Engineering（邦題『ソフトウェア開発 55の真実と10のウソ』／日経BP出版センター刊、2004年）」の第5章で、ソフトウェア・メトリクス（特に、ソフトウェア・サイエンス）に関し、以下のように述べています。
「また、ソフトウェア・メトリクスには、『ソフトウェア・サイエンス（software science）』の『呪縛』もある。ソフトウェア・サイエンスとは、計算機界のパイオニア、Murray Halsteadが、ソフトウェア工学の基本的な科学となることを狙って提案したもので、計測する項目と計測方法を厳密に定義した。当時は、それらしく見え、メトリクスのゴールと思われた。いろいろな研究者が、この技法で測定した数値を分析したところ、実測値とソフトウェア・サイエンスのデータの間には、相関関係がないか、負の相関関係があることが分かった。中には、占星術と関連付ける人もいた。プロジェクトの『科学的』なデータは、汚名にまみれ、大部分はゴミ箱いきとなった。ソフトウェア・サイエンスが崩壊した状況を知っている人は、ソフトウェア・メトリクスすべてを同類と見なし、葬り去ろうとした」――（『ソフトウェア開発 55の真実と10のウソ』／日経BP出版センター刊、2004年）の第5章より
確かに、アメリカ人の年配のプログラマとソフトウェア・メトリクスの話をすると、いまでも、不快な顔をする人がいます。おそらく、ソフトウェア・サイエンスと混同していると思うのですが、たかだかソフトウェアの1つの技術なのに、そこまで嫌悪感を催すことに大きな感銘を受けた覚えがあります。ソフトウェア・サイエンスが、ソフトウェア開発のプロセス改善の切り札になると信じていたのに、裏切られた……。かわいさ余って憎さ100倍というところです。
占星術との相関関係を分析するというのは、ソフトウェア・サイエンスに対する最大の侮辱でしょう。そんな話を聞くたびに、「科学的根拠のない学説を立ててはならない」「自説に対し、必要以上に立派過ぎる名前を付けてはならない」ことを痛感しました。
テーマ その3：メトリクスの意味
ソフトウェア・メトリクスの数値は何を表現するのか？ これについても、いろいろな人が議論しました。
まず、「循環的複雑度は、1つのプログラム・モジュールの複雑性を表している」というところからはじまり、「では、ソフトウェア全体の複雑度を求めるには、すべての構成モジュールの複雑度の総和を計算すればよい」と進みました。問題はここからです。「複雑度ではなく、ソフトウェアの品質そのものを計測したい」という“大きな欲”が出ました。ある意味、必然的な流れなのですが、これが大紛糾のもとになったのです……。
品質を計測するのなら、「品質とは何か？」という大命題に真正面から突き当たります。これは、「人生とは何か？」「幸福とは何か？」に相当する「ソフトウェア工学における永遠のテーマ」です。当時のソフトウェア工学では、品質をいくつかの要素に分解する研究は進んでいました。例えば、ソフトウェア工学の大家、Barry Boehmは、品質を「完全性」「正確性」「無矛盾性」「装置独立性」「装置効率」「伝達性」「アクセス性」「構造性」「自己記述性」「簡潔性」「明瞭（りょう）性」「拡張性」に分解しています。メトリクスの研究者は、各要素を測定し、品質そのものを計測しようとしたのです。
“品質の分解”まではいいのですが、問題は、品質の各要素の計測です。これは、簡単ではありません。例えば、完全性を測定する場合、何を測ればいいのか？ バグの総数、バグの影響度、仕様変更の数、テストの網羅性……など、完全性に関係すると思われるものを測ることになるのですが、完全性と計測項目の対応付けがものすごく大変です。ソフトウェアの仕様を数学的モデルに置き換えたり、仕様記述言語で表現したりと面倒なことが容易に想像できます。結局、“品質の測定”は、対象が巨大過ぎて、挫折してしまいました。
この状況は、小学校のPTAの合唱大会に似ています。はじめは、軽い気持ちで、土曜日の午後、あるクラスの児童とお母さんたちが自発的に集まって、楽しく合唱をしていたのですが、それが評判になり、校長先生が全校を挙げての行事にしようと画策し、さらに、県の教育委員会が全県の公式イベントにしてコンクール形式にしようとしたけれど、話が大きくなり過ぎてまとまらず、結局、空中分解してしまった……。
こぢんまりと複雑性を計測していたうちはよかったのですが、話が「ソフトウェアの品質測定」まで大きくなった途端、挫折したのです。これも、ソフトウェア・メトリクスにとって、不幸の1つと思えてなりません。
テーマ その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は、どちらがエラいのかという論争からはじまりました。
アメリカ英語に、「Monday morning quarterback」というイディオムがあります。日曜日に開催されたフットボールの試合の内容を月曜日の朝に、あれこれと注文をつけることであり、「すべてが終わった後で、『こうすれば成功したのに』と批判することはたやすい」という意味で使います。開発が終わった後で、このモジュールは複雑過ぎると文句をいっているのが、metrics-after-the-factというわけです。第三者が開発したソフトウェアを受け入れるかどうかを決める「acceptance test」や、5つの候補の中でどのツールを購入するかを決定する場合には適用できるのですが、“新規開発では使えない”との結論になりました。
ソフトウェア開発の“計器飛行”を目指したmetrics-before-the-factの方がエラいという点では意見が一致したのですが、問題は、ソフトウェア開発を成功に導くには、何をどう計測して、どのように使えばいいかです。これも、品質の計測と同様、非常に大きなテーマであり、どこから手を付けていいのか分かりませんでした。例えば、仕様の複雑度を計測するには、仕様を形式的記述言語で表現したり、状態遷移モデルやペトリネットなどで表したりする必要があります。
一方で、そんな面倒なことはやりたくないというのがソフトウェア開発技術者の本音ですし、仕様をすべてモデル化することは不可能です。対象があまりに大きくて面倒だったため、「いつ、計測するのか？」「どうすれば、metrics-before-the-factが可能か？」の議論は立ち消えになりました。
はじめは、「ソフトウェア開発を定量的に制御して管理できる」と期待され、前途洋々だったソフトウェア・メトリクスですが、以上の4つのテーマに対する大論争を経て、大混乱し、気が付けば反抗期へと突入していたのです……。
次回は、ソフトウェア・メトリクスの反抗期の後半、および、安定期について解説します。（次回に続く）
東海大学 大学院 組込み技術研究科 助教授（工学博士）
Copyright © ITmedia, Inc. All Rights Reserved.