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

　前回「構造化プログラミングからオブジェクト指向への進化」では、ソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」「成熟・定着期」に分割し（図1）、混乱期の概要を述べました。また、それに関連し、構造化プログラミングとオブジェクト指向について解説しました。今回は、ソフトウェア・メトリクスがはじめて世の中に現れた胎動期を取り上げます。

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

1．ソフトウェア・メトリクス誕生のきっかけ

　混乱期、ソフトウェアに対する需要が急増しているのに、ソフトウェアの生産性がまったく改善されないことに対し、ソフトウェア業界は大きな危機感を持っていました。当時、ソフトウェアの生産性は“1人1カ月1000ステップほど”でした（いまでも、この値は同じですし、30年後も変わらないでしょう。この問題は、別の機会にアプローチします）。また、プログラムの品質も良くならず、何より、ソフトウェア開発プロジェクトをキチンと制御できませんでした。すなわち、当時プロジェクト・チームでソフトウェアを開発する場合、スケジュール、品質、コストをコントロールできなかったのです。「完成したときが出荷日だ」「プログラムは、仕様書で定義したとおりではなく、作ったとおりに動く」「品質はプログラムに聞いてくれ……」という状態です。

2．ケルビン卿の言葉

　「ソフトウェアは工業的生産物なのに、こんな作り方をしていてはダメだ。『計器飛行』をしたい……」。そんな思いが、ソフトウェア技術者の間で高まりました。「ソフトウェア開発プロジェクトを制御したい」と考えた技術者たちは、ある言葉に注目しました。それは、イギリスの高名な物理学者にして計測の大家、ケルビン卿（注1）がいった「計測できないものは制御できない」という言葉です。

　当時のソフトウェア技術者は考えました。「確かに、ケルビン卿のいうとおり、計測できなければ制御できない。……ということは、計測できれば制御できるんだ！」。一見、この考えは、正しいようにみえますが、集合論的には間違っています。「鳥ならば、動物である」を「鳥でないならば、動物でない」と変形させたのと同じで、変形後の論理は明らかに正しくありません（正しいのは、集合論における「対偶」であり、具体的には「動物でないなら、鳥でない」「制御できるのであれば、計測できる」です）。でも、当時の技術者には、そんな集合論の細かいことなど、どうでもよかったのです。「とにかく、何かを計らなければならない」という燃えるような情熱と強迫観念が生まれました。

　当時、どんなにいいかげんなソフトウェア開発会社でも計測していた項目が2つありました。それは「プログラムのステップ数」と「バグの数」です。でも、当時のソフトウェア技術者は、「これだけではダメだ。何かもっと効果のある数値を計測して、ソフトウェア開発プロセスを制御しなければ……」と考えたのです。そんなタイミングで出現したメトリクスが、McCabeの「Cyclomatic Number」とHalsteadの「Software Science」でした。

※注1：1824～1907年、本名：ウィリアム・トムソン。熱力学、電磁気学、流体力学で大きな功績を挙げたことで男爵位を授与され、以降、ケルビン卿と称する。絶対零度（－273.15℃）を0度とする絶対温度の記号「K」は、Kelvinの頭文字を取ったもの。

3．Cyclomatic Number：人類初のソフトウェア・メトリクス？

　ソフトウェア工学関係の学会誌にはいろいろありますが、圧倒的に権威が高いのがIEEE（注2）の「Transactions on Software Engineering」、通称「IEEE TSE」です。筆頭著者として書いた論文が1本でもこの学会誌に載ると、その分野の世界的権威と認められたも同然の扱いを受けます。1976年、銀河系で最高のその論文誌に、Thomas McCabe（注3）が「A Complexity Measure」と題した論文を発表しました（注4）。この論文以前にも、ソフトウェア品質の属性やメトリクスに関する書籍や論文はありますが、メトリクス関連の論文として、最初にIEEE TSEへ掲載されたのがこれです。筆者は、このことに（一応）敬意を表して、本講では、ソフトウェア・メトリクスの胎動期の開始年を1976年としました。

