ITパスポート｜アジャイルとは？ウォーターフォールとの違いをやさしく解説

2026年7月12日 11:40

※ 本記事にはアフィリエイトリンク（PR）を含みます。

アジャイルとは、ソフトウェアを小さく作って動くものを出すやり方です。感想をもらって改良を繰り返すので、変化に強いのが特徴です。いっぽうのウォーターフォールは、最初に全部決めて一気に作りきるやり方。この2つの違いこそ、ITパスポート（iパス）で最頻出のテーマなんですよね。

「アジャイル？スクラム？スプリント？横文字だらけで何が何やら…」と感じますよね。わかります。でも大丈夫。この記事では、家づくりや短距離走の例えで、1つずつやさしく整理していきます。計算はいっさい出てきませんよ。

この記事でわかること

開発モデル（ウォーターフォール・プロトタイピング・スパイラル）の違い
アジャイルとウォーターフォールの違い、そしてスクラムの進め方
オブジェクト指向・DevOpsなど、開発の考え方の言葉

この記事の要点（先に結論！）

アジャイルとは、小さく作って動くものを出し、感想をもらって改良を繰り返す軽量な開発手法の総称です。
ウォーターフォールモデルとは、工程を上流から下流へ順番に、後戻りせず進める開発モデルです。
アジャイルとウォーターフォールの違いは、短いサイクルで反復するか（アジャイル）、最初に全部決めて一気に作るか（ウォーターフォール）にあります。
スクラムとは、スプリントという短い期間を繰り返す、アジャイルの代表的な進め方です。
オブジェクト指向とは、データと操作を「もの（オブジェクト）」にまとめ、部品を組み合わせるように作る設計の考え方です。

1. ソフトウェアの「作り方」には型がある

前回の記事（B06a）では、システム開発が「要件定義→設計→プログラミング→テスト→導入→保守」の順に進むことを見ました。いわば家を建てる工程ですね。

この記事はその続きです。同じ家を建てるにも、進め方（段取り）にはいくつかの流儀があります。その流儀や道具を集めたのが、今回のテーマです。

なお、この記事は本書『いちばんやさしいITパスポート』の第6章「開発技術」に対応しています。第6章は範囲が広いので2つに分けていて、この記事は開発のやり方・考え方の担当です。開発の工程そのもの（テストの種類など）は別記事（B06a）で解説します。

この記事で扱うのは、次の3つのグループです。

作る手順の型…ウォーターフォール・プロトタイピング・スパイラルなどの「開発モデル」
今の主役アジャイル…スクラム・スプリント・XPなど、小さく速く作る進め方
設計と運用の考え方…オブジェクト指向・UML・DevOpsなど

2. 開発モデル：作る手順の「型」

まずは、昔ながらの「作る手順の型」から見ていきましょう。同じ工程でも、どんな順番・リズムで進めるかで型が分かれます。

代表的なのは、次の3つです。

ウォーターフォールモデル…上流から下流へ、後戻りせず一本道で進める
プロトタイピングモデル…早めに試作品を見せて、反応を確かめながら進める
スパイラルモデル…部分ごとに設計・開発・評価を繰り返し、らせん状に完成へ近づく

2.1 ウォーターフォールモデル：滝のように上から下へ

いちばん基本の型が、ウォーターフォールモデルです。

イメージは、その名のとおり滝（ウォーター）。水が上から下へ一方通行で流れるように、要件定義→設計→プログラミング→テストと、工程を順番に進めていきます。
ウォーターフォールモデルとは、各工程を上流から下流へ順番に進める開発モデルです。原則として、前の工程には後戻りしません。計画が立てやすく管理しやすい反面、あとから「やっぱり仕様を変えたい」に弱いのが弱点です。

2.2 プロトタイピングモデル：試作を見せて進める

次は、プロトタイピングモデルです。プロトタイプとは「試作品」のこと。

イメージは、試作の料理をお客さんに出して反応を見るやり方。早い段階で動く試作品を利用者に見せ、「イメージと合っているか」を確かめながら進めます。
こうすると、発注者と開発者の認識のズレを早めに発見できるんですね。「完成してから話が違った」を防ぐ型です。

2.3 スパイラルモデル：らせん状に繰り返す

3つ目は、スパイラルモデルです。スパイラルとは「らせん」のこと。

イメージは、らせん階段をぐるぐる回りながら上っていく感じ。システムをいくつかの部分に分け、「設計→開発→評価」を何度も繰り返し、1周ごとに完成度を上げていきます。
この「繰り返して育てる」という発想は、次に出てくるアジャイルにもつながる考え方です。

2.4 RADとリバースエンジニアリング

