システム開発手法まとめ｜ウォーターフォール・アジャイル・スパイラル・プロトタイプを図解で整理

ウォーターフォールとアジャイルは、発想の出発点がほぼ真逆です。「どちらが正しいか」ではなく、「何に向いているか」で選ぶもの——そう理解してから、この分野の問題が面白く感じられるようになりました。

システム開発手法は、中小企業診断士の1次試験「経営情報システム」でほぼ毎年問われるテーマです。ウォーターフォール・アジャイル・スパイラル・プロトタイプという4つの手法に加え、テスト技法やプロジェクト管理まで含めると範囲は広く感じられます。でも、「なぜその手法が生まれたのか」という背景を理解すると、特徴の違いが自然と整理されてきます。このページでは工程全体の構造から手法ごとの特徴まで、順を追って整理してみました。

論点	主なキーワード	出題傾向
開発手法	ウォーターフォール・アジャイル・スパイラル・プロトタイプ	4手法の比較は頻出。近年はアジャイルの出題が増加傾向
テスト技法	ホワイトボックス・ブラックボックス・単体/結合/システム/受入	テストの分類と目的の組み合わせが問われる
プロジェクト管理	WBS・PMBOK・EVM・スコープ・品質・コスト・工程	EVM指標（SV・CV・SPI・CPI）の計算問題も出題される
共通フレーム	SLCP・共通フレーム（SLCP-JCF）	ライフサイクルプロセスの標準化・発注者との合意形成が論点

システム開発の工程全体像

どの開発手法を選んでも、「何を作るか決める→設計→作る→確かめる→使い続ける」という大きな流れは共通しています。この基本工程を先に頭に入れておくと、各手法の違いが見えやすくなります。

要件定義

システム要件定義書
業務フロー図

毎年出題難易度 ★★☆

外部設計（概要設計）

画面設計書
データベース設計書

内部設計（詳細設計）

プログラム仕様書
モジュール設計書

実装（プログラミング）

ソースコード
単体テスト仕様書

テスト

テスト結果報告書
不具合管理表

運用・保守

運用マニュアル
変更管理記録

V字モデル

設計工程とテスト工程を対応させる

要件定義↔受入テスト、外部設計↔システムテスト、内部設計↔結合テスト、実装↔単体テスト、というように、左下降（設計）と右上昇（テスト）が対になる図形がVに見えることからV字モデルと呼ばれます。各テスト工程が「何を確認するための工程か」を明確にできる点が特徴です。

共通フレーム（SLCP-JCF）

発注者と受注者の共通言語

ソフトウェアのライフサイクル全体（企画→開発→運用→廃棄）を標準化したフレームワークです。発注者と受注者がプロセスの認識を合わせるために使われ、「共通フレーム2013」が現在の最新版です。ISO/IEC 12207をベースにしています。

ウォーターフォールモデル

FEATURE 01

各工程を順番に完了させてから進む

滝（ウォーターフォール）のように上流工程から下流工程へと一方向に流れる手法です。要件定義が固まってから設計を始め、設計が完成してから実装を始めます。前工程が完全に終わらない限り次の工程に進まないのが原則で、進捗の可視化がしやすいのが特徴です。

FEATURE 02

成果物が明確に残る

各工程で文書（要件定義書・設計書・テスト仕様書など）が成果物として蓄積されるため、品質管理や進捗管理がしやすいです。大規模なシステム開発や、法令・規制への準拠が求められる開発（官公庁・金融系など）に適しています。

メリット

各工程の終了タイミングが明確で、進捗管理がしやすい

成果物（ドキュメント）が蓄積されるため品質の担保がしやすい

大人数・長期プロジェクトでも役割分担が明確にしやすい

工数・コストの見積もりが立てやすい

デメリット

途中で要件が変わると手戻りコストが大きい

完成品を見るのがテスト工程以降のため、発注者が早期にフィードバックしにくい

