さて、アジャイル開発の本質の解説に戻りましょう。ウォーターフォール型への疑問（不満）を受けて生み出されたアジャイル開発は、「変化への柔軟な対応」を目的としています。今の世の中、どんな変化が起こるかは誰にもわかりません。ですが「そんなことは予測できなかった」という言い訳は、システム開発の現場においてはもう通用しない時代になりつつあります。開発初期で受けた要求が半年後、逆に顧客のビジネス上の価値を下げるものになっているのかもしれないのです。いかなるニーズの変化が起こってもそれを柔軟に受けとめ、迅速に対応する…。これこそがアジャイル開発における最大のメリットとなります。
もう少し具体的に見ていきましょう。アジャイル開発は、開発の過程を1週間から数週間単位（フェーズ）で区切ることが一般的です。そして各フェーズで優先度が高い順に要求を開発し、その段階で動くソフトウェアを作り上げ、その検証を顧客とともに行います。
ウォーターフォール型開発では各工程の成果物としてドキュメントが作成されますが、アジャイル開発ではドキュメントの作成は必要最小限にとどめ、その代わりにプログラムが成果物を代表します。また、顧客から要求の変更があれば次のフェーズ以降に反映させるようにします。このように短い期間でソフトウェアを創り上げるという反復作業（イテレーション）を繰り返しながら、徐々にその完成度を高め、最終的なリリースに至るのです。
こういったプロセスであれば、顧客は現段階にソフトウェアがどの程度できているか、自分の目で確認すること(可視化)ができます。「百聞は一見に如かず」といいますが、プリントアウトされた大量のドキュメントを読まされるよりも、目の前で動くソフトウェアを見せられたほうが、顧客がイメージをつかみやすくなるのは明らかでしょう。
また、複数の段階で何回も確認することができるため、変更の要望も伝えやすくなります。開発側も「要求は変化するもの」という認識を常に持っていれば、要求の変更を許容しやすい技術を採用することができるようになります。顧客のイメージから大幅に逸脱することも少なくなるでしょう。
