アジャイル開発についてお話しする機会があります。
今の仕事のスタイルがウォーターフォール開発で、そこをベースに考えたときに、多かれ少なかれ抵抗を感じたり、不安を覚える方がいらっしゃいます。
とても自然なことだと思っています。
そんなときにお話ししている話題を思いつくまま雑記しておきたいと思います。
短く端折って書いていくので、不明瞭でしたらごめんなさい。

ウォーターフォール開発とアジャイル開発は、そんなに違うものなのか

人によってとらえ方は様々ですが、ボクは"アジャイル開発"と"ウォーターフォール開発"には、本質的には大きな差は存在しないと考えています。
"差"を感じる方からお伺いするご質問のほどんどは、会社のルールや商習慣に伴う話題です。
ルールや商習慣を抜きにして仕事ができないということは重々理解していますが、そこで思考停止するより前に進む勇気を持ってもらえたらと思い、いつもお話ししています。

時々お伺いする話（都市伝説）

アジャイル開発が最新の銀の弾丸で、ウォーターフォールは古い
ウォーターフォール開発は計画的だが、アジャイル開発は無秩序
アジャイル開発は、プロトタイピング開発とかスパイラル開発と一緒

ボクは、これらは都市伝説だと思っています。

ウォーターフォール開発の基本的なこと

開発の全体像を把握してから作る
工程は後戻りしない
いわゆるV字モデル

ボクにはとてもわかりやすく、効率的に見えます。事実、そうだから永きに渡って重宝されてきたのだと思います。今でもこっちの方が向いている開発現場というのはたくさん存在します。

ウォーターフォール開発の何が問題なのか

開発手法として、理論上の問題は無いと思います。でも現実的には問題があります。
たとえば

重厚長大すぎて、一部の人間だけで全体を把握できるワケがない
設計書レビューで機能としての正しさを承認しろって言われてもカンペキにはできない
開発が１回作って終わりじゃないからドキュメントメンテナンス大変＆やらなくなる

要するに、人じゃ手に負えない規模になっています。秩序を維持するためにルールで縛っていたのに、気が付いたらルールに縛られて秩序が崩壊しています。
人間が掌握できないことに問題はあるかもしれませんが、ウォーターフォール開発そのものは悪くないと思います。

アジャイル開発の基本的なこと

未来予測はできないけど、わかってる範囲を把握・合意してから作る
今作ってる範囲に関しては、工程を後戻りしない
個々の機能（なんなら関数）に限って言えば、いわゆるV字モデル

厳密には、この説明は間違いがあります。
しかしながら、そもそも期間を短くして、人間が掌握できる単位で着実に仕事をしようとしているということは認識できるかと思います。
アジャイル開発が無秩序にモノを作っていると考えている方は改めてください。
アジャイル開発はウォーターフォール開発同様、個々の機能をカンペキに完成させます。
（余談ですが、無秩序に作る行為には "カウボーイコーディング" というかっこいい名前がついています）

アジャイル開発にすると、どんな問題が解決するのか

アジャイル開発とウォーターフォール開発には期間に関する差しか無いとすると、開発スタイルを変える意味は何なのかという話題になります。
期間を短くするだけだと考えても(実際はそうじゃないのですが、まずはとりあえず)、実は色々と意味があります。

わかっている範囲を作るので、各工程の完了基準が明確になる。作業も開始前から明確で、作業内容を明確にするためになんとなく過ぎていくムダな時間が減る
開発がインクリメンタル(機能追加の繰り返し)になる。もし途中で問題を検知しても、小さな痛みを感じるだけで問題を修正できる(機能削除、違う機能の追加という対応が容易)
開発がインクリメンタルであるということは、今後追加する機能に関してもどれくらいのペースで追加できるのかを実績値ベースで予測できる

プロトタイピング開発やスパイラル開発の方がアジャイル開発に近い？

雰囲気は近く感じるかもしれませんが、根本的に異なります。
アジャイル開発は、作業に対する完成基準が明確です。作りながら考えたりはしません。作りながら考えるフェーズがゼロだとは言いませんが、それはそれとして明確に分離して取り扱います。
アジャイル開発は、期間が過ぎたら出荷できる製品が完成しています。
要求事項がフンワリしているものは、そもそも作業を開始しません。
よって、開発手法としてはプロトタイピング等よりもウォーターフォール開発が近いです。

開発期間を区切っただけで出てくる障壁

よくご質問いただくものを書き出してみます。おおむね、会社のルールや商習慣に伴う話題です。

一括請負契約できない

契約行為と開発スタイルは別物です。"丸投げできない"というなら理解しますが、丸投げしないでください。
いつまでに何が完成するのかがわからないと予算化できないというのは理解しますが、それも開発スタイルとは別です。
また、開発途中の仕様変更や要件バグに伴う変更契約は、今も実施していますよね？

ドキュメントを書いている時間が取れなくなる

ドキュメントが緻密になっても多くの発注者はうれしくありません。ほしいのは動くモノです。

設計書無しでは仕様が正しく実装されているかわからない

理解します。必要な場面も存在することを認めます。でも重厚長大でメンテナンスされないドキュメントに振り回されるよりも、必要最低限の設計書にとどめるべきです。

全体計画無しで、どうやって進捗を把握するのですか？

アジャイル開発は全体計画が無いというのは誤解です。発注者サイドは必ず"中長期的にどうしていきたいのか"を表明します。開発者サイドは"中期的にどうなるのか"を開発結果をベースに予測し報告する義務があります。また開発者サイドには"短期的に何を提供できるのか、できないのか"を正直に報告する義務もあります。
ウォーターフォール開発と違うのは、無根拠な未来予測が存在しない(あっても開発者サイドから夢物語として語られない)というだけです。

そんな頻繁にテストできない

テストは基本的に自動化して毎晩実施してください。
毎日バグに気づいて修正したら、品質が高い状態を維持できます。アプリケーションを改修する際に"改修元にバグが無い"ということは、開発者の生産性を高めます。
またテスト用のコードを見たら、そのメソッドがどう使われるのかがわかるので、ドキュメントを読むより開発者の生産性を高めます。

その他たくさんありますがこれくらいで。

個人的にウォーターフォール開発よりアジャイル開発が優れていると思っていること

開発現場目線で考えたとき、ウォーターフォール開発の現場に感じる"やらされてる感"が、アジャイル開発の現場には少ないのが良いと思っています。
開発者が全員、ユーザーやプロダクトオーナーが欲しているものが何か、なぜ欲しいのかを考えたり聞いたりする機会が圧倒的に多くなります。
ここが理解できていると、開発するものに対する考え方が変わってきます。
作業も自発的になり、集中力も高い方が多い印象です。

「アジャイル開発やってます」と言う方の現場におじゃました時は、本当にアジャイル開発ができているかを、まずはこの雰囲気から感じ取るようにしています。