要件が曖昧なまま進めると後工程で発覚した際のリスクが高い

市場の変化が激しい分野では納品時に陳腐化するリスクがある

工程	主な成果物	確認事項
要件定義	システム要件定義書、業務フロー図	「何を作るか」の合意。発注者との認識合わせが最も重要な工程
外部設計	画面設計書、DB設計書、インタフェース仕様	ユーザーから見たシステムの振る舞いを定義する
内部設計	プログラム仕様書、モジュール構造図	プログラムの内部構造・処理ロジックを設計する
実装	ソースコード、単体テスト仕様書	設計書に基づいてコーディング・単体テストを実施
テスト	テスト結果報告書、不具合管理表	結合→システム→受入の順に確認範囲を広げる
運用・保守	運用マニュアル、変更管理記録	稼働後の障害対応・機能改善・バージョン管理

ウォーターフォールの弱点を考えると、最初の要件定義がいかに重要かがよくわかります。後工程になればなるほど修正コストが指数関数的に上がっていく——だから「要件定義が命」と言われるのだと、改めて納得しました。

アジャイル開発

プロダクトバックログ

レビュー・振返り

動くソフトウェア

スプリント計画

スプリント

1〜4週間

バックログ
実装すべき機能の一覧。プロダクトオーナーが優先順位をつけて管理する

スプリント
1〜4週間の反復開発サイクル。各スプリント終了時に動くソフトウェアを届ける

スクラム
アジャイルの代表的フレームワーク。スプリント計画・デイリースクラム・スプリントレビュー・レトロスペクティブの4セレモニーで構成

比較軸	ウォーターフォール	アジャイル
基本思想	計画通りに完成させる	変化に適応しながら価値を届ける
要件変更	原則として変更は受け付けない（手戻りコスト大）	変更を歓迎する（アジャイルマニフェスト）
リリース頻度	最終工程終了後に1回	スプリントごとに繰り返しリリース
ドキュメント	各工程で詳細な文書を作成	必要最低限。動くソフトウェアを重視
チーム規模	大規模でも適用しやすい	小規模・自己組織化チームが前提
向いている案件	官公庁・金融・要件が明確な大規模開発	WebサービスSaaS・スタートアップ・要件変更が多い開発

XP（eXtreme Programming）

アジャイルの代表的手法のひとつ

ペアプログラミング・テスト駆動開発（TDD）・継続的インテグレーション（CI）・リファクタリングなどの実践を重視します。5つの価値（コミュニケーション・シンプルさ・フィードバック・勇気・尊重）に基づいて高品質なソフトウェアを短サイクルで届けることを目標とします。

アジャイルマニフェスト（2001年）

4つの価値宣言

プロセスやツールより個人と対話を／包括的なドキュメントより動くソフトウェアを／契約交渉より顧客との協調を／計画に従うことより変化への対応を。右より左を重視するという考え方です。

スパイラルモデル・プロトタイプモデル

スパイラルモデル

リスク分析を核に、螺旋（スパイラル）を描きながら段階的に開発を進める手法です。1周ごとに「計画→リスク分析→開発→評価」を繰り返します。大型・長期のプロジェクトで、途中に潜むリスクを先に特定・対処しながら進めたい場合に適しています。

ウォーターフォールとアジャイルの中間的な特性を持ち、「全体の計画はあるが、工程ごとにリスクを精査しながら進む」というイメージです。開発規模が大きく、技術的に不確実な要素が多いプロジェクト（航空・宇宙・防衛分野など）で採用されることがあります。

プロトタイプモデル

早期に試作品（プロトタイプ）を作成し、ユーザーに確認してもらいながら要件を固めていく手法です。「完成品のイメージが伝わりにくい」「利用者が何を求めているかが曖昧」という状況で特に有効です。

プロトタイプは「捨てる前提」の試作品であり、確認後は本開発を改めて行うケースと、プロトタイプを発展させるケースがあります。要件定義の精度を上げるツールとして位置付けられることが多いです。

