ウォーターフォール開発手法は、図1のように、プロジェクトをいくつかのフェーズ（段階）に分け、各フェーズの中の作業や成果物を明確に定め、これを遂行していくという方式をとっています。各フェーズをしっかりと完了させてから次のフェーズに進むのが原則であり、また、あるフェーズに進んでから前のフェーズの作業をやりなおすことはしないことも原則とされています。それで、上流のフェーズから下流のフェーズに滝が流れるように進んでいることをイメージして「ウォーターフォール（英語で滝の意味）」と呼ばれています。

ウォーターフォール開発手法は、計画の構造が明快であり、WBS（Work Breakdown Structure、プロジェクトにおける作業を階層的な構造として把握する手法）やガントチャートのようなツールと相性が良く、ソフトウェアの受託開発において、発注側と受託開発側のコミュニケーションがしやすいというメリットがあります。

しかし、ウォーターフォール開発手法は、これを生み出した米軍において、現在では完全に否定され、アジャイル開発手法にとって代わられています。日本では、大規模プロジェクトを中心に、まだ採用されていますが、将来的にはアジャイル開発手法によって置き換えられる運命にあると考えられます。

ウォーターフォールのどこが問題なのかと言うと、プロジェクトの開始時に、完成されるソフトウェアの要件を厳格に定義しなければならない、という点にあります。これは、ソフトウェアの開発を社外に委託する場合に守るべき法律と相性が良かったこともあり、日本のソフトウェア開発の「常識」と化していました。かつては、開発するソフトウェアの複雑さも現在ほどではなく、また、世の中の変化の速度もゆっくりとしていました。しかし、現在の状況は違います。ソフトウェアに求められる要件は広く、複雑になり、さらに、世の中の変化の速度が激化しているために、1年先を見据えてソフトウェアの要件を厳格に定めるということは至難の業、いえ、ハッキリ言うならば人間の限界を超えています。かくして、ウォーターフォール開発の現場では、要件定義が不十分であるのに、「もう要件定義は完了している」ということにして次のフェーズに進むことを発注側に求められるということが横行しています。発注側は、契約された予算の範囲で、できるだけ多くの機能を実装させようとしますので、要件定義が不十分であると、拡大解釈がしばしば行なわれます。受託側は、拡大解釈に抵抗しますから、発注側と受託側の間には、緊張と駆け引きが常態として存在するようになります。こうなりますと、受託側は、本当に役に立つソフトウェアを作るのではなく、契約上の要件定義を満たすソフトウェアを作るようになります。発注側は、役に立たないソフトウェアは欲しくないので、ここでも緊張と駆け引きが発生します。

