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

過去問でウォーターフォールとスパイラルの違いを問われたとき、「どちらも段階を踏む手法なのに何が違うの？」と手が止まりました。整理してみると、プロセスの「繰り返し方」に決定的な差があることがわかって、それ以来すっきり区別できるようになりました。

経営情報システムでは、システム開発手法の特徴と使い分けが繰り返し問われます。ウォーターフォール・アジャイル・スパイラル・プロトタイピング、それぞれがどんな状況に向いていて、どこが試験で狙われやすいのか——一度整理しておくと、初見の設問でも迷わず選択肢を絞れるようになります。

4つの開発手法を一覧で比べる

まず4手法の全体像を並べます。「どの順序で進めるか」「要件が変わっても対応できるか」という2つの軸を念頭に置くと、それぞれの特徴がくっきり見えてきます。

要件確定型

ウォーターフォール

各フェーズを上から下へ順番に進める。前のフェーズを完了してから次へ移るため、仕様変更が難しい。要件が最初からはっきり決まっているプロジェクトに向く。

反復・変化対応型

アジャイル

短いサイクル（スプリント）を繰り返しながら開発を進める。要件変更に柔軟に対応できる。スクラム・XP（エクストリームプログラミング）などの手法がある。

リスク管理型

スパイラル

要件定義→設計→実装→評価のサイクルを螺旋状に繰り返す。各サイクルでリスク分析を行い、段階的に完成度を高めていく。大規模・高リスクなシステムに向く。

要件確認型

プロトタイピング

試作品（プロトタイプ）を早期に作成してユーザーに確認してもらい、要件を精緻化しながら開発を進める。要件が曖昧な場合や、UIの確認が必要な場合に有効。

手法	進め方	要件変更	リスク管理	向いているプロジェクト
ウォーターフォール	順番に1回のみ	困難	後半で発覚しやすい	要件が明確・変化が少ない
アジャイル	短サイクルで反復	柔軟に対応	早期に発見	要件が変化しやすい・小〜中規模
スパイラル	サイクルを螺旋状に反復	各サイクルで見直し	各サイクルで分析	大規模・リスクが高い
プロトタイピング	試作→確認→修正	試作で先行確認	要件確定後は低い	要件が曖昧・UIが重要

ウォーターフォールの5フェーズ

ウォーターフォールは「滝が上から落ちるように」各工程を一方向に進める手法です。フェーズの順番と、それぞれの工程で何を決めるかが試験で問われます。

PHASE 1

要件定義

システムに何をさせるかを決める工程。利用者のニーズ・業務フロー・制約条件を整理し、「システム要件定義書」としてまとめます。この段階で不足があると後の工程すべてに影響します。

PHASE 2

基本設計（外部設計）

システムの外側から見える仕様を設計します。画面レイアウト・帳票・データベースの論理設計・インターフェースなど、ユーザーが触れる部分の設計です。

PHASE 3

詳細設計（内部設計）

プログラムの内部構造を設計します。モジュール分割・アルゴリズム・データの物理設計など、開発者が実装に使う設計書を作成します。

PHASE 4

実装（プログラミング）

詳細設計をもとにコードを書く工程です。モジュール単位で開発し、単体テスト（ユニットテスト）を行いながら進めます。

PHASE 5

テスト（結合〜運用テスト）

結合テスト→システムテスト→運用テスト（受入テスト）の順で品質を確認します。各テストフェーズで対応する設計フェーズの仕様を確認します。

ウォーターフォールの弱点は、要件定義の段階で全ての仕様を確定しなければならない点です。後のフェーズで要件変更が発生すると、前のフェーズに戻る（手戻り）コストが非常に大きくなります。

アジャイル開発とスクラムの仕組み

アジャイルの根幹は「短いサイクルで動くものを届け続ける」という考え方です。代表的な手法がスクラムで、1〜4週間の「スプリント」という短い反復サイクルを繰り返します。

STEP 1 計画

STEP 2 設計・実装

STEP 3 テスト

STEP 4 レビュー

繰り返し次スプリントへ

スクラムには3つの役割があります。試験では各役割の責任範囲が問われることがあります。

プロダクトオーナー（PO）

プロダクトの価値を最大化する責任者。プロダクトバックログ（機能の優先順位リスト）を管理し、何を作るかを決定します。ビジネス側の代表です。

スクラムマスター（SM）

スクラムのプロセスが正しく機能するよう支援するファシリテーター。チームの障害を取り除き、スクラムの価値観とルールを守ることをサポートします。

開発チーム

実際にシステムを作るメンバー。自己組織化されたチームで、スプリント内で完成させる作業を自分たちで計画・実行します。一般的に3〜9人程度が理想とされます。

スパイラルとプロトタイピングの違い

スパイラルとプロトタイピングはどちらも「繰り返し」を含む手法ですが、目的がまったく違います。試験でこの2つが混同しやすいため、ポイントを整理します。

比較項目	スパイラル	プロトタイピング
繰り返しの目的	リスクを管理しながら段階的に完成度を上げる	試作でユーザーの要件を確認・確定させる
プロセス	計画→リスク分析→開発→評価を螺旋状に繰り返す	プロトタイプ作成→ユーザー確認→修正を繰り返す
重点	リスク分析（各サイクルで必ず実施）	ユーザーの合意・要件の精緻化
向いている規模	大規模・複雑・高リスクなシステム	要件が曖昧・UIが重要なシステム
試作品の扱い	各サイクルで実際に動くものを作る	プロトタイプは確認用・本番開発は別途行う場合も

