1月以上経っているから、もう書いてもよいかな。
若手プログラマー保存版！フローチャート徹底解説と作成カンニングペーパー
これは、日本ではあまり知られていないことなのだが、普段私たちがプログラミング教育で目にするフローチャートや、または「フローチャート」と聞いて思い浮かべるもの――JIS X 0121-1986の「情報処理用流れ図・プログラム網図・システム資源図記号」とかを使って手続き型のアルゴリズムを表現したようなアレは、少なくとも実務向けのツールとしては、40年ほど前にdeprecatedになっている。
フローチャート業界（！）では1975年にパラダイムシフトが起きており、それ以降に推奨される「近代的なフローチャート」は、私たちが思い浮かべるソレとは似ても似つかないものとなっている。
具体的には、例えば次のような図だ。
石を投げないで！ その前にお茶でも飲んで落ち着いて、『人月の神話【新装版】』を買うか借りるか本棚から取り出すかして「第15章 もう1つの顔」の「フローチャートの呪い」を読んで、それでも投げたければ私だけでなくフレデリック・フィリップス・ブルックス・ジュニア*1にもお投げなさい。
私たちがプログラミング教育で目にするようなフローチャート――仮にこれをフローチャート 1.0と表記し、上図のような「近代的なフローチャート」をフローチャート 2.0と表記するとしよう。
フローチャート 1.0の表現力は、手続き型の高水準言語とほぼ同等だ。
H・H・ゴールドスタインとJ・フォン・ノイマンによって発表されたときには（文献1）、小さな箱やその中の内容があたかも高水準言語として機能し、不可解な機械語ステートメントを意味のあるまとまりにしたものだった。
フローチャート 1.0の起源は、1947年の非公開レポート "Planning and coding of problems for an electronic computing instrument" になる*2。レポートの作者はハーマン・ハイネ・ゴールドスタイン*3とジョン・フォン・ノイマン*4だ。
1947年といえば、高水準言語どころかアセンブラさえ影も形もなかった時代だ。世界初の高水準プログラミング言語となるFORTRANは、ドラフト仕様の作成が1954年、マニュアルのリリースが1956年、コンパイラのリリースが1957年だ。で、おそらく世界初のアセンブラはEDSACのもので、1949年5月に稼働し始めたようだ（Wikipedia調べ）。フローチャート 1.0が歴史の表舞台に現れたのは、アセンブラ誕生の2年前だ。
このような歴史的経緯を考えると、高水準言語が無かった頃や、高水準言語がまだ普及していなかった時代には、高水準言語と同程度の表現力をもつフローチャート 1.0は有用なツールだったといえる。機械語やアセンブラでは直接書き下すことができない、一段上の抽象度でシステムを表現した、いわば「システムの設計図」の役割を担っていたのだ。
――が、しかし、逆に言えば、高水準言語全盛期である現代に、同程度の表現力しかもたないフローチャート 1.0は不要だ。わざわざフローチャート 1.0を書いたうえで高水準言語で書き直すぐらいなら、最初から高水準言語で書いてしまえばよい。これは、フローチャート 1.0だけではなく構造化チャートの類でも同じだ。
この辺りの疑念は、早い人ではFORTRAN誕生前後にすでに抱いていた。『人月の神話』の記述によれば、ケネス・ユージン・アイバーソン*5からの1957年の私信にて、フローチャート 1.0と高水準言語の表現力についての指摘がなされていたようだ。
アイバーソンが早い時点で気づいたように（文献2）、系統立った高水準言語ではそうしたまとめがすでになされており、それぞれの箱にはステートメントが入る（図15・2）。そこでもう箱自体、下書き段階での退屈で場所ふさぎな用途以外の何ものでもなく、削除してしまった方がよい。
（中略）
だから、リストに矢印を書き込むことにして、フローチャートはすっかりやめてしまった方がよいだろう。
つまるところ、高水準言語が広まったことにより、フローチャート 1.0は（実務向けのツールとしては）役目を終えたといえる。*6
ただし、「フローチャート 1.0が役目を終えた」という事実は、「フローチャートそのものが役目を終えた」ということを意味しない。なぜならば、高水準言語で短く簡潔に書くことが難しい抽象度の事象を描いたフローチャート 2.0は依然として有用だからだ。
先に挙げた図のようなフローチャート 2.0について、『人月の神話』にはこう書かれている。
現実のプログラムに関する1ページのフローチャートは、本質的にプログラム構造および局面または段階を示した図になる。その点に関しては非常に便利なものだ。図15・1は、そういうサブプログラム構造図を示している。
当然のことながら、このような構造図は苦労して作り上げられたANSIのフローチャート基準に従うことも、それを必要とすることもない。箱形、コネクタ、番号付けなどに関する規則はすべて、詳細なフローチャートを理解しやすくするためにだけ必要なのだ。
要するに、システム設計用の、抽象度の高い事象を記述するためのツールとしては、フローチャート 2.0の寿命はまだ尽きていない。また、フローチャート 2.0ではANSIやJISの記号を使う必要はない。
『人月の神話』で挙げられているプログラム構造図や、「UML版フローチャート」とも噂されるアクティビティ図は、いずれもシステムの一局面について、高水準言語では直接書き下すことのできない抽象度で表現するためのツールだ。自由度が高すぎるフローチャートに「明確な役割」と「役割に基づく制約」を設けたことで、より扱いやすいツールとなっている。それらを書く時に使用する記号はシンプルで、ANSIやJISのフローチャート用記号のような数が多くて複雑な代物ではない。
もちろん、システムのすべてをフローチャート 2.0のみで記述・設計することは難しい。しかし、それをいったらDFDや状態遷移図／状態遷移表などの他の記法だって同じだ。
構造化モデリングではイベントリスト・コンテキストダイアグラム・DFD・状態遷移図・構造図などの複数の記法を用いるし、オブジェクト指向分析・設計で用いるUMLは複数の表記法（UML 2.0で13種類）をまとめたものだ。すなわち、たった一つでシステムの全ての側面を記述・表現できるような、便利な記法は存在しない。どの記法も一長一短があるので、用途に応じて記法を使い分けよう――というのが現実解だ。
だから、フローチャート 2.0で記述できない事象について、フローチャート 2.0を責めるのはお門違いというか、そこを責めるのなら「お前それアクティビティ図でも同じ事言えんの？」と茶化される覚悟はしておいたほうがよい。
アクティビティ図でアクターの操作を記述できなくても、誰もアクティビティ図を責めないどころか、むしろ「いやいや、そこはユースケース図でいきましょうよ」となるはずだ。これがフローチャート 2.0になると、途端に「フローチャートじゃ書けないものがあるし……」という態度をとる人がいる。
そう言ってしまう前に、冷静になって、フローチャートをアクティビティ図に入れ替えて考えてみるべきなのだ。「アクティビティ図じゃ書けないものがあるし……」って、どう考えても当たり前だ（アクティビティ図で全て表現できるというのなら、UMLの残りの記法は何なのか……）。フローチャート 2.0も同じだ。
だいたい、フローチャート 2.0とUML 2.0の戦力比は1対13なのだ、記法の数的に。だから、「フローチャート 2.0の表現力はUML 2.0の13分の1ぐらい」と考えておけばよろしい。で、フローチャート 2.0で苦手なものは、別の記法で書けばよい。
フローチャート 1.0は戦力外だが、フローチャート 2.0はまだ生きている。まあ、フローチャート 2.0は、フローチャートという名前よりも「プログラム構造図」とか「UMLのアクティビティ図」とか、それぞれの方向に特化した別名のほうがしっくりくるのだが。
ともかく、フローチャート 1.0とフローチャート 2.0の区別をつけた上で冷静に議論できる人が増えることを祈るばかりである。
さて、一通り書き終えたから、状態遷移図と状態遷移表とシーケンス図の教育用サンプルでも作るとするか。
