あらら

前の会社にいた元後輩の子からメールが来る。ついのせられてしまったのか、仕事そっちのけでいろいろ書いてしまった。

いわゆるEAIですな。ニーズが高まっているのはよくわかります。しかも、単なるコード変換ではなくて、システム間において変換するデータの情報量の違いがでると、非常に面倒ですよね。

良いソリューションですか？うーん、難しいですね。パッケージを使うのをやめるとか。「なんちゃってパッケージ」で売ってみるとかどうでしょう。

というのは冗談ではなくて、パラメータを使ったカスタマイズによるパッケージはそろそろ限界がくるような気がします。理由はあまりにもパッケージが巨大化しているということです。歴史的に見て大戦艦が小型の飛行機に全く太刀打ちできなくなったように、巨大化はある時期で限界点がきて、シンプルで効率の良いテクノロジーがこれを凌駕するのではないかと考えています。生産形態が、少品種大量生産から、多品種少量生産に移行したように、（あるいは、見込み生産から受注生産などのBTOへ移行していくように）完全スクラッチ（あるいは部分的なスクラッチ）でも
パッケージ並みの値段で、かつすぐに提供できるというようなサービスが主流になっていくように思います。
ついでなので、もう少し書きましょう。パッケージの発想の原点は、要するにプログラミングレスでベストプラクティスを実現できるという点にあると思います。ようするに、プログラミングがいらないわけですから、故障も発生しないし、性能の心配もあまりしなくていいわけです。よって、パッケージビジネスに関わる人は、パッケージを開発する人を除いて、コンピュータに関するスキルをあまり必要としなくてもいいのです。これが、パッケージが流行した大きな要因だったのではないかと私は考えています。
ようするに、数時間研修を受けただけで、要員を確保することができるので、システムを扱えるベンダーがたくさん増えたのでは？ということです。
私は、ぼちぼちこの反動が来ると思います。つまり少数の優れた技術者だけで開発し、完全スクラッチでも安い価格で短期間に開発することができるような技術が登場するように思います。そしてそのときがきたら、大量の技術力のない余剰人員が・・・なんてことになってしまうのではないかと、恐れています。
例えば、ですが、画面は安全な形でお客さんが個々に作ることができるようなフレームワークがあるだけで、かなりのプログラマーは不要になるでしょう。(ただ、この「安全な形で」というのは簡単にはいかないのですが・・・。）あとは、内部の処理だけに注力するだけです。内部の処理も様々なフレームワークセットがあればお客さん固有のデータモデルをつくっても簡単に提供できたりできないか？と思います。というわけで、お客さん固有のデータモデル（あるいはオブジェクトモデル）を作るという極めて難しいスキルだけが残るというわけです。