スパイラルの核心は「リスク分析」です。各サイクルで必ずリスクを洗い出し、それを解決してから次のサイクルに進みます。一方プロトタイピングでは、ユーザーに「これで合ってますか？」と確認しながら要件を固めていくことが目的です。

家を建てるか、家具を作るか——日常の例で考える

4つの手法の違いを、家づくりとDIYの場面に当てはめると直感的に理解できます。

ウォーターフォール＝注文住宅の建築
設計図を最初に全部確定させて、基礎→骨組み→内装→外装の順で進めます。「壁の位置を変えたい」と途中で思っても、やり直しのコストは莫大です。着工前に全てを決めきることが前提。

アジャイル＝家具のDIY
まず棚1段分を作って部屋に置いてみる。「もう少し幅が欲しい」と感じたら次の1段で調整する。毎回小さく完成させて確認するので、方向転換がしやすいのです。

スパイラル＝大型施設の建設（リスク管理付き）
商業施設やインフラ設備など、「万が一失敗したら取り返しがつかない」プロジェクト。各フェーズで「地盤は大丈夫か」「予算は持つか」とリスクを洗い出してから次に進みます。

プロトタイピング＝間取り模型で確認してから建てる
「頭の中のイメージと実物が違った」を防ぐために、先に縮小模型を作ってお客様に確認してもらう。「やっぱりここを広くしたい」という要望を、本工事の前に拾い上げます。

「要件が最初から決まっているか」「変更が起きやすいか」「リスクが高いか」「ユーザーが仕様をイメージしにくいか」——これら4つの問いに答えることで、どの手法が合うかが自然に見えてきます。

向き不向きを整理する

ウォーターフォールが向く場面

要件が開発前に明確に定義できる

仕様変更がほとんど発生しない

複数チームが分業する大規模開発

ドキュメントの整備が必要な案件（官公庁・金融等）

アジャイルが向く場面

要件が開発中に変化しやすい

顧客と密に連携しながら進めたい

早期にリリースして市場の反応を確認したい

中〜小規模で自己組織化できるチーム

スパイラルが向く場面

規模が大きくリスクが高い

技術的な不確実性が高い

段階的に機能を追加・拡張する

プロトタイピングが向く場面

ユーザーが要件を言語化できていない

UIや操作感の確認が重要

早期にフィードバックを得て要件を固めたい

試験で問われるポイントと覚え方

試験頻出ポイント

01 ウォーターフォールの弱点は「手戻りコスト」——後のフェーズで問題が発覚した場合、前のフェーズに戻るコストが非常に大きい。要件変更に弱いという特徴が問われます。

02 スパイラルの最大の特徴は「リスク分析」——各サイクルで必ずリスク分析を行うことが他手法との違いです。「大規模システムに向く」という記述もよく出ます。

03 プロトタイピングは「要件確定」が目的——試作品を作るのは「完成品を早く届けるため」ではなく、「ユーザーの要件を確認・精緻化するため」です。この目的の違いをしっかり押さえましょう。

04 アジャイルの用語：スプリント・バックログ・スクラムの3役割——スクラムのプロダクトオーナー（何を作るか決定）・スクラムマスター（プロセス支援）・開発チーム（実装）の役割分担は頻出です。

05 外部設計 vs 内部設計の区別——基本設計（外部設計）はユーザー目線の仕様（画面・帳票・インターフェース）、詳細設計（内部設計）は開発者向けの内部構造（モジュール・アルゴリズム）です。

06 テストの種類と対応する設計フェーズ——単体テスト（詳細設計に対応）・結合テスト（基本設計に対応）・システムテスト（要件定義に対応）・運用テスト（業務要件に対応）という対応関係も問われます。

各手法を語呂や比喩で記憶に残すコツをまとめます。

手法	覚え方のキーワード
ウォーターフォール	「滝は逆流しない」→ 前のフェーズに戻れない・要件変更に弱い
アジャイル	「敏捷（アジャイル）」→ 機敏に変化へ対応・短サイクルで動くものを届ける
スパイラル	「螺旋＋リスク分析」→ ぐるぐる回りながらリスクを潰す・大規模向き
プロトタイピング	「試食コーナー」→ 食べてみてから注文を確定する・要件確認が目的

スパイラルとプロトタイピングの違いが最初はぼんやりしていましたが、「スパイラル＝リスク管理のため」「プロトタイピング＝要件確定のため」と目的で整理したらすっと区別できるようになりました。試験では手法の名前だけでなく「なぜその手法を選ぶのか」という判断基準まで問われるので、使い分けの軸を意識しておくと応用問題にも対応しやすいです。

U のメモ

経営情報システムを勉強し始めたとき、「どの手法が優れているか」という視点で覚えようとしていました。でも実際の試験では、「この状況ならどの手法が適切か」という判断基準が問われます。

要件が固まっているか・変化しやすいか・リスクが高いか・ユーザーが要件を言語化できているか——この4軸で整理すると、選択問題でも迷いにくくなります。

スクラムの3役割（PO・SM・開発チーム）は毎年のように出題実績があります。特に「プロダクトオーナーは何をする役か」というシンプルな問いでも意外と迷うので、役割と責任を言葉でスラスラ説明できるまで繰り返すのがおすすめです。