「ウォーターフォール(および計画駆動)とスクラム、どっちが速いの？」と言われた時の回答

忙しい人向けの結論

スクラムの開発は速さに向きません。
ウォーターフォールや計画駆動。
つまりあなたの今まで通りのやり方が向いています。

分かりましたね。ではこの記事は閉じていただいてけっこうです。

「忙しい人向けの結論」のあとに

よーし。これでさっきの連中は帰ったな。
いいんだよ、あんな連中。
スクラムなんて新しいやり方は向いてない、今まで通りでいいよ、で安心しちまうんだから。

そもそもなんですが「どっちが速いの？（どっちがいいの？）」と聞くこと自体がナンセンスです。
そんな悪い質問をするということは質問した人は答えを聞いて「安心したい」のです。
安心したがっているような人たちのお金の出ない質問に付き合っているほど私の人生は長くないので、安易に安心できる回答だけ包んで丁重に追い返すわけです。

前提が狂ってる

そもそもこの２つの方式を安易に比べることはできません。
まず大前提として、「最初に作りたかったもの」と「最終的に出来上がるもの」は同じではありません。
ウォーターフォールだろうが計画駆動だろうがスクラムだろうが変わりません。
作っている途中で学習や発見があり、「当初の計画よりプラス方向に修正する」「当初の計画では実行不能なのでマイナスを修正する」という作業が必ず発生します。

発生させたくないなら、以前にやった作業をできるだけトレースすることです。
製造業と同じです。同じように同じものを作るのです。
ところがそれではIT開発は成り立たないので今こうなっているわけです。

「最初に作りたかったもの」と「最終的に出来上がるもの」の差異や発見して計画を修正するイベントのコスト、この修正のオーバーヘッドとでも呼ぶべきコストとリターンを勘案して修正するかどうかが決まります。
まともなプロジェクトマネージャーがいるならそうです。

ウォーターフォールや計画駆動の場合、修正のオーバーヘッドのコストが高いので修正を取り入れる量が減ります。
スクラムの場合、修正のオーバーヘッドのコストが安いので修正のリターンがコストを上回る可能性が高く、修正を取り入れる判断をする回数が増えます。

なので「最初に作りたいもの」が同じでも、ウォーターフォールや計画駆動とスクラムでは「最終的に出来上がるもの」が異なります。
最終的に出来上がるものが異なるのにどちらが速いか遅いかを論じるなど無意味です。

一般論として

「最初に作りたかったもの」と「最終的に出来上がるもの」の差異や発見して計画を修正するイベントが少なさそうならウォーターフォールや計画駆動を選ぶべきですし、多くなりそうならスクラムを選ぶべきです。

ところがここに嘘があります。
今までウォーターフォールや計画駆動に慣れてきたメンバーに、「ウォーターフォールや計画駆動でやれ」と命じた場合と「スクラムでやれ」と命じた場合では作業スピードに差が出ます。
逆もまた然りです。

慣れや習熟、熟達という概念が存在するからです。
向こう数年のプロジェクトを見通して長期的に考えてください。
「最初に作りたかったもの」と「最終的に出来上がるもの」の差異や発見して計画を修正するイベントが少なさそうならウォーターフォールや計画駆動を選ぶべきですし、多くなりそうならスクラムを選ぶべきです。

しかしそんなものは見通せるものでしょうか？
いい質問ですね。
結論だけ言うと見通せません。多くのサービサーの先行事例（と書いて屍と読む）がそれを物語っています。

強いて言うなら、不確定要素が多いからスクラムとするのではなく、スクラムなら不確定要素が多くてもなんとかなるだろうと腹を括れるのでスクラムを選ぶ者もいます。
あるいは逆に毎回要件定義より前のフェーズに比較的潤沢なコストを分厚くはってウォーターフォールや計画駆動を選ぶ者もいます。

要するにお座敷がかかればどこへでも行く受託ならばともかく、（私が想定している多くの読者が属する）サービサーの内製開発の場合は経営上の意思決定としてどちらかにシフトする方が現在は主流です。
左右で打ちわける野球のスイッチヒッターのように状況に応じて前回はウォーターフォール（や計画駆動）、今回はスクラムと切り替えることは開発ユニットを無駄に混乱させ疲弊させるだけです。

さて最初の質問に戻りましょう。

質問：
「ウォーターフォール(および計画駆動)とスクラム、どっちが速いの？」

回答：
どちらが速いように組織を作るかは組織次第です。どちら向きに組織を作るかを決めるのは、経営陣の仕事です。