迅速なアプリケーション開発

ラピッド アプリケーション開発( RAD ) は、ラピッド アプリケーション構築( RAB ) とも呼ばれ、適応型ソフトウェア開発アプローチの総称であると同時に、 James Martinのラピッド開発手法の名前でもあります。一般に、ソフトウェア開発に対する RAD アプローチでは、計画よりも適応型プロセスに重点が置かれます。プロトタイプは、設計仕様に加えて使用されることが多く、場合によっては設計仕様の代わりに使用されることもあります。

RAD は、ユーザー インターフェイス要件によって駆動されるソフトウェアの開発に特に適しています (ただし、これに限定されません) 。グラフィカル ユーザー インターフェイス ビルダーは、ラピッド アプリケーション開発ツールと呼ばれることがよくあります。ラピッド開発へのその他のアプローチには、アダプティブモデル、アジャイル モデル、スパイラル モデル、統合モデルなどがあります。

迅速なアプリケーション開発は、1970 年代と 1980 年代に開発された、構造化シ​​ステム分析設計法(SSADM) などの計画主導のウォーターフォールプロセスへの対応でした。これらの方法の問題の 1 つは、橋や建物などの設計と構築に使用される従来のエンジニアリング モデルに基づいていることです。ソフトウェアは、本質的に異なる種類の成果物です。ソフトウェアは、問題解決に使用されるプロセス全体を根本的に変えることができます。その結果、開発プロセス自体から得られた知識をソリューションの要件と設計にフィードバックできます。^[1]計画主導のアプローチでは、要件、ソリューション、およびそれを実装する計画を厳密に定義しようとし、変更を抑制するプロセスがあります。一方、RAD アプローチでは、ソフトウェア開発が知識集約型のプロセスであることを認識しており、プロジェクト中に得られた知識を活用してソリューションを改善または適応させるのに役立つ柔軟なプロセスを提供しています。

最初の RAD 代替案は、バリー・ボームによって開発され、スパイラル モデルとして知られていました。ボームとその後の RAD アプローチは、厳密な設計仕様だけでなく、あるいはその代わりに、プロトタイプの開発を重視しました。プロトタイプには、従来の仕様に比べていくつかの利点がありました。

• リスクの軽減。プロトタイプは、ライフサイクルの早い段階で、システムの最も難しい可能性のある部分の一部をテストできます。これにより、設計の実現可能性に関する貴重な情報が得られ、チームが複雑すぎる、または実装に時間がかかりすぎることが判明したソリューションを追求するのを防ぐことができます。ライフサイクルの後半ではなく早い段階で問題を発見できるというこの利点は、RAD アプローチの主な利点でした。問題が早く発見されるほど、対処にかかるコストが安くなります。
• ユーザーは、仕様を作成するよりも、使用して反応することに長けています。ウォーターフォール モデルでは、ユーザーが一連の要件にサインオフしても、実装されたシステムを提示されたときに、特定の設計に重要な機能が欠けていたり、複雑すぎることに突然気付くことがよくありました。一般的に、ほとんどのユーザーは、システムがどうあるべきかを抽象的に定義するよりも、実行中のシステムのプロトタイプを体験できる方が、はるかに有用なフィードバックを提供します。
• プロトタイプは使用可能であり、完成品へと進化することができます。一部のRAD手法で使用されているアプローチの1つは、最小限の機能から中程度の有用性、そして最終的な完成システムへと進化する一連のプロトタイプとしてシステムを構築するというものでした。この方法の利点は、上記の2つの利点に加えて、ユーザーがプロセスのかなり早い段階で有用なビジネス機能を入手できることです。^[2]

バリー・ボームらのアイデアを基に、ジェームズ・マーティンは1980 年代にIBMでラピッド アプリケーション開発アプローチを開発し、最終的に 1991 年にRapid Application Development という書籍を出版して公式化しました。このため、IT プロフェッショナルの間でも RAD という用語をめぐって混乱が生じています。ウォーターフォール モデルの一般的な代替手段としての RAD と、マーティンが考案した特定の方法としての RAD を区別することが重要です。マーティン メソッドは、知識集約型および UI 集約型のビジネス システム向けに調整されました。

これらのアイデアは、ジェームズ・カーやリチャード・ハンターなどのRADの先駆者たちによってさらに発展、改良され、このテーマに関する画期的な書籍「Inside RAD」^[3]を共同執筆しました。この本では、RADプロジェクトマネージャが実際のRADプロジェクトでリアルタイムにRAD方法論を推進し、改良していく過程を追っています。これらの実践者や彼らのような人たちのおかげで、RADは従来のシステムプロジェクトライフサイクルアプローチに代わるものとして人気が高まりました。

