主なソフトウェア開発モデル

ソフトウェア開発モデルとは

ソフトウェアを開発するとき、いきなりプログラムを書き始めるのではなく、「どんな順序で」「どのように進めるか」を計画的に決める必要があります。この開発の進め方のパターンをソフトウェア開発モデルと呼びます。

ソフトウェア開発には、要件定義や設計といった上流工程と、プログラミングやテストといった下流工程があります。開発モデルの違いは、これらの工程をどのような順番・やり方で進めるかの違いだと考えるとわかりやすいでしょう。

ここでは、ITパスポート試験でよく問われる代表的な開発モデルを学んでいきます。

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

ウォーターフォールモデルは、最も古典的で基本的な開発モデルです。「ウォーターフォール（waterfall）」は英語で「滝」を意味します。滝の水が上から下へ一方向に流れ落ちるように、上流工程から下流工程へ順番に進めていく手法です。

具体的には、次のような流れで進みます。

1. 要件定義 ── 何を作るか決める
2. 設計 ── どう作るか決める
3. プログラミング ── 実際にコードを書く
4. テスト ── 正しく動くか確認する
5. 運用・保守 ── 完成したシステムを使い続ける

graph TB
  subgraph 上流工程
    A["要件定義"]:::primary
    B["設計"]:::primary
  end
  subgraph 下流工程
    C["プログラミング"]:::base
    D["テスト"]:::base
    E["運用・保守"]:::base
  end
  A --> B --> C --> D --> E

  classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333;
  classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af;
  classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;

ウォーターフォールモデルの最大の特徴は、原則として前の工程には戻らないということです。各工程をしっかり完了させてから次に進むため、大規模なプロジェクトで計画的に進めやすいというメリットがあります。

一方で、開発の途中で「やっぱりこの機能を変えたい」といった変更が生じると、前の工程に戻る手戻りが発生し、大きなコストと時間のロスにつながるというデメリットがあります。とくに、完成間近になって要件の誤りが見つかると、最初からやり直しに近い作業が必要になることもあります。

試験で出るポイント

ウォーターフォールモデルは「上流工程から下流工程へ一方向に進む」「手戻りが困難」という特徴がキーワードです。アジャイル開発との対比で出題されることもあります。

プロトタイピングモデル

ウォーターフォールモデルでは、完成品ができあがるまで利用者が実際の画面や動きを確認できません。そのため「思っていたものと違う」というミスマッチが起こりがちです。

この問題を解決するために考えられたのがプロトタイピングモデルです。開発の早い段階で試作品（プロトタイプ）を作成し、利用者に実際に触ってもらいながら要件を確認・修正していく手法です。

たとえば、業務システムを開発するとき、まず画面のデザインや基本的な操作だけを再現した簡易版を作ります。利用者がそれを操作して「ここはもう少し使いやすくしてほしい」「この機能も必要だ」といったフィードバックを返します。開発者はそのフィードバックをもとに改善を繰り返し、最終的な完成品を仕上げていきます。

プロトタイピングモデルのメリットは、利用者の要望を早い段階で反映できるため、完成後の「思っていたものと違う」という手戻りを大幅に減らせることです。ただし、試作品の作成に時間がかかるため、大規模なシステムには向かないこともあります。

試験で出るポイント

プロトタイピングの定義は「開発の早期に確認用のソフトウェア（プロトタイプ）を作成し、利用者に確認してもらう」です。2025年の試験でも出題されています。

スパイラルモデル

スパイラルモデルは、システムをいくつかの部分に分け、それぞれについて設計・開発・テストの工程を反復（イテレーション）しながら進めていく手法です。「スパイラル（spiral）」は「らせん」を意味し、らせん状にぐるぐると繰り返しながら完成度を高めていくイメージです。

各反復のサイクルでは、まずリスク分析を行い、技術的な課題や問題点を洗い出してから開発を進めます。これにより、リスクの高い部分を早い段階で発見し、対処できるのが大きなメリットです。