※注2：米国電気電子学会（The Institute of Electrical and Electronics Engineers, Inc.）。電気、電子系の世界最大の学会であり、慣例上「アイ・トリプル・イー」と読む。これを「アイ・イー・イー・イー」と読む人は、この論文誌を1回も触ったことがないことがすぐにバレるので注意。

※注3：トマス・マケイブと読む。ちなみに、“Mc”は「～の子供」という意味で、ハンバーガーで有名なマクドナルドは、「Donaldの息子」の意味。

※注4：「McCabe, T., “A Complexity Measure,” pp.308-320, Vol. SE-2, No.4, December 1976」。蛇足ながら、論文や書籍を参考文献として列記する場合、このように、「著者の姓、名、論文のタイトル、掲載論文誌、発行年月日」の順で記述するのが基本常識！

4．Cyclomatic Numberとは？

　Cyclomatic Numberは、日本語で「循環的複雑度」と訳されています。日本人は、漢字が大好きで、中でも教養の見せどころである四文字熟語を異常に好みますが、循環的複雑度は、さらに高度な六文字熟語であり、ものすごく難しそうな字面をしています。

　字面のシリアスさとは反対に、Cyclomatic Numberの計算は、図2に示したようにメチャクチャ簡単です。ソースコード（あるいは、フロー・チャート）のアーク（矢印）の数、ノード（結節）の数、プログラムの数から、あっという間に計算できます。Cyclomatic Numberをもっと簡単に計測したいなら、図3のように、グラフ（フロー・チャート）が、平面をいくつに分割するかを数えればいいのです（幾何学でのオイラー数です）。

図2　Cyclomatic Numberの計算法

図3　Cyclomatic Numberと幾何学

5．McCabeの憂うつ

　Cyclomatic Numberの計算は、超簡単です。計測対象のソース・コードを入力すれば、3秒で自動計算できます。問題というか、論争の震源地はCyclomatic Numberの計算法ではなく、“意味”にあります。「Cyclomatic Numberって何？」「複雑性の定義は？」をめぐって、当時のソフトウェア工学関係の学会は大紛糾しました。

　IEEE TSEは、銀河系で最も権威のある学会誌です。そこに論文が掲載されたからには、科学技術論文の執筆作法に従って書いた、質の高い有用な論文に違いないと考えるのが普通です。ところが、McCabeの論文には「Cyclomatic Numberとは何か？」や「複雑性の定義」はどこにも書いてないのです。「このように計算すると、ソース・コードの複雑度（Cyclomatic Number）を計算できるぞよ」との“神のお告げ”しか書いてありません。この“上から目線”の方法は「知能指数」と同じ路線をいくものです。

　知能指数の算出において、「知能とは何か？」はどこにも定義されていません。逆に、「このように計測した値を知能指数と呼ぶ」という科学技術らしからぬ方法を取っています。定義なしに使っている数字として、このほかに円やドルなどの貨幣単位があります。

　McCabeのCyclomatic Numberが発表されたとき、素晴らしい考えだと無条件に信じた人と、懐疑的な態度を取る人たちに二分されました（McCabeに対する筆者の筆致から、筆者がCyclomatic Number懐疑派と思う人が多いと思いますが、そのとおりです）。

6．懐疑派のいい分

　いまでは信じられないことですが、1980年代のソフトウェア工学関係の学会では、必ず、ソフトウェア・メトリクスのトラックが複数本あり、Cyclomatic Numberの「信奉派」と「懐疑派」が火花を散らせ、殴り合う直前（？）まで激しい論争を繰り返していました。筆者も含めた懐疑派のいい分は、「科学的根拠がない」「作ってから計測するのでは遅過ぎる」の2点でした。

6-1．科学的根拠がない

　懐疑派の反対理由の最大が“科学的根拠（Scientific Background）”です。論文の中で、「Cyclomatic Numberとは何か？」がどこにも書いていないのでは、科学的根拠がないといわざるを得ません。McCabeは「Cyclomatic Numberはソフトウェアの複雑性（これも、未定義です）と相関関係がある」と述べていますが、「極端なことをいえば、仕様書の重量もソフトウェアの複雑性と比例するはずだ。それなら、仕様書の重さも立派なメトリクスになる」と反論する人もいました。

