資格道場基本情報
資格道場 › レッスン一覧 › システム開発技術
システム開発技術・1/12・12分

開発モデルの種類とアジャイル

ゴール

ウォータフォール・プロトタイピング・スパイラル・RAD・アジャイル（スクラム/XP/ASD/FDD）を説明文から見分けられ、工程の並べ替え問題と「プロトタイプを何回作るか」の計算問題が自力で解けるようになる。

開発モデルは「どの説明がどのモデルか」を選ぶ問題として、免除試験を中心に毎年のように出ます。実務でも「この案件はウォータフォールで行くか、アジャイルで行くか」は最初に決める話なので、要件定義を分かる人ほど得点源にしやすい分野です。

このレッスンで稽古する（用語チェック・過去問）

結論：見分けるキーワードは1つずつ

開発モデルの問題は、説明文の中の決め手の一語を拾えば解けます。

  • 前の工程が終わってから次へ → ウォータフォール
  • 試作品・利用者に見せる・UI確認 → プロトタイピング
  • 繰り返す・リスクを評価 → スパイラル
  • 短期間・小さなチーム・ツール活用 → RAD
  • 短い反復（イテレーション/スプリント）・変化に対応 → アジャイル

開発モデル（開発プロセスモデル）とは「どんな順番・単位でシステムを作るか」の型のことです。

ウォータフォールモデル：滝は逆流しない

ウォータフォールモデルは、工程を順番に1回ずつ進め、前の工程の成果物（設計書など）を受け取って次の工程を行う逐次型のモデルです。名前のとおり、水が上から下へ落ちるように原則として前の工程に戻らないのが特徴です。家の建築で「設計図が確定してから基礎工事、基礎が終わってから柱」と進むイメージです。

工程の順番は次のとおりで、**「外側（利用者から見える）から内側（プログラムの中身）へ」**細かくなっていきます。

flowchart LR
  A["要件定義<br>何が必要か"] --> B["外部設計<br>システムの機能を定義"]
  B --> C["内部設計<br>機能をプログラムに分割"]
  C --> D["プログラム設計<br>各プログラムの内部構造"]
  D --> E["プログラミング<br>詳細手順を書いてコーディング"]
  E --> F["テスト"]
工程 やること 粒度
要件定義 現状の問題を分析し、要求をまとめる システム全体（業務目線）
外部設計 要求仕様を基に、システムに必要な機能を決める 利用者から見える範囲
内部設計 機能をプログラム単位に分割し、処理の流れを決める システムの内側
プログラム設計 1本のプログラムの中の構造（モジュール分け）を決める プログラム内部
プログラミング 詳細な手順を決めてコーディング 命令レベル
テスト 作ったものを確かめる 小さい単位→全体

要件定義やAPI設計の経験に置き換えると、「要件定義→画面・APIの外部仕様→内部のモジュール分割→個々の関数の設計→実装→テスト」と同じ流れです。長所は進捗管理がしやすく大規模向き、短所は後工程で要求の誤りに気づくと手戻り（前の工程からやり直すこと）が大きいことです。

原則として前の工程に戻らない要件定義外部設計内部設計プログラム設計プログラミングテスト誤りに気づくと上へ戻る＝手戻り大
工程は階段のように上から下へ一方向に進み、テストで要求の誤りに気づくと一番上まで戻ることになり、手戻りが大きい。

ウォータフォールの弱点を補う3つのモデル

ウォータフォールの「後で気づくと手戻りが大きい」を、それぞれ別のやり方で補ったのが次のモデルです。試験ではこの4つの説明を選択肢に並べて1つを選ばせるのが定番です。

モデル 決め手のキーワード 何を解決するか
ウォータフォール 工程を順に・前工程完了後に次へ・大規模向き 管理しやすさ
プロトタイピング 試作品を作り利用者の反応を確認・UIや応答性能の確認 要求の食い違いを初期につぶし、手戻りを減らす
スパイラル 要求分析〜実装を繰り返す・各回でリスクを評価 繰り返すたびにシステムを成長させる（成長型）
RAD 短期間・少人数・開発ツールを活用・期限（タイムボックス）厳守 開発スピード

似た言葉に注意：「段階的に機能を完成させ、繰り返して全体を仕上げる」はインクリメンタル（段階的）モデルの説明で、プロトタイピングではありません。プロトタイピングの本質は**「試作して見せて確かめる」、スパイラルの本質は「繰り返し＋リスク評価」**です。

  • 選択肢に「リレーショナルモデル」が混ざることがありますが、これはデータベースのデータモデルで、開発モデルではありません。
