エンドユーザがコーディングなしでアプリを作成する試みはいままで死ぬほど行われている。
商用アプリであれば
・EXCELのマクロ記録
・ACCESSマクロ
・RPAツール
ゲームであれば
・RPGツクール
・FF12のガンビット
・マリオメーカー
あたりが有名なところだとおもう。
ただし、ほぼすべてのコーディング無しアプリケーションは「後方互換」を犠牲にして成り立っている。後方互換とはそのアプリが動作する土台の仕様が変わっても、ユーザ作成のアプリが動作する事だ。例えば、windows7用に作成したアプリがWindows10で動作する場合、このアプリはWindows10に対して後方互換性があると言えるが、Excel95で作成したアプリがExcel2007で動作しない場合は、後方互換性が無いと言える*1。
動作環境の後方互換が無い場合、バージョンが変わるたびに、アプリの移植作業が必要になる。そもそも移植というのはより低レベル（コンピュータ寄り）な理解が必要になってくるため、コーディング無しでしかアプリを作れないメンバーにはハードルが高くなってしまう*2。
大体の職場において、「先人が作成した偉大なEXCELマクロ」は、とにかくマクロの記録に依存しており、余計な記載が多い。さらに言えば、EXCELマクロは「キーストロークの記録」に過ぎないものも多くEXCELの仕様が少し異なっただけで動作しなくなってしまう。
ACCESSに至っては、そもそも世代違いでACCESSファイルに互換がなくなって、最新のACCESSでは古いACCESSファイルを使用できなかったり、マクロをVBAに変換していた環境*3では日本語関数名、日本語変数名が正しく移行されなかったり、まあいろんなトラブルが発生する。
それでもEXCELやACCESSならばMicrosoft社の製品なので、(移行不具合が多く発生しようとも)使い続けるのは不可能ではない。しかし、コーディング無しツールはMicrosoft社だけが作成しているのではなく、いろんな会社が作っている。その会社が5年後存在するか？そのツールは5年後存在するか？をあらかじめ考えてから手を出すべきだろう。または「プロトタイプ作成」と割り切ってツールを使用するのも一つの手だろうと思う。
コーディング無しで作成されたアプリは「プロトタイプとしては優秀」だが寿命が短い。延命するためにはコーディングできるレベルの担当者が必要になる。そのような担当者を継続的に確保できないなら、外注するなり、プログラマを雇うなりして「寿命を迎える前にコーディングで別途アプリ化しておく」必要がある。
今後、問題になりそうなのはRPAツールだろう。コーディング無しで作れるかもしれないけれど、どうやって維持していくのかということを、ツールの選定と維持するための運用方法を制度化しておくべきと思われる。
*1:Excelがプラットフォームとして後方互換性が無いと言っているわけではない。あるExcel95アプリケーションがExcel2007に対して後方互換性が無かったというだけ
*2:例えばExcelの仕様で、新規Bookが作成される際、Excel95では10個のシートが作成される。Excel 2007あたりでは3つのシートが作成され、現行のExcelでは1つしかシートが作成されない。シートがデフォルトで3シートあるか、10シートあることに依存するマクロは、1つしかシートが作成されない現行のExcelでは動作しない。
*3:ACCESSではマクロとVBAが異なる存在、マクロでは細かい制御ができないのでVBA変換が可能だが、勝手に関数名やコントロール名に日本語が使用されたりする。その結果https://docs.microsoft.com/ja-jp/archive/blogs/office_client_development_support_blog/ver1708-issue-japanesenamevbamoduleこんなことが起こったりする。
