フローチャートの呪い - カレーなる辛口Javaな加齢日記

http://blog.livedoor.jp/dankogai/archives/51083212.html
http://d.hatena.ne.jp/NOV1975/20080719/p2
http://d.hatena.ne.jp/NOV1975/20080719/p4

いまさら議論するのも馬鹿らしいけど，フローチャートなんぞはものの役に立たない．
そんなものは作るだけ時間の無駄だし，何かの役にたつこともない．
それは何十年も前に結論が出ていると思う．

それはあまりに自明であったため，今では話題になることも少なくなった．

人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)

作者: フレデリック・P,Jr.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
出版社/メーカー: アジソンウェスレイパブリッシャーズジャパン
発売日: 1996/02/01
メディア: 単行本
購入: 4人クリック: 126回
この商品を含むブログ (49件) を見る

フローチャートの呪い
フローチャートは、プログラム文書作成の内でまったく過大評価されてきたものの一つだ．多くのプログラマはフローチャートなど全然必要としないのだ．何しろフローチャートが一ページ以上必要になるプログラムはほとんど無いのだから．
フローチャートはプログラムの判別構造を示すもので，構造の一面を示しているに過ぎない．(中略)
しかし，詳細で逐一記述したフローチャートは時代遅れの厄介者であり，アルゴリズムの考え方を初心者に手ほどきする場合に適しているだけである．(中略)
実際の所，フローチャートを描くことは，騒がれているほどには，実践されていない．プログラムを書き始める前に詳細なフローチャートを決まって書く熟練プログラマなどお目にかかったことがない．組織で決められた標準化のためにフローチャートが要求される場合，ほぼ間違いなく事後に作成されている．多くの開発現場では，完成したコードからこの「不可欠な」デザインツールを生成する機械語プログラムを誇らしげに使ってさえいる．

しかしこれまでのそうした努力からは，説得力のあるものはおろか，好奇心をそそるようなものも何ら出てきていない．私は今後もないだろうと思っている．
第一，別の所でも述べたように，フローチャートはソフトウェア構造を抽象化したものとしては非常に貧弱なものだ，実際，A.W.バークスやフォンノイマン，それにゴールドスタインが自分たちの提唱したコンピュータに必要とされる高水準制御言語を必死で提供しようとしたことから一目瞭然だ．フローチャートは現在改良されてはいるが，痛ましい数ページに渡る小型の連結形式では，デザインツールとしては本質的に不要だと言うことがはっきりしている．プログラマは，プログラムを書く前ではなく，書いてからフローチャートを書いているのだ．
(中略)
さらに基本的なこととして，既に述べたことだが，ソフトウエアの視覚化は難しいのだ．私たちの図示するものが制御の流れだろうが，変数範囲のネストだろうが，そのほか何であろうとも，複雑に運動しているソフトウェアの「象」を一次元的にしか感じられない．様々な関連する視点によって作られた図を全て重ね合わせたなら，全体としての概観を取り出すことが困難になってしまう．

大昔でさえこうなのだ．それより遙かに進歩したツールを持つ我々が，フローチャートなぞ使う理由はない．

http://d.hatena.ne.jp/JavaBlack/20060802/p3
http://d.hatena.ne.jp/JavaBlack/20060805/p1

なぜそんなにフローチャートが嫌われているかというと，単なる時間の浪費というだけでなく，フローチャートはプログラマの思考を阻害するからだ．フローチャートに書くことを強要された時点で，良いプログラムができる可能性は０になる．

人間はフローチャートのようには考えない
結局のところ、なぜフローチャートが駄目かといえばこれに尽きる。人間の発想は、フローチャートほど簡単ではない。

それでは、なぜフローチャートはこれほどわかりやすいのか。
表現力を犠牲にしているからだ。

プログラミング初心者の学習用としてもフローチャートは好ましくないと思う．初心者用言語でさえも好ましくない．

