CW：意外に根付かないRAD開発

「ローコード」アプリケーション開発のススメ

パーツを選んで設定を変更して他のパーツにつなげる。こうしてコーディングせずにアプリケーションを開発できるのがローコードプラットフォームだ。これを使うのは開発者の甘えなのだろうか？

公開 2018年04月12日 08時00分

更新 2020年03月17日 10時09分

著者

Adrian Bridgwater

[Computer Weekly]

印刷する連載新着通知を受け取る

　開発者は、いわゆる「ローコード」プラットフォームについてどう感じているのだろう。

　実のところ、まだよく分からない。アプリケーション開発全体の歴史を考えれば、その存在自体が比較的新しい現象なのだ。

　この分野で重要な役割を果たす企業の1つがOutSystemsだ。同社のローコードプラットフォームを使えば、アプリケーションをビジュアルに開発し、既存のシステムに統合できる。必要に応じて独自のコードを追加することも可能だ。

　今は、コード自動化、インテリジェントプロビジョニング、コンテナ化されるアプリケーション構造、パッケージサービスなど、さまざまなアプローチが花盛りの時代だ。この時代なら、ローコードは「能力が乏しい怠け者のプログラマーしか使わない」といった風評から抜け出せるのではないだろうか。いずれは、大量にソフトウェアを開発する企業にとっても便利で実用的な機能になるのだろうか。

　OutSystemsで英国とアイルランド担当のバイスプレジデントを務めるニック・パイク氏は、（間違いなく）ローコードの利用は広がると考えている。そのため、今は開発分野におけるローコードの立場を明確にすることに時間をかけている。つまり、高速プログラミングの分野では、RAD（Rapid Application Development）とアジャイル開発の違いをはっきりと理解し、正しく認識しなければならないのだ。

常にコードを高速に

　RADとアジャイルはどちらも簡単に言えば、コーディングを高速にする手段だと広く考えられている。だが、その違いはどこにあるのだろう。

　「RADもアジャイルも、ソフトウェアの配信を迅速かつ継続的に行うことを重視し、開発の後半でも要件の変更を受け入れる。ただし、アジャイルではその手法と理想的な作業環境が規定される。RADの方がはるかに柔軟性が高く、ソフトウェアを配信する正確な方法やスケジュールよりも品質の高い成果が重視される」

RAD方法論

　パイク氏によれば、開発サイクルの中で変化する顧客の構想に対応する柔軟性にRADの本質があるという。まず、大まかな要件を定義する。開発者はここから製品が何を実現する必要があるかを発想する。ただし、前段の詳細仕様書から懸け離れてはいけない。

　「次に、開発者は要件の全てまたは一部を満たすプロトタイプを作成する。このプロトタイプでは、ある作業状態に至る工程を省略できる。これが受け入れられるのは、その工程で生じている技術的課題を後の工程で吸収できるためだ。このプロトタイプをクライアントに提示し、クライアントからのフィードバックを得る。この時点で、クライアントは意見を変えたり、理論上適切だと思われていたことが実際には意味を成さないことに気付いたりすることがある。この種の改訂はRADアプローチの一環として受け入れられる。開発者は前の工程に戻り、製品の見直しを行うことになる」（パイク氏）

　クライアントからのフィードバックが全面的に肯定的であれば、開発者は製品の仕上げ工程に移る。そして、製品が要件を満たしているという確信を持ってクライアントに納入できる。