新人技術者のためのロジカル・シンキング入門（3） ―― 「必要とされる設計書」の作り方

【4】フローチャートは解決策になるか？

　ここまで，ブロック図を用いた設計の概要を説明してきました．次に，「設計書」というとたいていの人が思い浮かべるであろうフローチャートについて考えてみることにしましょう（図7）．フローチャートは，冒頭のCさんのような状況に置かれた人に解決策を与えてくれるのでしょうか？

図7　フローチャートの特徴
設計書というとフローチャートを思い浮かべる人は多いが，利点と欠点を見極めて使う必要がある．本稿の結論を述べると，狭い範囲の論理を検討するツールとしての利用にとどめるのが無難．上・中流のソフトウェア設計の工程には向かないと筆者は考えている

　まず試しに，「1から10までの整数を順番に足すプログラム」というものを想定して，フローチャートを作成してみることにしましょう．

　フローチャートは図8のようなものになるでしょう．「n」に答えの「55」が入るようになっていれば正解です．ここで注意していただきたいのは，フローチャートを使うことによって整理されたプログラム上の情報は何かということです．図を見るとそれは，処理の順序と分岐の条件だけです．

図8　1から10までの足し算のフロー
処理の順序と分岐の条件しか整理できていないのに注目．この程度のアルゴリズムの実装にフローチャートを書き起こすことは実務ではまずないが，整理できる事がらはどんなアルゴリズムに適用しても順序と分岐のみ

　実際，商用プログラムのコーディングでここまで単純なものを書かされることは，まずありません．しかし，どんなに複雑なプログラムであっても，フローチャートが整理してくれる情報の内容が変わるわけではありません．つまり，フローチャートはどのようなプログラムに適用しても，処理の順序と分岐の条件を整理してくれるだけなのです．

　ですから，図8で表せなかった情報は，もっと大きなプログラムの場合にも整理できないでしょう．例えば，ブロック図で重要な役割を果たしていた機能ブロック間のインターフェースの整理に，フローチャートは向きません．フローチャートは，機能ブロックの間のデータの流れを整理することができないからです．

　必然的にフローチャートは，狭い範囲の処理を整理するときにのみ使われることになります．複数の機能ブロックの間の関係を整理して，機能分けとその間の信号線を整理するという上・中流のソフトウェア設計の工程ではあまり使われません．

　たいていの人にとっては，フローチャートは新人研修のときに書かされたきりで，実際の開発で目にすることは少ないと思います．その理由は，フローチャートの利点を生かせる機会があまりないからだと筆者は思います．

● フローチャート作成にはC記述と同等の時間がかかる

　また，フローチャートには，記述するのにとても時間がかかるという欠点もあります．

　プロフェッショナルとしてしごとをしているたいていのプログラマなら，図8のフローチャートを描くのと同じくらいの時間で，「1から10までの整数を順番に足すプログラム」をC言語などで記述できることでしょう．ということは，例えば1,000ステップのプログラムのフローチャートを描くには，それを書いたのと同じくらいの時間を要すると考えたほうがよさそうです．そこまでしたところで，フローチャートが整理してくれるのは，処理の順序と分岐だけです．商用開発で作られるような規模のプログラムの全ソース・コードに対して，「詳細なフローチャートを書いてからプログラムを起こす」というのはかなり無理があると思います．