ここから「初心者向け言語が避けていること」言い替えれば「初心者が苦手なこと」が何であるかだいたいわかる。彼らは「抽象化」が苦手なのだ。

しかし、考えてみれば「抽象化」というのは、この半世紀にプログラミング言語が進化してきた方向そのものだ。あらゆるプログラミング言語はそれぞれの方向でより高い抽象化を実現するために進化してきている。

初心者への間口を広くするために基本機能はフラットにし、オブジェクト機能などを追加して抽象化もできる言語にすればいいじゃないか、と思う人もいるかもしれない。が、個人的にはそれはうまくいかないと思う。そのような言語では学ぶことを拒否する「自称初心者」はいつまでも抽象化機能を身につけず、質の悪いプログラムを生産し続けるだろう。

もちろん、志の高い人はそのような言語を通じて抽象化機能について学び使いこなせるようになるだろうが、それくらい志が高ければ、最初から初心者にこびない言語を使っても同じくらいか、もしかするとより短い期間で、良いプログラマに成長するだろう。

http://www.rubyist.net/~matz/20080204.html#p01

元ネタはFizz-Buzz問題と絡めてフローチャートを例に挙げているけれど，おそらく全く不適切な使用例だと思う．Fizz-Buzz問題さえもできない人間は*1，プログラミングに必要とされる抽象的な思考そのものが苦手らしい．そういう人間にとっては抽象的思考を阻害するフローチャートは害にならないかもしれないが，それと同時にフローチャートによって抽象的思考が鍛えられることもない．

FizzBuzzでいうと、一番大きなくくりである「１から１００まで処理する」の部分を書くことなしにいきなり「３の倍数のときはどうするんだっけ」ってことばかり考えているようなものです。そんな順番で処理を考えていってもろくなロジックにはなりません。

LISPerあたりだとそういう思想で作る人とかいるかも．この辺りの設計思想は言語によっても考え方自体が変わるんだよね．*2

Microsoft Visioをバカにするな。売れてる。Visioはちゃんと売れてるぞ。ファンもいる。プレゼン以外にも使う。
いいか。大切なことは、コード化しやすいフローチャートじゃない。苦しくても辛くてもフローチャート通りにコードを組むことなのだ。そうじゃないと保守と更新が本当に面倒くさいんだ。
なぜなら、管理するのはプログラマでも賢い小学生でもなく、普通の文系オジサンだからだ。読めないよ！プレゼン現場で見慣れたフローチャートぐらいしか。そのとおりに作っとけよ。管理にばっか譲歩を求めるんじゃなく、開発の人も分かりやすい書類を作る努力をしてよ。マジで。
プログラマがそういう考えだから、仕様書工房とかが売れるんだ。
買ったよ最新版も。くそう。
http://blog.livedoor.jp/dankogai/archives/51083212.html#comments

うーん，これはネタかな？*3

さもなくば，プログラミングがまともにできない自称「設計者」というIT業界のガン細胞ですね．もしこういうバカのいる会社に入った技術者がいれば，私は一刻も早く他の会社に移ることを強く推奨する．

COBOLerにはこういう人も多いって話だけど，いやはや時代遅れもここまで来ると哀れだな．

フローチャートをこの程度に考えているエンジニアなら、早めに辞めたほうが良い。
複雑な物事を丁寧に記述する能力がないのですね

「フローチャートはソフトウエアの複雑さを記述できない」というのが，フローチャートの本質的な欠陥なんだが．プログラムの複雑さはフローチャートのような単純な図形では記述することができません．

「ソフトウェア設計とは何か？」 http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

フローチャートってCOBOL的にはそれなりに有効なわけで。

それは「COBOLがいかにダメな言語か」を表しているだけじゃないかと．「COBOL(超ダメ言語)よりフローチャートの方がまだマシ」なんじゃないかと．COBOLという亡霊が未だに生き残ってることの方がよほど問題．