プロトタイピング試作品を作る利用者に見せる本開発反応を見て直す（初期に）スパイラル1周＝要求分析〜実装毎回リスクを評価周るたびに成長RAD短期間・少人数・ツール活用期限厳守期限の中で作り切る
プロトタイピングは試作品を見せて直すループ、スパイラルは繰り返すたびに大きくなる渦、RADは決めた期限の中で短く作り切る形。

プロトタイプの回数計算：残りが半分ずつ減る

「1回作るごとに未確定の仕様の50%が確定する」とき、確定するのは最初の量の50%ではなく、その時点で残っている量の50%です。だから未確定の割合は 0.5 → 0.25 → 0.125 … と掛け算で減ります。ピザを毎回「残りの半分」ずつ食べても、なかなかゼロにならないのと同じです。

  • n回後に残る未確定の割合 ＝ 0.5ⁿ
  • 「90%以上確定」＝「未確定が10%以下」と言い換えるのがコツ
回数 未確定の割合 確定した割合
1回 50% 50%
2回 25% 75%
3回 12.5% 87.5% ← まだ足りない
4回 6.25% 93.75% ← ここで初めて90%以上
未確定10%のライン最初未確定100%1回未確定50%2回未確定25%3回未確定12.5% 足りない4回未確定6.25%＝90%以上確定残りの半分ずつ減る（0.5ⁿ）
毎回「残りの半分」だけが確定するので赤い未確定部分は半分ずつ縮み、10%のラインを下回るのは4回目。

アジャイル開発：短く作って、こまめに見直す

アジャイル開発は、1〜4週間程度の短い期間（イテレーション、スクラムではスプリント）ごとに「計画→作る→動くものを確認」を繰り返し、変化に素早く対応する開発の考え方です。その中に具体的な手法がいくつかあり、試験では説明文がどの手法かを問われます。

手法 正式名称 決め手のキーワード
スクラム Scrum 役割（プロダクトオーナーなど）・イベント（スプリントレビューなど）・作成物（プロダクトバックログなど）・ルール
XP eXtreme Programming 5つの価値（コミュニケーション・シンプル・フィードバック・勇気・尊重）、テスト駆動開発・ペアプログラミング・リファクタリング
ASD Adaptive Software Development 推測・協調・学習のライフサイクル
FDD Feature Driven Development 全体モデル→フィーチャ（機能）リスト→フィーチャ単位で計画・設計・構築を繰り返す

ふりかえり（レトロスペクティブ）は、チームが「やり方」を見直して次に生かす場で、各イテレーションの最後に行います。毎日の朝会（進捗と困りごとを短く共有）や、タスクボード・ニコニコカレンダー（作業や気分の見える化）とは別物です。

短い期間を区切って繰り返すイテレーション1イテレーション2イテレーション3計画→作る→確認計画→作る→確認計画→作る→確認ふりかえりふりかえりふりかえり時間●●●●●●●●●●●●●●●●●●●●●●●●●●●●●＝毎日の朝会（全期間ずっと毎日）ふりかえり＝各イテレーションの最後に1回
短いイテレーションを3回繰り返す時間軸。ふりかえりは各イテレーションの最後に1回ずつ、朝会は全期間を通して毎日ある。

試験での問われ方

  • 説明文→モデル名：4つのモデルの説明を並べ、「ウォータフォールはどれか」「プロトタイピングの特徴はどれか」と聞く。決め手の一語で判断する。
  • 工程の並べ替え：作業内容をバラバラにして順番を問う。「機能を定義」と「プログラムに分割」、「プログラム内の構造設計」と「コーディング」の順番を入れ替えた選択肢が罠。
  • 回数計算：3回で87.5%確定になり「ほぼ90%」に見える点で誤らせる。
  • アジャイル手法の識別：スクラム・XP・ASD・FDDの説明を並べる。
  • ふりかえりの時期：朝会や毎日の活動を選ばせる罠。答えは「各イテレーションの最後」。
例題 1

未確定仕様の90%以上を確定させるプロトタイプ回数

プロトタイプを1回作成するごとに未確定な仕様の50％が確定するとき，プロトタイプ開始時点で未確定だった仕様の90％以上を確定させるには，プロトタイプを何回作成する必要があるか。

ア 1
イ 2
ウ 3
エ 4

出典：平成22年度 春期 基本情報技術者試験 午前 問50

