- Rapid Application Developmentの略で、プロトタイプを素早く作ってユーザーのフィードバックを繰り返し取り込みながら短期間でシステムを完成させる開発手法のこと
- 1990年代にジェームズ・マーティンが提唱した手法で従来のウォーターフォール開発の「時間のかかる詳細な事前設計」を避けてプロトタイプによる反復的な開発でユーザーの本当のニーズを掴むアプローチだ
- RADはアジャイル開発・スクラム・スパイラルモデルなどの現代的な反復開発手法の先駆けとなった概念で、特にWebアプリ・業務システムの初期開発フェーズでプロトタイプを作って要件を確認する場面で今も活用される
【深掘り】これだけ知ってればOK！
RADとウォーターフォール開発の違いを整理しよう。ウォーターフォール：要件定義→設計→開発→テスト→リリースという一方向の流れで各フェーズに長い時間をかける。手戻りが発生するとコストが高い。RAD：プロトタイプを素早く作ってフィードバックを繰り返す。要件の変更を歓迎する。ユーザーを開発に積極的に関与させる。短いサイクルでシステムを進化させる。
RADが有効な場面を理解しよう。有効な場面：ユーザーの要求が曖昧で反復的な確認が必要なシステム・時間的制約が厳しい・ユーザーが積極的に参加できる小〜中規模システム。向かない場面：セキュリティ・信頼性の要件が非常に高いシステム（航空管制・医療機器）・大規模で複数チームが関わる複雑なシステム・詳細な文書化が必要なシステム。
ローコード・ノーコードプラットフォーム（Bubble・AppSheet・Microsoft Power Apps）はRADの現代的な実装といえる。プログラミングスキルなしでプロトタイプを素早く作ってフィードバックを得るという流れがビジュアル開発ツールで実現されている。DXの現場では業務部門が自らローコードでプロトタイプを作る「シチズンデベロッパー」という概念も広がっている。
よくある誤解
RADは品質を犠牲にして速さだけを優先する手法だと思っている
RADは速さを重視するが品質を犠牲にするわけではない。プロトタイプによるユーザーフィードバックを繰り返すことで「本当に必要なもの」を正確に把握して開発するため、詳細な事前設計に時間をかけるウォーターフォールより的外れな機能を作るリスクが低い。
RADとアジャイルは全く別の概念だと思っている
RADはアジャイル開発の先駆けとなった概念だ。プロトタイプによる反復的な開発・ユーザーとの密な協力・変化への対応という核心思想はスクラム・XPなどのアジャイル手法と共通している。
会話での使われ方
要件が不明確なので、まずRADでプロトタイプを作ってユーザーに触ってもらいましょう。動くものを見せることで「これじゃない」という反応が早く得られます。
エンジニアが要件が曖昧な案件にRADアプローチを提案している場面。
ローコードツールでプロトタイプを1週間で作りました。業務部門がRADの感覚で触ってフィードバックをくれたおかげで、要件が一気に具体化できました。
情報システム担当者がローコードとRADアプローチを組み合わせた開発の効果を報告している場面。
このプロジェクト、スタートアップのMVP開発と同じ考え方ですね。まず動くものを作ってユーザーに見せて、フィードバックをもとに改善する。RADの現代版です。
プロダクトマネージャーがRADとMVP開発の概念的なつながりを説明している場面。
【まとめ】3つのポイント
- プロトタイプを素早く作りフィードバックを繰り返すことで短期間でシステムを開発する手法：詳細な事前設計に時間をかけるウォーターフォールと異なり動くプロトタイプでユーザーの本当のニーズを早期に把握することで的外れな開発を防ぎながら短期間でシステムを完成させる
- RADの核心思想はアジャイル・スクラム・MVP開発として現代に引き継がれている：「まずプロトタイプを作ってフィードバックを得る」というRADの思想はスタートアップのMVP戦略・スクラムのスプリントレビュー・ローコード開発など形を変えて現代の開発現場で生き続けている
- ローコード・ノーコードがRADの現代的な実装としてシチズンデベロッパーを生む：Bubble・AppSheet・Power Appsなどのローコードプラットフォームはプログラミングなしでプロトタイプを素早く作れるRADの現代版として業務部門自らがシステムを開発するシチズンデベロッパーの普及を支えている
よくある質問
-
QRADとスクラムはどう違いますか？
-
A
RADは1990年代に提唱された高速開発の概念・方法論です。スクラムはアジャイル開発の具体的なフレームワーク（スプリント・デイリースクラム・レトロスペクティブなど）です。RADの思想をスクラムが発展・実用化した関係にあります。
-
QRADはどんな規模のプロジェクトに向いていますか？
-
A
ユーザーが積極的に参加できる小〜中規模のシステムに向いています。大規模・複数チームが関わる複雑なシステムでは管理が難しくなります。
-
Qローコード開発とRADの関係は何ですか？
-
A
ローコード開発はRADの核心思想「プロトタイプを素早く作ってフィードバックを得る」をビジュアル開発ツールで実現したものです。非エンジニアでも参加できる点がRADをより幅広い層に広げています。
-
QRADで開発したシステムは品質が低いですか？
-
A
RADは品質を犠牲にするわけではありません。プロトタイプによる反復的な確認で「本当に必要な機能」を正確に作れるため、的外れな機能を大量に作るリスクが低いという利点があります。
【出典】参考URL
https://www.agilealliance.org/ ：Agile Alliance（アジャイル開発の国際機関）
https://www.microsoft.com/ja-jp/power-platform ：Microsoft Power Apps（ローコードRADツール）
コメント