RAD アプローチも、ビジネス リエンジニアリングへの関心が最高潮に達した時期に成熟しました。ビジネス プロセス リエンジニアリングの考え方は、情報技術の新しい機能を念頭に置いて、販売や顧客サポートなどのコア ビジネス プロセスを根本的に再考することでした。RAD は、大規模なビジネス リエンジニアリング プログラムの重要な部分になることがよくありました。RAD のラピッド プロトタイピング アプローチは、ユーザーとアナリストが、テクノロジによってコア ビジネス プロセスを根本的に再発明する革新的な方法について「既成概念にとらわれずに考える」のに役立つ重要なツールでした。^{[4] [5]}

ジェームズ・マーティンが RAD に親しみを持てたのは、デュポンの情報エンジニアリング部門とそのリーダーであるスコット・シュルツ、そしてオーストラリアと香港で数多くの RAD プロジェクトを成功に導いた特注の RAD 開発会社を率いたジョン・アンダーウッドとの関係によるところが大きい。

成功したプロジェクトには、ANZ銀行、レンドリース、BHP、コカコーラアマティル、アルキャン、香港ジョッキークラブなど多数が含まれます。

この成功により、スコット・シュルツとジェームズ・マーティンの両名はジョン・アンダーウッドとともにオーストラリアで時間を過ごし、オーストラリアが重要なミッションクリティカルな RAD プロジェクトの実装において圧倒的な成功を収めている理由とその方法の詳細を理解することになりました。

James Martin の RAD アプローチでは、プロセスを 4 つの異なるフェーズに分割します。

1. 要件計画フェーズ–システム開発ライフサイクル(SDLC)のシステム計画フェーズとシステム分析フェーズの要素を組み合わせたものです。ユーザー、マネージャー、IT スタッフ メンバーがビジネス ニーズ、プロジェクト範囲、制約、システム要件について話し合い、合意します。チームが主要な問題に同意し、続行するための管理者の承認を得た時点で終了します。
2. ユーザー設計フェーズ- このフェーズでは、ユーザーはシステム アナリストと対話し、すべてのシステム プロセス、入力、および出力を表すモデルとプロトタイプを開発します。RAD グループまたはサブグループは通常、共同アプリケーション設計(JAD) 手法とCASE ツールを組み合わせて使用​​し、ユーザーのニーズを実用的なモデルに変換します。ユーザー設計は、ユーザーがニーズを満たすシステムの実用的なモデルを理解し、変更し、最終的に承認できるようにする継続的な対話型プロセスです。
3. 構築フェーズ– SDLC と同様に、プログラムおよびアプリケーション開発タスクに重点を置きます。ただし、RAD では、実際の画面やレポートが開発されるときに、ユーザーが引き続き参加して、変更や改善を提案できます。そのタスクは、プログラミングとアプリケーション開発、コーディング、ユニット統合、およびシステム テストです。
4. カットオーバーフェーズ– データ変換、テスト、新システムへの切り替え、ユーザートレーニングなど、SDLC実装フェーズの最終タスクに似ています。従来の方法と比較すると、プロセス全体が圧縮されます。その結果、新しいシステムの構築、提供、運用開始がはるかに早くなります。^[6]

現代の情報技術環境では、多くのシステムが、ある程度のラピッドアプリケーション開発^[7]（必ずしもジェームズ・マーティンのアプローチではない）を使用して構築されています。マーティンの方法に加えて、アジャイル手法やラショナル統一プロセスがRAD開発によく使用されます。

RAD の利点として挙げられるものは次のとおりです。

• 品質の向上。ユーザーが進化するプロトタイプとやり取りすることで、RAD プロジェクトのビジネス機能性は、ウォーターフォール モデルで達成されるものよりはるかに高くなることがよくあります。ソフトウェアはより使いやすくなり、開発者の関心のある技術的な問題ではなく、エンド ユーザーにとって重要なビジネス上の問題に集中できる可能性が高くなります。ただし、セキュリティや移植性など、非機能要件(制約または品質属性とも呼ばれる)と呼ばれる他のカテゴリは除外されます。
• リスク管理。RAD に関する文献の多くは、スピードとユーザーの関与に焦点を当てていますが、正しく実行される RAD の重要な特徴はリスクの軽減です。Boehm が当初スパイラル モデルをリスク ベースのアプローチとして特徴付けたことは覚えておく価値があります。RAD アプローチは、早い段階で主要なリスク要因に焦点を当て、プロセスの初期段階で収集された経験的証拠に基づいて調整できます。たとえば、システムの最も複雑な部分のプロトタイプ作成の複雑さなどです。
• より多くのプロジェクトが時間通りに予算内で完了します。増分ユニットの開発に重点を置くことで、大規模なウォーターフォール プロジェクトを悩ませてきた壊滅的な失敗の可能性が減ります。ウォーターフォール モデルでは、6 か月以上の分析と開発を経て、システム全体を根本的に再考する必要があることに気付くのが一般的でした。RAD を使用すると、このような情報をプロセスの早い段階で発見し、それに基づいて行動することができます。^{[2] [8]}

