対象試験と出題頻度
スパイラルモデルは、ITパスポート・基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェア開発モデルの比較問題として定番化しており、「ウォータフォールモデル」「プロトタイピングモデル」「アジャイル開発」との違いを正確に区別できるかが問われます。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「スパイラルモデルって結局ウォータフォールやアジャイルと何が違うの？」と混乱しがちです。ここだけは確実に押さえてください。
スパイラルモデル（Spiral Model）とは、一言で言うと
「システムを部分（サブシステム）ごとに分け、設計・開発・評価のサイクルを繰り返しながら全体を完成させる開発モデル」
のことです。
イメージとしては、「家を一気に建てず、まずリビングだけ作って住んでみる」方式です。
リビングを使ってみて「キッチンはこっち向きがいいな」と気づいたら、その学びを次のキッチン建築に活かします。
さらにキッチンを使ってから寝室を作る、というように、一区画ずつ「作って→使って→次に活かす」を渦巻き状に積み重ねていく進め方です。
📊 スパイラルモデルの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Spiral Model |
| 提唱者 | バリー・ベーム（Barry Boehm）／1986年 |
| 分類 | 反復型開発モデル |
| 特徴 | サブシステム単位で「計画→分析→設計→評価」を反復、リスク分析を重視 |
| 向いている案件 | 大規模かつ要件不確実性の高いプロジェクト |
解説
従来の開発では、要件定義から設計・実装・テストまでを一方通行で進めるウォータフォールモデルが主流でした。
しかし、開発期間が長くなるほど「完成してみたら使い物にならなかった」「途中で要件が変わって手戻りが大量発生した」という事故が起こります。
この弱点を埋めるためにバリー・ベームが1986年に提唱したのが、リスクを早めに洗い出しながら少しずつ作り上げていくスパイラルモデルです。
渦巻き状に進む4つのフェーズ
1サイクル（1スパイラル）の中で、以下の4つのフェーズを順に回します。
これを必要な回数だけ繰り返し、サイクルごとにシステムが大きく育っていきます。
| フェーズ | やること |
|---|---|
| ① 計画 | このサイクルの目的・制約・必要資源を決める |
| ② リスク分析 | 想定される技術的・スケジュール的リスクを洗い出し、対策を立てる |
| ③ 開発・テスト | 対象サブシステムを設計・実装・テストする（プロトタイプを作ることもある） |
| ④ 評価 | 利用者にレビューを受け、次のサイクルの計画にフィードバックする |
図解：スパイラルモデルのイメージ
スパイラルモデルの動きを「サイクル内で何をするか」「サイクル間で何が変わるか」の2つの視点で整理します。
▼ 同じ4フェーズを繰り返し、サイクルごとにシステムが育つ
第1サイクル
基本機能を作る
学びを
反映
第2サイクル
機能を追加
学びを
反映
第3サイクル 🎯
機能を拡充し完成へ
📈 サイクルごとのシステム完成度
▲ 各サイクルで同じ4フェーズを回し、評価結果を次サイクルの計画に反映する
他の開発モデルとの比較
試験では他の開発モデルとの違いを問う形式が多いため、対比で押さえます。
| モデル | 進め方 | 見分けキーワード |
|---|---|---|
| スパイラルモデル | サブシステム単位で反復、リスク分析を重視 | 独立性の高い部分ごと、リスク |
| ウォータフォール | 上流から下流へ一方通行、原則手戻りなし | 工程順、後戻りしない |
| プロトタイピング | 早期に試作品を作って利用者の評価を得る | 試作、認識合わせ |
| アジャイル | 短期間（数週間）の反復で動くものを継続提供 | イテレーション、変化対応 |
スパイラルモデルは「反復」という性質ではアジャイルと似ていますが、1サイクルが大きく（数か月単位）、リスク分析を明示的に組み込む点が決定的に違います。
アジャイルの源流の一つとして位置づけられる存在です。
💡 スパイラルモデルの核心を3行で
・システムを独立性の高い部分に分け、サイクルごとに作り込む反復型の開発モデル
・1サイクルは「計画→リスク分析→開発・テスト→評価」の4フェーズで構成される
・リスクの早期発見と要件変更への柔軟性が強み、提唱者はバリー・ベーム
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
スパイラルモデルは、IP・FE・APの午前問題で開発モデルの比較問題として繰り返し出題されています。出題パターンは大きく2つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H30秋 午前 問49 |
スパイラルモデルの特徴として正しいものを選ぶ問題。 | ・「独立性の高い部分から開発し、ユーザレビューを反映して次工程へ」が正解 ・ウォータフォール・プロトタイプの説明がひっかけ |
| AP H29春 午前 問46 |
開発モデルの特徴を組み合わせる問題。 | ・「サブシステム単位の反復」がスパイラルモデルの特徴 ・成長型／段階的開発との混同に注意 |
| IP R4 問40 |
システム開発モデルの説明として適切なものを選ぶ問題。 | ・「部分単位で開発・評価を繰り返す」がキーワード ・ウォータフォール・アジャイルとの区別 |
📝 IPA試験での出題パターン
パターン1：「スパイラルモデルの特徴を選べ」
4つの開発手法の説明文が並び、スパイラルモデルに該当するものを選ぶ形式。正解の選択肢には「独立性の高い部分（サブシステム）ごとに開発を繰り返す」「ユーザの評価を次工程に反映する」というキーワードが含まれます。ひっかけは「上流から下流へ一方通行」（ウォータフォール）、「試作品で要件を確認する」（プロトタイピング）、「短いイテレーションで動くソフトウェアを継続提供」（アジャイル）です。
パターン2：「開発モデルの組合せ問題」
複数の開発モデル名と説明文を正しく組み合わせる形式。「リスク分析を重視」「サブシステム単位の反復」のキーワードでスパイラルモデルを特定します。
試験ではここまででOKです。ベームの原論文の細かい図形（4象限の渦巻き図）を描けるレベルまでは問われないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. スパイラルモデルの説明として、最も適切なものはどれでしょうか？
- A. 要件定義から運用まで工程を順に進め、原則として前工程に戻らない一方通行の開発モデル。
- B. システムを独立性の高い部分ごとに分割し、設計・開発・評価のサイクルを繰り返しながら全体を完成させる開発モデル。
- C. 開発の早い段階で試作品を作成して利用者の評価を受け、その結果を要件に反映する開発モデル。
正解と解説を見る
正解：B
解説：
選択肢Bは、サブシステム単位での反復という核心と、サイクル内で「設計・開発・評価」を回すという特徴を正確に表しており、これがスパイラルモデルの定義そのものです。
選択肢Aはウォータフォールモデルの説明です。工程を上流から下流へ一方通行で進める点が特徴で、スパイラルモデルのように反復はしません。選択肢Cはプロトタイピングモデルの説明です。試作品で利用者の認識合わせを行う手法であり、サブシステム単位で全体を繰り返し作り込むスパイラルモデルとは進め方が異なります。
よくある質問（FAQ）
Q. スパイラルモデルとアジャイル開発はどこが違うのですか？
どちらも反復型ですが、1サイクルの粒度と思想が違います。スパイラルモデルは数か月単位の大きなサイクルでサブシステムを作り込み、リスク分析を明示的なフェーズとして組み込むのが特徴です。アジャイルは1～4週間程度の短いイテレーションで「動くソフトウェア」を継続的に提供し、変化への適応を最優先します。歴史的にはスパイラルモデル（1986年）がアジャイル（2001年のアジャイルソフトウェア開発宣言）の源流の一つです。
Q. スパイラルモデルが向いている案件と向いていない案件は？
向いているのは、要件が固まりきっていない大規模システムや、新技術を採用するためリスクが読みづらいプロジェクトです。サイクルごとにリスクを潰せるため、不確実性に強くなります。一方、要件が完全に固定されていて変更がほぼない小規模案件には不向きです。サイクル管理のオーバーヘッドが利益を上回ってしまい、ウォータフォールの方が効率的になります。
Q. インクリメンタルモデル・反復型モデルとの呼び方の違いは？
広い意味ではすべて「反復型開発」に分類されますが、IPA試験では区別して扱われます。インクリメンタル（段階的）モデルはシステムを機能ごとに分け、段階的に追加リリースしていく手法です。スパイラルモデルはこれにリスク分析と評価ループを組み込んだ発展形と理解してください。試験では「リスク分析」というキーワードが出てきたらスパイラルモデル、と判断すれば問題ありません。
Q. スパイラルモデルの欠点はありますか？
いくつかあります。サイクルを重ねるたびに要件が膨らみ、当初の予算・スケジュールを超過しやすい点が代表的です。また、各サイクルでリスク分析を行うため、リスク評価ができる経験豊富な技術者がチームに必要になります。さらに、最終的な完成形が見えにくいため、固定価格契約のプロジェクトには馴染みにくいという実務上の課題もあります。試験ではここまで深く問われませんが、実務では知っておくと役立ちます。
