設計書からソースコードを自動的に生成することの何がいけないのか

某SIerの「設計書からソースコードを自動的に生成するソリューション」について、エンジニアの間でブーイングの声が広まってる感があったので、ちょっと前に考えたことを書いてみる。

設計書からソースコードを自動生成することの何がイケてないのか。
それは、どんな設計書なら自動的にソースコードを生成出来るのか?ということに尽きる。
ソースコードを生成するということは、結局は変換をするということである。機械的に自動生成が出来るためには、ソースコードに変換するための情報が設計書と自動生成ツールの中に全て揃っていなくてはいけない。つまり、完全に動くソースコードに変換できるような情報をすべて設計書に書かなくてはいけないということを意味するのだ。実行可能な設計書と言ってもいいだろう。

かつての UMLモデリングツールなども MDD(Model Driven Development: モデル駆動設計)を称して、UMLモデルからソースコードを自動生成することを目指していて、UML2.0の仕様策定に介入し結果的にUMLは必要以上に複雑化してしまった。今日において、その複雑な仕様を全て駆使してUMLダイアグラムを描いている人は居るだろうか。結局、広くは認知されていないUML仕様を駆使して UMLダイアグラムをツールで作りこむより、ソースコードを直接書いたほうが早いし、もちろん動くし、認知度だって高いから保守性も高いし。当たり前だが、自動的に生成することは手段であって、目的は書くこと・読むことにおける効率化なのだ。現在(元々の意味のMDDではない)自動生成MDDツールは流行っていないし世間では終わった議論なのだが、歴史は繰り返されるということか。

さらに言うと、ソースコードを直接書いたほうが早い、ということについては「ソフトウェア設計とは何か?」を連想させる。この記事は、ソフトウェア開発をハードウェア開発などの工学になぞらえたとき、ソフトウェアの設計とはプログラミングまでの作業を意味し、ソースコード・リスティングが(工学的な設計基準を満たす)設計書であるという主張をしている。そして製造にあたるのはビルドとなる。全くその通りだと思う。
そう、我々は現在のコンパイルする言語を使う限り、すでに自動生成を実施済みなのだ。設計結果であるソースコードから、製品となるランタイムモジュールを。
さて、ソースコードが設計書としての厳密さを持っていることは疑う余地はないが、設計そのものの表現力については発展途上かもしれない。しかしプログラミング言語は、アセンブラの時代から考えれば人間が理解しやすい記述法やパラダイム(例えばオブジェクト指向など)を取り入れて進化しているし、書き方もコードがその意図を示すようなお作法や、設計書たるソースコードの可読性・保守性を促進するためのリファクタリング技法も生まれているわけで、世の中はソースコードを設計書として扱う方向に進んでいるのだから、それに逆らうようなことをしても世界の標準的な技術の恩恵を受けることができず苦しむだけだ。

ところで、ソースコードを書くよりも、実行可能な設計書を書く方が早いケースは本当にないのだろうか。自分は DSL(Domain Specific Language: ドメイン固有言語)がそれに近い考えのように思っている。ドメインの知識に基づいて、ドメインのルールの記述に注力し、裏方となる厳密にコンピュータシステムで動作可能とするために必要な細かい記述を省略して書けるような、そのドメインに固有の言語で記述された設計(書)であれば、その設計からソースコードを生成(またはそのまま実行)する方が、ソースコードを書くより早いかもしれない。もちろんそんなDSLを開発・保守するのはタダではないので、どちらがエコなのか、という判断が必要となる。