フローチャート、失伝の奥義

目次

AI によるコード補助が当たり前となった現代では、誰かがノートを取り出して問題を解くためのアルゴリズムや計画をスケッチする姿は、ほとんど見かけなくなりました。 かつてフローチャート作成は、解決策を視覚化するための基本的な方法の一つでした！確かに時間はかかりますが、長い目で見ればバグの少ない解決策を生み出すので、もしかしたら、今こそ改めて取り組む価値があるのかもしれません。

以下は、1983 年に出版された「Programming the 8086/8088（著：James W. Coffron）」からの抜粋です。その洞察は私のものではなく、当時、人々が冷蔵庫のように大きな IBM PC で、 古き良きアセンブリを使いながら、メモリをいじりつつロジックを探っていた時代のものです。

なんと時代が変わったことでしょう…。

フローチャート作成

フローチャートとは、アルゴリズムを記号で表現したものであり、通常は四角形やひし形のシーケンスで表されます。フローチャートでは、四角形はコマンド（または実行可能な文）を表し、ひし形は「情報 X が真なら A を実行し、そうでなければ B を実行する」といったテストを表します。

図 1.1 はフローチャートの例を示しています。フローチャート作成は、アルゴリズムの仕様を定めた後、実際にコーディングする前の中間ステップとして強く推奨されます。驚くべきことに、プログラミング人口の 10% ほどは、フローチャートを準備しなくてもプログラムを成功裏に書けると言われています。

しかし残念ながら、90% の人が自分はその 10% に属していると信じているのです。その結果、平均して 80% のプログラムは最初の実行で失敗します。（これらの数値は正確なものではありません。）要するに、多くの初心者プログラマーはフローチャートを描く必要性をほとんど感じていないのです。フローチャート作成を無視すると、プログラムに誤りが生じやすくなり、結局はテストと修正（デバッグ作業）に長い時間を費やすことになります。

Programming the 8086/8088（James W. Coffron 著）より引用した図

だからこそ、フローチャート作成という規律は、すべてのケースで強く推奨されます。フローチャート作成には、コーディング前に少し余分な時間が必要ですが、
その結果として短時間で正しく動作する明快なプログラムを得ることができます。この手順を十分に理解すると、一部のプログラマーは紙を使わずに頭の中だけで行うことも可能です。しかし、その場合、フローチャートにより提供されるドキュメントがないため、他人には理解しにくいプログラムになりがちです。
そのため、10 行や 15 行を超えるプログラムでは、フローチャートを厳格に活用することが、今でも普遍的に推奨されています。

この習慣は、もはや堅牢で動くコードを出荷するために絶対必要ではないかもしれません。しかし、良い解決策がまったく思いつかないときに、フローチャート作成という古き良きツールは今でも役立つかもしれません。