graph TB
  subgraph イテレーション["1回のイテレーション"]
    A["計画"]:::base --> B["リスク分析"]:::alert
    B --> C["開発・テスト"]:::base
    C --> D["評価"]:::primary
  end
  D -->|"完成度を上げて繰り返す"| A

  classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333;
  classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af;
  classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;

スパイラルモデルは、ウォーターフォールモデルの「計画的に進められる」利点と、プロトタイピングモデルの「途中で確認・修正できる」利点を組み合わせた手法といえます。

RAD（Rapid Application Development）

RAD（Rapid Application Development）は、その名の通り「高速にアプリケーションを開発する」ことを目指す手法です。

RADでは、開発を支援するツール（GUIビルダーやコード自動生成ツールなど）を積極的に活用し、少人数のチームで短期間に開発を完了させます。利用者も開発に参加してフィードバックを行いながら、素早く完成品を仕上げていくのが特徴です。

RADは小規模から中規模のシステム開発に適しており、短い納期で成果物を求められる場面で効果を発揮します。

開発モデルの比較

ここまで学んだ4つの開発モデルを、「進め方の特徴」「メリット」「デメリット」で整理してみましょう。

モデル	進め方	メリット	デメリット
ウォーターフォール	上流→下流へ一方向に進める	計画的で管理しやすい	手戻りが困難、変更に弱い
プロトタイピング	早期に試作品を作り確認	利用者の要望を反映しやすい	試作品作成に時間がかかる
スパイラル	反復（イテレーション）で段階的に開発	リスクを早期に発見できる	管理が複雑になりやすい
RAD	ツール活用で短期間に開発	開発スピードが速い	大規模システムには不向き
アジャイル	短いサイクル（イテレーション）を反復し、動くソフトウェアを少しずつ作る	要件の変更に柔軟に対応できる	全体の進捗管理が難しい

これらのモデルは「一方向か反復か」「早期に利用者が確認できるか」という2つの軸で整理すると、違いが明確になります。ウォーターフォールは一方向で利用者確認が遅く、プロトタイピングは早期に確認でき、スパイラルは反復しながらリスクを管理し、RADはスピード重視で進めます。アジャイルは短い反復サイクルで変化に柔軟に対応します。アジャイルの詳しい手法（スクラム、XPなど）については、アジャイルのページで解説しています。

試験で出るポイント

各モデルの名前と特徴を結びつける問題がよく出ます。とくに「ウォーターフォール＝一方向・手戻り困難」「プロトタイピング＝試作品で早期確認」「スパイラル＝反復＋リスク分析」の組み合わせを正確に覚えましょう。

リバースエンジニアリング

リバースエンジニアリングは、既存のソフトウェアのソースコードや動作を解析して、設計情報や仕様を抽出する手法です。通常の開発が「設計→コード」という流れであるのに対し、リバースエンジニアリングは「コード→設計」と逆方向に進むため、「リバース（reverse＝逆）」と名前がついています。

たとえば、古い業務システムの設計書が残っていないとき、稼働中のプログラムのソースコードを解析して仕様書を復元するような場面で使われます。既存システムの保守や、新システムへの移行の際に役立つ手法です。

なお、リバースエンジニアリングは「開発モデル」というよりも「既存ソフトウェアを分析する手法」ですが、ITパスポートのシラバスではこの項目に含まれています。

試験で出るポイント

リバースエンジニアリングは「ソースコードを解析して仕様書・設計情報を抽出する」手法です。「リファクタリング」と混同しないよう注意しましょう。リファクタリングは「外部から見た機能を変えずに内部構造を改善する」手法であり、目的がまったく異なります。この違いは過去に繰り返し出題されています。

まとめ

ソフトウェア開発モデルは、プロジェクトの規模や要件の確定度合い、リスクの大きさなどに応じて使い分けます。一つの「正解」があるわけではなく、状況に合ったモデルを選ぶことが重要です。試験では、各モデルの名前・特徴・メリット・デメリットを正しく結びつけられるかが問われます。あわせて、リバースエンジニアリングの定義と、リファクタリングとの違いもしっかり押さえておきましょう。

