構造化プログラミングの苦難の歴史：山浦恒央の“くみこみ”な話（22）

今回は「構造化プログラミング」の歴史について解説。その道のりを理解することは、プログラミングを正しく理解することにもつながるはずだ

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

――ソフトウェアの品質、複雑性、生産性を計測するのが「ソフトウェア・メトリクス」です。ソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」「成熟・定着期」に分割し、何を、何のために、どうやって測定するのかというソフトウェア・メトリクスの本質に迫ります。

　前回「ソフトウェアの定量的測定の甘いワナ」では、ソフトウェア・メトリクスとソフトウェア開発両方の混乱期といえる40〜50年前、どのようにソフトウェアを開発・設計してきたかについて、簡単に解説しました。

　今回は、当時勃発した「構造化プログラミング大論争」という大きな事件について述べます。いまでこそ、ソフトウェア技術者の常識である「構造化プログラミング」は、当時、中世の宗教弾圧のような激しいバッシングを受け、苦難の道を歩んだのです。

1．ソフトウェア危機

　いまから50年前、アセンブリ言語での開発が中心だったソフトウェア産業界に、COBOL、FORTRAN、PL/I、Pascalなどの高級言語が普及しはじめました。これにより、生産性、品質が飛躍的に向上しました（注1）。また、それと同時にプログラミングの需要も爆発的に増加したのですが、供給がまったく追い付きませんでした……。当然、これではソフトウェアの品質も制御できません。

※注1：高級プログラミング言語による生産性もアセンブリ言語と同様、1カ月で1000ステップ程度ですが、アセンブリ言語に比べると、高級言語はステップ当たりの効率が4〜5倍高いため、生産性も4〜5倍上昇しました。これだけ生産性が向上したのは、ソフトウェア開発史上、最初で最後。また、最初にして最後の「銀の弾丸」が高級言語です。

　生産性と品質は上がらないし、制御もできないこの現象を、当時「ソフトウェア危機（Software Crisis）」と呼びました。このソフトウェア危機を瞬時に解決する方式（一種の銀の弾丸です）として、大いに期待されたのが構造化プログラミングでした。

　構造化プログラミングは、「品質が高い」「作りやすい」「理解しやすい」「保守しやすい」プログラミングを実現することを目的にしています。いまでは、構造化プログラミングは、プログラミング作法の基本中の基本であり、プログラミング制御構造の根幹であり、ソフトウェア技術者の常識といえます。

　構造化プログラミングが確立し、ソフトウェア業界で認知されるに至るまで、以下の3つの大きな出来事があり、そのたびに業界は紛糾し、対立し、大論争が起き、大混乱したのです。

1. Böhmの数学理論
2. Dijkstraの書簡
3. Knuthの論文

2．Böhmの数学理論

　これは1966年、イタリアのソフトウェア工学の研究家であるCorrado Böhm（コラド・ベーム）が唱えたもので、どんなプログラムでも、「連結（Concatenation）」「選択（Selection）」「反復（Iteration）」の3つで表現できるという理論です（図1）。

図1　Böhmの数学理論

　当時のプログラミング言語はアセンブリ言語が中心で、やっとCOBOLやFORTRANが普及しはじめたころです。プログラミングの制御構造は、「無条件分岐文（goto statement）」が主流でした。というより、当時はいまでは当たり前の「if then else」構造など存在せず、goto文しかなかった時代でしたので、Böhmの「goto文がなくてもプログラミングはできる」「goto文を使わないプログラミングは理解しやすい」という説は、異端の理論として誰も本気にしませんでした。

　世の中を大きく変える潮流は、どんなものでもそうですが、発端はごく小さく、誰の目にもとまらないところで、ひっそりとはじまるのです。

3．Dijkstraの書簡

　1968年、OSとソフトウェア工学の両分野で巨大な業績を挙げたEdsger Dijkstra（エズガー・ダイクストラ）（注2）が、ACM（American Computing Machinery：注3）の論文誌へ「Goto Statement Considered Harmful」と題した書簡を送り付けました。

※注2：共有資源を排他制御する場合に、プロセス間で使用するセマフォの概念を提案したのもDijkstra。2002年8月6日没。

※注3：IEEEと並び、世界を代表するコンピュータ関連の学会。昔は羽振りがよかったが、いまは規模、活動範囲、重要性の点でIEEEに及ばない？

　これは、Böhmの数学理論と同じ路線をいくものですが、数学理論は「goto文がなくてもプログラミングは可能」というgoto文の消極的な否定であったのに対し、Dijkstraの書簡は「goto文はスパゲッティ構造（注4）を助長する」とし、「goto文は有害である」という衝撃的な内容でした。世の中のソフトウェア技術者に対し、「君たちは間違っている！」と正面から宣戦布告したのです。

