日経SYSTEMの「開発現場の自動化」と情報処理教育に関する提言の「手順的な自動処理」と見える化
日経SYSTEMの２００８年３月号の特集は、「これならできる！ 開発現場の自動化」のようですね。
開発の自動化といった場合、もはや、伽藍とバザール（大聖堂とバザール）の話を持ち出すまでもなく、大がかりなCASEツールによる自動化を考える人は少なく（いないと言っていい？）、部分部分に切り分けて、そこを自動化しているという流れになっていると思う。
日経SYSTEMも、ぱらぱらとしかみてないんだけど、たぶん、そんなかんじ。
開発の部分部分を自動化し、それをつなげるという感じの、バザール型のようだ。
で、自動化について、ここのブログでもよく取り上げているので、さらに、ここでは、突っ込んだ話をしたい。自動化の本質を表す言葉は、
日本の情報教育・情報処理教育に関する提言2005（2006.11改訂/追補版）
http://www.ipsj.or.jp/12kyoiku/teigen/v81teigen-rev1a.html
にでてくる（以下斜体は上記サイトより引用）、
5. 「手順的な自動処理」の構築
だと思っています。この概念は、こんなかんじ
（1）問題を同定および記述した上で、その定式化をおこない、解決方法を考える。[注A1]
（2）解決方法を、アルゴリズムとして組み上げ、自動処理可能な一定形式で記述した、コンピュータ上で実行可能なものとして実現する。
（3）実現したものが問題解決として適切であるかを検証し、必要なら問題の定式化まで戻ってやり直す。
で、重要なのは、この後の話
ここで、記述する方式としては直ちにプログラミング言語が想起される かも知れないが、上記の定義はそれに限定されないことを注意しておき たい。たとえば、表計算のワークシート上において自動処理を記述することも、上記の定義にあてはまる。
ってこと。
つまり、開発というと、最終的にはプログラミング言語を書くことと思われてしまうかもしれないけど、「システム開発」という問題を定式化した場合、システム開発における自動処理可能っていうのが、かなりあるんじゃないか（いわゆるワーカーさんがやっていたような、やり方を知っていれば標準化されていて、できる部分）。
だったら、その自動処理可能な部分の開発手順をコンピューター上で、できるだけ、上流で、見える化させて、（システムに必要な）パラメータを入れて（ここでパラメータは、データ項目名など）、一度データを入れたら、あとは自動的にドキュメントやソースを作ったほうがいいんじゃないか？
っていう考えだと思います。
で、さらに言うと、
客に、コンピューターを導入して省力化とかいう前に、
自分が、コンピューターを導入して省力化しろよ！
っていう論理だな。そしてさらに、
客に、見える化、見える化っていうなら、
まずは、自分の開発を見える化しろよ！
っていう話だな・・
