ITパスポート 令和7年度 問44:development_managementに関する問題
システム開発の早い段階で,目に見える形で利用者の要求が確認できるように確認用のソフトウェアを作成するソフトウェア開発モデルとして,最も適切なものはどれか。
- aアジャイル
- bウォーターフォール
- cスパイラル
- dプロトタイピング正答
AI解説(初心者・標準・上級)
理解度に合わせて3レベルの解説を無料で読めます。
答えは d「プロトタイピング」 です。
プロトタイプ=“試作品・見本”のこと。開発の早い段階で、まず動く見本をパパッと作って利用者に見せ、「こんな感じでいい?」と確認する作り方です。
家を建てる前に模型を見せて「玄関はここでOK?」と確かめるのに似ています。早めに見せることで「思ってたのと違う!」という失敗を防げます。
👉 覚え方:プロトタイピング=“見本を先に見せて確認”。
ほかの選択肢:a アジャイル=少しずつ作って変更に対応/b ウォーターフォール=全部決めてから順番に作る/c スパイラル=危ない所から少しずつ繰り返して作る。
なぜこれが正解か
正解は d。プロトタイピングは、開発の早期に試作品(プロトタイプ)を作って利用者に提示し、要求を“目に見える形”で確認・すり合わせる開発モデル。仕様の認識違いや要求漏れを早期に発見でき、手戻りを減らせる。問題文「目に見える形で要求を確認するための確認用ソフトを作成」はプロトタイピングの定義そのもの。
各選択肢の解説
- a アジャイル:短い反復で動くソフトを継続リリースし変更に迅速対応する手法群(試作品提示が主目的ではない)。
- b ウォーターフォール:要件→設計→実装→テストを順に進める方式。早期の現物確認は不得手。
- c スパイラル:リスクの大きい部分から反復して開発を進める、リスク駆動の反復型。
覚え方・ひっかけ注意
キーワードは「早い段階」「目に見える形」「確認用ソフト」=プロトタイピング。アジャイルと迷うが、“試作品を作って要求を確認”という目的の明示があればd。
プロトタイピングモデルの理論的背景と目的
プロトタイピングモデルは1970〜80年代に、ウォーターフォールモデルの「要件定義の質の低さ→後工程での大量手戻り」という問題への対策として確立された開発手法である。要件定義段階では利用者自身も「何が欲しいか」を完全に言語化できないことが多く、文書化された仕様書だけでは認識の齟齬が生じやすい。プロトタイプ(試作品)を早期に開発・提示することで、利用者は「実際に触れることで自分の真のニーズを発見」できるようになり、要求品質の精度を高めることができる。これを「要求の明確化」と「開発リスクの早期低減」の二つの観点で捉えることが重要である。
プロトタイプの種類と活用タイミング
プロトタイプには目的と完成度によって複数の種類がある。
- 低忠実度プロトタイプ(Lo-Fi):紙・ホワイトボードに画面レイアウトを描いたスケッチ。作成コストが極めて低く、初期の要求確認に使う。
- 高忠実度プロトタイプ(Hi-Fi):実際の画面操作に近いインタラクティブなモックアップ。FigmaやAdobe XD等のUIデザインツールで作成。
- スロービープロトタイプ:特定の技術的実現可能性を確認するために作る技術検証型のもの。PoCと近い概念。
プロトタイピングの実施タイミングは要件定義フェーズが基本だが、UIリニューアルや新機能のA/Bテストなど開発途中での活用も増えている。
誤答選択肢との明確な区別
- 選択肢a(アジャイル):反復開発で変更に迅速に対応する手法全般。早期に動くソフトウェアを提供する点はプロトタイピングと共通するが、「要求確認のための試作品作成」がアジャイルの主目的ではなく、変更対応と継続的デリバリーが核心。
- 選択肢b(ウォーターフォール):各工程を一方向に実施。早い段階での利用者確認は設計上ない。
- 選択肢c(スパイラルモデル):要求分析→リスク分析→プロトタイプ開発→評価を繰り返すBoehmのモデル。プロトタイプを使うがリスク管理を重点に置く点で純粋なプロトタイピングモデルとは異なる。
試験での位置づけと出題傾向
マネジメント系「開発管理・ソフトウェア開発モデル」の頻出テーマ。設問の「目に見える形で利用者の要求が確認できるようにする」というキーワードがプロトタイピングの最大の特徴を表す。スパイラルとプロトタイピングの区別(スパイラルはリスク分析が中心・繰り返し回数が設計で決まっている、プロトタイピングは要求確認が目的)が問われる高難度バリアントも出題される。
選択肢の発展補足
プロトタイピングの最大のリスクは「プロトタイプが本番システムと誤解される」ことである。プロトタイプは基本的に「確認用の使い捨て」として設計されるべきだが、実際の開発現場ではプロトタイプがそのまま本番コードとして使い続けられ、品質問題(テスト不十分・設計の一貫性欠如)を引き起こすケースが多い。このリスクを「プロトタイプの進化的成長(Evolutionary Prototyping)」と「使い捨てプロトタイプ(Throwaway Prototyping)」の区別で管理する手法が実務で使われる。基本情報技術者以上ではUCD(User Centered Design:ユーザー中心設計)・ユーザビリティテストとプロトタイピングの関係まで出題される。
出典:IPA(情報処理推進機構)公式 ITパスポート試験 令和7年度 問44/ 公的機関配布資料につき出典明記の上引用。解説は合格ナビによる独自AI解説です。