RAD の欠点として挙げられるものは次のとおりです。

• 新しいアプローチのリスク。ほとんどの IT ショップにとって、RAD は、経験豊富な専門家が作業方法を再考する必要のある新しいアプローチでした。人間は事実上常に変化を嫌うため、新しいツールや方法で実行されるプロジェクトは、チームが学習する必要があるという理由だけで、最初は失敗する可能性が高くなります。
• 通常の操作ではエンドユーザーには見えないことが多い非機能要件に重点が置かれていません。
• 貴重なリソースの時間が必要です。RAD へのほぼすべてのアプローチに共通していることの 1 つは、ライフサイクル全体を通じてユーザーと開発者の間でやり取りがはるかに多いことです。ウォーターフォール モデルでは、ユーザーは要件を定義し、開発者がシステムを作成するとほとんどが立ち去ります。RAD では、ユーザーは最初からプロジェクト全体に関与します。これには、ビジネス側がアプリケーション ドメインの専門家に時間を投資する意思があることが必要です。逆説的なのは、専門家が優秀で、自分のドメインに精通しているほど、実際にビジネスを運営する必要が増し、上司に時間を投資するよう説得するのが難しくなる可能性があることです。このようなコミットメントがなければ、RAD プロジェクトは成功しません。
• 制御性の低下。RAD の利点の 1 つは、柔軟で適応性の高いプロセスを提供することです。理想は、問題と機会の両方に迅速に適応できることです。柔軟性と制御性の間には避けられないトレードオフがあり、一方が多ければ他方は少なくなります。プロジェクト ( 生命にかかわるソフトウェアなど) が敏捷性よりも制御性を重視する場合、RAD は適切ではありません。
• 貧弱な設計。プロトタイプに重点を置きすぎると、場合によっては「ハックアンドテスト」方式になり、開発者が個々のコンポーネントに小さな変更を絶えず加え、全体的な設計を改善できる可能性のあるシステムアーキテクチャの問題を無視することになります。これは、システムのユーザーインターフェイスに重点を置くマーティンのような方法論では特に問題になる可能性があります。^[9]
• スケーラビリティの欠如。RADは通常、小規模から中規模のプロジェクトチームに焦点を当てています。上記の他の問題（設計と制御の不足）は、非常に大規模なシステムにRADアプローチを使用する場合に特別な課題となります。^{[10] [11] [12]}

RAD を実装するための実用的な概念:

• RAD の主なソフトウェア ツールが表現されるグラフィカル ユーザー インターフェイス ビルダー
• 第 4 世代プログラミング言語(例: FileMaker、4th Dimension、dBase、Visual FoxPro)

その他の類似概念:

• フローベースプログラミング
• リーンソフトウェア開発
• サービスとしてのプラットフォーム
• ローコード開発プラットフォーム
• ノーコード開発プラットフォーム

• スティーブ・マッコーネル(1996)。『Rapid Development: Taming Wild Software Schedules』、Microsoft Press Books、ISBN 978-1-55615-900-8 
• Kerr, James M.; Hunter, Richard (1993)。Inside RAD: 90日以内に完全に機能するシステムを構築する方法。McGraw -Hill。ISBN 0-07-034223-7。
• Ellen Gottesdiener (1995)。「RAD の現実: 誇大広告を超えて RAD の本当の仕組み」アプリケーション開発トレンド
• ケン・シュワバー(1996)。アジャイルプロジェクトマネジメント with Scrum、Microsoft Press Books、ISBN 978-0-7356-1993-7 
• スティーブ・マッコーネル(2003)。プロフェッショナル ソフトウェア開発: スケジュールの短縮、製品の高品質化、プロジェクトの成功率の向上、キャリアの向上、Addison-Wesley、ISBN 978-0-321-19367-4 
• ディーン・レフィングウェル (2007)。『ソフトウェアの敏捷性のスケーリング: 大企業向けベストプラクティス』、Addison-Wesley Professional、ISBN 978-0-321-45819-3 
• スコット・スティナー (2016)。フォーブス リスト:「ラピッド アプリケーション開発 (RAD): ソフトウェア開発者にとってスマートで迅速、かつ価値あるプロセス」