開発モデル(ウォーターフォール型、アジャイル型(スクラム等)、プロトタイプ型)

この章で覚えておきたいこと

• ウォーターフォールは、工程を順番に進めて前工程の成果物を次工程へ引き渡す開発モデルです。
• プロトタイプは、試作品を早く見せて利用者との認識ずれを減らす開発モデルです。
• スパイラルは、反復そのものではなく、リスク分析を繰り返しながら進める点が本質です。
• アジャイルは、短い反復で動く成果物を作り、変化に応じて優先順位を見直す考え方です。
• スクラムはアジャイルの代表的フレームワークであり、役割、イベント、成果物の対応で問われます。
• プロダクトオーナーは価値最大化とプロダクトバックログ管理、スクラムマスターはスクラム運営の支援と障害の除去を担います。
• デイリースクラムはスプリントゴールへの進捗を検査し、スプリントバックログや次の作業計画を調整する15分のイベントです。
• XPは、ペアプログラミング、テスト駆動開発、リファクタリングなどの実践を重視します。
• フィーチャ駆動開発は、利用者価値のある小さな機能単位で進める手法です。
• ローコード開発は少ないコード量で素早く作る開発手段であり、スクラムやXPのような開発手法そのものではありません。
• DevOpsは開発モデルではなく、開発と運用を連携させて継続的に改善する考え方です。

基本知識

まずは出題される粒度を分けて覚えます

一次試験では、似た言葉を同じ階層の概念として並べてひっかける出題が多いです。そのため、最初に何を説明している言葉かを切り分けることが重要です。

ウォーターフォール、プロトタイプ、スパイラルは、開発工程をどう進めるかを表す開発モデルです。アジャイルは、変化に対応しながら短い反復で進める開発の考え方です。スクラムはその考え方を具体的に運用するフレームワークであり、XPは品質を高めるための実践色が強い手法です。フィーチャ駆動開発は機能単位で進めるアジャイル系手法です。ローコードは開発を速くするための手段であり、DevOpsは開発と運用の連携思想です。

この切り分けができると、2023_2第13問や2025第13問のように、スクラム、XP、ローコード、DevOpsが同時に並んでも落ち着いて判断できます。

ウォーターフォール型は順番に進めるモデルです

ウォーターフォール型は、要件定義、設計、実装、テスト、移行のように、工程を順番に進める考え方です。前工程の成果物を固めてから次へ進むため、計画や管理がしやすく、大規模案件や要件が比較的安定した案件と相性がよいです。

試験では、「前工程の承認後に次工程へ進む」「工程ごとの成果物を管理する」といった表現が出たら、まずウォーターフォールを疑います。一方で、利用者に早く画面や試作品を見せる説明ならプロトタイプ、短い反復で優先順位を見直す説明ならアジャイル系です。

ウォーターフォールやV字モデルの文脈では、開発成果物とテスト範囲の対応も問われます。詳しいテスト技法は 品質評価 で扱いますが、F_08では工程対応を押さえます。

| 確認段階 | 主な対象 | 見ること | 典型的なひっかけ | |---|---|---|---| | 単体テスト | モジュール、関数、部品 | 個々の処理が設計どおり動くか | 利用者の受入確認と読む | | 結合テスト | モジュール間、外部インタフェース | 呼び出し、データ受渡し、連携が正しいか | 性能テストそのものと読む | | システムテスト | システム全体 | 機能・非機能要求を全体として満たすか | 単一部品だけの動作確認と読む | | 受入テスト | 発注者・利用者視点 | 業務目的や要求に合っているか | 開発者だけが内部構造を確認するテストと読む |

プロトタイプ型とスパイラル型は反復の目的が違います

プロトタイプ型は、試作品を作って利用者に見せ、要件や画面イメージを具体化するためのモデルです。要件の曖昧さや認識ずれを早い段階で減らしたいときに向いています。試作品を見せることが中心であり、テスト工程の代替ではありません。

スパイラル型は、計画、開発、評価を反復しつつ、その都度リスク分析を重ねて完成度を高めるモデルです。単に何度も繰り返すからスパイラルなのではなく、リスク評価が中核にある点を押さえる必要があります。

問題文で「試作品を見せる」が書かれていればプロトタイプ、「リスクを分析しながら反復する」が書かれていればスパイラルです。この差は古い年度でも繰り返し問われています。

アジャイル型は変化への対応を重視します

アジャイル型は、短い期間で計画、実装、テスト、確認を繰り返し、利用者や顧客の反応を受けて優先順位を見直しながら進めます。最初にすべての要件を固定するのではなく、変化を前提に進める点が特徴です。

ただし、アジャイルは無計画に作るという意味ではありません。短い反復ごとに目標を定め、成果を確認し、次の反復へつなげます。試験では、「計画しない」「レビューしない」「テストしない」といった極端な説明は誤りになりやすいです。

スクラムは役割とイベントの対応で覚えます

スクラムは、アジャイル開発を進める代表的なフレームワークです。一次試験では、役割とイベントの説明を入れ替える形でよく出題されます。2024第14問と2025第13問は、この取り違えを正面から問う出題でした。

プロダクトオーナーは、スクラムチームが生み出す価値を最大化する責任を持ち、プロダクトバックログの内容や優先順位を管理します。スクラムマスターは、スクラムが正しく機能するように支援し、障害物の除去や進め方の改善を助けます。開発者は、スプリント内でインクリメントを作ります。

