最近、ノーコード／ローコードについて調べる機会があった。プログラムのソースコードを極力記述せずにシステムを開発できる手法で、全くコードを書かずに開発できるのがノーコード、少量のコードで開発できるのがローコードだ。ノーコード／ローコードはプログラミングに比べて学習コストが低く、アイデアをすぐに形にできるというメリットがある。
もっとも、個人的にはノーコードやローコードに対してそれほどいいイメージは持っていなかった。そもそも、コードを極力書かずにソフトウエアを作るというアイデアは大昔からある。例えばソフトウエアを高速に開発する「RAD（Rapid Application Development）」や、その手法の1つであるコード自動生成の「CASE（Computer Aided System Engineering）」などだ。こうしたトレンドは、様々に名前を変えて何度も繰り返されてきた。正直、目新しさはない。
通常のソフトウエア開発に組み込まれて意識されなくなったものもある。例えば、アプリ画面の部品配置や機能割り当てをドラッグアンドドロップでできる機能は、登場した当初は大きな注目を集めた。しかし、いまや統合開発環境（IDE）が標準で搭載する当たり前の機能になっている。
ノーコード／ローコードでは開発を始めるハードルがプログラミングに比べて低い点は、まぎれもないメリットだ。一方でいくつか問題もある。
まず「ベンダーロックイン」から逃れられない点だ。汎用のプログラミング言語で書いたソフトウエアは、様々なプラットフォーム上で動作する。一方、ノーコード／ローコードツールで開発したソフトウエアは、そのままでは別のツールの環境では動かない。ツール間の互換性がないことが多いからだ。
あるツールを一度使い始めたら、そのツールを使い続ける必要がある。しかし、ベンダーがそのツールの提供をやめたり、ベンダー自体がなくなってしまったりする事態も考えられる。一般論でいえば、大手ベンダーが提供する人気の高いツールを使うのが無難だろう。
また、ノーコード／ローコードには、複雑なシステムの開発には向いていないという特性もある。ノーコード／ローコードでは、手軽さを実現するためにソフトウエアの領域を絞り、あらかじめ用意した部品の組み合わせでシステムを構築することが多い。開発できるシステムの自由度は必然的に低くなる。
ただし、これはデメリットとまではいえないだろう。ミッションクリティカルな基幹系システムは従来の手法で開発し、ちょっとした業務改善のためのシステムは労力をかけずにノーコード／ローコードで開発する、という役割分担をすればいいだけの話だ。
