日経エレのブログ「プログラミングは『設計』か『製造』か」

最近忙しくて、いくつか来るメールニュースのタイトルさえ読めていない。なのでここのところ浦島太郎状態だ。しかも明日から週末まで、もしかしたら山の中に篭もる感じになるため、ネットにすらつなげないかもしれない。まぁ、なるようになれ、だ。

たまたま見たメールニュースに「プログラミングは『設計』か『製造』か」というタイトルがあったので読んでみた。書いているのは日経エレの大森記者だ。まぁ記者の眼にせよこのブログにせよ、日経BPの記者が書いているコラムはほとんどの場合宣伝込みなので、斜めに読まなくてはならない。日経ものづくりは別だけど。これもどうやら、SPLCやスターロジックの宣伝のようだ。別に宣伝をしても良いのだが、イマイチ何を言いたいか分からない。大森記者に限った話ではないが、記者なのだから支離滅裂な文章を書かず、宣伝とは悟られないような名文を書いて欲しいと常々思う。

この文章、本当に突っ込みどころが多い。

曰く「ものづくりの現場にいる方は『ソフトウエアといえどもモノなのだから，プログラミングはソフトウエアを製造する行為だ』と自然に考えていると思います。だから，ソフトウエア開発も自動化できるはずだ，と」。おいおい、ものづくりの現場にいる人は、ものが自動で勝手にできるなんて思っちゃいないよ。自動で作っているように見えるまでに大変な苦労をしているのだから。

曰く「「プログラミングは設計である」という考え方に大きな影響を受けて生まれたのが『アジャイル開発プロセス』という先進的なソフトウエア開発手法です」。そうなのか。そんな矮小な概念だったのか、アジャイルというヤツは。

曰く「組み込みソフトウエア開発の分野は，ソフトウエアの仕様が比較的はっきりしているので，IT系のシステム開発より製造に近いという面はあります」。えぇぇぇ、まだ完成もしていないハードとのすり合わせなんて日常茶飯事なのに。仕様がはっきりしていて作りやすい組込みソフトなんて、ほとんど聞かないけどなぁ。

曰く「ソフトウエアの要件さえ確定すれば，あとはコードの自動生成ツールを駆使してソフトウエアを完成させるというのです。ここにあるのはまさに製造の考え方です」。だから、製造というのは、要件が確定すれば後は設備が勝手に作ってくれるんじゃないんだって。生産工程の設計とか初期流動管理とか、山ほど色々知恵を絞るんだって。

とまぁ、色々と難の多い文章だが、では本当にスターロジックのツールを使うと、設計無しでツールがプログラムを自動生成してくれるのだろうか。僕はこのツールをよく知らないが、それは可能かもしれないな、と思う。事実、制御系のソフトウェア開発では、Matlabなどを使ってCコードを自動生成するモデルベース開発という取り組みが盛んになりつつあるからだ。ちなみに、モデル駆動開発ではありません、念のため。

ただし、そのためにはいくつかの条件が必要になる。まず、作ろうとするものの自由度が低いことだ。特にドメインに関する自由度が低い方がよい。自由度が高いコード自動生成ツールは、要するにフレームワークやライブラリ、コンパイラと何ら変わらなくなってしまう。次に、非機能要求を含む要求それぞれに対して、サブプログラムなどの設計要素が1対1で対応することだ。何らかの設計上の共通化は、コンパイラの最適化のようにアルゴリズム的に規定できるのであれば可能である。これはすなわち、メモリなどのリソース制約やスループットなどの性能要求を満たしにくいということにつながる。もう少し一般化すると、要求に対する設計のすり合わせが発生すると、かなり自動生成は難しくなるだろう。

要するに、ドメインがかなり限られていて、要求と設計要素が1対1で対応し、リソース制約や性能要求が緩いアプリケーションであれば、以前からコードの自動生成は可能である。コンパイラ（アセンブラもか？）が出現した時に、一部の人々はもうプログラムを書かなくてよいと喧伝しただろう。フレームワークも、そういう喧伝をされることがある。モデルベース開発に至っては、いまだにそう思っている人がいる。

しかし実際には、多くの場合、自動生成は難しいだろう。それは上述の条件が満たされないからだ。そしてもう一つ理由がある。パーキンソンの法則があるからだ。冷蔵庫が一杯になったので買い換えても、すぐにまた一杯になる。それがパーキンソンの法則だ。これは、自動生成についても同じことが言えるだろう。

コンパイラが生まれたことで、プログラミングは無くなったか。否。では何が変わったか。それは、開発者の知的リソースに対するアウトプットが増加したのだ。つまり、同じだけ頭を使ってできるソフトウェアが、より複雑になったり、高機能になったりしたのだ。一方、開発者の知的リソースそのものは変わらない。こちらはむしろ、ラインエディタからスクリーンエディタになったり、統合開発環境が出てきたりといったことの方が寄与しているだろう。

すなわちツールで自動生成が可能になったら、ほんの少しの間だけ開発者は頭を使わなくて済むようになるだろうが、すぐに開発対象の要求が高度になったり納期が短くなったりして、何らかの形で頭を極限まで使うようになるだろう。コンパイラによってメモリマップを書かなくて済むようになったがごとく、頭を使う対象は変化する。しかし頭を使うことそのものは、形は変わるものの、同じである。我々の欲望の進化は、技術の進化よりも常に速いのだ。

もちろん、コードの自動生成に意味が無いなんてことは全くない。歓迎すべきだ。これは、頭を使うことを減らしてくれるツールである。しかし同じくらい重要なのは、頭を使うこと、すなわち設計とは何かを考え抜き、頭を使うことをいつも楽にしてくれるツールや方法論を考え出すことだろう。設計という高度に知的な行為に対する洞察をすること無しに、ソフトウェア開発は楽にならないと思う。コンパイラが出ようが出まいが、我々が知的なミスをすることは変わらないし、クリエイティブな感覚を持つことが楽でないのも同じである。そういったことをきちんとソフトウェア工学で扱わなくてはならないのだろう。コンピュータに代行させることだけが工学では無い、と僕は固く信じている。