このような状況に対して「アジャイル」開発手法というものが認知されるようになりました。アジャイルは、いくつかの開発手法の総称で、スクラムやリーンはアジャイル開発手法の一種です。ウォーターフォールとアジャイルの違いは、アジャイルソフトウェア開発宣言 (https://agilemanifesto.org/iso/ja/manifesto.html) によって象徴的に示されていますが、簡単に言うと以下の違いがあります。

	ウォーターフォール	アジャイル
プロジェクト計画	厳格 直線的	柔軟 反復的
プロジェクトのゴール	事前に決定	修正可能
利用者と開発者の関係	命令的	協調的
開発者の姿勢	契約遵守	顧客の利益にフォーカス
ドキュメンテーション	厳格 フォーマットに従う	柔軟 ソースコードを重視

日本ではアジャイル方法論の中でスクラムが普及しています。スクラムは、小規模なチームによって、2週間程度の期間の「スプリント」を繰り返してゴールへと向かっていく手法です。それぞれのスプリントは、その最初にスプリントのゴールを定め、その期間の中で、最大の効率をもってゴールへと迫ります。スプリントのゴールは、プロジェクトバックログと呼ばれる、プロジェクト全体で達成すべき機能や残作業のリストから、そのスプリントで達成することが望ましいものを取り出して、顧客とスプリントのメンバーの協議で決定します。複雑なもの、要件が不明確なものは、なるべく後のスプリントに残しておきます。これはプリジェクトが進むに連れて、プロジェクトが解決しようとしている問題領域についての理解が深まるからです。知識が少なかったときより、知識が多くなったときに重大な決断をする方が、より的確な決断が可能になる、ということから、このような方式が採用されています。

スクラムは、日本人の働き方や組織に合っていて、実践しやすいという特徴があります。スクラムに対してリーンは、やや掴みどころのない印象を与えるかもしれません。

リーンは、スクラムにおけるスプリントのような決められたペースでのPDCAサイクルは持ちません。プロジェクトバックログに相当する機能のリストは持ちますが、あまり厳格には考えません。リーンでは機能のリストから、次に作業すべき候補を10個程度抽出し、開発チームは、その中のひとつを選んで、集中的に作業します。成果物は、試作バージョンのアプリケーションとして、顧客が実際に触れる状態をキープして提供します。実際に操作できる試作バージョンを、実際に操作してみることほど、顧客から開発チームに有益なフィードバックを与えるものはない、という発想から、このような方法が採用されています。また、リーンでは開発チームが抱えている仕掛り中の作業を、できるだけ少ない個数に制限します。これは、交通渋滞に例えられるのですが、仕掛り中の作業が多数になると、開発チームの効率が低下すると考えることに由来します。ウォーターフォールでは、スケジュールの遵守が優先され、開発チームが遊ばないように、作業を詰め込む傾向がありますが、リーンでは、作業の詰め込みはかえって効率を低下させる元凶だと考えます。

リーンでは、開発プロセスや開発チームの組織編成、会議体の構成等を、常時進化させることを追求します。プロジェクト毎にやるべき作業は異なり、また、プロジェクトの段階によっても、最適な仕事のスタイルは変ってくるからです。このためリーンのプロジェクトの形態は、これといった定番スタイルを持ちません。スクラムの方が、スプリントを単位とする、わかりやすい作業スタイルがあるので、日本では人気があるようです。しかし、スクラムでもリーンのコンセプトを適用することは可能ですし、実際に適用しているプロジェクトは存在します。弊社は、リーンにこだわって、スクラムがおちいりがちな弊害を打破することを目指しています。

ウォーターフォールに慣れたチームがスクラムに移行しようとするとき、おちいりがちな罠が2つあります。

1つはプロジェクトのゴールを契約上の要件定義に固定しまうことです。プロジェクトの発注側は、コスト削減や納期の短縮を名目にアジャイル開発=スクラムを求めますが、実際には、発注時に示した要件定義を100%実現することを求めています…米軍は似非アジャイルを拒絶するチェックリストとして、開発サイドに要件を変更する権限がないプロジェクトは真のアジャイルではない、ということを定めています。

https://qiita.com/YankeeDeltaBravo225/items/9f08c0eccd48f00b9f9e

簡単に言えば、アジャイル開発を採用するなら、プロジェクトの開始時に想定していたゴール（要件定義、機能リスト）はその時点におけるイメージであって、過不足や未決定事項を少なからず含んでいると考えるべきなのです。しかし、そのような認識は「担当者」のレベルでは合意されていても、稟議を決裁した上層部は、稟議書に記載された機能リストが100%実現されるものと期待してしまいがちです。こうなると、現場としては、上層部の期待に応えるために（事態がややこしくならないようにするために）、稟議書に記載された機能リストを実現することをプロジェクトのゴールとして固定化してしまうのです。こうなるとスクラムで開発しようとしても、やっていることはウォーターフォールに回帰せざるを得ません。結果として、スプリント毎の作業結果を報告することで、アジャイルで開発していますよ、というアリバイを作るだけになってしまい、いわゆる似非アジャイルになってしまうわけです。

スクラムは、正しく運用すれば、非常に効果的な開発スタイルです。また、アジャイルに不慣れな組織でも、漸進的に導入し、ゆっくりと習熟していくことの可能な、穏当なスタイルだとも言えます。しかし、それだけに、似非アジャイルに留まってしまうリスクがあります。