RAD（Rapid Application Development）

短期間での開発完了を目指す高速開発手法です。ビジュアル開発ツール・コンポーネント再利用・タイムボックスによる制約を組み合わせて開発サイクルを短縮します。プロトタイプモデルと似ていますが、RADはツールや手法を活用した「速度重視」の開発全体の考え方で、プロトタイプは「要件確認のための試作」に焦点を当てている点が異なります。

インクリメンタルモデル

機能を少しずつ（インクリメンタルに）追加しながら完成に近づける手法です。最初にコア機能を開発し、リリース後に追加機能を段階的に組み込みます。スパイラルモデルとの違いは「リスク分析」の有無にあり、インクリメンタルはリスク分析を中心に置いていません。

手法	核心的な発想	リスク対応	向いているケース
ウォーターフォール	計画通りに順序良く完成させる	前工程の徹底的な文書化で防ぐ	要件明確・大規模・規制が多い
アジャイル	変化に適応しながら価値を届ける	短サイクルの反復で早期発見	要件変動多い・Webサービス
スパイラル	リスク分析を繰り返しながら段階的に進む	各スパイラルで積極的にリスク分析	大型・長期・技術的不確実性が高い
プロトタイプ	試作品で要件を確認してから本開発	早期の試作でユーザー要件のズレを防ぐ	要件が曖昧・ユーザーがイメージ困難

テスト技法

単体テスト
各モジュール

結合テスト
モジュール間

システムテスト
システム全体

受入テスト
発注者確認

ホワイトボックステスト

プログラムの内部構造（ロジック）を把握した上でテストする手法です。すべての命令・分岐・ループが少なくとも1回は実行されるようにテストケースを設計します。

カバレッジ（網羅率）が重要な指標で、命令網羅・分岐網羅・条件網羅などの種類があります。単体テストで主に使われます。

ブラックボックステスト

プログラムの内部構造を見ずに、入力と出力の関係だけでテストする手法です。仕様書に基づいて「この入力に対してこの出力が返るか」を確認します。

代表的な設計技法は同値分割（有効・無効な入力グループを代表値でテスト）と境界値分析（範囲の境界付近の値でテスト）です。

テスト段階	対象範囲	実施者	主な確認内容
単体テスト	個々のモジュール・関数	開発者（プログラマ）	仕様通りに動作するか・分岐ロジックの正確さ
結合テスト	複数モジュールの連携	開発チーム	インタフェース・データの受け渡しが正しいか
システムテスト	システム全体	開発チーム（QA）	要件定義の内容をすべて満たしているか・性能・セキュリティ
受入テスト	発注者視点での全体確認	発注者・利用者	業務要件を満たしているか・本番環境での動作確認

プロジェクト管理の基本

WBS

作業分解構造（Work Breakdown Structure）

プロジェクト全体の作業を階層的に分解したリストです。「成果物ベース」で作業を細分化し、それぞれの作業に担当者・工数・期間を割り当てます。ガントチャートはWBSを時系列に並べた進捗管理ツールです。

PMBOK

プロジェクトマネジメント知識体系

PMIが策定するプロジェクト管理のベストプラクティス集です。統合・スコープ・スケジュール・コスト・品質・資源・コミュニケーション・リスク・調達・ステークホルダーの10知識エリアで構成されます。

EVM

アーンドバリューマネジメント（Earned Value Management）

コストと進捗を統合管理する手法。PV（計画価値）・EV（出来高）・AC（実コスト）の3指標から、SV（スケジュール差異）・CV（コスト差異）・SPI（スケジュール効率）・CPI（コスト効率）を算出します。

QCD

品質・コスト・納期のバランス

プロジェクト管理の3要素。Quality（品質）・Cost（コスト）・Delivery（納期）の3つはトレードオフの関係にあり、ひとつを改善しようとすると別のふたつに影響が出やすいです。スコープも含め「4要素」で語られることもあります。

