「アジャイル開発って結局どんな開発手法？スクラムやXPと何が違うの？」と試験勉強で頭がこんがらがる方は多いはずです。
この記事では、アジャイル開発の全体像から代表的な手法、ウォーターフォール型との違い、そして試験での出題パターンまで一気に整理します。
対象試験と出題頻度
アジャイル開発は、ITパスポート・基本情報技術者・応用情報技術者のすべてで毎年のように出題される最重要テーマです。
特に午前問題では「アジャイルソフトウェア開発宣言の4つの価値」「イテレーションの目的」「スクラム・XP・ペアプログラミングなどのプラクティス」が定番化しており、ウォーターフォール型開発との違いを正確に区別できるかが問われます。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★★★
ランクS（超重要）絶対に覚える必要あり
用語の定義
アジャイル開発（Agile Software Development）とは、一言で言うと
「短い反復サイクルで設計・実装・テストを繰り返し、動くソフトウェアを少しずつ育てていく開発手法の総称」
のことです。
イメージとしては、「回転寿司」です。
コース料理（ウォーターフォール）は前菜からデザートまで全メニューが先に決まっていて、途中で「やっぱりサーモン追加」とは言いにくい仕組みです。
一方、回転寿司は1皿ずつ取って食べて、お腹の空き具合や好みに合わせて次の注文を変えられます。
アジャイル開発もこれと同じで、機能を1〜4週間ほどの小さな単位に切り分け、1サイクルごとに顧客の反応を見ながら次に作るものを調整していくスタイルです。
📊 アジャイル開発の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Agile Software Development |
| 提唱年 | 2001年（アジャイルソフトウェア開発宣言） |
| 反復単位 | イテレーション／スプリント（1〜4週間程度） |
| 代表的手法 | スクラム、XP（エクストリームプログラミング）、FDD、リーンソフトウェア開発 |
| 得意な領域 | 要求が変わりやすい業務システム、Webサービス、新規事業のプロダクト開発 |
解説
従来のシステム開発は、要件定義→設計→実装→テストを上流から下流へ一方向に進めるウォーターフォール型が主流でした。
仕様を固めてから作る方式は大規模・要件固定の案件では強い一方、「使ってみたら違った」「市場が動いて要件が変わった」といった事態に弱いという課題がありました。
この弱点を補うため、2001年に17名の開発者が集まり「アジャイルソフトウェア開発宣言（Agile Manifesto）」を発表しました。これがアジャイル開発という言葉の出発点です。
アジャイルソフトウェア開発宣言の4つの価値
宣言文では、左側の項目にも価値を認めつつ「右側により価値をおく」と表現されています。試験で頻出なのはまさにこの構造です。
| 価値を認めるもの（左） | → | より価値をおくもの（右） |
|---|---|---|
| プロセスやツール | よりも | 個人と対話 |
| 包括的なドキュメント | よりも | 動くソフトウェア |
| 契約交渉 | よりも | 顧客との協調 |
| 計画に従うこと | よりも | 変化への対応 |
※ 出典：The Agile Manifesto（agilemanifesto.org, 2001）
図解：ウォーターフォール vs アジャイルの進み方
■ ウォーターフォール型（一方通行）
→ すべての工程を順に1回だけ実施。完成までユーザーは動くものを見られない。
■ アジャイル型（短いサイクルで反復）
イテレーション1（2週間）
イテレーション2（2週間）
→ 各サイクルの最後に「動くソフトウェア」が完成。顧客のフィードバックを次のサイクルに反映できる。
代表的なアジャイル手法
アジャイル開発は1つの手順書ではなく、共通の価値観を持つ複数の手法の総称です。
試験ではスクラムとXPの2つを押さえれば十分得点できます。
| 手法 | 特徴 | 代表的なプラクティス |
|---|---|---|
| スクラム （Scrum） |
チームの「動き方」を定めたフレームワーク。プロダクトオーナー・スクラムマスター・開発チームの3役で運営する | スプリント、デイリースクラム、スプリントレビュー、レトロスペクティブ |
| XP （エクストリーム プログラミング） |
技術的なプラクティスを重視。コミュニケーション・シンプル・フィードバック・勇気・尊重の5つの価値を基礎とする | ペアプログラミング、テスト駆動開発（TDD）、リファクタリング、継続的インテグレーション |
| FDD | 「機能（feature）」単位で計画・設計・実装を繰り返す手法 | フィーチャーリスト、機能ごとの設計 |
| リーン ソフトウェア開発 |
トヨタ生産方式の考え方をソフトウェア開発に適用。ムダの排除と価値提供の流れを重視する | ムダの排除、品質の作り込み、迅速な提供 |
代表的なプラクティス（XP・スクラム共通含む）
過去問で名前と説明が出題される具体プラクティスをまとめます。詳細は個別記事で深掘りするため、ここでは概要だけ押さえます。
| 名称 | 概要 |
|---|---|
| イテレーション／スプリント | 短い反復サイクル。要求の不一致を早く解消し、変化に追従するための単位 |
| ペアプログラミング | 2人1組で1台のPCを使い、コードを書く役とレビューする役を交代しながら開発する |
| リファクタリング | 外部から見た振る舞いを変えずに、内部構造を整理してコードを改善する作業 |
| テスト駆動開発（TDD） | 先にテストコードを書き、それを通すように実装を進めるスタイル |
| バーンダウンチャート | 残作業量を縦軸、時間を横軸にとり、進捗を可視化する右肩下がりのグラフ |
| インセプションデッキ | プロジェクトの初期段階で目的・スコープなどの共通認識を得るための10個の問いと答え |
図解：バーンダウンチャートのイメージ
残作業量の推移（バーンダウンチャート）
← 時間（スプリント開始 → 終了）→
予定線より実績が上にあれば「遅れ」、下にあれば「進み」と読み取る。チーム全員が一目で進捗を共有できる仕組みである。
💡 アジャイル開発の核心を3行で
・短い反復サイクルで動くソフトウェアを少しずつ育てる開発手法の総称
・宣言文の「個人と対話／動くソフトウェア／顧客との協調／変化への対応」の4つの価値が土台
・代表手法はスクラム（運営の枠組み）とXP（技術プラクティス）の2つを最優先で押さえる
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
アジャイル開発は、IP・FE・APすべての午前で繰り返し問われる頻出度Sのテーマです。問われるのは大きく3つの切り口です。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R5秋 午前 問49 |
アジャイルソフトウェア開発宣言で「より価値をおく」もの。 | ・4つの価値の右側を選ぶ典型問題 ・「契約交渉より顧客との協調」が定番 |
| AP R6秋 午前 問49 |
プロジェクトの目的・スコープの共通認識を得るためのプラクティス。 | ・正解は「インセプションデッキ」 ・初期段階で使う点がキー |
| FE R3免除 問49 |
アジャイル開発でイテレーションを行う目的。 | ・「要求との不一致を短いサイクルで解消し、変化に対応する」が正解 |
| FE R4免除 問50 |
バーンダウンチャートとして適切な図を選ぶ問題。 | ・縦軸=残作業量、横軸=時間、右肩下がりのグラフを選ぶ |
| SC R5秋 午前Ⅱ 問23 |
アジャイル開発手法のうちスクラムの説明はどれか。 | ・XP（5つの価値）と取り違えないこと ・スクラム＝役割と会議体の枠組み |
| IP R6春 問40 |
アジャイル開発の特徴を選ぶ問題。 | ・小さい単位で開発と改善を繰り返す点が正解の決め手 |
📝 IPA試験での出題パターン
パターン1：4つの価値の穴埋め・正誤判定
「左側よりも右側に価値をおく」の対応関係を選ばせる。ひっかけは左右を入れ替えた選択肢。「契約交渉に最も価値をおく」「ドキュメントを最優先する」と書かれていたら誤答。
パターン2：プラクティス名と説明のマッチング
ペアプログラミング、リファクタリング、TDD、バーンダウンチャート、インセプションデッキなどの名称と説明を結びつける形式。XPとスクラム所属プラクティスの取り違えに注意。
パターン3：ウォーターフォールとの違い
「要件をすべて固めてから一方向に進める」のがウォーターフォール、「短い反復で動くものを作りながら要件変化に追従する」のがアジャイル。この対比を問う形式が頻出。
試験ではここまででOKです。スクラムイベントの厳密な時間枠（タイムボックス）まで深追いする必要はありません。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. アジャイル開発の説明として、最も適切なものはどれでしょうか？
- A. 短い反復サイクルで設計・実装・テストを繰り返し、動くソフトウェアを少しずつ届けながら要求の変化に対応する開発手法の総称である。
- B. 要件定義・設計・実装・テストの各工程を上流から下流へ一方向に進め、前工程が完了してから次工程に着手する開発手法である。
- C. 試作品を早期に作って利用者に評価してもらい、その評価を反映させて本番システムを構築する開発手法である。
正解と解説を見る
正解：A
解説：
選択肢Aは、短い反復（イテレーション）で動くソフトウェアを増分的に届け、変化に対応するというアジャイル開発の本質を正しく述べています。アジャイルソフトウェア開発宣言の「変化への対応」「動くソフトウェア」の価値観とも一致します。
選択肢Bはウォーターフォールモデルの説明です。工程を一方向に進める点でアジャイルの反復型とは正反対の特徴を持ちます。選択肢Cはプロトタイピングモデルの説明です。試作品の評価を本番に反映する点が特徴であり、短いサイクルで動くソフトウェアを継続的に届けるアジャイルとは目的・進め方が異なります。
よくある質問（FAQ）
Q. アジャイル開発はどんなプロジェクトに向いていますか？逆に向かない案件は？
向いているのは要求が変わりやすいWebサービス、新規事業のプロダクト、社内業務システムのリニューアルなどです。逆に、人命や金融に関わるミッションクリティカル系で「仕様変更を許さない」案件、巨大なハードウェア連動システム、契約上スコープを最初に固めなければならない官公庁案件などは、ウォーターフォール型のほうが適合します。実務では両者を組み合わせる「ハイブリッド型」も増えています。
Q. スクラムマスターとプロジェクトマネージャーは同じですか？
役割が異なります。プロジェクトマネージャーは進捗・コスト・要員を「指揮・統制」する管理者です。一方、スクラムマスターはチームが自律的に動けるよう障害を取り除く「サーバントリーダー（奉仕型リーダー）」であり、メンバーへの指示や評価は行いません。プロダクトオーナーが「何を作るか」、開発チームが「どう作るか」、スクラムマスターが「うまく回るよう支える」という3者の役割分担になっています。
Q. アジャイル＝ドキュメントを書かない、という理解で合っていますか？
誤解です。宣言文は「包括的なドキュメントよりも動くソフトウェアに価値をおく」と述べているだけで、「ドキュメントを作らない」とは言っていません。実際のチームでもAPI仕様書・設計判断のメモ・運用手順書などは適切に残します。重要なのは「目的を見失った分厚いドキュメントの量産を避ける」ことであり、必要な情報は必要な粒度で残すのが現場の常識です。
Q. 「イテレーション」と「スプリント」は何が違いますか？
指している中身はほぼ同じ「短い反復サイクル」です。呼び方が手法によって違うだけで、一般的なアジャイル文脈では「イテレーション」、スクラムでは「スプリント」と呼びます。スプリントは長さを固定する（タイムボックス）のが特徴で、通常1〜4週間で設定します。試験では用語の言い換えとしてどちらも登場するので、両方の名前と意味を結びつけて覚えておけば困りません。
Q. DevOpsとアジャイル開発はどう違いますか？
アジャイル開発が「開発チーム内で素早く動くものを作る」ことに焦点を当てるのに対し、DevOpsは「開発（Dev）と運用（Ops）の壁を取り払い、リリース後の安定運用までを高速化する」ことに焦点を当てます。アジャイルでビルドした成果物をDevOpsの仕組み（CI/CDパイプライン、自動テスト、自動デプロイ）に乗せて素早く本番へ届ける、という補完関係になっています。