---

過去問で実力チェック

過去問に挑戦

Q. 開発対象のソフトウェアを，比較的短い期間で開発できる小さな機能の単位に分割しておき，各機能の開発が終了するたびにそれをリリースすることを繰り返すことで，ソフトウェアを完成させる。一つの機能の開発終了時に，次の開発対象とする機能の優先順位や内容を見直すことで，ビジネス環境の変化や利用者からの要望に対して，迅速に対応できることに主眼を置く開発手法はどれか。

• ア アジャイル
• イ ウォータフォール
• ウ 構造化
• エ リバースエンジニアリング

解答（令和2年）

正解: ア

Q. リバースエンジニアリングで実施する作業として，最も適切なものはどれか。

• ア 開発中のソフトウェアに対する変更要求などに柔軟に対応するために，短い期間の開発を繰り返す。
• イ 試作品のソフトウェアを作成して，利用者による評価をフィードバックして開発する。
• ウ ソフトウェア開発において，上流から下流までを順番に実施する。
• エ プログラムを解析することで，ソフトウェアの仕様を調査して設計情報を抽出する。

解答（令和2年）

正解: エ

Q. 運用中のソフトウェアの仕様書がないので，ソースコードを解析してプログラムの仕様書を作成した。この手法を何というか。

• ア コードレビュー
• イ デザインレビュー
• ウ リバースエンジニアリング
• エ リファクタリング

解答（令和5年）

正解: ウ

Q. リファクタリングの説明として，適切なものはどれか。

• ア ソフトウェアが提供する機能仕様を変えずに，内部構造を改善すること
• イ ソフトウェアの動作などを解析して，その仕様を明らかにすること
• ウ ソフトウェアの不具合を修正し，仕様どおりに動くようにすること
• エ 利用者の要望などを基に，ソフトウェアに新しい機能を加える修正をすること

解答（令和5年）

正解: ア

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

• ア 開発する機能を小さい単位に分割して，優先度の高いものから短期間で開発とリリースを繰り返す。
• イ 共通フレームを適用して要件定義，設計などの工程名及び作成する文書を定義する。
• ウ システム開発を上流工程から下流工程まで順番に進めて，全ての開発工程が終了してからリリースする。
• エ プロトタイプを作成して利用者に確認を求め，利用者の評価とフィードバックを行いながら開発を進めていく。

解答（令和6年）

正解: ア

Q. ソフトウェア開発モデルであるアジャイルモデルの特徴に関して，次の記述中の a，b に入れる字句の適切な組合せはどれか。

アジャイルモデルとは，要件を確定してから開発を実施するウォーターフォールモデルの [　a　] する形で提唱された，[　b　] できるようにソフトウェアを開発するための手法の総称である。

	a	b
ア	課題を改善	開発工程で生じる種々の変更に迅速に対応
イ	課題を改善	開発工程を順に実施
ウ	特徴を継承	開発工程で生じる種々の変更に迅速に対応
エ	特徴を継承	開発工程を順に実施

• ア 課題を改善 / 開発工程で生じる種々の変更に迅速に対応
• イ 課題を改善 / 開発工程を順に実施
• ウ 特徴を継承 / 開発工程で生じる種々の変更に迅速に対応
• エ 特徴を継承 / 開発工程を順に実施

解答（令和7年）

正解: ア

Q. システム開発の早い段階で，目に見える形で利用者の要求が確認できるように確認用のソフトウェアを作成するソフトウェア開発モデルとして，最も適切なものはどれか。

• ア アジャイル
• イ ウォーターフォール
• ウ スパイラル
• エ プロトタイピング

解答（令和7年）

正解: エ

もっと過去問を解きたい方へ

フライトパスアプリなら、詳しい解説や分野別の過去問演習、SRS（間隔反復）学習ができます。

App StoreGoogle Play