ローコード開発の課題とソリューション

テクノロジーの世界で新しい話題が尽きると、私たちはしばしば懐かしい過去の引き出しを開けて、古き良き記憶を取り出します。そこでは、誰もが自分の持つ歴史的な経験を披露し合うような、ちょっとした自慢大会が始まるものです。

「私はTRS-80で『スタートレック』をプレイしていましたよ。BASICで書かれていて、キャラクターのセリフを変更したりして『本当ですか、スポック氏？それは論理的ではありませんね』なんて。」

「へぇ、私はApple IIで『Beyond Zork』をプレイしていました。すべてのコマンドをキーボードで打ち込まなければならなかったんですよ！」

「Atari 800でカセットテープに保存したプログラムを再生して、ソースコードがどんな音を出すのか確認したことを覚えていますか？」

「私は初めてのプログラムを、パンチカードとカードリーダーを使ってメインフレームで実行しましたよ」

長年プログラミングに携わってきた者として、前世紀に解決しようとしていた同じ課題に対して、異なる用語や技術で再構築された古いコンセプトを目にするのは驚きです。これらのコンセプトを理解する上で重要なのは、特定の課題を解決するためのソリューションの歴史ではありません。むしろ、世代を超えて同じ問題に取り組む必要性を認識し、なぜ以前のソリューションでは問題を完全に解決できなかったのかを探ることです。それらのソリューションは時代を先取りしすぎていたのでしょうか、それともより根深い問題があったのでしょうか？

ローコード開発の課題

ローコード開発というコンセプトは、プログラミングの黎明期から存在していました。当時は「ローコード」や「ノーコード」とは呼ばれていませんでしたが（4GL、CASE、RADなどの呼称でした）、ローコード開発が実現しようとしている課題は、アラン・チューリングが「なぜそのコーディングにそんなに時間がかかるんだ!?」と叫んでいた時代から（これは創作的な引用ですが、実際にあってもおかしくありません）、常に優先課題でした。

この問題の核心は、システム開発における高コストな人的リソースへの依存をいかに軽減するか、そして開発ライフサイクルをいかに加速させるかという点にあります。

ローコード開発の目的

1. 企業はいかにして開発者への依存度を下げることができるでしょうか？ここでは基本的な需要と供給の法則が適用されます。需要が増加し供給が限られている状況では、コストは上昇します。すべてのアナリストが指摘するように、アプリケーション開発への需要は記録的なペースで増加し続けています。ローコード開発は、非技術者でもグラフィカルなポイント＆クリックのユーザーインターフェースを通じて、コードレスまたは最小限のコードでアプリケーションを作成できる機能を提供します。ローコードアプリケーションは、非技術者のインプットに基づいてプログラムを構築し、必要なコードを生成します。
2. この魔法のような機能を実現しながら、いかにしてプロセスを加速できるでしょうか？ローコード開発の背景にある考え方の一つは、パワーユーザーが要件をビジネスアナリストに伝え、アナリストがそれを文書化して開発者（ビジネスを理解していなくても必要なコードを作成する）に回すという従来のプロセスを、エンドユーザー自身がアプリケーションを構築することで高速化できないか、というものです。必要なのは単純なポイント＆クリック操作だけです。魔法のボタンを押せば、新しいプログラムが出来上がります。

ローコード開発の問題

ローコード開発アプローチは、いくつかの重大な問題を引き起こしました。最も顕著なのは、狭い範囲のビジネス機能をサポートする、多数の小規模で非連携のアプリケーションが乱立したことです。これらのアプリケーションは、エンドユーザーが正しいと解釈したビジネスルールに基づいて個別に構築されましたが、実際には、そのビジネスルールが正しくなかったり、特定のビジネス領域を超えた有効性が限られていたりしました。このアプローチは多くのエンドユーザーを満足させたかもしれませんが、システム全体でのデータの品質と一貫性を確保する企業戦略とガバナンスの遵守が欠如していました。これらのソリューションは、必ずしもベストプラクティス（バージョン管理、統合テストなど）をサポートしておらず、セキュリティリスクを増大させることもありました。結果として、組織の各部門は自分たちのローカルシステムのデータを絶対的なものとして受け入れましたが、異なるロジックのため、ビジネス機能間で情報が一致することはほとんどありませんでした。これが適切な意思決定戦略とならないことは明らかです。

