EUCは、非専門家でもコンピュータ処理が可能になるという概念。90年代には、そこにプログラム開発も含まれるようになっていました。一般の人でもプログラムを作れるようになるという考え方です。4GLは、第1世代の機械語、第2世代のアセンブラ、第3世代のCOBOL・FORTRANのような手続き型言語を経て、当時登場したアプリケーション開発に特化した第4世代の言語です。そしてアプリケーションを迅速に開発しよう、という考え方がRADでした。

　当時よくあった例が、Windowsの上でブロックを組み合わせるビジュアルプログラミングで、バックエンドにあるデータベースに格納されているデータを引っ張ってきて帳票やレポートにするような処理を簡単にできる、といったものでした。

　これらは今でいうノーコード／ローコードとほぼ同様のものです。ノーコード／ローコードの考え方は、最近急に生まれたものではなく、従来からあった考えをリブランディングしたものと言えるでしょう。

　当時は日本でも世界でも、プログラマー人口が圧倒的に足りず、「そのうちプログラマー不足でいろいろなことができなくなる」と言われていました。そこで多くの人にプログラミングができるようになってもらう必要があると考えられていました。この点でも、労働人口減少が懸念される現在の状況と少し似た部分があります。

アプリの負債化で一度は途絶えた
ノーコード／ローコードへの潮流

　では、90年代の「EUC/4GL/RAD」の潮流はその後、どうなったのでしょうか。

　この頃はWindowsの普及とともに、多くのカスタムアプリケーションが作られ、使われていました。先に挙げた帳票アプリやレポートアプリなどが「PowerBuilder」「dbMAGIC」といったツールによって数多く作られる中で、その作成をスタート地点として、本格的なアプリケーション開発のスキルを身に付けようという人も現れ始めていました。

　しかし、これらのツールやプラットフォームによる開発では、アプリを誰もが作れる一方で、1つ1つの動作は隠されて、ある種、ブラックボックス化した状態になります。簡単な業務や動作をアプリケーションにして動かすにはよいのですが、工夫を重ねて動作が複雑化していくと、うまく動かないときに何がいけないのかがわからなくなることがあります。また、障害が起きたときの対応にも苦労し、保守性が悪化します。

　さらに悪いのは、アプリの管理・メンテナンスが属人化するという点です。いろいろな人がさまざまなアプリを作って、使われること自体はよいのです。ただ、アプリを量産していた人が異動したり退職したりすると、そのアプリを他の人が理解することやメンテナンスすることができなくなりがちです。

　そうなると、そのアプリが「負債化」します。アプリ自体は業務に必要で、使わないという選択はできない。かといって別のツールやプラットフォーム上で同じ動作をするようにアプリを移植したくても、中身がブラックボックス化していて移植できない。となるとツールやプラットフォーム全体を切り替えたくても切り替えられず、ほかの進んだプラットフォームへいつまでたっても移行できないということになりかねません。