SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か？

以前Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してにて

何でもかんでもとにかく自動生成させたがる。特にExcelなどの表から大量のクラスを自動生成させるなど。たいていそのようにして生成されたクラスはゴミで保守も大変なものになりがちです。

ということを書いたことに対して、会社の忘年会で上司や同僚の間で議論が盛り上がって興味深かったので、ここで自分の考えを再度整理させていただきたいと思います。（忘年会で1次会、2次会の間ずっとこういった話題で話が盛り上がるというのはかなり特殊な部署なのかなとは思います。「SIerのやり方はXXだ」一口に言っても、それは全体的な一般傾向を表しているのであって、実際はさまざまな人々がいることを忘れてはなりません。あくまでもそういう意味で捉えてください。）
それで、私の周りにはプログラミング好き、技術好きが多いのですが、それでも自動生成の善悪については意見が分かれるようです。誤解を恐れず一言で言うと、この業界の技術者には「SIer脳」の人と「アジャイル脳」の人がいるように思います。理想的には臨機応変に両者を柔軟に使い分けられるハイブリッド脳がよいのだろうけれども、多くの場合考え方がどちらかに偏っていることが多いのですね。それで、いままでの慣習や教育というのが大きいので、数から言うと前者に偏っている人の数が圧倒的に多くて、「アジャイル脳」の人はごく少数で異端者扱いということが普通のようです。（ちなみに私は完全に「アジャイル脳」に偏っていて、会社員としては問題ありかもしれません。）
私もそうですがアジャイル脳の人は本能的に設計とコーディングが切り離せないものであるという考え方に心底ほれ込んでいるのですね。（プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して）つまり、コーディングを単純な製造工程ではなくて、著作とかデザインといった創造的な作業であると捉えています。この考え方ではコードと設計は一体であり、どちらが先か後かというのは鶏と卵の議論と同様に意味をなしません。一方SIer脳の考え方では、たとえ繰り返し型開発の価値を認める人であっても、やはり設計（書）が先で、コードはそれに付随して半自動的に製造されるものであるという考え方が根強いようです。アジャイル脳の考え方からすると「DNAの連続性を考慮するとどうしても卵が先でなくてはならない」といった議論と同様におかしく思えてしまうのですが、やはり設計書が先行しなくてはならないという考え方に囚われています。そして、ExcelにせよUMLにせよそこから自動的にJavaなどのコードを自動生成することはユーザーの目に触れる設計書とコードとのトレーサビリティーが確保される上での有効な手段であると考えます。
たとえば、Excelのテーブル定義書からエンティティクラスを自動的に生成するツールをSIer脳の人は非常にありがたがります。*1でも、私はどうしてもそういったツールは好きになれないのであって、できることであれば使いたくないと考えてしまいます。好きになれない理由としては以下のようなことがあげられます。*2

Excel表では継承や値オブジェクトなどオブジェクトモデルを正確に表現できず、多くの場合テーブルとクラスが一対一対応するような設計に帰着する*3
Excelと生成したソースコードとの間で2重メンテナンスの問題が発生する可能性がある（DRYの法則に反する*4）
自動生成ではテストファースト的な開発が困難
自動生成ではソースコード上で積極的にリファクタリングしたり、頭を使って設計することが困難

たとえば、以下のようなコードだったら、Excel表と読みやすさはほとんどかわらないはずです。

public class User {
  
  @NotNull
  @Size(min=4, max=8)
  private String userName;

...

}

その上コードは実行可能だから設計の妥当性を簡単に試験できるし、リファクタリングによる設計変更もきわめて簡単にできます。さらに、継承やアノテーションなどプログラミング言語本来の機能をいかんなく発揮することができます。どうしてもSEや顧客がコードを読みたくないのであれば、JavaコードからExcel表を生成することは容易に可能です。このようにアジャイル脳になっているとコードこそが多くの場合設計の最良の手段であり、これを中心にしてその他の文書は必要に応じて補助的に発生する副生成物であると考えます。

まずはコード上でじっくり設計を考えた後で、説明資料として後から必要に応じて要点をUMLで文書化するという流れの方が作業手順としてしっくり来ることが私の経験上ほとんどです。コードこそが設計の本質をもっとも正確かつ簡潔に表現できる手段なのであり、UMLはそのある側面を捉えやすくする方便としての一表現に過ぎないなどと言うと怒られてしまうでしょうか？

同様に、アジャイル脳は一般的にDDLからエンティティクラスをボトムアップで生成する*5ことを好まず、エンティティクラスからDDLを自動生成するトップダウンのO/Rマッピングを好みます。この点でテーブル定義書や画面定義書からクラスを自動生成するのが望ましいと考えているSIer脳の考え方とはまったく正反対です。
なお、Excelからクラスを生成する場合、Excelを唯一のソースコードであると考えるのであれば、アジャイル脳的にもまだ許容できます。（mavenならExcelをsrc/main/excel配下に格納して、生成したJavaコードをtarget配下に生成してSVN上でも共有しない）この場合、ExcelはDSLの一種であると考えていることになります。ただ、バイナリファイルなので共有が難しいし、重いし、通常は不便で良い事無しだと思います。
もちろん、自動生成をすべての分野で否定しているわけではなく帳票作成とかビュー周りとかテストコードとか形式化が可能な分野であればよいと思うのですが、自動生成することによってドメインモデルのような最重要の領域において、コード上できちんと設計する自由を奪ってしまう*6のは私の理想とする世界の基準では悪であると思えてしまいます。
しかしながら、何が善で何が悪かということはさまざまな要素によって決まるものであり、一概に決めつけることはできないでしょう。戦前であれば他国の領土を侵略することが善であったのと同じように多数派の意見が正義であると考えられるものです。そういう意味において、現在の多くのSIでは自動生成は有効なツールであると考えられれているのだと思います。また、アジャイルなどというのは現実の仕事の進め方にマッチしないとんでもなく悪い考え方とされてしまいます。そもそも製造業のメタファーからPGが自発的に設計を考えるということを許容しない文化が非常に深く浸透しています。私としてはこうした状況は残念に思いますが、それが多くの場合、現在の業界の現実なのだと思います。

*1:こうした傾向になるもう一つの理由として会社でFWやツールを作る部署と実際に業務システム開発を担当する部署が明確に分かれているというのも原因のひとつとして考えられます。業務と切り離されていると有能なプログラマーの才能がツールなどに費やされることになります。確かに、そういったツールの開発は楽しいので。

*2:もちろん、アジャイルなRailsだってscaffoldingの自動生成機能などはありますが、それは開発初期の成果物のベースを作るものであって、設計書とコードをずっと同期するというSIer脳的発想とはまったく異なるものです。

*3:もちろんそうした設計がすべて悪と決め付けているわけではありません。ただし、そのような付加価値の低いシステムのスクラッチ開発は今後少なくなると思います。

*4:最近の傾向としてはRooのようにアノテーションなどソースコード中のメタ情報を元にバイトコードに機能を織り込むような考え方が流行かもしれません。これだとDRYの原理が保たれますので。

*5:Hibernate Toolsではこうした方向の生成をリバースエンジニアリングと呼んでいます。Javaコードが設計の中心であるという思想が表れたものと言えると思います。同僚に言ったらテーブル定義書を中心に考えてそれはフォワードエンジニアリングでしょと言われたことがあります。なにが世界の中心か、大きな思想のギャップを感じました。

*6:多くの業務システムではレガシースキーマの存在を考慮しないといけないため、テーブル設計がまず最初にありきという制約がある場合が多いという事実はもちろんあります。