指標	計算式	プラスの意味	マイナスの意味
SV（スケジュール差異）	EV − PV	計画より進んでいる	計画より遅れている
CV（コスト差異）	EV − AC	予算内に収まっている	予算超過している
SPI（スケジュール効率）	EV ÷ PV	1より大きければ順調	1未満なら遅れあり
CPI（コスト効率）	EV ÷ AC	1より大きければ効率的	1未満なら予算超過傾向

身近な場面で考えてみると

ケーススタディ：スマホアプリ開発でどちらを選ぶか

場面A（WF向き）

官公庁向けの住民票申請アプリ。法律上の要件・セキュリティ基準・アクセシビリティ対応が明確に規定されており、途中での仕様変更は原則不可。契約形態も請負（成果物の確定引渡し）が多い。→ウォーターフォールが適合しやすい。

場面B（アジャイル向き）

スタートアップが開発するフードデリバリーアプリ。競合の動向や利用者の反応を見ながら機能を追加・変更し続ける必要がある。ユーザーインタビューを毎スプリントに組み込みたい。→アジャイル（スクラム）が適合しやすい。

選択の視点

「要件はどれくらい固まっているか」「変更はどれくらい発生しそうか」「リリースは一度でいいか何度も続けるか」「チーム規模はどれくらいか」の4点を確認すると、手法選択の方向性が見えてきます。実務では両者を組み合わせたハイブリッドも珍しくないです。

過去問で確認する

アジャイル開発に関する記述として最も適切なものはどれか。

ア：各工程を順番に進め、前工程が完了してから次工程に移る
イ：大規模な要件定義を最初にまとめて行う
ウ：短い開発サイクル（スプリント）を繰り返しながら機能を追加していく ← 正解
エ：要件変更は原則として受け付けない

解説

アジャイル開発の核心は「短いサイクル（スプリント）の繰り返し」と「変化への柔軟な対応」です。ア・イはウォーターフォールの説明。エは逆で、アジャイルマニフェストは「計画に従うことより変化への対応を」と明示しており、要件変更を歓迎します。スクラムのスプリント（通常1〜4週間）がその代表的な実践です。

ソフトウェアのテスト技法に関する記述として最も適切なものはどれか。

ア：ホワイトボックステストは、プログラムの内部構造を考慮せずに入力と出力の関係だけをテストする
イ：ブラックボックステストは、プログラムの内部ロジック（分岐・ループ）を網羅的に確認する
ウ：単体テストは、複数のモジュールを組み合わせてインタフェースの整合性を確認するテストである
エ：同値分割は、入力データを有効・無効のグループに分け、各グループから代表値を選んでテストする技法である ← 正解

解説

ア（ホワイトボックス）とイ（ブラックボックス）の説明が入れ替わっています。ホワイトボックス＝内部ロジックを見るテスト、ブラックボックス＝入出力の関係だけを見るテスト、という区別が核心です。ウは結合テストの説明。エの同値分割は、無効な値と有効な値のグループ（同値クラス）をそれぞれ代表値でテストするブラックボックステストの技法で、正しい記述です。

U のメモ

システム開発手法の問題は、「手法の名前と特徴を丸暗記する」より「なぜその手法が生まれたのか」を理解するほうが、応用問題にも対応しやすいと感じています。

ウォーターフォールは「計画の重視」、アジャイルは「変化への適応」、スパイラルは「リスクの先読み」、プロトタイプは「要件の見える化」——それぞれが別々の課題を解決するために生まれた手法です。課題が違えば解決策が違うのは当然のことで、そう整理すると4手法が自然に頭に入ってきました。

EVM（アーンドバリューマネジメント）は計算問題として出ることもあるので、SV・CV・SPI・CPIの式と「プラス・マイナスの意味」は確認しておくと安心できます。