読者です 読者をやめる 読者になる 読者になる

Wagby と GeneXus の違い

Wagby も GeneXus も「自動生成ツール」というカテゴリの製品ですが、両者の仕組みは大きく違います。この二製品はよく比較されるようですので、カタログスペックでは判断できない、製品の思想に踏み込んで違いを明らかにしてみようと思います。

なお、私は Wagby をつくっている会社の代表取締役です。その立ち位置をご理解いただいた上で、以下の内容をお読み下さい。

共通する概念

両者とも仕様書からソースコードの自動生成をうたっています。WagbyJava のみを対象にしていますが、GeneXus は Java, .NET, Ruby と多様です。(ただし、その違いは後述するように、あまり重要ではないと考えています。)

共通するのは、この概念のみです。実際の開発スタイルは大きく異なります。

ノンプログラミングと形式言語

Wagby は「ノンプログラミング」を掲げています。Wagby の仕様書は業務ルールを細かく指定する欄が数多く提供されています。SE は対象業務を Wagby で開発するにあたり、その業務の特性をすべて仕様書に明らかにしていきます。一例をあげると、"コンボボックスで入力させる" という要件一つとっても、次のような業務ルールの設定欄があります。(これもまだ一部です。)

  • どのモデルの、どの項目をコンボボックスとして表示させるのか。
  • 表示の並び順をどうするか。
  • 検索時には "未選択" という状態で検索できるようにするか。
  • 検索時には "すべて" を検索できるようにするか。
  • 別項目の値によって、選択肢を絞込むか。(大項目・小項目関係)

実際の業務アプリケーションは、このようなルールの集合体です。Wagby の特徴は、業種・業態が違っても、このような普遍性のあるルールを洗い出し、仕様書として記載できるようにしたことです。この仕様書から、Javaソースコードを生成します。

一方で GeneXus は「形式言語」を提供しています。これは私がみるところ、Basic 言語に近いものです。GeneXus は仕様書を形式言語で書くのですが、これはいわゆる構造化プログラミング言語です。つまり仕様書と呼んでいますが、実際にはプログラムを書きます。

そのプログラムが、さらに Java .NETソースコードに変換されます。ソースコード生成というより、ソースコード変換(トランスレーション)という感覚です。

このような違いから、Wagby は仕様書を Excel で記述できますが、GeneXus は専用の開発環境を提供しています。

大切な違いなので繰り返します。Wagby のいう仕様書は業務ルールのパラメータですが、GeneXus は独自のプログラミング言語を使って仕様書を記述します。

生成されたソースコードの扱い

WagbyJava 開発者によるカスタマイズを受け入れます。生成されるコードはタブの位置、改行の位置から気にするようにしています。Struts, Spring, Hibernate というオーソドックスな OSS フレームワークで構成されているため、これらを知っている Java 開発者はコードを追えますし、カスタマイズ方法の理解度も早いでしょう。

GeneXus は Javaソースコードを出力しますが、生成されたコードに手を入れることは非推奨と伺いました。仕様書(形式言語)側を修正することが求められます。

GeneXus が出力するコードはいわゆる Java で Web アプリを書くときの標準的な文化に沿ったものではなく、あくまでも独自コードなのだろうと推察します。これは .NET でも Ruby でも同じでしょう。そうであれば GeneXus 流、と割り切ってしまって、生成コードに手を入れることは選択しないことも理解できます。

しかし、私はここに違和感を感じます。

開発者にとって、その開発言語の文化に沿ったコードが生成され、それを変更・保守できるかは重要な関心事です。それを許さないのであれば、ソースコード生成にとらわれる必要はなかったのではないでしょうか。形式言語を直接、中間言語に変換し、ランタイムエンジン上で動作するという選択肢もあったはずです。

GeneXus がソースコードを生成する意味

これは私見です。GeneXus の意図は、非オブジェクト指向言語(Basicライク)で Web アプリケーションを構築する選択肢を開発者に提供することではないかということです。