　また、図4を挙げて、Cyclomatic Numberと複雑度に関係がないことを論証する研究者もいました。図4の左のフロー・チャートは、2重ループで、それぞれ最大1万回繰り返します。この図4のCyclomatic Numberは「3」で、非常に低く、それ故、複雑度も低いはずです。しかし、実行され得る経路数（パス数）は、1万×1万＝1億にもなり、テスト実施の観点からも、直感的に見ても、極めて複雑な構造をしています。

図4　Cyclomatic Numberと複雑度

　一方、図4の右のフロー・チャートは、横幅は広いものの、47都道府県ごとに処理する非常に単純なCASE文で、スッキリしたシンプルな構造をしています。なのに、Cyclomatic Numberは「47」もあり、McCabeにいわせると「言語道断の複雑さ」を持っていることになります。このように、「Cyclomatic Numberと複雑度の間には、相関関係がない」「Cyclomatic Numberの定義がない」というのが懐疑派の最大の反対理由です。

6-2．作ってから計測するのでは遅過ぎる

　Cyclomatic Numberは、完成したソース・コードや、フロー・チャートに対して適用します。出来上がったソース・コードのCyclomatic Numberが「37」のように非常に大きな値になった場合、作り直さなければならないのでしょうか？作ってから測定して「このモジュールは複雑過ぎる！」といわれても困りますよね。つまり、「37」という大きな値になる前に、設計段階で複雑性を下げるようなガイドラインとして、Cyclomatic Numberを使えないのか？というのが懐疑派のもう1つの論点です。

　Cyclomatic Numberは、すでに出来上がったものに適用するメトリクスであり、いわゆる「metrics-after-the-fact」です。例えば、「来年、社内に開発支援ツールを導入したい。その場合、ツールの複数の候補から、一番よいものを選ぶ」という状況では使えます。しかし、開発している最中に、どうすれば品質や生産性を上げ、スケジュールを守れるかのガイドラインにはなり得ません。野球の試合の翌日、評論家がいろいろなデータで勝因・敗因分析をするには適していますが、監督が試合の最中に、勝つための戦略を選ぶデータにはなりません。現場のソフトウェア技術者が求めているのは、「ソフトウェアを開発している最中に、どうすれば、品質、コスト、スケジュールを守れるかのガイドライン」であり、いわゆる「metrics-before-the-fact」なのです。

7．信奉派のいい分

　懐疑派の上記の2つの「いいがかり（？）」に対するCyclomatic Number信奉派の反論は、次のものでした。「Cyclomatic Numberは、『Empiricalな法則（経験則）』であり、結果的に役に立つのなら、どんどん使えばよい。特に、ソフトウェア工学は、経験則の集合である。理論的な証明は、後からついてくる。工学はそのようにして進歩してきた」。この反論には不思議な力強さと説得力があります。

　また、「作ってから、Cyclomatic Numberを計測し、よくない値が出たら作り直すのか？」という懐疑派の反論に関してですが、かつて、筆者はある学会のランチで、McCabeの隣に座ったことがあり、そのとき、この疑問を直接本人にぶつけました。McCabeのいい分は、「新規開発は1度だけだが、保守は何度も何度も実施する。保守のときにCyclomatic Numberを計測し、複雑なものなら、注意して保守を実施すればよい」という非常に巧妙なものでした。McCabeはその当時、Cyclomatic Numberを引っ下げ、ソフトウェア開発コンサルタントとしてアメリカ中を飛び回っており、聞かれそうな問題に対して、キチンと理論武装していたのです。

　このように、人類初のソフトウェア・メトリクスをめぐって、信奉派と懐疑派が正面からぶつかり、ソフトウェア工学の分野は熱い論争が勃発しました。（次回に続く）

【筆者紹介】

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

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

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