ローコード／ノーコードソフトウェア開発が内包するリスク：Computer Weekly製品ガイド

最新のローコード開発ツールは、ビジネスユーザーと開発者の両方の助けになり得る。その現状を解説する。

[Bob Tarzey，Computer Weekly]

　ビジネスユーザーがRAD（ラピッドアプリケーション開発）ツールを使い、自らプログラムを開発して生産性を高めようとする取り組みが長年にわたって続いてきた。基本的な表現や文字入力以外はコーディングをほとんど伴わないビジュアル開発環境がそれだ。最初にこのアイデアが脚光を浴びたのは1980年代と1990年代で、関連するツールは4GLと呼ばれた。先駆者のほとんどは数年の成功を経て衰退したが、ここ数年で再びこのアイデアが、「ローコード」と名前を変えて注目されるようになった。これは野心的に「ノーコード」プログラミングと呼ばれることもある。

　ローコード開発ツールは宣言型、つまり一般的なアプリケーションを構成するユーザーインタフェースやビジネスロジック、アルゴリズム、データ処理のビジュアルなモデリングが可能で、制御用のコードを記述する必要がない。画面の背後で何千行ものコードが生成されることもある。そうしたコードにアクセスして手を加えることも可能だ。それが必要とされる量が多いほど技術性は強まる。3GLスキルが要求される度合いは必要性と使う製品によって異なる。

　ローコード開発ツールのプロバイダーのほとんどは自分たちの製品について、真にビジネスユーザーを支援でき、従来の開発者も企業向けアプリケーションを開発できると主張する。4GLが失敗した分野でローコード開発が成功できるとプロバイダーが確信する理由の一つとして、平均的なビジネスユーザーは20〜30年前よりも技術に詳しくなっていることが挙げられる。さらに、アプリケーションがツールプロバイダーのクラウドプラットフォームにデプロイされることが多く、パフォーマンスや可用性、拡張性、サービス品質、セキュリティをコントロールできるという事情もある。

関連記事

• 「ローコード」アプリケーション開発のススメ
• AI＋RPA＋ローコード開発製品によるタスク自動化環境
• RPAによって自動化したプロセスをさらにスマート化する方法
• AIがスクリプトを生成するコードレスなアプリテスト自動化ツール登場
• APIファーストアプローチのソフトウェア開発、成功の秘訣

ローコード開発のメリットとデメリット

　こうしたデプロイ方式は、ローコード開発の主なデメリットの一つ、すなわちプロプライエタリによる囲い込みの問題を浮上させる。ただしこの問題は、批判的な立場から誇張されることもある。第一に、多くのサプライヤーは「Amazon Web Services」（AWS）や「Microsoft Azure」「Google Cloud」といった主要なパブリッククラウドへのデプロイに対応している。ただし、生成されるコードがプロプライエタリになって移植できないこともある。たとえ非プロプライエタリな3GLコードが生成されたとしても、従来のプログラマーにとってさえも扱いにくい構造や形式であることもある。

　ローコード開発ツールには、そのまま使えるコンポーネントを提供するライブラリが付属している。これを使えばブロックチェーンや人工知能（AI）といった最新のイノベーションに対応できる。コンポーネントはそのツールのサプライヤーやサードパーティー、ユーザーのコミュニティーから提供され、有料のものも無料のものもある。外部との連携を可能にするAPIは、例えばWebサービスを呼び出すことができる。APIはかつての4GLには欠けている場合もあった。多くがアプリケーション開発の中心的存在と見なすバージョン管理やDevOps対応といった機能については、ローコード開発ツールによってサポート度が異なる。

　ローコード開発ツールのプロバイダーはさらに、アプリケーションテストの高速化、エラー率の低下、信頼できるセキュリティの向上をうたっている。これらはいずれもコスト削減につながり、4GLでは不十分と見なされた分野だった。当然ながら、ローコード開発ツール自体の料金は必要だ。一方、3GLコンパイラの多くはオープンソースで、無料のオープンソースライブラリを活用している。

　ローコード開発ツールサプライヤーは、自分たちの製品はコスト効率が高いと主張する。プログラマーの雇用は高コストであり、ローコード開発ツールを使えばビジネスユーザーが開発の主導権を握ってプログラマーの必要性を減らせるという理由による。だが現実はもちろん、それがどの程度達成できるかにかかっている。多くの場合、現在いるプログラマーが少しだけ生産的になれるという程度にとどまる。

サプライヤー