残りの2語も、名前と意味だけ押さえておきましょう。

RAD（ラド。Rapid Application Development）…少人数・短期間で素早く開発する手法。ツールや試作品をうまく使います。
リバースエンジニアリング…完成したソフトウェアを分解・解析して、設計や仕様を逆にたどって明らかにすること。イメージは完成した料理から逆にレシピを推測すること。仕様書のない古いシステムの解析などに使います。

3. アジャイル：小さく作って繰り返す（この記事の主役）

さあ、この記事の主役、アジャイルの登場です。

アジャイル（すばやい・機敏な、という意味）とは、迅速かつ柔軟にソフトウェア開発を行う、軽量な開発手法の総称です。ウォーターフォールの「あとから変更しにくい」という弱点を補う存在で、変化に素早く対応します。

3.1 アジャイルとは？

イメージは、使える一部屋ずつ作って、住んでもらって感想を聞く家づくり。

全部の設計を固めてから一気に建てるのではありません。まず数週間で「使える小さな部分」を作って渡します。そして利用者の感想（フィードバック）を受け、次の部分を作る。この短いサイクルをぐるぐる繰り返すのがアジャイルです。
だから、途中で「やっぱりこうしたい」が出ても、次のサイクルで柔軟に取り込めるんですね。

3.2 ウォーターフォールとアジャイルの違い

ここが最頻出ポイントです。2つの違いを、しっかり対比で覚えましょう。

ウォーターフォール…最初に全部決めて、後戻りせず一気に作りきる。計画的だが、変更に弱い。
アジャイル…小さく作って動くものを出し、感想をもらって改良を繰り返す。変更に強い。

ざっくり言えば、滝（一方通行）か、短いサイクルの繰り返しか。仕様が固まった大規模開発ならウォーターフォール、変化が多い開発ならアジャイル、と向き不向きがあります。

4. スクラム：アジャイルの代表的な進め方

アジャイルには、いくつかの具体的な進め方があります。その代表格がスクラムです。

スクラムとは、スプリントという短い期間を繰り返して開発を進める、アジャイルの代表的な方法です。試験でもいちばんよく問われます。

4.1 スプリントを繰り返す

スプリントとは、1〜4週間ほどの開発の1サイクルのこと。この期間で「使えるもの」を1つ仕上げます。

イメージは、短距離走（スプリント）の繰り返し。一気に長距離を走るのではなく、短い全力ダッシュを何本も重ねる感じですね。
1回のスプリントでは、計画を立て→開発し→できたものをレビューし→ふりかえり（レトロスペクティブ。良かった点・改善点を話し合う会）をして、また次のスプリントへ進みます。

4.2 3つの役割（スクラムチーム）

スクラムで動くチームをスクラムチームと呼び、3つの役割（ロール）に分かれます。

イメージは、文化祭の実行委員。「何をやるか決める人」「実際に作る人」「段取りを回す人」がいますよね。それと同じです。

プロダクトオーナー…何を作るか、優先順位を決める責任者
開発者…実際にものを作る人たち
スクラムマスター…チームがうまく回るよう支援し、じゃまなもの（障害）を取り除く人

4.3 やることリスト（バックログ）

作るべきものは、リストで管理します。ここもよく問われます。

プロダクトバックログ…作るべき機能・要望を、優先順位順に並べた一覧（やることリスト全体）
スプリントバックログ…そのうち、今回のスプリントでやる分を取り出したリスト（今回やる分の付箋）

なお、1つ1つの要望はユーザーストーリーという短い文で書きます。「〇〇として、△△したい」と、利用者目線で書くのが特徴です。

4.4 XPとその他の実践テクニック

アジャイルには、XP（エクストリームプログラミング）という手法もあります。これは技術的な実践テクニックを重視する進め方です。

代表的なテクニックを、一言ずつ押さえておきましょう。

ペアプログラミング…2人1組で1台のPCに向かい開発する。イメージは2人で運転（運転手と、隣で見るナビ役）。その場でレビューが進みます。
テスト駆動開発（TDD）…先にテスト（合格条件）を書いてから、それを満たすプログラムを書く。答え合わせの基準を先に決めてから問題を解くイメージです。
リファクタリング…動作は変えずに、プログラムの内部構造を整理・改善すること。イメージは味は変えずにキッチンを整理整頓すること。
継続的インテグレーション（CI）…書いたコードをこまめに統合して自動テストし、問題を早く見つける仕組み。

5. オブジェクト指向とUML：設計の考え方

ここからは、プログラムの「設計の考え方」です。大きく2つの流派があります。

