最新のツールやサービスによって開発者の生産性は向上するものの、依然として「アプリギャップ」は存在する。これは、開発者が持つリソースで構築できるコードと、利害関係者が求めるコードの隔たりだ。開発チームには大きな負担がかかっており、仕事に優先順位を付けて、コアビジネスシステムとそれに必要なツールに注力せざるを得なくなっている。
そのため、ローコードツールが人気になったのは意外なことではない。ローコードの根幹にあるのは、エンドユーザーに必要なアプリケーションの構築と共有に役立つツールセットを提供するという耳慣れたコンセプトだ。「Excel」と「Access」の論理的な後継技術であるローコードツールは、データへのアクセスを開放して、アプリケーションとサービスを結びつける手段を提供する遊び場であり、共通のビルディングブロックからシンプルなユーザー体験を構築することができる。業務からワークフローを抽出し、それらの取得したアクションをコードに変換できる現代的なプロセスオートメーションツールと考えていいだろう。
「Zapier」やMicrosoftの「Power Platform」などのローコードツールは、ユーザーが必要なアプリを必要なときに構築できるようにして、開発の需要を軽減する手段とみなされることが多い。アプリギャップを低減する有効な手段ともいえるが、大きな制限があるため、ローコードツールを他と切り離して見るのは不可能だ。
APIを管理
ローコードの導入を急ぐあまりに忘れられがちなことだが、これは本質的にワークフローと統合のテクノロジーであるため、エンドポイントを構築して管理する。ここでは既存の開発チームが不可欠になる。というのも、既存のアプリケーションとサービスのマネージドAPIを提供する作業を担当してもらう必要があるためだ。大半のローコードツールで使用される「REST」ベースのAPIモデルは実装とサポートが比較的容易だが、そのプロセスによって一連の新たな問題が発生する。それらのAPIへのアクセスを誰に許可し、APIを通してどれだけのものにアクセスできるようにすべきなのか。
ローコードソリューションは、既存のIDプラットフォームに紐付いた何らかの形でのAPI管理なしに導入することはできない。データのセキュリティと整合性を確保するために、ロールベースアクセス制御と管理されたスロットルが必要になる。必要なユーザー以外は保護されたデータにアクセスできないようにするとともに、ユーザーが多すぎるせいで基幹業務システムの運用に影響が出ないようにしなければならない。API管理をローコードスイートの一部にすれば、APIへのアクセスが必要なユーザーにシンプルなセルフサービスプロセスで対応し、不使用のアカウントを回収してデータの損失を回避することができる。
チームでの作業
また、ローコードが単独で開発されるという問題がある。アセットが複数回作成されるケースは非常に多く、コードの再使用と移植性という利点が活かされていない。問題の一端は、多くのローコードがユーザー固有の環境で開発されており、ソース管理システムやGitHubなどのソーシャルコーディング環境と統合されていないことにある。原初のローコード環境であるExcelでさえ、ユーザー固有のモデルから離れつつあり、新しいLAMBDA関数によってコードブロックを異なるプロジェクト間で共有できるようになっている。
もちろん、視覚的なドラッグ＆ドロップキャンバスで生成されるとしても、ローコードがコードであることに変わりはない。主流のエンタープライズ開発でコードを扱うのと同じようにローコードを扱い、安全性と信頼性を確保する必要がある。また、可能な場合は、それらのアプリケーションの構築に使う知識を保持し、他のチームと共有できるようにしておきたい。
初期のローコードツールは、それに不可欠なものが多く欠けていた。確かに、ローコードツール中心のプロセスを作成して、開発者のレビューやその他のマイルストーンを設けることはできたが、そうしたアプローチはローコードの明白な利点を阻害し、数カ月しか使用されないようなアプリを迅速に開発する妨げとなる。
