対象試験と出題頻度

プロトタイピングモデルは、ITパスポート・基本情報技術者・応用情報技術者の3区分で出題されるテーマです。

ソフトウェア開発モデルの比較問題として定番化しており、「ウォータフォールモデル」「スパイラルモデル」「アジャイル開発」「RAD」との違いを正確に区別できるかが問われます。

詳細をクリックして確認
対象試験:
ITパスポート
基本情報技術者
応用情報技術者
出題頻度:
★★★☆☆
ランクB(標準)覚えておくと有利

用語の定義

情報処理試験を勉強していると、「プロトタイピングモデルって試作品を作るだけ?ウォータフォールやスパイラルとどう違うの?」と混乱しがちです。

プロトタイピングモデル(Prototyping Model)とは、一言で言うと

 「開発の早い段階で試作品を作り、利用者に触ってもらって要件を固める開発モデル

のことです。

イメージとしては、注文住宅のモデルハウスです。

図面だけ見せられても、お客様は「実際の広さや動線」をイメージしづらいものです。そこで完成前に小さなモデルハウスを建てて、実際に歩いてもらい「ここの動線が悪い」「キッチンはもう少し広く」といった意見を引き出します。

プロトタイピングモデルも同じ発想で、本番システムを作る前に画面や機能の試作品を見せて、利用者の本音を早めに引き出すアプローチです。

📊 プロトタイピングモデルの基本情報

項目 内容
英語名 Prototyping Model
分類 ソフトウェア開発モデルの一種
主な目的 要件のあいまいさ解消・利用者との認識合わせ
適した場面 要件が固まりにくい新規システム、UIが重要なシステム

解説

従来のウォータフォールモデルでは、要件定義の段階で利用者の要望を文書にまとめ、それを元に設計・実装まで進めます。

しかし、文書ベースの要件確認には限界があり、完成品を見せたときに「思っていたものと違う」となるケースが頻発しました。

このような後戻りを減らすために考案されたのが、早い段階で動く試作品を見せて利用者からフィードバックを得るアプローチです。

開発の流れ

大まかな流れは「要件のヒアリング → 試作品作成 → 利用者による評価 → 要件の修正」を繰り返し、要件が固まったところで本格開発に移行します。

🔄 プロトタイピングモデルの開発フロー

🔁 要件が固まるまで繰り返す
①要件
ヒアリング
②試作品
作成
③利用者
評価
④要件
修正
修正内容を試作品に反映して再評価へ(②に戻る)
✅ 要件が確定したら次へ
⑤本格開発(設計・実装・テスト・リリース)

メリットとデメリット

試作品を介したコミュニケーションには明確な利点と欠点があります。

観点 内容
メリット ・要件のあいまいさを早期に解消できる
・利用者と開発者の認識ズレを防げる
・後工程での大規模な手戻りが減る
デメリット ・試作品作成の工数が追加で発生する
・大規模システムには不向き
・利用者が試作品を完成版と誤解することがある

他の開発モデルとの比較

本モデルを正しく位置づけるには、他の主要な開発モデルと「何が特徴か」で整理するのが近道です。

モデル名 特徴 見分けキーワード
プロトタイピングモデル 試作品で要件を確定させてから本開発に進む 試作品、要件のあいまいさ
ウォータフォールモデル 要件→設計→実装→テストを順に一度だけ進む 上流から下流、後戻りなし
スパイラルモデル サブシステム単位で設計〜評価のサイクルを回す リスク分析、サイクル
アジャイル開発 短い反復で動くソフトウェアを継続的にリリース イテレーション、変化への対応
RAD 少人数・短期間でツールを駆使して高速開発 短期間、高速、少人数

では、この用語が試験でどのように出題されるか見ていきましょう。

💡 プロトタイピングモデルの核心を3行で

・試作品を早期に見せて利用者の意見を引き出す開発モデル
・要件があいまいなときや、UIが重要なシステムに向いている
・小規模向け。大規模システムでは試作の工数が膨らみ不向き


試験ではこう出る!

プロトタイピングモデルは、IP・FE・APの3区分で開発モデルの比較問題として繰り返し出題されています。出題パターンは大きく2つに分かれます。

📊 過去問での出題実績

