　ミス・ユニバースの選定から自動車の性能、プロ野球選手の能力、ワインの味に至るまで、2つ以上のモノがあると、とにかく比較・評価して順位を付けたがるのが人間の癖です。その場合、「まあまあよい」「そこそこおいしい」「大体OK」のように、曖昧（あいまい）で主観的な表現をするのではなく、無理やりにでも具体的な数値で対象物を表現しようとします。

　ソフトウェアも例外ではありません。ソフトウェアは「工学的生産物」ですので、数値による評価は必須と思われています。でも現実に、キチンと数値を測定している正直で親孝行なプログラマはほとんどいません。また、ソフトウェア開発では開発プロセスを具体的な数値で測定し、その結果を実作業に反映させることが超重要ですが、そんな当たり前のことを実施しているソフトウェア技術者や組織はほとんどありません。それどころか、「ソフトウェアの何をどのように測定すればいいのか」という正解は、いまだに誰も分かっていないのです。

　なぜ、ソフトウェアで測定しないのか（正確には、「昔は測定していたのに、なぜ、いまではしなくなったのか」）？ソフトウェア測定の何がそんなに難しいのか？測定にどんな落とし穴があるのか？これが今回のテーマです。

1．ソフトウェア・メトリクスの苦難の道程

　1980～90年代にかけて、「ソフトウェア・メトリクス」という言葉が世界的に大流行しました。ソフトウェア・メトリクスとは文字通り、「ソフトウェアを定量的に測定すること」です。このように記すと、必ずといっていいほど「何をどう測定するの？」と質問が飛んできます。ソフトウェア・メトリクスの歴史は、「1．何を測定するのか？」「2．どのように測定するのか？」「3．どう使うのか？」を模索してきた歴史といえます。いまでも、ヘドロが舞う視界0メートルの海底に立ち、手探りでこの3つを探している状態です。

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

　図1にソフトウェア・メトリクスの「栄光と没落の歴史」、あるいは、「苦難の道程」を示します（この図は、わたしが独断で一方的に作成したものであり、一般に認知されているものではありません）。ソフトウェア・メトリクスの歴史を見れば、“なぜ、ソフトウェア・メトリクスが難しいのか”“どのようにすればソフトウェアを測定でき、その結果を生かせるのか”が見えてくると思います。

2．ソフトウェア・メトリクスの歴史：混乱期（1968～75年）

　江戸時代末期、民衆の怒りや不満、社会の疲弊、海外からの圧力が大混乱と激動を呼び、明治維新という「革命」につながりました。これと同じで、ソフトウェア開発が大混乱し、ソフトウェア・メトリクスが出現するきかっけをつくったのがこの「混乱期」です。

　なぜ、1968～75年までなのか？

　まずは、最終年の1975年について。翌1976年、世界で初めてソフトウェア・メトリクスの論文が権威ある学会論文誌に掲載されました。1976年は、「メトリクス誕生の年」です。「革命前夜」の意味で、混乱期の終了年を1975年としました。

　そして、開始年の1968年ですが、これには大きな意味があります。この年は、公式ドキュメントにはじめて「ソフトウェア工学（Software Engineering）」という言葉が載った記念すべき年なのです。同年、ローマで北大西洋条約機構（NATO）の会議が開催され、その席上で“ソフトウェア工学”という発言があり、議事録に載りました。

　エンジニアリングという言葉は、日本語では「工学」と訳す場合がほとんどですが、実際の英語の意味は、そんなにシリアスで重いものではありません。「モノ作り」とか「製造」程度のごく軽いものです（海外のエンジニアや研究者と話していると、彼らのいう「Software Engineering」の約90％は、“ソフトウェア開発”の意味で使っています）。従って、ローマ会議での“Software Engineering”の発言も、高品質ソフトウェアを早く低コストで生産する“ソフトウェア工学”を意識したものではなく、単に、「ソフトウェアを作ること」を意味しています。

　当時のソフトウェア開発はどんな状態だったのか？アポロ11号で3人の宇宙飛行士が月面着陸したのが1969年です。もちろん、宇宙船の運行制御はコンピュータでコントロールしていました。また、世界初の仮想記憶をベースにしたメインフレーム用のOS「OS/360」が開発されたのもこのころです（開発期間：1963～66年。開発総工数は5000人年で、人類史上、最初で最後の超巨大プロジェクトといわれています）。

　このように、いまから40年以上前もプログラムを開発していました。当時のソフトウェア開発は一口でいえば「職人芸」の世界です。高級言語として、COBOLやFORTRANが出現したものの、やはり主流は読みにくく書きにくいアセンブリ言語でした。CPUの処理能力は低いし、メモリは超高価なリソースなのでごくわずかしか実装されていません（現代の組み込み系ソフトウェアも、メインフレームやPC系のアプリケーションに比べると、メモリの実装量は少なく、CPUの処理能力は低いので、当時と同じ状況といえます）。

　当時のプログラマは、メモリ占有量を減らし、実行ステップ数も少なくするため、芸術的なプログラミングをしました。読みやすさ、作りやすさよりも、小さくて速いソフトウェアを作ろうとしたのです（現代の組み込み系ソフトウェア開発でも、同じです）。その結果、理解しにくく作りにくいソフトウェアが氾濫（はんらん）することになりました（いまの組み込み系ソフトウェア開発でも同様であり、組み込み系でのプログラム開発の方式は40年前に逆戻りしているといえます）。

　もちろん、そんなことではソフトウェア開発の生産性は上がりません。工程、品質、コストという「工学の3大要素」も制御できません。コンピュータに注目が集まり、ソフトウェアに対する需要が爆発的に増えた時代でしたが、マーケットの要求に応えるソフトウェアが、質、量ともに作ることができなかったのです。これが世にいう「ソフトウェア危機（Software Crisis）」です。

　「いまのプログラム開発の方法は間違っている！職人芸的なプログラム開発から脱却して、工業的にソフトウェアを作らねばならない……」。いまはやりの坂本龍馬みたいに危機感と燃える志を持ったソフトウェア技術者があちこちに現れたのがこの時代です。いまでは誰でも知っている「構造化プログラミング」という言葉が誕生したのもこのころです。

　以上が、ソフトウェア開発における「夜明け前」の概況です。次回は、同じく夜明け前に起きた「構造化プログラミング大論争」について解説します。（次回に続く）

【筆者紹介】

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

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

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