4GL懐古主義者の「企業アプリ開発には、Javaは行き詰まっている」という主張

Publickeyのある記事がJava開発者の目を引いていた。

これは、IT系の雑誌編集者がMike Gualtieri氏のBLOG記事を要約したものだが、あまり現実的な主張に思えなかった。他の人のコメントは賛否両論だが、賛同者でも趣旨は分かるが非現実的という感想のようだ。

業務アプリ開発で、Javaを批判しつつ4GLを勧めているのだが、狐につまされるような論理展開で混乱してきたので、論点を整理して妙なところを指摘してみる。

1. Javaは業務アプリには複雑すぎる？

Gualtieri氏は、インターネット普及以前は、専門知識が無い開発者でも4GLを使えば小規模アプリを開発できたが、インターネット普及後はJavaによる企業アプリケーション開発が主流になったと回顧している。既にアーキテクチャを構築し、業務アプリを開発・維持する能力がある開発チームや、独立ベンダーで商用アプリケーションを開発する場合は、今でもJavaは優れた選択肢である。しかし、Javaは複雑で開発に時間がかかるので、変化の激しい現状にあわないそうだ。

2. 4GLが企業アプリの救世主になる？

Gualtieri氏は、Javaの複雑さから逃れるために、企業アプリの開発では4GL（Lightswitch, WaveMaker, Uniface, Progress, OpenEdge）を採用すべきだと主張している。4GLは、定義によってはSQLやRも含む範囲の広い概念だが、Gualtieri氏はデータベースとフォーム・デザイナーが組み込まれた、dBASEやLotus Notes、MS-Access、PowerBuilderのような開発環境を4GLと想定している。最近の4GL製品は、特にワークフロー管理機能（BPM）に利点があるそうだ。

3. 4GLは存在したが、Javaが選ばれて来た

しかし、だいぶ以前から4GLにはウェブをサポートしていたが、Javaの普及を阻害できなかった。Lotus Notesにウェブ・アクセス機能がついたのは2001年だし、FileMakerも1999年からウェブ・サーバーとして機能する。もちろん使われているケースはあるが、主流にはならなかった。Javaがサーバーサイドで急激に普及したのは、10年ぐらい前からであり、ポータビリティ(Write once, run anywhere)のあるオブジェクト指向言語であるJavaが、4GLより開発者のニーズを良く抑えていた為だと言えるだろう。

4. 4GLは複雑で規模が大きいものは苦手

4GLはフォームやデータベース・アクセス部分が組み込まれているため、業務要件がシンプルな場合は生産効率が高い。しかし、特殊なフォームや、細かいデータベース・アクセスが必要になると、4GLは業務要件に対応できなくなりがちだ。また、スクリプト部分の言語仕様は旧世代のBASICである事が多いため、ライブラリの整備が難しく、構造化しづらく、規模が大きくなると設計が混乱しやすくなる。

5. 古い4GLアプリは継続的な開発では支障が出る

上述した以外にも、4GLに問題はある。4GLは人気とは言えず、標準化もされていないため、継続的な開発では支障が出てくる。(1)後方互換性が低くアプリケーションの保守コストが増大し、(2)専門家コミュニティが衰退して情報源が限られ、(3)ウェブなどの技術トレンドの変化に対応仕切れなかった製品もあるそうだ。

Gualtieri氏は、変化が早くなったと指摘しているが、古いコードを全て捨てるわけではない。製品が優れいても、すぐに廃れてしまったら困ってしまう。将来性がベンダー依存で疑わしいのも、4GLの大きな問題の一つだ。

6. 4GLが成功するケースは、エンド・ユーザー開発

4GLはオールインワンな開発環境なので、単純なアプリケーションには向いている。学習コストも低いので、部門レベルでの業務アプリをエンド・ユーザーが構築できる可能性があり、うまく行けばニーズにレスポンス良く開発が進むので良い成功体験になりえる。

しかし、業務要件が複雑で高度になると、4GLで対応できないケースも出てくる。構造化が難しいため、開発が進むと混乱が増すし、保守に問題がでる傾向がある。MS-Access等の4GLで書かれたアプリが問題になっている場合は少なくない。途中で高度な専門家の助けが欲しくても、特定の4GLの専門家は多くは無い。

7. 現在のエンド・ユーザー開発では、Excelが使われている

IT Proが、エンドユーザー開発はExcelで満たされているため、4GL製品は下火になった指摘している。MS-AccessやPowerBuilderがあるので4GLが無くなったわけでは無いが、技術者が開発ツールとして4GLを用いているのは聞いたことはあるが、4GLを使った開発をエンド・ユーザーが行っているという話を聞かないのも確かだ。

つまり、4GLの成功ケースはエンド・ユーザー開発であるが、実際にはExcelが使われる事が多いので、エンド・ユーザー開発で使われる事はあまり無い。

8. 論点が曖昧で、誤解が多い

Gualtieri氏の批判だが、論点を曖昧にして混乱を招いている。

まず、職業プログラマーが使うツールとして評価しているのか、それともエンド・ユーザーが使うツールとして評価しているのかが曖昧だ。エンド・ユーザーに最近の4GLが適したとしても、エンド・ユーザーがJavaを使う事は基本的に無いので、Javaが行き詰っていると言え無い。

次に、デスクトップ・アプリケーションの話なのか、ウェブ・アプリケーションの話なのか分からない。4GLでウェブ関連製品のSharePoint Serverと連係できると言っているのでウェブの話だと思うが、JavaデスクトップのGUIの批判もあって明快ではない。古きよき時代の業務アプリは、4GLではなくDelphiやVisual BASICで書かれていたと思うのは、私だけでは無いはずだ。

また、瑣末的な部分も多いが、OSやDBがC++で書かれているとか（C言語の誤り？）、Javaが他の言語と連係できないとか（JNIの存在は？）、認識に誤りがあると思える点は多々ある。JavaのGUIも批判も、NetBeansやEclipseにはGUIビルダー等には触れられていない。

9. 懐古主義的4GL待望論

Gualtieri氏はJavaは複雑で4GLなら単純だと主張している。しかし上述したとおり、誰にとって簡単なのか、どう有利なのかを明確にしておらず、その根拠は過去の4GLによるエンド・ユーザー開発と、最近の4GLにBPM機能があると述べているに過ぎない。また、Javaを完全に代替できる4GL製品は無いとも述べている。確かにJavaは複雑かも知れないが、これでは行き詰っているとは言えない。

実際のところ、開発規模は年々複雑になっている。昔は便利なツールで簡単に開発できたと、Gualtieri氏は懐古しているのだろうが、実際は開発している業務要件が複雑になり、Javaが状況を複雑にしているわけではない。この記事を紹介したPublickeyの新野淳一氏は、技術トレンドの変化を伝えたかったようだが、よく読んでみると理解に苦しむ文章としか言いようが無かった。