http://d.hatena.ne.jp/masayang/20080621/1214006721

他人(主に新人)に既存のプログラムを教えるのにはフローチャートを利用してます。
アレは絶対ダメでコレが絶対に良いという考え方はプログラマ向きではないですね。

もとの記事も「絶対ダメ」などとは言ってないと思うけど．あくまで「フローチャートが全く非効率で，実用的でない」ということなのだ．これに対する反論は「フローチャートはこんなに効果的だ」というものであるべきなのだが，出てくるのは「こういう場面に限定すればフローチャートでも(我慢すれば)使うこともできる」という論点をすり替えるものばかり．

そういう用途にフローチャートが絶対に使えないとまでは言えないけど，それがフローチャートである必然性はない．PAD図でもUMLでも同程度に効率的(或いは非効率的)だ．時には自然言語による箇条書きが最も効果的な場合さえ少なくない．*4
自然言語と同等以下の効率しかない時代遅れの表記法に，一体どれほどのを学習コストかける意義があるというのだろう？それって結局，「今やフローチャートを使う意義は無い」ってことじゃないだろうか．

http://d2.oredoco.net/archives/84

で、たいていの人は、頭の中でフローチャートを書いてそれをそのままプログラム言語に落としこめるので、一見、フローチャートと言うものが必要ないように思うだけ。

たとえばPerlでテキスト処理を書くとしたら、正規表現とかつかえるので、そのようなフローチャートを頭にかいてコードに落とすでしょう。

嘘です．
プログラミングではもっと複雑な構造を頭の中でイメージします．それはフローチャートなどという原始的な二次元画像では表現できません．*5

最近の若者が作るソースはひどい。構造化ができてない。たぶん、フローチャート的な考え方が存在しないのだろう。オブジェクト指向とかそういう以前の問題で、NG。

ぜんぜん関係ない．仮にどれほど優秀な人がいても，あなたの元には３年と留まることはないだろう．

http://d.hatena.ne.jp/goodbye_bluemonday/20080720

フローチャートは、多くの場合、上流工程の設計者が、コーダーに向けて、ブログラム内容を、まさに「プレゼン」する為に長年使われてきたのだよ。

「多重下請け構造」とか「上流工程」という奴が，既に時代遅れの代物，前世紀の遺物なのだよ．きっとこの人は自分が過去の遺物だなんて頑なに認めようとしないんだろうなと．

システムエンジニア不要説

http://d.hatena.ne.jp/masayang/20080719/1216511611

ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。

もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。

抽象的な表現を徐々に具体表現に落としてきているわけだから、コードのある部分を変更したときに影響を受ける設計書の範囲を特定するのは簡単ではない。仮に頑張ってそこを特定し、設計書を修正したとしても、今度は各設計書間の整合性を確認するのに膨大な時間がかかる。つまりお金がかかる。

昔はシステムエンジニアという職種は必要だったかもしれない。
でも、今も必要なのかというと...自分は懐疑的だ。本当はいらないんじゃないか、と。

もちろん、日本全国に数十万人いると思われる「コーディングできないシステムエンジニア」は、そんな話を否定することであろう。存在意義を否定されるわけだから。

技術が変われば分業体制も変わる

http://d.hatena.ne.jp/masayang/20080720/1216567031

デザイナが先にHTMLテンプレートを作成し、プログラマがそれを参照にeRubyを書くという古典的手法では、「先に画面デザインを確定させる必要がある」ということになり、Agileの持ち味をぶち壊すことになる。

(中略)デザイナ作業によるデグレードをテストで検知できるか否かにかかっているのではないかと。つまり、テストフレームワークの選択と、それをチームが正しく使っているかどうか。
進化した技術を習得した技術者が集まる現場では、当然分業体制も変わってくるよね、という当たり前といえば当たり前の結論。だけど、わかってない人達は、わかってないこともわかってくれない。COBOL屋の話と同じだ。