高速アプリケーション開発とは

3. フィードバックの取り込み

準備した最新のプロトタイプを、RAD開発者が顧客またはエンドユーザーに見せます。そして、インターフェイスや機能に関するあらゆるフィードバックを収集します。この段階で、必要であれば製品要件を精査します。

顧客の考えが変わる場合や、机上では適切に思えた内容がプロトタイプにするとおかしいとわかる場合があるからです。顧客も人間なので、これは仕方ありません。フィードバックがそろったら、ステップ2の段階に戻ってプロトタイプの作成を続けます。フィードバックがすべて肯定的なもので、顧客もプロトタイプに満足している場合は、ステップ4に進みます。

4. 製品の完成

この段階では実装の最適化や再設計を行い、安定性や保守性を高めていきます。本番データとバックエンドとの接続、ドキュメントの作成、本番への確実な移行を実現するために必要なその他の保守タスクを行うこともあります。

Boehm氏のスパイラルモデルとMartin氏のRADモデルのいずれにおいても、これら4つのステップに従うことで開発チームはリスクを低減し、優れた製品を開発することができます。ただし、高速アプリ開発には欠点もあります。

高速アプリケーション開発のメリット

RADのメリットについてはすでにいくつか説明しましたが、改めて掘り下げて見ていきます。

高速アプリケーション開発のデメリット

もちろん、高速アプリケーション開発もバラ色のメリットばかりというわけではありません。では、この流れに冷や水を浴びせるようなデメリットをご紹介しましょう。

高速アプリケーション開発がチームに適するかどうか

これで、RADプログラミングのメリットとデメリットがわかりました。では、高速アプリ開発手法でメリットを得やすいプロジェクトタイプを考察していきましょう。

社内ビジネスツール、またはアプリやWebサイトなどの顧客向けポータルを作成する場合は、高速アプリ開発手法でエンドユーザーエクスペリエンスを向上させることができます。 しかし、基幹ソフトウェア（航空管制システム、植え込み型ファームウェアなど）を開発する場合にRAD手法を採用するのは、不適切なだけでなく無責任だといえます。制御モジュールの故障を体験したパイロットや、ペースメーカーの誤動作に悩まされた心不全患者が、あの世からプロトタイプのフィードバックを提供することはできないからです。

プロジェクトで高速開発環境を選択する際には、前もって次のような点を確認しましょう。

1. 製品がミッションクリティカルかどうか

製品がエンドユーザーのセキュリティや生命に関わる場合、エラーはほぼ許容されません。高速開発環境を利用できるのは、エラーの試行錯誤が許される場合のみです。

誰にも悪影響を及ぼすことなく製品のシミュレーションを行うことができる場合は例外ですが、エンドユーザーへの公開前にプロジェクトを完璧に仕上げる必要がある場合、そもそも高速アプリ開発は選択肢から外すべきです。

2. エンドユーザーや顧客のフィードバックを取得できるかどうか

この記事で説明してきたとおり、高速アプリケーション開発には、エンドユーザーの協力が欠かせません。積極的なフィードバックの提供やユーザーテストへの参加などが求められます。

顧客も、進行中の高速アプリケーション開発プロセスのイテレーションでは頻繁にフィードバックを提供する必要があります。

3. 成果物を分割できるかどうか

高速開発環境では、ユーザーフローが不完全だったり不足したりしているプロトタイプを、早い段階で頻繁にエンドユーザーに公開する必要があります。そのため、プロジェクトを分割し、製品全体ではなく一部（またはモジュール）を開発して提示することが求められます。モダナイゼーションの障壁となることが多いのが、ビジネスユースケースをエンドユーザーに提供する前に行う、バックエンドでの複数のサードパーティとの連携です。

この問題は、エンドユーザーが想定するデータセットに似た模擬データを生成するデータ合成プロセスを利用することで回避できます。これにより、事前にコネクタを作成するという手間を増やさず、プロトタイプで動作をモデル化することができます

4. チームが迅速にイテレーションを行うことができるかどうか