構造化手法…処理の流れ（手順）に注目して、プログラムを分割・整理する伝統的なやり方
オブジェクト指向…データと操作を「もの（オブジェクト）」にまとめて部品化するやり方

オブジェクト指向とは、データ（性質）と操作（動き）を1つの「オブジェクト（もの）」としてまとめる考え方です。部品を組み合わせるように、システムを作っていきます。

イメージは、性質と動きをセットにした部品。たとえば「犬」という部品に、「名前・年齢」という性質と「吠える」という動きをひとまとめにしておく感じですね。部品として使い回しやすいのが利点です。

5.1 UMLとユースケース

オブジェクト指向で設計するとき、その中身を図で表す共通ルールがUMLです。

UML（ユーエムエル。Unified Modeling Language）…オブジェクト指向の設計を図で表す、統一された表記法。イメージは設計図の世界共通の書き方です。
ユースケース…利用者（アクター）がシステムをどう使うかを表したもの。UMLの「ユースケース図」で描きます。

iパスでは、この3語（オブジェクト指向・UML・ユースケース）を「名前と役割」で押さえれば十分です。深い中身までは問われません。

6. DevOpsとMLOps：開発と運用がタッグを組む

新しめの言葉、DevOpsとMLOpsも見ておきましょう。どちらも「開発」と「運用」の連携がテーマです。

DevOps（デブオプス）とは、開発（Development）チームと運用（Operations）チームが連携し、素早く継続的にリリース・改善していく考え方・文化のことです。
イメージは、開発チームと運用チームが同じ台所に立つこと。作る人と、動かし続ける人の間の壁をなくすんですね。バラバラに動くより、ずっと速く改善できます。

MLOps（エムエルオプス）とは、その機械学習（Machine Learning）版。AIモデルの開発と運用を、継続的に回していく考え方です。

7. 開発の共通ルール：共通フレームとCMMI

最後に、開発の「共通のものさし」を2つ。名前と役割だけで大丈夫です。

共通フレーム（SLCP。Software Life Cycle Process）…ソフトウェアの開発と取引を適正化するため、企画から開発・運用・保守までの作業項目を1つずつ定義・標準化した共通のものさし。発注者と開発者が同じ言葉・同じ区切りで話せるようにするものです。
CMMI（シーエムエムアイ。能力成熟度モデル統合）…開発組織のプロセスの成熟度（開発力）を評価・改善するモデル。成熟度を5段階のレベルで定義します。開発力が5段階の何級か、を判定する通信簿のようなものですね。

なお、これらの制度・用語はシラバスVer.6.5（2026年7月時点）にもとづいています。

8. まとめ：3行でふりかえり

開発モデルには、一本道で進むウォーターフォール、試作を見せるプロトタイピング、繰り返すスパイラルがあります。
アジャイルは小さく作って改良を繰り返す進め方で、代表がスクラム（スプリント・3つの役割・バックログ）です。
オブジェクト指向・UML・DevOps・共通フレーム・CMMIは、名前と役割をセットで押さえれば得点できます。

いかがでしたか？主役のアジャイルは「小さく作って繰り返す」、ウォーターフォールは「一気に作りきる」。まずはこの対比から覚えてみましょう！

9. よくある質問（FAQ）

Q1. アジャイル開発とは何ですか？わかりやすく教えてください。

A. アジャイル開発とは、ソフトウェアを小さく作って動くものを出し、利用者の感想をもらって改良を繰り返す、軽量な開発手法の総称です。数週間ごとに「使える版」を出しては直していくので、途中の仕様変更に強いのが特徴です。代表的な進め方にスクラムがあります。

Q2. アジャイルとウォーターフォールの違いは何ですか？

A. ウォーターフォールは最初に全部決めて、後戻りせず一気に作りきる進め方です。いっぽうアジャイルは、短いサイクルで小さく作り、感想をもらって改良を繰り返す進め方です。ウォーターフォールは変更に弱く、アジャイルは変更に強い、という違いがあります。

Q3. スクラムとは何ですか？

A. スクラムとは、スプリントという1〜4週間ほどの短い期間を繰り返して開発する、アジャイルの代表的な進め方です。プロダクトオーナー・開発者・スクラムマスターの3つの役割があり、やることリスト（プロダクトバックログ）から今回の分を取り出して開発します。

Q4. オブジェクト指向とは何ですか？わかりやすく教えてください。

A. オブジェクト指向とは、データ（性質）と操作（動き）を「もの（オブジェクト）」としてひとまとめにし、部品を組み合わせるように開発する設計の考え方です。部品を使い回しやすいのが利点です。その設計を図で表す共通ルールがUMLで、利用者の使い方を表すのがユースケースです。