イベントも目的を分けて覚えます。デイリースクラムは、開発者がスプリントゴールへの進捗を検査し、必要に応じてスプリントバックログや次の作業計画を調整する15分のイベントです。障害の共有やコミュニケーション改善は、その過程で得られる副次的な効果として押さえます。スプリントレビューは、スプリントでできた成果をステークホルダーに示し、フィードバックを得る場です。スプリントレトロスペクティブは、チームの進め方を振り返り、次回へ向けて改善する場です。

試験で特に危ないのは、次の取り違えです。価値最大化を担うのはスクラムマスターではなくプロダクトオーナーです。障害除去を担うのはプロダクトオーナーではなくスクラムマスターです。成果を見せてフィードバックを得るのはデイリースクラムではなくスプリントレビューです。進め方を振り返るのはレビューではなくレトロスペクティブです。

XPは具体的な実践で見分けます

XPは、変化に対応しながら品質を高めるための具体的実践を重視する手法です。ペアプログラミング、テスト駆動開発、リファクタリング、継続的インテグレーション、共同所有、持続可能なペースなどが代表例です。

2023_2第13問では、XPそのものの説明と、XPを構成する実践であるリファクタリングの説明を取り違えさせる形で出題されました。外部から見た振る舞いを変えずに内部構造を改善するのはリファクタリングであり、XP全体の定義ではありません。

2025第13問では、XPのペアプログラミングが正しく問われました。2人で1つのコードを扱い、相談やその場でのレビューを通じて品質を高める実践だと覚えておくと、分担作業の説明と混同しにくくなります。

フィーチャ駆動開発は小さな機能単位で進めます

フィーチャ駆動開発は、利用者に価値のある小さな機能のかたまりを単位として、計画、設計、実装を進める手法です。アジャイル系手法の一つであり、ウォーターフォールのように全工程を一方向へ一括で進める手法ではありません。

2023_2第13問では、「ユーザにとって価値のある小さな機能のかたまりを単位として、実際に動作するソフトウェアを短期反復的に開発する」という説明が正しいものとして出ています。機能単位という言葉が出たら、フィーチャ駆動開発を連想できるようにしておくと有利です。

ローコード開発は開発手段であり、開発モデルではありません

ローコード開発は、GUI部品やテンプレート、部品再利用などを使って、コード記述量を減らしながらアプリケーションを素早く構築する方法です。何をどの順序で進めるかという開発モデルやフレームワークとは役割が違います。

2025第13問では、ローコード開発に対して、反復的に優先順位を付けて開発する説明があてられていましたが、これはローコードではなくアジャイル系手法の説明に近いです。ローコードは、スクラムで進める現場でも使えます。つまり、ローコードは進め方ではなく作り方を効率化する手段だと整理します。

DevOpsは開発と運用をつなぐ考え方です

DevOpsは、開発と運用の壁を低くし、自動化や監視、継続的改善を通じて、導入、運用、改善を速く安定して回す考え方です。ウォーターフォールやスクラムと同じ「開発モデル」の欄に置かれることがありますが、厳密には役割が異なります。

2023_2第13問と2025第13問では、どちらも「開発と運用を分離する」という誤った説明が置かれました。DevOpsは分離ではなく連携です。CI/CDや監視、自動化と結び付くことが多いですが、それ自体がスクラムやXPの代わりになるわけではありません。

実務では、スクラムで開発を進め、XPの実践で品質を高め、ローコードで実装を速め、DevOpsで運用までつなぐことがあります。試験でも、このように階層の違う概念を横並びにされるため、何を説明している文かを先に判定することが重要です。

この章のまとめ

ウォーターフォールは順番に進めるモデル、プロトタイプは試作品で要件を具体化するモデル、スパイラルはリスク分析を伴う反復型モデルです。アジャイルは短い反復で変化へ対応する考え方であり、その代表的フレームワークがスクラムです。

スクラムでは、プロダクトオーナーが価値最大化とバックログ管理、スクラムマスターが運営支援と障害除去を担います。デイリースクラムはスプリントゴールへの進捗を検査し、スプリントバックログや次の作業計画を調整する15分のイベント、スプリントレビューは成果確認とフィードバック取得、レトロスペクティブは進め方の改善です。ここを取り違えないことが最重要です。

XPはペアプログラミングやテスト駆動開発などの実践、フィーチャ駆動開発は小さな機能単位で進める手法、ローコード開発は少ないコード量で素早く作る手段、DevOpsは開発と運用の連携思想です。試験では、開発モデル、フレームワーク、実践、手段、思想を同じものとして読まないことが得点差になります。

一次試験過去問での出方

2023_2第13問では、DevOps、XP、フィーチャ駆動開発、リーンソフトウェア開発を並べ、用語そのものの定義と、その一部を構成する実践や別手法の説明を切り分ける問題でした。特に、XPとリファクタリングの取り違え、フィーチャ駆動開発と機能単位の反復開発の対応、DevOpsと開発・運用の連携を押さえておく必要があります。

2024第14問では、スクラムの役割とイベントが中心でした。プロダクトオーナーとスクラムマスターの責任範囲、デイリースクラムとスプリントレビュー、レトロスペクティブの目的の違いを正確に覚えているかが問われました。近年では最も典型的なスクラム用語の取り違え問題です。

2025第13問では、スクラム、ローコード開発、DevOps、XPを混在させ、イベントの目的、開発手段、開発と運用の関係、具体的実践を切り分ける問題でした。デイリースクラムは成果発表の場ではないこと、ローコードは反復開発手法ではないこと、DevOpsは分離ではなく連携であること、XPのペアプログラミングの意味をまとめて確認する必要があります。

それ以前の問題では、ウォーターフォール、プロトタイプ、スパイラルの違いも継続的に問われています。特に、プロトタイプは試作品による要件具体化、スパイラルはリスク分析を伴う反復という軸で見分ける問題は何度も出ています。