アジャイルは、価値の高いものから小さく作って利用者に届け、その反応から学んで次を決める、という進め方とそれを支える考え方です。
小さく作って、確かめて、直す
システム開発の古くからの進め方にウォーターフォールがあります。最初に要件をすべて確定し、要件定義・設計・開発・テストと上流の工程から順に進めて、全部の工程が終わってからリリースします。作るものが最初から決まっている仕事には向いていますが、開発の途中で要求が変わると、前の工程に戻るのが大変です。
ウォーターフォールは最後に1回、アジャイルは輪を1つ回るごとにリリースします。
ところが新しいサービスのように、何を作れば喜ばれるのかが最初には分からない仕事が増えました。長い開発のあいだに、本当に欲しいものが変わってしまうこともあります。そこで、ウォーターフォールのこの弱点を補う進め方として広まったのがアジャイルです。 アジャイルは、開発する機能を小さく分け、優先度の高いものから短い期間で開発とリリースを繰り返し、途中で生じる変更にすばやく対応します。
土台にあるのが仮説検証です。「この機能があれば使ってもらえるはずだ」という考えは、作る前の時点ではまだ仮説にすぎません。小さく作って実際に使ってもらい、その反応で確かめます。外れていたら早めに方向を変えればよく、作り込んだあとで気づくより失うものが小さくて済みます。
何から作るかを決める物差しは、利用者や事業にとっての価値です。シラバス案はこれを価値駆動という語で挙げています。計画どおりに進んでいるかより、求められている価値をどれだけ届けられたかで進み具合を見ます。
似た言葉と区別しておきます。プロトタイピングは、試作品を利用者に見せて要求を確かめる進め方で、短い間隔でリリースを繰り返すこととは別です。 DevOps は、開発（Development）と運用（Operations）の担当が協力して、作ったものを素早く安定して届け続ける取り組みです。 リバースエンジニアリングは、できあがったソフトウェアを解析して、仕様や設計を取り出すことです。 共通フレームは、ソフトウェア開発とその取引の適正化に向けて、工程や作業項目を一つ一つ定義して標準化した枠組みで、開発の進め方そのものではありません。
アジャイルソフトウェア開発宣言と12の原則
アジャイルの考え方は、2001年に17人のソフトウェア開発者がまとめたアジャイルソフトウェア開発宣言に表れています。宣言は、次の4つの価値を挙げています。
4つの価値（日本語訳）
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
左の皿も空ではありません。両方に価値があり、右により重きを置く、という宣言です。
宣言は続けて「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」と書いています。 右を重んじても、左を捨てるわけではありません。 アジャイルでも必要なドキュメントは作り、計画も立てます。「ドキュメントは作らない」「計画は立てない」というのは、よくある誤解です。
宣言の背後には、行動の指針となる12の原則（アジャイルの原則）があります。IPA の解説書が付けた見出しで並べます。
アジャイル宣言の背後にある原則（IPA の見出し）
01 顧客の満足を求め続ける
02 要求の本質を見抜き、変更を前向きに
03 成果物を2-3週間で、リリースし続ける
04 全員で共通の目標に向かおう
05 人の意欲は信頼から
06 コミュニケーションは直接対話で
07 進捗も品質も現物で
08 一定のペースでプロジェクトにリズムを
09 よい技術、よい設計、よい品質の追求
10 ムダ＝価値を生まない、を探してヤメる
11 よいモノはよいチームから
12 自分たちのやり方を毎週、調整する
原則の本文には「要求の変更はたとえ開発の後期であっても歓迎します」「動くソフトウェアこそが進捗の最も重要な尺度です」とあります。進み具合は、設計書が何割できたかではなく、実際に動くもので測ります。
IPA は、この宣言を実践する人に共通のマインドセット（ものの考え方）ととらえ、「ソフトウェア開発」を製品やサービス、働き方と読み替えても通じる、と説明しています。シラバス案のアジャイルマインドは、この考え方を身につけた姿勢と考えてよく、開発者だけでなく、企画や営業の仕事にも当てはめられます。
新しい社内アプリを作るチームで、メンバーが進め方について意見を出しました。アジャイルソフトウェア開発宣言の考え方に沿うものはどれですか。
× 宣言は、左のドキュメントにも価値があると認めています。必要なドキュメントは作ります。
○ 正解 計画は立てるが、使った人の反応で優先順位が変わったら、計画を見直すです。
計画を捨てずに、計画に従うことより変化への対応に重きを置いています。宣言の考え方そのものです。
× 原則は「要求の変更はたとえ開発の後期であっても歓迎します」としています。変化への対応と逆の姿勢です。
× 原則は、動くソフトウェアこそが進捗の最も重要な尺度だとしています。設計書の割合では、本当に価値が届いているかは分かりません。
スプリントで回す
アジャイルを実際に進める枠組みの代表がスクラムです。スクラムは開発を短い期間に区切って繰り返します。この1回分の期間をスプリントと呼びます。シラバス案が「スプリント（期間のサイクル）」と書いているのはこのことです。繰り返しの1回を、一般にはイテレーション（反復）ともいいます。
スプリントは1か月以内の決まった長さで、前のスプリントが終わるとすぐ次が始まります。予定の機能が終わらなくても期間は延ばしません。期間を先に固定した時間の枠をタイムボックスといいます。
1回のスプリントの中に、計画・開発・レビュー・ふりかえりがすべて入っています。
スクラムの用語
プロダクトバックログ … 作りたい機能や直したい点の一覧。優先する順番に並べ、並び順はプロダクトオーナーが責任を持つ
スプリントプランニング … スプリントの最初に、このスプリントで何を作るかを一覧の上から選んで計画する
デイリースクラム … 開発者が毎日15分で、進み具合と今日の作業を確かめる
スプリントレビュー … できあがった動くもの（インクリメント）を関係者に見せ、次にやることを話し合う
スプリントレトロスペクティブ（ふりかえり） … チームの進め方を見直し、次のスプリントでの改善を決める。これでスプリントが終わる
スクラムのチームは、プロダクトオーナー1人、チームがスクラムを正しく回せるよう支えるスクラムマスター1人、そして複数の開発者からなり、通常は10人以下です。 ほかに、ペアプログラミングやテスト駆動開発など開発の技法をまとめたXP（エクストリームプログラミング）という手法もあります。
ふりかえりとKPT
ふりかえりは、チームが自分たちの進め方を定期的に見直す場です。プロジェクトの最後に1回だけ開く反省会ではなく、進行中に、スプリントなどの区切りごとに短い時間で行います。12の原則にも「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」とあります。
日本でよく使われるふりかえりの手法がKPT（Keep・Problem・Try の頭文字）です。
KPT の3つの欄
Keep … うまくいって、今後も続けたいこと
Problem … うまくいかなかったこと、改善したいこと
Try … 次に試したいこと。Problem の解決策や、Keep をさらに伸ばす案
Try に書いた案は、次のスプリントで試して、次のふりかえりで結果を確かめます。
大事なのは、問題を並べて終わりにしないことです。Try に出た案を次のスプリントで実際に試し、次のふりかえりで効果を確かめる。この繰り返しで、チームの進め方が少しずつよくなります。 Try の案を全部いっぺんに実行する必要はなく、効果が見込めて実行しやすいものから試します。 また、ふりかえりはだれかの責任を追及する場ではありません。問題には、チームとして向き合います。
2週間ごとにスプリントを回しているチームが、KPT でふりかえりをしています。KPT の使い方として最も適切なものはどれですか。
× ふりかえりは個人の責任を追及する場ではありません。チームとして、次にどうするかを考えます。
× 全部を一度にやる必要はありません。効果が見込めて実行しやすいものから試します。
× 最後に1回だけでは、学んだことをこのプロジェクトに生かせません。ふりかえりはスプリントごとに行います。
○ 正解 前回の Try で試したことがうまくいったかを、今回のふりかえりで確かめるです。
試した結果を確かめ、うまくいったものは Keep に、まだのものは次の Try につなげます。こうして進め方を少しずつ直していきます。
まとめ
この回で持ち帰ること
1. アジャイル＝機能を小さく分け、優先度の高いものから短い期間で開発とリリースを繰り返す。途中の変更にすばやく対応できる。ウォーターフォールは全部の工程が終わってからリリース
2. 仮説検証：作る前の考えは仮説。小さく作って使ってもらい、反応で確かめる。何から作るかは価値で決める（価値駆動）
3. 開発宣言の4つの価値＝個人と対話・動くソフトウェア・顧客との協調・変化への対応。左側にも価値はある（ドキュメントも計画も作る）
4. スプリント＝1か月以内の決まった長さの繰り返しの単位。プランニング・開発・レビュー・ふりかえりが中に入る
5. ふりかえりは進行中に定期的に。KPT＝Keep（続けたい）・Problem（うまくいかなかった）・Try（次に試す）。Try は次のふりかえりで確かめる
この節で解ける公開問題
令和4〜8年度の公開問題のうち、この節の知識で解ける問題は次の3問です。
教科書の一覧（現行の試験の順）教科書の一覧（新しい試験の順）過去問
Udemy の ITパスポート講座を、受講者数・★評価・口コミで比べたページです（広告を含みます）。
出典：IPA「ITパスポート試験 シラバス（案）Ver0.1」（2026年8月31日）、「ITパスポート試験 シラバス Ver6.5」、 「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」（agilemanifesto.org の日本語訳。© 2001, 上記の著者たち）、 IPA「アジャイルソフトウェア開発宣言の読みとき方」「アジャイル開発の進め方」（2020年2月）、 IPA「アジャイル型開発におけるプラクティス活用事例調査 ガイド編」（2013年3月）、 K.シュエイバー／J.サザーランド「スクラムガイド」（2020年11月、日本語版）。 練習問題は当サイトが説明のために作ったものです。