この項目では、ダイクストラらによるソフトウェア工学的手法としての「構造化プログラミング」について説明しています。goto文論争については「goto文」をご覧ください。

構造化プログラミング（こうぞうかプログラミング｜英: structured programming）は、コンピュータ・プログラムに構造を導入して記述をより簡素明快にし、ソフトウェアの品質の向上と開発の効率化を目指したコンピュータ・プログラミング技術である。

今日の「構造化プログラミング」は複数の誤解を招く言葉となっており、本来の定義とソフトウェア技術者を含む世間の用法の間に差異が生じている。この様な事情から構造化プログラミングには以下の3つの解釈が存在している。
1969年に計算機科学者のダイクストラらによって提唱され反響を呼んだソフトウェア工学理論[1]。ここで構造化プログラミング（structured programming）の名称が初めて使われ、広く知られるようになった。

1966年に計算機科学者のベームらが発表した構造化定理（structured program theorem）によるプログラミング理論。

1958年に公開された「ALGOL 58」を先駆けとする構造化プログラミング言語を用いた開発環境。名称が確立される以前からソフトウェア技術者の間では漠然と実践されていた。

今日の構造化プログラミングに対する一般的な認識は、(2)と(3)が示す「順次、選択、反復といった制御フローをブロック単位で表現し、それらを直列または入れ子状に配置する事でプログラムの構造化を実現する」という事になっている。

しかし、(1)のダイクストラが提唱した理論が本来の意味での構造化プログラミングであり、本項では(1)について説明する。(2)と(3)については「構造化定理」が該当記事となる。
目次

1 概要

2 歴史

3 誤解

3.1 Millsによるgoto-lessプログラミング

3.2 「三つの構造化文」

3.2.1 事実

3.2.2 構造化定理と誤解



4 ダイクストラによるプログラムの正しさの検証手法

4.1 プログラムの正しさに関する様々な意見


5 脚注

5.1 注釈

5.2 出典


6 参考文献

7 関連項目

7.1 関連人物


8 外部リンク

概要

ダイクストラは1969年のワーキングペーパー[1]で構造化プログラミングについて以下のように語っている。
良く構造化されたプログラム（well-structured programs）：プログラムのサイズが大きくなっても正しさを証明できる構造にすること。構造化定理とは無関係。

段階的抽象化（step-wise abstraction）：プログラムの意味のある部分をくくり出して抽象化文にすること。抽象化文は現在で言えば、関数やメソッドに相当する。これによって、プログラムの可読性が向上する。ダイクストラは段階的抽象化をするプログラムは構造化定理と同様の制御構造を使うべきと述べているが、このワーキングペーパーでそのような制御構造に触れているのはここだけであり、構造化プログラミングが構造化定理とあまり関係ないことがわかる。

段階的詳細化（step-wise refinement）：1969年のワーキングペーパーにこの言葉は登場しないが、段階的抽象化の説明の最後に「抽象的プログラムから始めるのもこの手法の1つの側面」と書いており、段階的詳細化のことに他ならない。段階的抽象化とは逆に抽象的な設計から始めて詳細化していくことによって設計を容易にする。

抽象データとその上で動作する抽象化文の共同詳細化（joint refinement）：現在のオブジェクト指向のクラスに近い考えである。抽象データ＝メンバ変数、抽象化文＝メソッドと言うことである。抽象データとその上で動作する抽象文を組み合わせて詳細にしていくのである。

プログラムの階層化：ダイクストラは共同詳細化の結果（オブジェクト指向のクラスに似たもの）を真珠に例えて、プログラムの階層化を説明した。ダイクストラは、階層化されたプログラムを真珠のネックレスに例えた。真珠のネックレスは真珠を交換して、変更を容易にしたり、真珠の再利用も可能である。

以上のように構造化定理とはあまり関係のないことであるが、現在でも構造化プログラミングと構造化定理は混同されている。
歴史

コンピュータが実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった[2][注釈 1]。遡れば、コンピュータ・プログラムのデバッグという仕事の大変さについて1949年に感じた、ということを自伝に残しているウィルクスが、その後に、アラン・チューリングが「大規模ルーチンの検証」といったことを話していた、と書いている。

1960年代ではプログラムはフローチャートによる設計が広く採用されており、goto文も広く使われていた[3][4]。その一方でgoto文の多用はプログラムの質を下げるという性質や、多くのプログラムはgotoを使わずに記述できるという性質が経験則として知られていた。例えば1959年のハインツ・ツェマネクによるgoto文への疑問[5]。1960年から始まるD. V. Schorreによるインデントで制御の流れを表すアウトライン形式のプログラム記述、1963年のPeter Naurのgo to文に隠れたfor文の指摘、その翌年のGeorge Forsytheによるアルゴリズムからのgo to文除去、1965年のダイクストラや1966年のPeter Landinによるgo to文なしプログラミングの実験に関する発表が挙げられる[3]。

そして1966年コラド・ベームとジュゼッペ・ヤコピーニによって、任意のフローチャートは基本フローチャートの組み合わせによる等価なフローチャートに変換できるという定理が示された[6]。この定理は後に、IBMの研究員ハーラン・ミルズ（英語版）らによって構造化定理(Structure Theorem)として再定義された[7][注釈 2]。なお前述のように、これを構造化プログラミングと結びつける論者は大変多いが誤解である。

1968年にダイクストラは“Go To Statement Considered Harmful”[5][8]という記事を発表し、大きな反響を呼んだ[9][10]。この騒ぎがきっかけで構造化プログラミングを知った者が多いことを示して、クヌースは「go to文を用いた構造化プログラミング」の中で「go to 文除去の話の二番目の場面は，多くの人たちが第一幕だと思っている事実である．」とこの騒動を指して評している。1980年代にマイコンが普及した際に、そのBASICにおいて（由来などの詳細は全く曖昧なまま）「GOTO命令を使わないのが『構造化プログラミング』」などと言われたりしたなど、騒動の影響は後年まで残った。[注釈 3]

1968年、NATO主催のソフトウェア工学会議[11]でソフトウェア危機が共通認識となったとき、ダイクストラは時が来たと考えた[12]。当時、ダイクストラを含むソフトウェア危機の存在に気づいていた人々は、プログラミング活動に対する変化の到来を予測していた。しかしこの転換期が訪れるまで、世間一般はそれを受け入れる準備ができていなかった[12]。

翌1969年、再び開催されたNATOのソフトウェア工学会議において、ダイクストラは「構造化プログラミング(Structured Programming)」という語を提唱した[1][注釈 4]。ダイクストラはこの提唱において goto 文に一言触れただけで[注釈 5]、プログラムサイズが大きくなったとしても正しさを証明できる良く構造化されたプログラム(well-structured programs)、大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)、抽象データとその操作の抽象文の共同詳細化(joint refinement)、そして真珠のネックレスに例えたプログラムの階層化について述べた。

ダイクストラは、構造化プログラミングという言葉を作ったとき2つの失敗をしたと述べた。商標登録しなかったことと定義しなかったことである[13][12]。そのため、構造化プログラミングは標語（スローガン）となってしまい、IBMのプログラミング規範をまとめたIPT(Improved Programming Technologies)によって当時のプログラマに広く流布した[14][15]。