※注4：めんが絡み合うスパゲッティのように、制御構造が複雑怪奇なプログラムを意味するソフトウェア工学用語

　当時、Böhmが数学理論で提唱した連結・選択・反復の3つの基本構造を備えた言語は存在しませんでした。構造化COBOL、構造化FORTRANなど、構造化プログラミングに準拠した言語ができたのは、構造化プログラミングが認知されてからですので、ずっと後のことです。

　ソフトウェア業界の超有名人であるDijkstraの「goto文有害説」に対し、当時のプログラマはものすごく困惑し、大混乱しました。当時の大多数の技術者の意見は、「Dijkstraがいいたいことは分かるが、現実にgoto文なしで、どのようにプログラミングすればいいのか？」でした。中には、goto文有害説に猛反対し、「goto文がないと、プログラミングは不可能だ」との説を唱える過激派も現れ、大きな論争となりました。

4．Knuthの論文

　Böhmの数学理論で小さな火がつき、Dijkstraのgoto文有害説が油を注いで燃え上がった構造化プログラミング大論争は、1974年に収束しました。このきっかけになったのが、同年、ソフトウェア業界のご意見番であるDonald Knuth（ドナルド・クヌース）が発表した論文「Structured Programming with Goto Statements」です。

　同論文の中で、Knuthは「構造化プログラミングとは、『goto文を使わないプログラミング』ではなく、書きやすく、理解しやすいプログラミングのことである」と述べ、「例えば、エラー処理のように、goto文を使う方が分かりやすい場合があり、その場合、goto文を使ってもよい」と書きました。Knuthの論文は、両派の意見を取り入れた“和集合”、あるいは町内のもめ事を長老が政治的に決着させた感がありますが、大加熱した論争はこれで一応決着しました。

　賛成派、反対派の両派が合意したのは以下の事項です。

1. 構造化プログラミングとは、書きやすく、理解しやすいプログラミングのことである。
2. 構造化プログラミングは、goto文をなるべく使用せずにプログラミングすることである。goto文の使用はエラー処理に限定し、かつ「前方goto文（後戻りするgoto文ではなく、先へ進むgoto文）」に限る。

　要するに、「部屋への出入りはドアを使い、手近な窓やベランダが開いているからといって使用しないこと。ただし、火事や地震のような非常事態の場合は、そばの窓から避難してもよい」ということです。

　その後、いろいろな研究者がこのトピックスを取り上げました。現代の構造化プログラミングの定義として一般的なのは以下のものです。

ソースコードが、「連結」「選択」「反復」「呼び出し（Invocation）」の4つの構造を持ったブロックだけで構成され、各ブロックの「入り口（Entry）」と「出口（Exit）」が1つしかない場合、構造化プログラミングという。

　これまでアセンブリ言語を使ったことがなく、現在の高級プログラミング言語しか知らない若年層のソフトウェア開発技術者は、構造化プログラミング論争の意味が理解できないことでしょう。なぜなら、現在の高級プログラミング言語を使うこと＝構造化プログラミングだからです。

　言語仕様として、構造化プログラミングの“縛り”が入り、当たり前のことが当たり前になるまで、10年近く大論争が続いたのです。if文やwhile文を見たとき、「職人芸のプログラミング」から「書きやすく理解しやすいプログラミング」に進化するまで、苦難の道のりがあったことを、少しだけ思い出してもらえれば幸いです。

5．それからの構造化プログラミング

　構造化プログラミング問題が決着し、ソフトウェア業界が合意して長い年月がたちましたが、書きやすく理解しやすいプログラミングを求める旅はまだ続いています。

　構造化プログラミングは、「書きやすく理解しやすい制御構造」を定めたものであり、データ構造に関しては何の制限もなく、一種の無法地帯といえます。

　「制御＋データ＝プログラミング」の名言どおり、コントロールの構造化だけでは不十分。データの構造化も必要です。そして、「理解しやすいデータ構造」を目指したのが、新しい潮流である「オブジェクト指向プログラミング」です。

　この構造化プログラミングが確立した歴史や、オブジェクト指向プログラミングに至る道のりが分かっていないと、オブジェクト指向によるプログラミングを正しく理解できず、オブジェクト指向の長所を生かしたプログラミングにはなりません。この話は、非常に面白いトピックを含んでいるのですが、誌面が尽きましたので、別の機会に譲ることにします。（次回に続く）

【 筆者紹介 】

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

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

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