U「ウォーターフォールとアジャイル、どっちが優れているのか？」と最初は思っていました。でも調べてみると、どちらが正しいという話ではなく、「どんなシステムを作るのか」によって使い分けるものだと分かって、一気に整理できました。
システム開発手法とは、ソフトウェアをどのような順序・体制で作り上げるかの設計思想です。「どうやってコードを書くか」ではなく、「誰が・いつ・何をするか」というプロジェクト全体の進め方を定めます。
試験では、各手法の特徴・メリット・デメリットと「どんなシステムに向いているか」が問われます。名前と定義を暗記する前に、なぜその手法が生まれたのかという背景を押さえておくと、選択肢を見た瞬間に判断できるようになります。
4つの主要開発手法：全体像をつかむ
| 手法 | 進め方 | 最大の特徴 | 向いているシステム |
|---|---|---|---|
| ウォーターフォール | 工程を順番に・逆戻りなし | 計画通りに進む。文書化が充実 | 要件が明確・変更が少ない大規模システム |
| スパイラル | 機能ごとにウォーターフォールを繰り返す | リスク分析を重視しながら段階的に開発 | 大規模・高リスク・要件が段階的に確定 |
| プロトタイプ | 試作品を作って顧客確認→改良を繰り返す | 要件の曖昧さを早期に解消できる | 要件が不明確・顧客が具体的イメージを持ちにくい |
| アジャイル | 短いサイクルで動くソフトを繰り返し届ける | 変化への対応力が最も高い | 要件が変化しやすい・スモールスタートのサービス |
ウォーターフォールモデル：計画通りに進む王道手法
ウォーターフォール（瀑布型）は、水が上から下へ流れるように前の工程が完全に終わってから次の工程へ進む手法です。1970年代から使われてきた最も伝統的な手法で、大規模開発の標準として長く使われてきました。
定義
設計
設計
保守
U「工程の逆戻りなし」というのがウォーターフォールの核心ですね。水は上から下にしか流れない——そのイメージを持つと「前工程の完了が絶対条件」という制約が自然に頭に入ります。
アジャイル開発：変化に強い反復アプローチ
アジャイル（Agile＝「俊敏な」）は、短い開発サイクル（イテレーション・スプリント）を繰り返しながら、動くソフトウェアを継続的に届ける手法です。2001年の「アジャイルソフトウェア開発宣言」から広まりました。
「計画通りに進む」より「変化に対応する」ことを優先します。顧客との継続的なコミュニケーションが前提です。
スクラムのスプリントサイクル（2〜4週間を1単位）
バックログ
計画
実行
振り返り
（次のスプリントへ）
スパイラルモデルとプロトタイプモデル
銀行ATMとSNSアプリで考えてみると
「どの手法を使うべきか」は、要件の変化しやすさ・品質要求の厳しさ・規模によって決まります。
| システム例 | 特性 | 適した手法 | 理由 |
|---|---|---|---|
| 銀行ATM・勘定系システム | 要件が明確・バグ絶対NG・大規模 | ウォーターフォール | 厳格な品質管理・文書化が必須。途中変更は許容されない |
| SNS・EC サービス | 要件が変化・スピード優先・スモールスタート | アジャイル | ユーザーの反応を見ながら機能を追加・変更し続ける |
| 新規業務システム（要件不明確） | 顧客もイメージが曖昧・中規模 | プロトタイプ | 試作品を見せることで要件が明確になる |
| 大規模基幹システム刷新 | 高リスク・長期・段階的リリース | スパイラル | 機能ごとに開発・リスク分析しながら進める |
U「どっちが優れているか」ではなく「何を作るかで使い分ける」——この視点を持てると、試験の選択肢も「このシステムの特性なら〇〇手法が向く」と判断できるようになりますね。
試験頻出ポイントのまとめ
- ウォーターフォール：工程の逆戻りなし。要件定義→外部設計→内部設計→実装→テスト→運用の順序を覚える
- アジャイル：短いイテレーション（スプリント）を繰り返す。変化対応力が最高。スクラム・XPが代表手法
- スパイラル：機能単位でウォーターフォールを繰り返す＋リスク分析が特徴
- プロトタイプ：試作品→顧客確認→改良を繰り返す。要件が不明確なときに有効
- スクラムの3役割：プロダクトオーナー・スクラムマスター・開発チーム
- XPの主要プラクティス：テスト駆動開発（TDD）・ペアプログラミング・継続的インテグレーション（CI）
- 手法の選択基準：要件の明確さ・変化の頻度・品質要求・規模の4軸で判断
