フローチャートの書き方という話になると、その記号の丸暗記の話に置き換わってしまうことが多い。しかし、フローチャートの記号など、必要があれば、いくらでも参照できるのだ。また実務で必要に迫られて使い出せば、自然に頭に入ってくる。フローチャートの記号などを金科玉条で、何も考えずに暗記しようとする授業が、情報系の学校、IT系の学校で行われているとすれば、それは実に貧弱な、悲しい授業といういことになる。フローチャートの書き方で大切なのは、記号の暗記ではなく、事象なり対象の構造あるいは遷移を洞察する力、自分...

何のためにフローチャートを書くのだろうか。SE 、PGの世界でいえば、問題の対象を論理的な構造、流れとして表記して、システム、プログラム、コードに落とし込むためであることが多い。
対象とする領域の業務のアナライズ段階で使われることもあるし、詳細設計以降、プログラムの直前段階で、特に条件分岐が複雑だと、PGに誤解を与えないように、防御的に使われることもある。なかなか詳細設計で、すべてにフローチャートを記述することを求める潤沢な予算のあるプロジェクト、案件は、珍しくなっていると思う。
昨今のOO（O...

白状と懺悔をしておく。OO開発、UMLが日本でも使われだしたころに飛びつき、社内で「布教」をした一人であるｗフローチャートじゃなくてさ、どうしてもとなれば、UMLでアクティビティ図でいいじゃんとしていた。まあ、それはそれでフロチャート、手続き型言語で構造化プログラミングの経験者ばかりの時は、それで、そこそこ良かったんだ。でも数年経過すると状況が変わった。最初からOO言語の世代が来てからだ。なんかメソッドの中の記述が不自然だよなぁ・・・話が通らないなぁ・・・ｗなんでだ？JAVAしか知りません・・・...

さて、フローチャートの書き方を学ぶことは無意味かどうか、もう結論は出ている。学生なら学生のうちにやっておけ・・である。実務に入ったら、フローチャートを目にすることはほとんどない。フローチャートを納品物として書けといわれるケースも少ないだろう。だが、それは、PGなら頭の中で、自分で書けて当然でしょ・・・の世界である。できるのは、学生の間だけかもしれないぞ。
まあ、俺でも、時々難しいメソッド、関数を書こうとするとき、その場で手書きで、フローチャートモドキを、さっさと書いてからコードに落とすことがある...