自動生成ツールの効果的な使い方セミナー」は120名のお申し込みをいただき、満員御礼となりました。当日の来場者数も107名となり、主催した超高速開発コミュニティ幹事の立場として、改めて関心の高いテーマであると感じたところです。ご来場いただいた皆様、ありがとうございました。開始20分前に、発表者*1による「じゃんけん」で発表順が決まりました。Wagbyという順となり、私たちは三番目(最後)になりました。これは結果的には好都合で、二社ともスマートフォン向けデモがあったため、急遽、この内容を加えさせていただきました。(実は当初、予定していたシナリオには含まれていませんでした。)さて私自身、この企画をとても楽しみにしていました。いずれもお客様先でよく競合する製品ですが、どのようにしてアプリケーションをつくっていくのか、じっくり拝見したことはありませんでした。今回の企画は製品の優劣を決めるものではありません。「似ている製品のように感じられるが、実際にはここが違う。」という各ツールの思想や特徴を学べる機会として位置づけていました。以下、各ツールの発表を聞いて、私なりの視点でまとめてみました。PerformerGeneXusやWagbyと違って、データベーススキーマは自動生成しません。設計情報に(手動もしくは半自動で)反映させるところが出発点になります。データベース技術者からみると、既存のテーブルを活用しやすいでしょう。データベースを操作する例として、二つの項目を検索条件に指定したあと、SQLに近い構文をエディタで入力し、検索ルールを規定しました。生のSQLではなく、これをラップした形で開発者が楽できるように、という配慮がされています。複雑な業務処理については、別途開発者が作成したモジュールをどのタイミングで、どういうパラメータを付与して呼び出すかを指定することで対応します。Performerが自動生成したコードは変更しないというのが基本方針のようです。アピール点は「オブジェクト指向を知らなくてもJavaベースのWebアプリケーションが開発できる」でしたので、「RDBの知識があって、Javaは初心者レベルという技術者」であれば十分に使えると解釈しました。系ベースだが、今後はどうするのか。」というものがありました。いうことでしたので、今後はどの技術をベースにされていくのか、興味があります。いう「リポジトリ」と同じであることがわかりました。言葉は違いますが、つまり設計情報のことです。GeneXusはWagbyと同様、設計情報が起点になります。設計情報からデータベーススキーマを作成し、画面処理や業務処理のコードを生成します。設計情報の多くはパラメータ化されていますが、さらにGeneXus言語によって複雑なロジックも記述できます。開発者が必ず気にする「生成されたソースコードの扱い」ですが、生成コードに手を加えることは想定されていない、でした。仮に手を加えたとしても、GeneXusが再び自動生成を行うと上書きされてしまいます。これに対するGeneXusの回答は、ソースコードに手を入れるのではなく、GeneXus言語を使う、です。GeneXusの世界で完結できればソースコードに手を入れる必要はありません。コードがどういうものかはまったく気にしないでいいということになります。これを補完するGeneXus言語」によって、Javaなどのオブジェクト指向を学ばなくてもWebアプリケーション開発ができる、というのがアピール点になります。設計情報のカバー範囲は広く、多くの業務処理はパラメータ設定によって実現できることも特徴です。表にまとめてみました。非プログラマ+Java技術者(中級レベル以上)ここで私が感じる最大の差別化ポイントは、開発者に求めるスキルです。RDBを操作でき、Javaは初心者という方も使えるようにという意図を感じました。ベースにしていることも、採用理由の重要なポイントになりそうです。提供する世界を満喫してもらえばHappyという意図を感じました。単なる実行環境でしかありません。コード生成型ですが、生成コードに手を入れる必要はない(そしてオブジェクト指向を学ぶ必要がない)ということが採用理由の重要なポイントになりそうです。技術者の組み合わせ」で開発してもらおうという意図があります。