解き方と答えを見る
  1. 条件を整理：1回ごとに「残っている未確定仕様」の50%が確定する → 1回ごとに未確定は0.5倍になる。
  2. n回後の未確定の割合は 0.5ⁿ と表せる。
  3. ゴールを言い換える：「90%以上確定」＝「未確定が10%（0.1）以下」。つまり 0.5ⁿ ≦ 0.1 となる最小の n を探す。
  4. n=1：0.5¹ = 0.5（50%未確定）→ 0.1より大きい。
  5. n=2：0.5² = 0.25（25%未確定）→ 0.1より大きい。
  6. n=3：0.5³ = 0.125（12.5%未確定＝87.5%確定）→ 0.1より大きい。まだ足りない。
  7. n=4：0.5⁴ = 0.0625（6.25%未確定＝93.75%確定）→ 0.1以下。条件を満たす。
  8. 最小の回数は4回。

答え：エ（4回）。3回では87.5%しか確定しない。

例題 2

ウォータフォールの作業内容を順に並べる

ウォータフォールモデルによるシステム開発工程の作業内容 a～f を，実施する順序で並べたものはどれか。 〔作業内容〕 a 現状の問題点を調査・分析し，対象システムへの要求を定義する。 b システムとして必要な機能をプログラムに分割し，処理の流れを明確にする。 c 詳細な処理手順を設計し，コーディングする。 d テストを行う。 e 各プログラム内の構造設計を行う。 f システムの要求仕様を基に，システムとして必要な機能を定義する。

ア a, b, f, c, e, d
イ a, f, b, e, c, d
ウ a, f, b, e, d, c
エ a, f, e, b, c, d

出典：平成21年度 秋期 基本情報技術者試験 午前 問49

解き方と答えを見る
  1. 各作業を工程名に置き換える：a＝要件定義、f＝外部設計（システムの機能を定義）、b＝内部設計（機能をプログラムに分割）、e＝プログラム設計（各プログラム内の構造）、c＝プログラミング（詳細手順を設計しコーディング）、d＝テスト。
  2. 「全体→細部」の順に並べる：要件定義(a) → 外部設計(f) → 内部設計(b) → プログラム設計(e) → プログラミング(c) → テスト(d)。
  3. 並びは a, f, b, e, c, d。
  4. 選択肢と照合：アは f と b が逆、ウは c と d が逆（テストの後にコーディングはあり得ない）、エは b と e が逆（分割する前にプログラム内部は設計できない）。

答え：イ（a, f, b, e, c, d）

要点（試験直前に読む）

  • ウォータフォールの順番は「要件定義→外部設計（機能定義）→内部設計（プログラム分割）→プログラム設計→プログラミング→テスト」。全体から細部へ。
  • 決め手の一語：前工程完了後に次へ＝ウォータフォール、試作＝プロトタイピング、繰り返し＋リスク評価＝スパイラル、短期間＋ツール＝RAD。
  • 「残りの50%が確定」は掛け算。未確定は0.5ⁿ。90%確定＝未確定10%以下 → 4回（3回は87.5%で不足）。
  • スクラム＝役割・イベント・作成物、XP＝5つの価値＋ペアプロ/TDD/リファクタリング、ASD＝推測・協調・学習、FDD＝フィーチャ単位。
  • ふりかえり（レトロスペクティブ）は各イテレーションの最後。

ひっかけ

  • 工程の並べ替えで「機能を定義（外部設計）」と「プログラムに分割（内部設計）」を入れ替えた選択肢 → 機能が決まらないと分割できない、と考えれば見破れる。
  • プロトタイピングの問題に「部分的に完成させて繰り返す（インクリメンタル）」や「リスクを評価（スパイラル）」の説明が混ざる → 「試作」の語があるものだけを選ぶ。
  • 回数計算で3回（87.5%）を選ばせる → 「90%以上確定＝未確定10%以下」に言い換え、0.5ⁿ を1回ずつ計算して確かめる。
  • スクラムを問う問題でXP（5つの価値）・ASD（推測・協調・学習）・FDD（フィーチャ）の説明が並ぶ → 「役割・イベント・作成物」がスクラムの決め手。
  • ふりかえりの時期で「毎日の朝会」を選ばせる → ふりかえりはイテレーションの区切り（最後）。

用語（20）