試験回 出題内容 問われたポイント
IP R元秋
問35
プロトタイピングの特徴を選ぶ問題。 ・「試作品で利用者の意見を反映」が正解
・ウォータフォール・段階的開発の説明がひっかけ
FE H30秋
午前 問50
プロトタイピングモデルを採用する目的を選ぶ問題。 ・「開発初期に利用者と仕様を確認」が正解
・テスト工程の効率化などが誤答選択肢
AP H29春
午前 問49
プロトタイピングが有効な状況を選ぶ問題。 ・「要件があいまいなとき」が正解
・要件が固まっている場合は不向きと判断する

📝 IPA試験での出題パターン

パターン1:「特徴を選べ」
4つの開発モデルの説明文が並び、プロトタイピングモデルに該当するものを選ぶ形式。キーワードは「試作品」「利用者の評価」「要件のあいまいさ解消」。「上流から下流へ順に進める」「リスク分析を伴うサイクル」「短い反復で動くソフトウェア」が出てきたら、それぞれウォータフォール・スパイラル・アジャイルなので除外する。

 

パターン2:「適用が有効な状況を選べ」
「要件がはっきりしない」「利用者がシステムイメージを持てていない」といった文脈で本モデルを選ばせる形式。逆に「要件が確定済み」「大規模で工程管理を厳格にしたい」場合はウォータフォールが適切なので注意してください。

 

試験ではここまででOKです。試作品の作り方の詳細(throwaway型・evolutionary型の区別)まで問われることはほぼないので、深追いは不要です。


【確認テスト】理解度チェック

ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。


Q. プロトタイピングモデルの説明として、最も適切なものはどれでしょうか?

  • A. 開発の早い段階で試作品を作って利用者に評価してもらい、その意見を反映しながら要件を確定させる開発モデル。
  • B. 要件定義・設計・実装・テストの工程を上流から下流へ順に一度だけ進め、原則として後戻りしないことを前提とする開発モデル。
  • C. システムを独立性の高いサブシステムに分割し、各サブシステムごとにリスク分析を伴う設計〜評価のサイクルを繰り返す開発モデル。

正解と解説を見る

正解:A

解説:
選択肢Aは、試作品を介して利用者の意見を吸い上げ、要件のあいまいさを早期に解消するというプロトタイピングモデルの本質を述べています。

選択肢Bはウォータフォールモデルの説明です。工程を順に進めて後戻りを前提としない点が特徴で、試作品の概念は登場しません。選択肢Cはスパイラルモデルの説明です。サブシステム単位でリスク分析を伴うサイクルを回す点が異なり、利用者評価による要件確定を主目的とする本モデルとは役割が違います。


よくある質問(FAQ)

Q. 試作品はどこまで作り込む必要がありますか?

利用者に「使い勝手」を判断してもらえる程度で十分です。画面の見た目と主要な操作フローだけ実装し、内部のデータ処理はダミーで済ませることが一般的です。試作品の作り込みすぎは本来の目的(要件確認)から外れ、コスト超過の原因になります。なお、試作品をそのまま発展させて本番システムにする「進化型プロトタイピング」と、試作品は捨てて本番は作り直す「使い捨て型プロトタイピング」がありますが、IPA試験ではこの区別までは問われません。

Q. アジャイル開発と何が違うのですか?

目的の置き方が異なります。プロトタイピングは「要件確定のために試作品を作る」アプローチで、要件が固まれば従来型の開発に移行することもあります。アジャイルは「変化を前提に短いサイクルで動くソフトウェアを継続的に届ける」開発スタイルそのものです。両者は排他的ではなく、アジャイル開発の中で試作品を活用する場面もあります。

Q. モックアップやワイヤーフレームと同じ意味ですか?

近い概念ですが厳密には別物です。ワイヤーフレームは画面の骨格を線で示した設計図、モックアップは見た目を再現した静的な画面イメージ、プロトタイプは実際にクリックや入力ができる動く試作品を指します。プロトタイピングモデルでは、利用者に実際に操作してもらうため、モックアップ止まりではなく動くプロトタイプを用意するのが基本です。

Q. 大規模システムには本当に向かないのですか?

システム全体に対して適用するのは不向きです。試作品の作成範囲が膨大になり、コストと期間が現実的でなくなるためです。ただし、大規模システムでも「特に要件が固まっていない画面」や「利用頻度の高い業務フロー」など、部分的に取り入れる手法は実務でよく行われています。試験では「大規模システム全体への適用」という文脈なら不適切と判断してください。