ウォーターフォールかアジャイルか論は、単純にどちらかがより良いとかより悪いとかというよりも、どういう状況のときどういう方法が効果的なのか見極めて、適切に選択していこう、という段階なのだろうと思います。とはいっても、現場的に実際に見極めようとなると悩ましいこと此の上なし。なぜ悩ましいのでしょうか。根本要因として、それぞれを進める上でかかるコストが、ある種のジレンマ構造になっているのではないかと考えました。
誤り無く計画されその通り遂行できたウォーターフォールが一番安いのだと考えます。仮に1だとします。次がアジャイル。アジャイルには本来的に試行錯誤することが内包されているので、ウォーターフォールでさくっと進められた場合に対して、例えば5〜10といったコストがかかります。そして失敗したウォーターフォール。誤ったあるいは的を外した計画に基づいて進められたウォーターフォールは、例えば10〜∞のコストがかかります。分かっているならウォーターフォールでやりたい、でも失敗は恐ろしい、という構造な訳です。
下のイメージで、矢印の線の長さがコストを表します。図中青実線矢印のウォーターフォールは一直線に進めます。赤矢印のアジャイルは右往左往します。アジャイルの「俊敏」の意味は、（いい意味（＝誤ったら軌道修正できる）でも悪い意味（＝最短という訳ではない）でも）右往左往できる、ということだと理解します。青破線矢印の失敗するウォーターフォールは全く誤った方向へ、取り返しが付かない段階にまで一直線に進んでしまいます。
あるいは、ウォーターフォールは統計的に“ボラティリティ”が大きい、アジャイルは小さいと云うこともできそうです。
◇
プロジェクトについて、ウォーターフォールが可能なのかアジャイルが適するのかは、プロジェクト自体の絶対的特質によって決まるものではなく、開発チームとプロジェクトとの相対的関係で決まると考えます。チームがそのプロジェクトの領域に関してどれだけの知見を備えているかで決まります。チームがプロジェクトの領域を熟知していて、十分に妥当な計画を検討できる、と云うならば、素直にウォーターフォールでがんがん進めてしまった方が早いでしょう。プロジェクトがチームにとって未知の領域ならば、アジャイルで進めるのが適切でしょう。同一のプロジェクトでも、開発チームによって、ウォーターフォールが早いかアジャイルが適切か変わる、ということです。
一つのプロジェクト内でも、大抵は、よく知っている領域と、あまり知らない領域とが混在しているでしょう。こういった場合はプロジェクト全体を以って、どちらの方法論が適切かと検討するよりも、どの領域が良く理解されていて（※ウォーターフォールが可能）、どの領域は不明瞭な点が多いのか（※アジャイルが適切）、それを見極め、サブプロジェクトに分割して捉えるのがよいでしょう。
開発チームとプロジェクトとの相対的関係は、チームの成長あるいは習熟度によっても変わってきます。あるプロダクトの継続的開発をしていて、当初は未知の領域でも、次第にその領域の問題構造・課題構造が明確になってくるでしょう。当初はアジャイルで進めるのが適切だと考えても、そのうち、少なくとも一部はウォーターフォールで進めた方がいいと思うようになるかもしません。それは、チームのそのプロダクトに対しての習熟度が向上した結果かもしれません。
◇
ここで一点だけ制約を忘れないようにします。アジャイルは大規模では実施できません。
ウォーターフォールでは組織的仕組みで物事を進めようと考えます。ウォーターフォールは仕組みによるのでスケールさせることができます。アジャイルはメンバー各人のコミットメントに期待しあるいは依存します。アジャイルでは、メンバー各位それぞれがプロジェクトやプロダクトへコミットしているという状態が維持されていることによって、チームとしてのパフォーマンスが発揮されます。個々人のコミットメントに依存するやり方はスケールできません。よって、大規模（＝即ち大人数）ではアジャイルは実施できない、ということになります。
◇
まとめます。
チームが対象領域を熟知しているならば、ウォーターフォールを選択することができます。未知の領域ならばアジャイルを選択しなければなりません。プロジェクトが小規模の場合、これで問題ありません。プロジェクトが大規模だった場合、次のような結論となるでしょう。チームが対象領域を熟知しているならば、ウォーターフォールを選択することができます。未知の領域ならば、そのプロジェクトは実施してはいけません。まずは小規模のプロトタイプ・プロジェクトをアジャイルで立ち上げるべき、ということとなります。
そして「熟知」しているかどうかは、チームとプロジェクトとの相対的な関係です。同じプロジェクトでもチームが異なれば判断も変わります。プロジェクト内でも部分に分割すれば、よく知っている領域と知らない領域とに分けられるでしょう。さらに、同じチームでも時間を経て習熟度が増せば、これもまた判断は変わります。
◇
＜追記１＞
開発チームがプロジェクトに対する知見を備えていると云えるかどうかについて、同一チーム同一プロジェクトでも、チーム運営の仕方によっても変わり得ると考えます。一つのチームとはいえ構成メンバーは複数人です。メンバー間で対象プロジェクトに対する知見の深さは一般にまちまちだと想定されます。対象のプロダクトやプロジェクトに対して特に知見の深い者がチームに属していた場合、プロジェクト・プランニングにおいて彼／彼女の意見を特に中心として、ウォーターフォールが可能な程度の計画を策定し、他のメンバーはそれに従う、というやり方を採用することができます。しかし、その（＝彼／彼女の意見を中心に据える）判断自体にウォーターフォールとしての“ボラティリティ”が大きいというリスクが内在しているとして、普通にアジャイルを採用することもできます。
＜追記２＞
本記事で仮定したウォーターフォールとアジャイルのコスト構造の話は、「民主主義」、「良い独裁」、「悪い独裁」を比較する論に似ていると思いました。民主主義は良い独裁よりも全くもってパフォーマンスは悪い、しかし悪い独裁に陥るリスクを回避できる現実的な選択肢である、と。あるいは、本文に書きましたが、一般には投資先として“ボラティリティ”が大きいところは避けます。“ボラティリティ”が大きいところに張っていくのは投機です。（※一般の人は投機には手を出さないようにしましょう。。）アジャイルは、普通のチームが普通のプロジェクトで普通に改善を進めていくには、バランスのとれた方法論なのだと云えるのでしょう。
＜追記３＞
本記事を書くまで、なんとなく、ウォーターフォールよりアジャイルの方がイノベーションと親和性が高いようなイメージを持っていました。しかし、本記事のように理解するならば、（破壊的）イノベーションはアジャイルからは生じない、と云えそうです。イノベーションを期待する場合は、良い独裁に賭けていく必要があると思われます。（※言わずもがな、スティーブ・ジョブス氏のような人々を想定します。）一般のプロジェクトでも、特別なブレークスルーを期待するならば、特に知見の深い者をチームの中心に据えて、彼／彼女の判断に基づくウォーターフォールを計画する必要があるのだろうと思いました。
◆以上