ウォータフォールモデル うぉーたふぉーるもでる
要件定義からテストまでの工程を順番に進め、前の工程が完了してからその成果物を使って次の工程に進む開発モデル。
⚠ スパイラルやアジャイルは「繰り返す」。ウォータフォールは原則戻らず1回で流す。
プロトタイピングモデル ぷろとたいぴんぐもでる
開発の初期に試作品を作って利用者に確認してもらい、UIや性能の要求を早めに確定させて後の手戻りを減らすモデル。
⚠ スパイラルの「繰り返しながらリスク評価」と混同しやすい。キーワード「試作」があればプロトタイピング。
スパイラルモデル すぱいらるもでる
要求分析から実装までの工程を繰り返し、毎回リスクを評価しながらシステムを成長させていくモデル。
⚠ インクリメンタルモデル（部分を完成させて足していく）とも似る。スパイラルの決め手は「リスク評価」。
RAD Rapid Application Development（ラピッドアプリケーションデベロップメント）
少人数のチームが開発ツールを活用し、期限を区切って短期間でシステムを作り上げる開発手法。
⚠ アジャイルも短期間だが、RADの決め手は「開発ツールの活用」と「短期間での完成」。
インクリメンタルモデル いんくりめんたるもでる（段階的モデル）
システムを部分ごとに一通りの工程で完成させ、それを繰り返して段階的に全体を仕上げるモデル。
⚠ プロトタイピングの選択肢で罠として出る。「部分的に機能を完成させて繰り返す」はこちら。
要件定義 ようけんていぎ
現状の問題点を調査・分析し、新しいシステムに求めることを明確にする最初の工程。
外部設計 がいぶせっけい
要求仕様を基に、利用者から見えるシステムの機能や画面などを決める工程。
⚠ 内部設計と取り違えやすい。「機能を定義」が外部、「プログラムに分割」が内部。
内部設計 ないぶせっけい
外部設計で決めた機能を、プログラム単位に分割して処理の流れを決める工程。
⚠ プログラム設計は「1本のプログラムの中身」。内部設計は「どのプログラムに分けるか」。
プログラム設計 ぷろぐらむせっけい
分割された各プログラムの内部構造（モジュールの分け方など）を決める工程。
⚠ 内部設計より後、コーディングより前。
手戻り てもどり
後の工程で問題が見つかり、前の工程に戻って作業をやり直すこと。
アジャイル開発 あじゃいるかいはつ
短い期間ごとに動くソフトウェアを作って確認することを繰り返し、要求の変化に素早く対応する開発の考え方。
⚠ スパイラルも繰り返すが、アジャイルは「短い反復で動くものを出す」考え方の総称で、スクラムやXPを含む。
イテレーション iteration（反復）
アジャイル開発で繰り返す1〜4週間程度の開発期間の単位。
⚠ スクラムでは同じものを「スプリント」と呼ぶ。
スクラム Scrum
役割（プロダクトオーナーなど）・イベント（スプリントレビューなど）・作成物（プロダクトバックログなど）・ルールから成るアジャイル開発の枠組み。
⚠ XPは5つの価値と開発プラクティス、ASDは推測・協調・学習、FDDはフィーチャ単位。
プロダクトオーナー product owner
スクラムで、作るものの優先順位（プロダクトバックログ）に責任を持つ役割。
プロダクトバックログ product backlog
スクラムで、作るべき機能や改善を優先順位順に並べた一覧。
XP eXtreme Programming（エクストリームプログラミング）
5つの価値を基礎に、テスト駆動開発・ペアプログラミング・リファクタリングなどの実践を推奨するアジャイル手法。
⚠ 「5つの価値」「ペアプログラミング」があればXP。役割・イベントの話ならスクラム。
ASD Adaptive Software Development（適応型ソフトウェア開発）
推測・協調・学習のライフサイクルを繰り返すアジャイル手法。
⚠ 「推測・協調・学習」の3語が出たらASD。
FDD Feature Driven Development（ユーザ機能駆動開発）
全体モデルを作り、優先度付きのフィーチャ（機能）リストを作って、フィーチャ単位で計画・設計・構築を繰り返すアジャイル手法。
⚠ 「フィーチャ」が出たらFDD。
ふりかえり（レトロスペクティブ） retrospective
各イテレーションの最後に、チームが進め方を見直して次の改善策を決める活動。
⚠ 毎日行う朝会（進捗共有）とは別。ふりかえりはイテレーションの区切りで行う。
朝会 あさかい（デイリースクラム）
毎日短時間で、チームの進捗や困りごとを共有する打ち合わせ。
⚠ ふりかえりの時期を問う問題で罠の選択肢になる。

このレッスンの過去問

このレッスンで稽古する
要件定義から外部設計・内部設計へ →