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

ラピッドアプリケーション開発（RAD）は、ラピッドアプリケーション構築（RAB ）とも呼ばれ、適応型ソフトウェア開発手法の総称であると同時に、ジェームズ・マーティンのラピッド開発手法の名称でもあります。一般的に、RADのソフトウェア開発手法は、計画よりも適応的なプロセスを重視します。プロトタイプは、設計仕様書に加えて、あるいは場合によっては設計仕様書の代わりに用いられることもあります。

RADは、ユーザーインターフェースの要件に基づいて開発されるソフトウェアに特に適しています（ただし、これに限定されるわけではありません）。グラフィカルユーザーインターフェースビルダーは、しばしばラピッドアプリケーション開発ツールと呼ばれます。その他のラピッド開発手法には、アダプティブモデル、アジャイルモデル、スパイラルモデル、ユニファイドモデルなどがあります。

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

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

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

バリー・ボームらのアイデアを基に、ジェームズ・マーティンは1980年代にIBMでラピッド・アプリケーション開発（RAD）手法を開発し、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プロジェクトの実施において、なぜ他国に比べて圧倒的に成功を収めているのか、その方法論と詳細を理解するために時間を費やした。

ジェームズ・マーティンのRAD（ラピッド・アプリケーション開発）のアプローチでは、プロセスを4つの明確な段階に分けています。

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

現代の情報技術環境では、多くのシステムが何らかの形でラピッドアプリケーション開発^{[ 7 ]}（必ずしもジェームズ・マーティンの手法とは限らない）を使用して構築されています。マーティンの手法に加えて、アジャイル手法やRational Unified ProcessがRAD開発によく使用されます。

RADの利点とされるものには、以下のようなものがある。

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

RADの欠点とされるものには、以下のようなものがある。

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

RADを実装するための実践的な概念：

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

その他の類似概念：

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

• スティーブ・マコーネル(1996) 『ラピッド・デベロップメント：手に負えないソフトウェア開発スケジュールの克服』マイクロソフト・プレス・ブックス、ISBN 978-1-55615-900-8
• Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less . McGraw-Hill. ISBN 0-07-034223-7。
• エレン・ゴッテスディナー（1995年）「RADの現実：誇大宣伝を超えてRADの真の働き」アプリケーション開発トレンド
• ケン・シュワバー（1996）。スクラムによるアジャイルプロジェクト管理、マイクロソフトプレスブックス、ISBN 978-0-7356-1993-7
• スティーブ・マコーネル(2003).プロフェッショナル・ソフトウェア開発：より短いスケジュール、より高品質な製品、より成功するプロジェクト、より充実したキャリア、アディソン・ウェスリー、ISBN 978-0-321-19367-4
• ディーン・レフィングウェル（2007）。『ソフトウェアの俊敏性を高める：大企業のためのベストプラクティス』、アディソン・ウェスリー・プロフェッショナル、ISBN 978-0-321-45819-3
• スコット・スタイナー（2016年）。フォーブス誌リスト：「ラピッドアプリケーション開発（RAD）：ソフトウェア開発者にとってスマートで迅速かつ価値のあるプロセス」

• RADモデルを用いた作業における課題
• 迅速なアプリケーション開発に適したプロジェクトとはどのようなものか
• RAD実装の実例