U
「ウォーターフォールとアジャイルって、どう違うんだろう？」——システム開発手法は、プロジェクトの性質によって最適解が変わります。各手法の特徴と「どんな状況に向くか」を理解することが、試験でも実務でも本当に役立ちます。
システム開発手法の全体マップ
システム開発手法には多くの種類がありますが、大きく「計画駆動型」と「変化対応型」に分けることができます。どちらが優れているという話ではなく、プロジェクトの性質（要件の明確さ・変更頻度・規模・チーム構成）によって最適な手法は異なります。
| 分類 | 代表的な手法 | 特徴 | 向いている状況 |
|---|---|---|---|
| 計画駆動型 | ウォーターフォール | 全工程を事前に計画。順次実行 | 要件が明確・変更が少ない大規模開発 |
| 計画駆動型 | V字モデル | 開発と検証をV字の対応関係で管理 | 品質保証が重視される組込みシステム |
| 試作型 | プロトタイピング | 早期に試作品を作りフィードバックを得る | 要件が曖昧・UI重視のシステム |
| 反復型 | スパイラルモデル | リスク分析→プロト→評価を繰り返す | リスクが高い大規模・長期プロジェクト |
| 変化対応型 | アジャイル開発 | 短いサイクルで開発・フィードバックを繰り返す | 要件変更が多い・スピード重視 |
| 変化対応型 | RAD/DSDM | ユーザー参加型・タイムボックス制 | 短期開発・ユーザー関与が得られる場合 |
システム開発手法は「計画駆動型」と「変化対応型」に大別できます。プロジェクトの性質によって最適な手法を選ぶことが重要です。
ウォーターフォールモデル：基本と各フェーズ
ウォーターフォール（waterfall）モデルは、水が滝を上から下へと流れるように、各工程を順番に進める開発手法です。1970年代から使われてきた最も伝統的な手法で、今でも大規模基幹システムの開発では主流の手法です。
| フェーズ | 内容 | 主な成果物 |
|---|---|---|
| ①要件定義 | 業務要件・システム要件を確定する | 要件定義書、業務フロー図 |
| ②外部設計（基本設計） | 画面・帳票・インターフェース等ユーザー視点の設計 | 外部設計書、画面設計書 |
| ③内部設計（詳細設計） | データベース設計・モジュール設計などシステム内部の設計 | 内部設計書、DB設計書 |
| ④プログラミング（コーディング） | 設計書に基づいてプログラムを作成する | ソースコード |
| ⑤単体テスト | 個々のモジュール・関数を単独でテストする | 単体テスト仕様書・結果報告書 |
| ⑥結合テスト | 複数のモジュールを組み合わせてテストする | 結合テスト仕様書・結果報告書 |
| ⑦システムテスト（総合テスト） | システム全体として要件を満たすか検証する | システムテスト仕様書・検収報告書 |
| メリット | デメリット |
|---|---|
| 進捗管理がしやすい（フェーズが明確） | 要件変更に対応しにくい（前工程に戻るのが困難） |
| ドキュメントが整備される | 動くシステムが完成するまで時間がかかる |
| 役割分担が明確 | 要件定義の段階で全ての要件を確定する必要がある |
| 大規模・長期プロジェクトに向く | ユーザーのフィードバックが遅い段階にしか得られない |
ウォーターフォールは「要件定義→設計→開発→テスト」を順番に進める手法。進捗管理のしやすさが強みですが、要件変更への対応が難しいという弱点があります。
プロトタイピングモデル：試作品で要件を確定する
プロトタイピングモデルは、開発の早い段階で試作品（プロトタイプ）を作り、ユーザーに使ってもらいながら要件を確定していく手法です。「作ってから気づく」問題を、早期の試作フィードバックで解決することができます。
①基本要件の把握 → ②プロトタイプ作成（簡易版） → ③ユーザーレビュー → ④要件の修正・追加 → ⑤プロトタイプの改善 → ⑥（繰り返し） → ⑦本番システムの開発
| 種類 | 内容 | 用途 |
|---|---|---|
| 使い捨て型プロトタイプ | 要件確認後に廃棄することを前提に作成する | UI確認・要件の明確化 |
| 進化型プロトタイプ | プロトタイプを徐々に改善して最終製品にする | 要件が徐々に固まるシステム |
| ペーパープロトタイプ | 紙・ホワイトボードで画面イメージを描く | 早期の画面レイアウト確認 |
| モックアップ | 動かないが見た目を実際に近づけたもの | デザイン・UIの確認 |
プロトタイピングは早期の試作品でユーザーフィードバックを得る手法。「使い捨て型」は要件確認後に廃棄、「進化型」はそのまま本番システムへ発展させます。
スパイラルモデル：リスク分析を繰り返す開発
スパイラルモデルはBoehm（ベーム）が提唱した手法で、「計画→リスク分析→開発→顧客評価」という4象限のサイクルを繰り返しながら、らせん状にシステムを発展させていきます。大規模・長期プロジェクトにおけるリスク管理に優れた手法です。
| 象限 | 活動内容 |
|---|---|
| 第1象限：計画立案 | 目標・代替案・制約条件を明確にする |
| 第2象限：リスク分析・解決 | リスクを識別・評価し、プロトタイプで解消する |
| 第3象限：開発・テスト | 設計・コーディング・テストを実施する |
| 第4象限：顧客評価 | 顧客レビューを受けて次サイクルの計画を立てる |
| 比較項目 | ウォーターフォール | スパイラル |
|---|---|---|
| リスク管理 | あまり重視されない | 各サイクルでリスク分析を必ず実施 |
| 顧客関与 | 要件定義とレビュー時 | 各サイクルで継続的に関与 |
| 適した規模 | 中〜大規模 | 大規模・高リスクプロジェクト |
| コスト見積もり | 事前に概算可能 | サイクルを重ねるにつれ精度が上がる |
スパイラルモデルは「計画→リスク分析→開発→評価」を繰り返す手法。各サイクルで必ずリスク分析を行う点が最大の特徴です。
アジャイル開発：スクラム・XP・カンバン
アジャイル（agile：俊敏な）開発は、2001年に発表された「アジャイルソフトウェア開発宣言」を土台とした開発思想と手法群の総称です。「動くソフトウェアを素早く、継続的に届ける」ことを最優先にしています。
| 左辺（重視するもの） | 右辺（軽視ではなく、左辺をより重視する） |
|---|---|
| 個人と対話 | プロセスやツール |
| 動くソフトウェア | 包括的なドキュメント |
| 顧客との協調 | 契約交渉 |
| 変化への対応 | 計画への追随 |
スクラムはアジャイル開発の最も普及したフレームワークです。2〜4週間の「スプリント（Sprint）」と呼ばれる短い開発サイクルを繰り返します。
| 用語 | 内容 |
|---|---|
| プロダクトバックログ | 開発すべき機能・要件の優先順位付きリスト |
| スプリントバックログ | 今スプリントで取り組む作業のリスト |
| スプリント（Sprint） | 2〜4週間の開発サイクル。毎回動くソフトウェアを完成させる |
| デイリースクラム | 毎朝15分の立ちミーティング（昨日/今日/障害の共有） |
| スプリントレビュー | スプリント終了後に成果物を顧客に見せるレビュー |
| スプリントレトロスペクティブ | チームのやり方を振り返り改善する（カイゼン活動） |
| プロダクトオーナー | バックログの優先順位を決定する責任者 |
| スクラムマスター | チームのファシリテーター・障害除去役 |
| 実践 | 内容 |
|---|---|
| ペアプログラミング | 2人1組でコードを書く（1人が打鍵、1人がレビュー） |
| テスト駆動開発（TDD） | コードを書く前にテストを書き、テストが通るようにコードを書く |
| リファクタリング | 動作を変えずにコードの品質・可読性を改善する |
| 継続的インテグレーション（CI） | コードを頻繁に統合し、自動テストで品質を確認する |
| 小リリース | 小さな機能単位で頻繁にリリースする |
カンバンはタスクを「To Do / In Progress / Done」のような列で可視化し、作業の流れを管理する手法です。スクラムと異なりスプリントの概念がなく、継続的に流れるように作業を処理します。保守・運用業務に適しています。
アジャイル開発は「変化への対応」を最重視する開発思想。スクラムはスプリントを繰り返す最も普及したフレームワーク、XPは技術的実践（TDD・ペアプロ）を重視、カンバンは作業の流れを可視化します。
ユーザー参加型開発：RADとDSDM
ユーザー参加型開発は、顧客・エンドユーザーを開発チームに積極的に参加させることで、要件の齟齬を早期に解消し、ユーザーニーズに合ったシステムを短期間で開発する手法です。
| 手法 | 内容 | 特徴 |
|---|---|---|
| RAD（Rapid Application Development） | プロトタイピングとユーザー参加を組み合わせた高速開発 | 60〜90日での開発を目標。小規模チーム・CASE（自動化）ツール活用 |
| DSDM（Dynamic Systems Development Method） | RADを発展させたフレームワーク。タイムボックス制 | 時間・コストを固定し、品質・機能を調整。英国発祥 |
| JAD（Joint Application Development） | ユーザーと開発者が共同でシステム設計を行うワークショップ型 | 要件定義・設計フェーズの短縮に効果的 |
「時間を固定し、その範囲内で最大の価値を届ける」という考え方です。「3週間のスプリントで何ができるか」を考えるアジャイル開発の基本的な考え方と同じです。従来の「全機能が完成するまで時間をかける」とは逆の発想です。
ユーザー参加型開発（RAD・DSDM）はユーザーを積極的にチームに巻き込むことで、要件齟齬を早期解消し、短期間でのシステム完成を目指します。
開発手法の選択基準：比較マトリクス
どの開発手法を選ぶかは、プロジェクトの性質によって異なります。「要件の明確さ」「変更頻度」「規模」「チーム構成」の4軸で判断することが基本です。
| 選択基準 | ウォーターフォール | プロトタイピング | スパイラル | アジャイル |
|---|---|---|---|---|
| 要件の明確さ | 高（事前に全要件確定） | 低〜中（試作で明確化） | 中（段階的に確定） | 低〜中（変化を想定） |
| 変更頻度 | 低（変更に弱い） | 中 | 中〜高 | 高（変化を歓迎） |
| プロジェクト規模 | 中〜大規模 | 小〜中規模 | 大規模 | 小〜中規模 |
| 顧客関与 | 低（節目のみ） | 高（継続的フィードバック） | 高（各サイクル） | 非常に高（常に関与） |
| リスク管理 | 低 | 中 | 高（必ず分析） | 中（スプリントで対応） |
開発手法の選択は「要件の明確さ」「変更頻度」「規模」「顧客関与度」で判断します。試験では「この状況に最適な手法」を選ぶ問題が頻出です。
ウォーターフォール vs アジャイルの詳細比較
ウォーターフォールとアジャイルは対照的な哲学を持つ手法として、試験でも実務でも対比されることが多いです。どちらが「正しい」のではなく、状況に応じた使い分けが重要です。
| 比較項目 | ウォーターフォール | アジャイル |
|---|---|---|
| 開発思想 | 計画通りに完璧に作る | 変化に適応しながら価値を届け続ける |
| 要件確定 | 開発前に全要件を確定する | 開発しながら要件を洗練していく |
| リリースタイミング | 全機能完成後に一括リリース | 機能単位で頻繁にリリース |
| ドキュメント | 詳細なドキュメントを重視 | 必要最低限。動くソフトウェアを優先 |
| 変更対応 | 変更管理プロセスが重い | 変更を歓迎・プロセスを軽くする |
| チーム規模 | 大規模チーム可（役割分担） | 小規模自己組織化チームが基本 |
| 進捗管理 | ガントチャート・マイルストーン | バーンダウンチャート・ベロシティ |
| 顧客関与 | 最初と最後（検収時） | 毎スプリントで関与 |
実際の開発現場では、ウォーターフォールとアジャイルを組み合わせる「ハイブリッド型」も増えています。要件定義・設計はウォーターフォール的に進め、実装・テストはアジャイル的なサイクルで行うというアプローチです。
ウォーターフォールは「計画通りに完璧に作る」、アジャイルは「変化に適応しながら価値を届け続ける」という哲学の違いがあります。現実には両者を組み合わせるハイブリッド型も普及しています。
試験頻出ポイントと過去問分析
| 論点 | 頻出度 | 要点 |
|---|---|---|
| ウォーターフォールの各フェーズと順序 | ★★★ | 要件定義→外部設計→内部設計→コーディング→テスト |
| 各手法の特徴と適した状況 | ★★★ | 要件明確→ウォーターフォール、変化多い→アジャイル等 |
| プロトタイピングの目的と注意点 | ★★☆ | 要件確定のための試作品。本番流用は禁止 |
| スパイラルモデルの特徴 | ★★☆ | リスク分析を各サイクルで必ず実施 |
| アジャイル宣言の4つの価値 | ★★☆ | 個人と対話・動くソフト・顧客協調・変化への対応 |
| スクラムの用語 | ★★☆ | スプリント・バックログ・スクラムマスター等 |
| XPの実践（TDD・ペアプロ等） | ★★☆ | テスト先行・2人1組・リファクタリング |
試験では各開発手法の特徴と「どんな状況に向くか」を問う問題が多いです。各手法固有のキーワードと「状況→手法」の対応関係を整理しておきましょう。
よくある質問（FAQ）
システム開発手法は、ウォーターフォール・プロトタイピング・スパイラル・アジャイルという4つの系譜を理解し、「状況に応じた手法選択」ができるようになることが目標です。各手法の固有キーワードを確実に覚えて、試験の選択問題に対応できるよう準備しましょう。