　ローコード／ノーコード開発の分野に参入するサプライヤーは、本稿では網羅し切れないほど増えている。必然的にここで取り上げるサプライヤーは一部にすぎない。そうしたサプライヤーはローコード開発にさまざまな角度からアプローチし、それぞれ違うニッチに対応している。小規模の非上場企業でごく最近台頭してきたばかりのサプライヤーもあれば、昔ながらの大手もある。吸収合併は始まっており、今後も統合が続くだろう。

　大手の中の一社、Microsoftは既存の複数の製品を組み合わせて「PowerApps」というローコード開発ツールを作り、Azureと密接に連携させている。Oracleには同社のデータベース管理システムと連携させた「Oracle Application Express」と「Visual Builder Cloud Service」という2つのローコード開発ツールがあり、クラウドベースとオンプレミスのデプロイに対応している。Salesforce.comは2014年、複数の製品を組み合わせた「Salesforce Lightning」を登場させた。同製品はAppExchangeライブラリによって支えられ、「Force.com」で他のアプリケーションを拡張するために使われることもある。同製品はプロプライエタリなApexコードを生成する。

　Quick Baseは1999年にさかのぼる古参だが、現在はインメモリデータベースをベースとする完全なクラウドベースプラットフォームになった。

　Pegasystemsも1980年代にさかのぼる。同社のローコード開発ツール「Pega Infinity」がビジネスプロセス管理から進化したのに対し、同社の「App Studio」にはRPA（Robotic Process Automation）のような複雑なニーズ用のコンポーネントが含まれる。Zohoの「Creator」は2006年にリリースされた。同製品で運用されているアプリケーションは公称500万以上。スモールビジネスに重点を置いていることも一因だが、エンタープライズユーザーも存在する。同製品は「Deluge」というプロプライエタリのスクリプト言語を使う。OutSystemsのローコード開発ツールはモバイル、ウェアラブル、モノのインターネット（IoT）、Webアプリケーションの開発に対応する。C#と.NETのコードを生成し、同社またはパブリッククラウドでデリバリーできる。オンプレミスにもある程度は対応する。ユーザーはビジネスユーザーよりもプロの開発者の方が多い。

　新手のニッチサプライヤーとしては、Betty Blocksのノーコード開発ツールが2012年に初リリースされた。コア機能をカプセル化した「ブロック」を組み立てる形でアプリケーションを構築する。顧客の約90％は同社のクラウドにデプロイしているが、Azureとオンサイトホスティングにも対応する。拡張機能の開発には「Elixir」というコードを利用する。一方、2013年に創業したSkuidの設計＆デプロイ製品は、ユーザーが分散されたデータソースに接続し、コードを書くことなくオーダーメイド方式のアプリケーションを組み立てることができる。同社はSAPおよびGoogleと提携している。

　ニッチにフォーカスしている新興サプライヤーもある。Appianはビジネスプロセス管理市場の出身で、同社のローコード開発ツールは企業のプロセス自動化をルールの定義と分析の提供の両方で支援する。DevOpsのサポートによってCI/CDの自動化を実現し、包括的なセキュリティ証明書もそろっている。Mendixの強みはIoTのサポートにある。これを目的として2018年にSiemensに買収され、Siemensの「MindSphere」に統合された。デプロイはオンプレミスの他、幅広いクラウドプラットフォームに対応する。同社はIBMおよびSAPとも提携している。AppSheetは主にモバイルアプリ開発に重点を置き、ビジネスユーザーを開発者として後押しすることが成功の鍵になると考えている。

買い手の責任負担

　経験豊富なプログラマーの多くは1980年代に4GLに取り組み始めた。まず「VAX Rally」は、当時のIT企業の中で最も大きな成功を収めていたDEC（Digital Equipment Corporation）が後押ししていた。この製品を今Googleで検索すると、Computer History Museumの項目が1件のみ表示される。

　各サプライヤーは、4GLが衰退した分野で現代のローコードおよびノーコード開発ツールが勝利できると確信する。ただし一部は勝ち残れるかもしれないが、全てではない。全社が生き延びるには、この市場は混み合い過ぎている。

　評価に当たっては開発機能だけに着目するのではなく、生成されたアプリケーションやコードの長期的なサポートにも目を向ける必要がある。その寿命がサプライヤーそのものの寿命を上回る可能性もある。場合によっては従来型の3GL言語の方が、長期的なサポートに優れるという結論に達するかもしれない。