フローチャートとFizzBuzz問題

先の低水準言語での研修 - novtan別館関連エントリに今や懐かしき、FizzBuzz問題の紹介記事が上げられていた。どういう基準だかわからないけど、面白い。
プログラマ職に応募してくる人間のほとんどが書けない「Fizz-Buzz問題」：濃縮還元オレンジニュース｜gihyo.jp … 技術評論社
さて、研修の話だけど、低水準言語ってだけではなく、きちんとフローチャートを書かせて処理の流れを整理し、あるいは効率が悪くないかを考えさせる、ということも重要だと思っています。
これが意外と真っ直ぐ書けないものなんですよ。やろうとしている処理はごく単純なものです。でも言語を想定して書いちゃうから変なフローチャートになる。確かに「レジスタに値をロード」とか考えながら書かなきゃならないのだけど、それ以前に全体の大きなフローが見えていない。FizzBuzzでいうと、一番大きなくくりである「１から１００まで処理する」の部分を書くことなしにいきなり「３の倍数のときはどうするんだっけ」ってことばかり考えているようなものです。そんな順番で処理を考えていってもろくなロジックにはなりません。
でっかい分岐が出来て、処理の最後の方で合流するとかはやっちゃダメだよっていってもその理由を考えようとしてもくれなかったりします。まあ、メモリも潤沢にある環境でプログラムを考えるとどうでもいいことなのかもしれないけれども、そういう小さな積み重ねが色々な問題に発展するし、業務の一番表面的な、つまり仕様どおり書いていればいいところを作れるようにはなりますが、仕掛けの部分なんて作らせられません。
かつて、COBOLが登場したときの売り文句は「これで仕様書さえあればユーザーがプログラムすることが出来る。プログラマは要らない」と言われたものです。その言葉が事実に反したことはこれまでの歴史が証明していますが、実は真実であったともいえます。実際に業務を行うユーザーが、そんな簡単な作業に従事する必要はなく、事務作業レベルのコーダー(なぜかSEと呼ばれることも多い)が作業すればいいじゃん、という話になっただけだという…
EoDといって実装のスキルレベルを下げていくこと自体は良いことだと思うんですけど、それはあくまで一人一人が「作業員」であることを想定しているからですよね。標準化、という意味合いやプロジェクトの速度的な問題もあると思いますけれど。僕のいる会社が育てようとしている人材像は、設計・コアロジックのプログラミングがきちんとでき、それを武器にお客さんと交渉できる人たちです。全員がそうなる必要はないけど、チームとしてそうなっていなければその手の仕事にはなりません。
フローチャートも前世代の遺物的な扱いをされることが良くあります。実際、オブジェクト指向プログラムにおいて、全体の流れをフローチャートで書くのは困難です。でも、初学者に求められている能力は、まず、短い処理内(関数とかメソッドとか)での正しい処理の書き方です。FizzBuzzを実装する以前に、フローチャートが書けなかったりする人はいませんか？書けたとして、そのフローチャート、何かおかしくありませんか？
フローチャートを書いてから、コーディングしろっていってもフローチャートがおざなりになっている人や、コードをフローチャートで表現したらこうなりました、的なものを書いてくる人がやっぱり何人かいるんですよね。実際に頭の中でフローチャートが書けているからいいやって人もいますが、大抵の人は、コードを逐次的に書くイメージで思い付きをただフローに表わしていくだけです。それだとスパゲティー予備軍。「あ、ここはこれだとダメだからこっちに特殊処理を…」じゃなくて、流れがおかしいからそうしなきゃならなくなっていることに気付いて欲しいんだけど…
フローチャートをきっちり仕上げてくる人は、その先でシンプルできれいなコードを書いてくれることが多いです。そして、慣れてくればフローチャートなんて書かなくてもコードがシンプルに構造化されていくものなのです。

追記

なんか研修の話をしているのに言語の話として言及されたので追記したよ
フローチャートを言語の問題として語っちゃダメだよdankogai - novtan別館