最後は当たり前のような質問になりますが、RADプログラミングに見合うペースでイテレーションを行うことができるかどうかを自問しましょう。もちろん、従来のソフトウェア開発手法で生成したコードが変更不可能というわけではありませんが、変更に相当の労力を伴う「骨組み」部分があることは確かです。プロジェクトの骨組みとなる必要最小限のコード、つまりボイラープレートを作成する労力もゼロではありません。大きな労力が必要になる場合も多いのです。

アプリケーションの中核を構築したり、不適切な前提を途中で修正したりすることで、どうしても実用プロトタイプのデリバリーに費やせる時間やエネルギーが削られてしまいます。また、開発チームだけでなく、設計チームと製品チームにもアイディエーションとアシミレーション（顧客やエンドユーザーからのフィードバックの処理）とのコンテキストの切り替えを前向きに、かつ迅速に行うことが求められます。

このプラクティスがすべてのチームに浸透するとは限りませんが、少なくとも学んだり、便利なツールを活用したりすることはできます。チームが迅速にイテレーションを行うことができない場合や、その実現に役立つツールに予算をかけられない場合、RAD開発は選択肢としてふさわしくないかもしれません。

RADとアジャイルの比較

開発手法について調べる際は、フレームワーク同士を比較するのが通例です。高速アプリケーション開発はアジャイルソフトウェア開発と直接比較されがちです。

しかし、この二つを比べるのは難題といえます。確かにRADはアジャイルの前身ですが、アジャイルは「開発モデル」の概念を大きく超えます。手法というよりは、哲学というべきものなのです。 このことが伝わるよう、各コンセプトの基本原則を比較してみました。

高速アプリケーション開発ツール

おわかりいただけたかと思いますが、高速アプリケーション開発は特定の言語、ツール、インターフェイスというよりは、むしろソフトウェア開発手法です。しかし、高速なプロトタイプ作成、開発、フィードバック収集の推進にはツールが役立ちます。

設計・プロトタイプ作成用ツール

このカテゴリの製品を利用すると、インタラクティブな設計を非常に迅速に行えるようになります。また、リストに掲載されているWebflowなど一部のツールでは、デザイナーが設計全体をブラウザに依存せず動作するプロトタイプとしてエクスポートすることができます。

ユーザーテスト・フィードバック用ツール

ここまで何度も説明したとおり、RAD手法では顧客やエンドユーザーからの頻繁なフィードバックが必要です。また、最近の業態として、オフサイトで働く開発者は顧客からのインプットが必要になるたびに泊まりがけの出張をするのではなく、リモートでフィードバックをもらいたいと考えています。

高速アプリケーション開発ツール

チームのテクノロジー要件が厳格である場合やスキルが限られている場合、今の手法を貫くほうが簡単です。テクノロジーの移行コストを正当化できない場合が多いからです。しかし、新しい開発アプローチを積極的に検討しようとするのであれば、このカテゴリのツールが生産サイクルの加速に役立ちます。

OutSystemsで高速アプリケーション開発を実現する方法

おわかりいただけたかと思いますが、高速アプリケーション開発は特定の言語、ツール、インターフェイスというよりは、むしろソフトウェア開発手法です。しかし、高速なプロトタイプ作成、開発、フィードバック収集の推進にはツールが役立ちます。

OutSystemsは、AIによって強化された最先端のローコードアプリケーションプラットフォームです。高速アプリケーション環境だけでなく、ホスティング、動的な拡張、リリースの自動化、パフォーマンス監視、ユーザー管理、バージョン管理など多くのことを実現できます。その最たるものが強力な開発環境です。

OutSystemsプラットフォームは、複雑な作業を自動化・簡素化する高生産性ツールと従来の開発手法のパワーや表現力を組み合わせることで、ITに近い役割を担う人員がベテランのITプロフェッショナルのようにエンタープライズレベルのWebアプリケーションやモバイルアプリケーションを高速に作成することを可能にします。

高速な開発の体験

オンラインデモを予約するか、OutSystemsの無償版をお試しください。