ベンダーロックインはどう考える？

　超高速開発ツールに限らず、さまざまなソリューションを検討する際に考えるべきは、ベンダー独自の技術を採用することでベンダーロックインされることをどう考えるのかというところだろう。100％ピュアなJavaでコードを自動生成する製品であれば標準技術としてベンダーロックインされることはない。対して、クライアント環境に実行環境をインストールするタイプのものであれば、ベンダー独自技術で動作させるためにベンダーロックインされることになる。

　一般的にはベンダーロックインを回避することが最良だが、情報システム部門の体制や人材などによっては、ベンダーにお任せしてロックインされていたほうがいいケースも存在する。確かにブラックボックス化された環境は回避できるに越したことはないが、例えばDBが直接ツール側から一括修正できたりクラスタ環境など安定稼働の要求に応える環境づくりがツール側で最初から用意されていたりなど、得られるメリットも少なくない。情報システム部門の置かれている環境を十分配慮し、最適な選択をしてほしい。

　なお、ソースコードを自動生成するツールの中には、全て自動生成してくれるものばかりではない。外部サービスの呼び出しなど一部を自前でプログラミングする必要があるものもある。これは自動生成率などと呼ばれ、何％のソースコードが自動生成されるのかといいう割合だ。このあたりもベンダーロックインの要素として考えておく必要がある。

中長期的な継承性は必要

　開発ツールを選択する際には、どうしても短期的な視点で考えがちだが、できれば中長期的な視点で見た“継承性”という視点も忘れずに考慮しておきたい。一時期アジャイル開発がもてはやされたが、アジャイルで成功している企業を見ると、きちんとドキュメントを残しておき、将来の改変に備えた環境をしっかり作っているものだ。

　それは、アプリケーションだけでなく、そのうえで扱うデータに対しても同じことだ。きちんと移行環境が整っていないと、将来改変したときにデータ移行がうまくいかず、新しい環境に持っていけないといったことにもなりかねない。開発ツールだけを議論するのではなく、その周辺も含めて環境を継続していけるのか、次世代への移行は十分考慮されているのかという視点をもっておくことが重要だ。

　オープンな仕様の仕組みを使っているものの、企業内でアレンジして使ってしまうと、結果として属人化してしまうため、オープンな仕組みだから継承性があるというわけでもないのが現実だ。

ツールごとの差異を十分見極める

　超高速開発ツールは、一見すると同じように見えてもその対応状況には違いあることを知っておこう。例えば対応しているDBの種類が異なっていることはもちろん、ビジネスロジックをGUI上で簡単に設計できるかテキストベースで記述するのか、外部との連携にSOAP／REST対応しているか、独自のSQLが必要かどうか、権限設定が画面やデータ単位で設定できるか、移行を容易にする仕組みが備わっているか、プロジェクト管理に必要な課題管理や構成管理の機能が内包しているかなど、細かく見ればさまざまな部分で違いが出てくる。

　ただし対応していないからNGというわけでは当然なく、自社が重視する仕様にマッチしているかどうかという視点で選択することが必要だ。せっかくビジネスロジックが簡単に設定できるものを選択しても、画面帳票の機能が脆弱（ぜいじゃく）であれば、ユーザーから受け入れてもらえない仕組みとなってしまう可能性もある。

　なお、この手のツールは外から見ても違い分かりにくいため、比較表を作成しているベンダーも少なくない。1社に偏ることなく、複数の比較表を入手し見比べてみることも大切だ。

ライセンス体系は大きく異なる

　ツール選択を決定づける大きなポイントの1つに、ライセンスがある。このライセンスの考え方は、ツールによっても異なってくるので十分注意が必要だ。ソースコードを自動生成するツールの場合、基本的には開発ツールとしての費用が求められるが、実行環境も提供しているツールの場合、利用するクライアントの数に応じてライセンスが発生するなど、runtimeの数によってもコストが変わる。

　開発環境だけ提供しているツールを見ると金額が大きく見えがちだが、実行環境に対して費用は一切掛からないため、トータルで見ると割安に感じることもあるだろう。逆に利用する人数が少なければ、実行環境を伴ったもののほうが全体で安価に仕上げることもできるはずだ。各ベンダーのライセンス体系に違いあることは、きちんと理解しておきたい。