Java による Web アプリケーション構築は、実際のところ、かなり大変です。GeneXus のアプローチですと、Java .NET を学ばなくとも Basic ライクな言語で Web アプリをつくることができます。ソースコード変換によって Java 化されるので、安定したJVM 上でアプリを運用できます。

そして、それは Wagby とは異なる視点です。WagbyJava の良さを活かすことを前提としています。逆にいえば、Wagby のできることを拡げるためには Java の知識が必須です。そのため Wagby による開発は、業務SEとJavaプログラマの両方が必要になります。ノンプログラミングですが、Java プログラマを排除しません。むしろ単純なコードは自動生成させることで、プログラマには本質的な業務ロジックの開発に集中してもらうことを意図しています。

このことから、GeneXus のマルチ言語対応は、あまり重要ではないと考えています。(さらにいえば、プロジェクトの途中で開発言語を変えることは、ちょっと想像できません。どちらかというと開発言語の変更ではなく、JVM .NET Framework かというプラットフォームを選択できるという意味が強いでしょう。)

業務ロジックの扱い

Wagby は業務ロジック(バッチ処理を含む)は定義ファイルでは書けません。ここでいう業務ロジックとは、複数のモデル(テーブル)をさまざまなルールで更新するようなものを指します。(なお、一つのモデルに閉じた場合は、定義ファイルである程度の計算ルールを記述できます。)

GeneXus は業務ロジックもバッチ処理も仕様書で書けて、自動生成できると聞いたときは驚きました。しかし上述したように、独自言語で記述するということですので、それはプログラミングそのものです。つまり業務ロジックをJava として書くか、GeneXus が提供する言語で書くかですので、この点について大きな差はないと考えています。

お客様層の違い

では Wagby を使うのに Java の知識が必須かというと、そうではありません。実際のところ、100% Wagby 定義ファイルだけで構築できるアプリケーション(現場で運用しているもの)が多くあります。Wagby の標準機能で足りないというときに、はじめて Java 開発者が登場します。よって Wagby は "現場担当者が自分でアプリをつくることができる" とアピールしています。(そして困ったときは Java 開発者に声をかけてください、とも伝えています。)

GeneXus は仕様書という枠内にプログラム言語を記述するため、現場担当者を対象としたものではなく、開発会社(SIer)向けといえます。ただし Java でも .NET でも Ruby プログラマでもなく、GeneXus プログラマへの転身が必要です。

開発ライセンスの違い

Wagby は 1 案件毎に 1 つ、ご購入いただいています。1 つの案件に携わる開発者の数は何人でもよく、開発者ライセンスは(1案件の範囲内で)無制限にコピーできます。納品先(エンドユーザ)の利用規模による課金体系です。

GeneXus は開発者ライセンスとして提供されています。開発がピークに達した時、ライセンスが不足するという問題がありそうな気がします。例えば一つのライセンスで昼・夜交代で開発するというような運用もあるかも知れません。それは開発者にとって厳しい環境だろうと想像します。ただし開発ライセンスを一本用意すれば、複数の開発案件に対応できるというメリットがあります。

まとめ

同じ "自動生成ツール" といっても、ここまで違いがあることに今更ながら驚きます。と同時に、自動生成という切り口でさまざまなアイデアがあるということに気付かされます。

自動生成の起点となる情報(仕様書)をどう表現するか。この表現方法は最近では DSL と言われますが、Wagby は key, value を最小単位とするリポジトリ型の DSL であり、GeneXus は 独自言語を提供します。それぞれにメリット、デメリットが存在し、また、好みがあります。互いのよい点を真似しつつ、より使い勝手のよい製品へと発展していけるよう、がんばりたいと思います。

P.S.
GeneXus についての誤った記述、誤解がありましたら訂正します。コメント欄にご記入ください。

Wagby開発スタッフ募集中です!