ITパスポート 令和8年度 問38：development_managementに関する問題

答えは b「ウォーターフォールモデル」 です。

ウォーターフォールとは「滝（waterfall）」のように、上から下へ順番に進めて後戻りしない作り方です。設計→開発→テスト…と一段ずつ確実に下りていきます。最初に作るものがハッキリ決まっていて、途中で変更が少ないときにピッタリです。

👉 覚え方：ウォーターフォール＝「滝のように一方通行・後戻りなし」。決まったものを順番に作る。

ほかの選択肢：a アジャイル・c スパイラル・d プロトタイピングは、どれも「途中で変更しながら進める」やり方なので、変更が少ない開発には合わず×。

なぜこれが正解か

正解は b。ウォーターフォールモデルは、要件定義→設計→実装→テスト→運用と工程を上流から下流へ順番に進め、原則として前工程に戻らない開発手法。各工程の成果物を固めてから次へ進むため、要求事項が明確で仕様変更が少ない開発に最も適する。

各選択肢の解説

• a アジャイル開発：短い反復で動くソフトを作り、変化に柔軟対応。仕様変更が多い開発向け。
• c スパイラルモデル：開発を螺旋状に繰り返し、リスクを評価しながら段階的に作る。要求が固まりきらない開発向け。
• d プロトタイピングモデル：試作品を作り利用者の反応を見て要求を確定。要求が曖昧な開発向け。

覚え方・ひっかけ注意

「要求が明確・変更が少ない」→ウォーターフォール。「変更が多い・要求が曖昧」→アジャイル/スパイラル/プロトタイピング。ウォーターフォールは後戻りに弱く、終盤での要件変更に高コストという弱点も頻出。

理論的背景

ウォーターフォールモデル（Waterfall Model）はウィンストン・ロイスが1970年に論文で記述したシステム開発手法で、「要件定義→基本設計→詳細設計→実装→テスト→運用保守」という工程を上流から下流へと順序立てて実施し、各工程完了後に後工程に進む逐次・不可逆的な開発モデルである。名称は各工程が滝（Waterfall）のように上から下に流れ落ちることに由来する。ウォーターフォールが最も効果を発揮する条件は「要求事項が明確・変更が少ない・技術リスクが低い」という三条件の充足で、本問はまさにこの状況を問題文に示している。対比されるアジャイル開発はその逆の「要件が不明確・変更が多い・ユーザーフィードバックが重要」な状況に適する。スパイラルモデルはリスク分析を各反復に組み込み、プロトタイピングモデルは早期プロトタイプでユーザー要件を確認する手法で、どちらも変更・不確実性に対応するための手法。

実務での使われ方

ウォーターフォール開発が現実に有効なプロジェクトタイプとして、大規模なパッケージ導入（ERP・基幹システムの刷新）・官公庁の情報システム調達（要件定義→仕様確定→入札→開発という調達プロセスが法令上固定されている）・組み込みソフトウェア（ハードウェアと仕様が連動するため変更コストが極めて高い）が挙げられる。「V字モデル（Vモデル）」はウォーターフォールを拡張した品質管理モデルで、左辺（開発工程）と右辺（テスト工程）を対応させ、各テスト工程が対応する設計工程の要件検証を行う構造とする。単体テスト↔詳細設計・統合テスト↔基本設計・システムテスト↔要件定義という対応関係。EU・日本では官公庁ITプロジェクトへのアジャイル適用が進んでいるが、監査・変更管理・調達透明性の観点からウォーターフォール的な節目（マイルストーン）を維持しながらアジャイルを組み合わせる「ハイブリッド型」開発が現実解として定着しつつある。

試験での位置づけ

開発モデルの比較・適切な使用場面の選択はITパスポートのシステム開発・プロジェクトマネジメント系で最頻出テーマ。本問の識別ポイントは問題文に「要求事項が明確・仕様変更が少ない」という適用条件が明示されており、この条件にウォーターフォールが最も合致する。典型的誤答パターン：アジャイル開発（a）との混同でアジャイルは「要件が固まっていない場合・変更が多い場合」に適する。スパイラルモデル（c）は各反復でリスク分析を行い、リスクの高い大規模なプロジェクト向け。プロトタイピングモデル（d）は要件が不明確なシステムの仕様確認に特化。近年はアジャイル・スクラムの実践問題（スプリント・バックログ・デイリースクラム等の用語）が増加しており、ウォーターフォールとアジャイルの適用条件の比較理解が高得点の鍵。

選択肢の発展補足

選択肢aのアジャイル開発の代表的フレームワークはスクラム（Scrum）・XP（eXtreme Programming）・Kanban・SAFe（Scaled Agile Framework）で、スクラムは2〜4週間のスプリントを繰り返し、スプリントレビュー・スプリントレトロスペクティブで継続的な改善を行う。スクラムマスター・プロダクトオーナー・開発チームの三ロールが特徴的。選択肢cのスパイラルモデルはBarry Boehmが1988年に提唱。大規模・高リスクなシステム開発（航空宇宙・防衛システム等）に適し、各スパイラルで「計画→リスク分析→開発・テスト→評価」を繰り返す。選択肢dのプロトタイピングモデルはUI/UX設計の確認・要件の可視化に特に有効で、Figmaのようなプロトタイピングツールを使ったデザインスプリントが現代版の実践形態。「要求の明確さ・変更頻度・プロジェクト規模・リスクレベル」の4軸で開発モデルを選択するという判断フレームワークを持つことで応用問題にも対応できる。