"(顧客)..."

(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう。
(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない。
(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市場の変化、環境の変化、競合他社、キャッシュフロー等を考えてみれば至極当然のことだ。
はっきり言っておけば、最初から要求が決まっており、作るべきものが全て明らかになっていて、かつその要求が変化する可能性が極めて低いプロジェクトであれば、ウォーターフォールの方が楽かもしれない。
(開発) 言われた通りやって給料もらえればそれでいいや、というマインドの人は基本的にウォーターフォールの方が楽。
（寄せ集め（下手すりゃ派遣元に出向してみたいな）でのチームでアジャイルが難しいのはチームの能力を向上させるインセンティブが働かないから）
(開発) 顧客の利益（やプロジェクトの利益）に関心がない人もウォーターフォールの方が楽。アジャイルな開発の目的や考え方への適合性の問題
(開発) 小さい失敗も許されないような組織風土の場合はウォーターフォールが楽。最終的には最後に一番大きい失敗になるわけだが。Agileの基本はFail Fast(失敗は早めに) とSmall Success(小さい成功の積み重ね)。
(開発) 個人主義の組織。こういう場合は豪腕のマネージャがいるようなウォーターフォールじゃないと回らないかも。そもそもAgileチームとして成立しない。これは組織内での人事評価基準と密接に関わっていることが多い。ナレッジの共有が進まないパターンでもある。
ソフトウェアのライフサイクルが短い使い捨てのような場合や、一端作れば終わるプロジェクトに属している場合は、将来の負債について一般的に関心がないので、ウォーターフォールを楽と思うかもしれない。継続的に製品コードを改善し続ける理由がないし、チームを改善し続ける必要もない。終われば良いというフォースが一番強く働く

ちなみに、工場でのものづくりにおいて、少ない品種の大量生産から多品種少量生産に変わったのは、社会的必然性があったからで、ウォーターフォールからアジャイルへの流れも社会的必然性と僕は捉えている。システムは作ること自体は目的でもなんでもない。システム自体が手段だ。さらにいえばアジャイルやウォーターフォールというやり方も手段でしかない。ただ、ビジネスの速度、環境変化の速度、テクノロジーの変化、そういうのを踏まえると、単に楽だからと理由で変化に対応しない組織や人はいずれ淘汰されていくだろう。