フローチャートといっても幾つか種類があるらしいが、プログラミングにおけるフローチャートの話だ。あの、アルゴリズムの教科書か何かに出てくるような、JISで記号が定められているアレ。
フローチャートの起源はどこだろうか？ 英語版Wikipediaのフローチャートの項によると、プログラムの設計にてフローチャートを使い始めたのはハーマン・ハイネ・ゴールドスタインとフォン・ノイマンだ。1947の非公開レポート "Planning and coding of problems for an electronic computing instrument" にオリジナルのフローチャートが載っているようだ*1。
『人月の神話』の第15章にフローチャートに関する記述があるのだが、そこで挙げられている参考文献としてもこのレポートが提示されている。
時を1947に戻して……
さて、1947年である。
当時のプログラミング言語は何だったろうか？ 恐らく機械語か、せいぜいアセンブラだろう。世界初の高水準プログラミング言語FORTRANはドラフト仕様の作成が1954年、マニュアルのリリースが1956年、コンパイラのリリースが1957年だ。高水準言語なんて代物はまだ影も形も無かった。
高水準言語が存在しない当時に誕生したフローチャートはどのようなものだったか？ 『人月の神話』にはこう書いてある。
H・H・ゴールドスタインとJ・フォン・ノイマンによって発表されたときには（文献1）、小さな箱やその中の内容があたかも高水準言語として機能し、不可解な機械語ステートメントを意味のあるまとまりにしたものだった。
おそらく今日でも目にする、高水準言語に直接置き換えてしまえる程度の内容だったのだろう。しかしそれでも当時としては画期的なツールだったようだ。機械語やアセンブラの時代において、高水準言語相当の役割を担っていた（少なくとも、高水準言語相当の役割を担う目的で生み出された）のだから当然だろう。
FORTRANが登場した1957年頃になると……
しかし1957年頃になると、フローチャートの有用性は揺らぎ始めたようだ。APLの創案者であるケネス・ユージン・アイバーソンは、少なくとも高水準言語相当の内容のフローチャートに関して1957年の時点で有用性を疑っていたようだ。これまた『人月の神話』より、先ほどの引用箇所の続き。
アイバーソンが早い時点で気づいたように（文献2）、系統立った高水準言語ではそうしたまとめがすでになされており、それぞれの箱にはステートメントが入る（図15・2）。そこでもう箱自体、下書き段階での退屈で場所ふさぎな用途以外の何ものでもなく、削除してしまった方がよい。
「文献2」というのは「1957年の私信より。」となっている。この時期はアイバーソンがAPLの元となる記法を創案した頃なので、FORTRANの誕生は直接的な関係があるのかどうかは微妙な所だろう。
この引用箇所のどこまでがアイバーソンの主張した内容なのか不明ではあるが、仮に前段のみだったとしても、アイバーソンは「詳細に記述したフローチャートの内容は、そのまま高水準言語で置き換えてしまえる」といったようなことを考えていたと言える。
そして『人月の神話』が出版された1975年は……
1975年の『人月の神話』では、高水準言語相当の役割を果たす類のフローチャートに関しては明確に否定している。
しかし、詳細で逐一記述したフローチャートは時代遅れの厄介物であり、アルゴリズムの考え方を初心者に手ほどきする場合に適しているだけである。
だから、リストに矢印を書き込むことにして、フローチャートはすっかりやめてしまった方がよいだろう。
とはいえ、フローチャートそのものを否定している訳ではなさそうだ。
現実のプログラムに関する1ページのフローチャートは、本質的にプログラム構造および局面または段階を示した図になる。その点に関しては非常に便利なものだ。図15・1は、そういうサブプログラム構造図を示している。
当然のことながら、子のような構造図は苦労して作り上げられたANSIのフローチャート基準に従うことも、それを必要とすることもない。箱形、コネクタ、番号付けなどに関する規則はすべて、詳細なフローチャートを理解しやすくするためにだけ必要なのだ。
つまり今日でもアルゴリズムの教科書で目にするような詳細なフローチャートは（初心者の学習用を除いて）不要だが、プログラムやサブプログラムの全体を俯瞰するような1ページ程度のフローチャートには有用性がある、という主張のようだ。
2011年のフローチャートに関する私見
ここからは私見。
id:eel3:20090713:1247412910 でも書いたように、使用するプログラミング言語よりも高水準な内容なら、2011年でも使えなくはないだろう。それこそ『人月の神話』にもあるような、プログラム／サブプログラム全体を1ページ程度で俯瞰するような類のフローチャートだ。
ただフローチャートは基本的に「手順を記述する」という側面が大きいツールなので、その辺りの特性が足を引っぱることがあり得る。
例えば我々が構築するシステムは1975年当時よりも巨大になっている訳で、そうなってくると「手順」以外を記述する方法も重要になってくる。その良い例がUMLで、あれは複数の表記法で構成されている。
また我々の使用するプログラミング言語も、今ではオブジェクト指向プログラミング言語だったり、手続き型といいつつも宣言型プログラミングのパラダイムから輸入した機能があったりする。つまり手続き型以外のパラダイムが徐々に身近になりつつある訳で、フローチャートの「手順」という特性だけでは荷が重いと思う。
ぶっちゃけた話、手続き型プログラミングする分にはフローチャートはまだ使えると思うが、宣言型プログラミングでフローチャートは非常に厳しいというか正直無理だろう。
