さて、統合CASEツールに対するdisりに定評のある弊ブログですが、今回は、統合CASEツール、そろそろ死に絶えた感が出てきたので、その辺の歴史的な考察をしつつ、ローコード・ノーコードの話に展開していきたいと思います。

　開発ツール分類については、以下をご参照下さい。

　COBOL時代に開発された統合CASEツールが、まだ、生き残っていた時代は、Java Web時代でした。いずれも、取り得るアーキテクチャの数が、オンラインとバッチの、1つ～2つ位しかない時代で、フレキシビリティの低い自動生成型のツールでもやっていける時代でした。

　しかし、その後（2015年前後）、SPAなどのフロントエンド系のUIフレームワークが登場し、大手の統合CASEツールも、Java Webから、コチラにシフトして行った感はあるのですが、ココで大きく失敗して、統合CASEツールは完全に姿を消すに至ったように思います。

　失敗した理由には、

• SPAなどのフロントエンド系のUIフレームワークが、業務系アプリケーションに向いていなかった点、進化が早過ぎ、多様化に伴う流行り廃りがあったのが、大規模スクラッチ系の保守に向かなかった点。
• そして、多様化の中、フレキシビリティの低い自動生成型のツールでは対応できなくなって行って、事業的にも投資対象が、クラウド、SaaS、DXとか、そんな感じになってきているのもアリ、最終的には、投資対象では無くなって行った点。

　等がアルかと思います。

　そして、予想通り、生き残り得るのは、前々回にも言及した「IDE＋パッケージ＋テンプレート」型の開発支援ツールになって来ており、コレ等には、「フレキシビリティが高く、クラウド、SaaS、DXに追随できるポテンシャルがある。」と言うのが、その根拠になっているかと思います。

---

　...で、次は、ローコード・ノーコードで、コレについては、以前にも言及しているのですが、コレ、上記の分類的には、「RAD ツール」・「EUC ツール」なんですよね。そう言う意味で（、以前の投稿の繰り返しになりますが）、ローコード・ノーコードは、マーケティング的には新しいかもしれませんが、テクノロジ的にはあまり進歩していないように思います。

　また、中には、「統合 CASE ツール」っぽいモノもあったり、分類上、数多くのツールが「ローコード・ノーコード」と言うジャンルの中に乱立しているので、機能比較による評価が難しくしていて、昨今、解消されつつある「情報の非対称性」が解消されずに残っている分野である気がします。

　まぁ、でも、そんな世の中ですが、


　なんて言う情報も出ていて、
　コレを見て、重要なのは、


　の部分じゃないか？
　と思ったりします。

　確かに、「クラウドによる、SDx化で、アプリケーション・エンジニアがインフラを担うようになる。」と、先日のFgCFの中でも言われていて、そんな中で、定常業務的なインフラ屋の仕事は減って行くんじゃないだろうか？と思ったりもします（そう言えば、某社の仮想化トップランナーも、昔はWin32GUI系のアプリ開発をされていて、2005年以降のブームに乗って、仮想化のインフラストラクチャに転向したりしていて、今では、クラウド～IaC辺りに取り組まれているように思います）。

　そう考えると、


　などと思えてきます。


　具体的には、弊ブログでも度々、予測していますが、


　と思います（そう考えると、Excel、Access、VBAの代替ではなく競合。位の位置付けなんじゃないか？と思います）。

　...と、まぁ、色々とありますが、「RAD ツール」/「EUC ツール」/「統合 CASE ツール」のいずれの方式のツールにしても、取り得るアーキテクチャの数は少なく、フレキシビリティが低いので、自身の要件の中で使用するのが良いように思います。

　あと、そもそも、ローコード・ノーコードが流行った理由としては、MPA・SPAなどのWebや、スマホ・ネイティブに対応したRADツールが登場しておらず、コレ等の開発が非常に面倒だったことに起因している感もあるのですが、ただ、昨今、コレ等の開発ツールも進化してきており、VB6、Windows FormsやWeb Formsのノリで開発できるようになれば、また、流れも変わってくるかもしれないなぁ、なんて思いながら、以下の記事を眺めてみたりしました。

• 【飲食店のコロナ対策は非接触オーダー】
  モバイルオーダーの「SmartDish」が大幅アップデート！
  ｜株式会社CARCHのプレスリリース
  https://prtimes.jp/main/html/rd/p/000000030.000064504.html

　...と言う事で、次回は、Flutterについて書きます。