もう一つの問題は、組織全体の重要なビジネス機能を担うアプリケーションの数でした。時間の経過とともに、元の開発者が去り、IT部門は、文書がほとんどないか全くない、急速に老朽化・陳腐化する技術で構築された何百、何千ものアプリケーションのサポートに追われることになりました。他のビジネス機能への影響を把握せずに、ドキュメント化されていない何千ものアプリケーションを廃止しようとするのは困難です（私もこのような取り組みに参加したことがありますが、夏休みを台無しにしかねません）。最終的に、監視、ガバナンス、ベストプラクティスの欠如は、アプリケーションを迅速に作成できるメリットを上回る大きな混乱を生み出しました。

現在のローコード開発ソリューション

いくつかの企業は、ローコードの概念をより戦略的で包括的なアプローチへと進化させました。現在のエンタープライズプラットフォームでは、非技術者でもポイント＆クリック型のフロントエンドを使用して、アプリケーションのデータモデル、ビジネスロジック、データ関係を管理できます。これらの情報はデータとして扱われ、データベースなどに保存されます。この産業用ローコードアプローチにより、非技術者はプラットフォーム上で複数のエンタープライズアプリケーションにまたがる単一のデータモデルを構築しながら、すべてのアプリケーションのビジネスルールを一貫して管理できます。この重要な情報は、孤立したアプリケーションではなく、より大きな環境の一部として存在するため、ポータブルとなり、プラットフォームのアップグレードや適応が可能になります。最も重要なのは、ビジネスルールのような重要な変更を、高額なプログラマーではなく、非技術者が時間をかけて行えることです。

もちろん、先に説明した元のコンセプトに基づいて、ローコード/ノーコード開発ソリューションの現代版を提供している企業も多くあります。これらのソリューションでは、非技術者がデータソースをビジュアル出力に接続することで、コードを作成せずにリアルタイムの情報を提供する簡単なアプリを迅速に構築できます。これらのアプリの中には、書き戻し機能を提供したり、ワークフロープロセスのような一般的なビジネス機能の中で動作したりするものもあります。これらは、このようなソリューションの優れたユースケースであり、運用情報をリアルタイムでユーザーに提供する上で特に効果的です。素晴らしいことです！

このモデルで私が懸念する問題は、以前の世代のローコードで経験した問題と同じです。適切なガバナンスと戦略がなければ、アプリケーションは制御可能な速度を超えて作成されてしまいます。これらのソリューションは戦術的なものであり、一貫したビジネスルールを管理する中央集権的な場所を提供しないため、重要なビジネスロジックがシステム間で切断され、分離されたままになります。さらに、ビジネスロジックが変更されたり、技術のアップグレードが必要になったりした場合、企業は何百、何千ものアプリケーションにわたるビジネス変更の影響を判断し、必要な変更を行うプロセスを開始しなければなりません（痛い経験があり、もう二度と戻りたくありません）。

まとめ｜ローコード開発の課題とソリューション

ローコード開発は長い間存在し、さまざまな形で再登場してきましたが、開発の現場で確固たる地位を維持することに苦心してきました。しかし、より安価で迅速なシステム開発の必要性は変わっておらず、人々が常にローコードの概念に立ち返るという事実は、有効なソリューションを導き出せる可能性を示しています。

現在の多くのローコード開発ソリューションは、ユーザーにリアルタイムで情報を提供できる小規模で単純なアプリの迅速な作成に焦点を当てています。問題は、有効なユースケースがあるかどうかや、ソリューションが機能するかどうかではなく、より重要なのは、企業が開発環境を管理できなくなる前に、開発の取り組みを統制する勇気があるかどうかです。時が答えを示すでしょうが、その混乱の収拾は私に任せないでください。

新しい産業用ローコードアプローチは、ローコードの概念を新しい次元に引き上げています。Arasのような企業は、ローコードの概念を用いてプラットフォームを設計し、アプリケーション構築に必要なコード量を大幅に削減しています。Aras Innovatorは、ビジネスとそのプロセスをモデル化することで、使いやすいUIで非技術者がビジネスルールとデータ関係をサポートするデータモデルを作成します。Arasの産業用ローコードソリューションは、単一のプラットフォーム上でエンタープライズアプリケーションを構築する豊富なプラットフォームサービス群の上に構築されています。この強靭なプラットフォームは、プログラマーを必要とせずに新しいビジネス要件に適応できる、安全でアップグレード可能かつスケーラブルな環境を提供します。

これら2つのアプローチは共にローコードの概念を活用していますが、実際には比較できないものです。一方は当時と同じリスクを伴う過去の取り組みの再来であり、もう一方はアプリケーション開発における大きな前進です。

ついに、数世代にわたるソフトウェア開発を経て、高額な開発者への依存度を下げながら開発ライフサイクル時間を短縮するという目標が実を結びました。アラン・チューリングも少しは安心できることでしょう。