世の中、ネタとして取り上げると時として大変なことになる話題が幾つもあって、フローチャートも微妙にその1つだと思うのだけど、あえて取り上げてみようと思った。思ったのだけど面倒なので「微妙にフローチャート的なもの」の話にしようと思う。
その前に、フローチャートは世の中で色んな使われ方をしているようだけど、ここでは次のような使い方に主眼を置いていることに注意すること。
- 教育用途ではなく、業務で使用されるケース。
- 但し業務で公式／正式な資料として作成するものではない。
- 開発者が個人的に使う。
- 基本的に他人に見せない。但しブリーフィング等で説明する際に補助的に使うことがある。
私の周囲ではフローチャートそのものを使うことはないのだけど、何となく似たようなものを目にすることがある。それは私のメモ書き用ノートの中だ。ちょっと込み入った処理を実装する前に非常に大雑把な処理フローを書くことがある。正直なところ、見た目は「箇条書き＋矢印」で構成されていて、全然フローチャートらしくないのだけど、処理の流れを矢印を用いて表現している点では間違いなくフローチャート的だと思うので、フローチャートの変種だと言い張ることにする。
「非常に大雑把な処理フロー」と書いたけど、かなり短いフローチャートでもC言語で実装すると数十〜数百行以上コードになったりする程度に大雑把だ。このフローチャートは殆ど順次処理で、時々分岐が入るけどループは珍しい部類になる。異常系のことなど含まれてすらいないことが多々ある。数百行ともなると確実に関数分割されているし、時には小さなモジュールもどきまで実装されていることもあるのだけど、フローチャート上ではそんなことは分からない。
ちょっと例を挙げてみよう。といってもお仕事関連のことは書けないので、少々古くなるけど、その昔コンソールアプリでexprライクな超簡易電卓もどきを書いた時のメモを晒してみる。現物はC言語でコメント等を含めて1000行ぐらいになった。私のコードはコメントの量が多いと思うので、世間一般的な書き方にするともう少し行数が減ると思う。
初期化する ↓ 入力データから演算式を生成する ↓ 演算式を評価する ↓ 評価結果を出力する ↓ 後片付け
当時、雑誌か何かでコンパイラ開発の入門記事を読んでいた影響で、わざわざ「演算式」という抽象的な表現を持ち出している。もっとも力量不足で構文木を作るまでには至らなかった。
ところで何でこんなものを持ち出したかというと、最近『人月の神話』を読み返していて、フローチャートが現れた時代には主にアセンブラが使われていたという記述に気づいたからだ。
偏見かもしれないけど、私が考える「世間一般におけるフローチャートのイメージ」は、情報処理やアルゴリズムの教科書にあるような、ともすると分岐条件に「J≧5」なんて書かれてたりするやつだ。それこそC言語などでそのまま書き下せそうなやつ。
高水準言語が主流な現在では、そのようなフローチャートは（初級者以外には）意味が無い。高水準言語でそのまま書き下せるのなら、フローチャートを経由せずに直接コーディングしてしまえば済む話だ。でもアセンブラを使っている場合はどうだろうか？ 私は本物のアセンブラの経験がなくて基本情報技術者試験のCASL IIを触ったことしかないのだけど、例え高水準言語でそのまま書き下せてしまう内容でも、アセンブラからみたら抽象度の高い世界だと思う。高水準言語で書き下せる程度のフローチャートとアセンブラの間にあるレベル差は、高水準言語とアセンブラの間のレベル差と同じだ。アセンブラで書くなら、その程度のフローチャートでも十分に使い物になると思う。
つまり現代においてフローチャートが役に立たないと言われる理由の一つは、高水準言語とフローチャートで表現している内容がほぼ同じレベルである、という点だと思うのだ。なら、開発で使用する高水準言語で直接書き下せない程度に抽象度の高いフローチャートなら使い物になるかもしれない。開発対象や使用言語にもよるけど、組込み関係の仕事では処理フローを気にすることがそれなりにあって、「細かいところは置いておくとして、大まかにこんな流れで」というレベルで手順を整理しておく必要がある。というか私の場合、整理して書き留めておかないと細かい実装をしているうちに忘れてしまう。
「抽象度の高いフローチャート」は基本的に高水準言語で直接書き下せない。実装の際にはフローチャートに隠されている細部を考えることになる。その結果、フローチャートと実装は必ずしも1対1で対応するとは限らないというか、対応する方が珍しくなる。何しろ実装では色々な工夫がなされるからだ*1。フローチャートと実装が比較的近い形で対応するのは、フローチャートの内容が段階的詳細化における上位層（ドライバ）の中身になった場合ぐらいだろう。
もっともフローチャートは手順しか表現できないので、常に有用というわけではない。抽象度が上がると処理フロー以外の部分の重要性が増すので、フローチャートの活躍の場は減って他の表現手法（DFDなりUMLなり）が使用される傾向にあると思う。それにRubyのように言語自体の抽象度が高いと、活躍の場は更に減りそうだ。
ちなみに、教育用途として初歩の初歩で世間一般的なイメージのフローチャートを使うのは有りだと考えている。プログラミングの教育はボトムアップ式で、単純な制御構文を扱うところから始まることが多いけど、何しろプログラマ未満の人は往々にしてそういった細かい世界で躓くレベルだから（私もそうだった）。但しそのフローチャートから卒業できないとヤバイとは思う。
*1:関数ポインタの配列でイベントドリブンっぽくするとか、状態遷移とか。
