ウォーターフォールとアジャイルは、それぞれ異なる前提と目的を持つマネジメント手法です。ウォーターフォールは全体計画の精度を前提に効率的な開発を目指し、アジャイルは変化に適応しながら試行錯誤を重ねることに重点を置きます。しかし、世の中ではマネジメント手法としてフェアな評価ができていないようにも感じます。
その要因は、アジャイルの説明が精神論や感情論に寄りすぎている点にあると思っています。そこで、そういった要素を排除し、双方をマネジメント手法として整理してみました。
前提条件
僕は、いわゆるエンタープライズ業界の人なので、SIerがいるような規模の組織を前提にしていますが、マネジメント手法としての考え方は、どの業界でも利用できると思います。
「ウォーターフォール」とは、大手SIerなどで定義されているウォーターフォール的なマネジメント手法のこと。V字と呼ばれる要件定義、基本設計、詳細設計、実装、単体テスト、結合テスト、運用テストなどのフェーズを利用します。
「アジャイル」とは、スクラムおよび、その派生となるマネジメント手法のこと。本記事ではスプリントに関わる各種イベントのみを扱います。大規模手法としてのLeSSやScrum@Scale、その派生も含まれます。なので、以下ではスクラムと表現します。
「マネジメント手法として」とは、精神論、文化論、組織論やチーム論は除き、可能な限りマネジメント手法としての仕組みを対象にします。
マネジメントの基本活動とは
まず、両者を比較するための共通の視点として「マネジメントの基本活動」を定義します。それは以下の4つです。
- 計画
- 実行
- 確認
- 調整
どんなマネジメント手法だろうが「計画し、計画に従って実行し、実行の成果を確認し、確認結果を持って調整を行う」という活動を含みます。PDCAとして知られています。
ウォーターフォールの手法
ウォーターフォールは、初期段階で全体計画を立案し、その全体計画に従ってフェーズ分割を行い、実行・確認・調整を繰り返す、という考え方になっています。一般的には、要件定義フェーズにおいて、検討対象のシステム機能、アーキテクチャについて検討を行い、これを実現するためのスケジュール、コストを明確にします。
ウォーターフォールにおける確認は、フェーズ単位で厳しく行われ、フェーズ内では緩やかな確認がされています。フェーズの完了時には必要とされるドキュメントやソースコードなので成果物を確認します。フェーズ内では進捗管理と呼ばれる「個別作業の進み具合」を確認していることが多いです。
調整はフェーズ完了時に実施しても間に合わないので、日々の進捗管理の結果で随時実施し、フェーズ単位での日程や成果物が達成できることを目指します。遅延がある場合の調整優先順は、リソース（残業もしくは要員追加）＞スケジュール（遅延）＞スコープ（機能削減）となります。特にスコープの変更が行われた場合には、変更管理と呼ばれるプロセスが実行され、全体計画との差分が管理されます。
アジャイル（スクラム）の手法
スクラムは、定期的なサイクル（1週間〜1ヶ月程度）の繰り返し期間（スプリントと称する）を定義し、次の1サイクルの計画のみを立案します。計画成果物は「動くソフトウェア」であることが推奨されています。
スクラムにおける確認は、サイクル単位で厳しく行われ、サイクル内では緩やかな確認がされています。サイクルの完了時には（可能な限り多くの）関係者を集めたレビューが実施され、「動くソフトウェア」をみて、その場でフィードバックを得ます。サイクル内ではカンバンを使ったタスクの実施と完了の確認が行われます。作業進捗ではなく、タスク完了の定義を明確にすることで厳密な進捗管理を行うことが推奨されます。
1サイクルごとの計画しかないため、サイクル内の調整は不要です。ただし、中長期の見通しに対して調整があった場合は、次のサイクルの計画を通じて調整が行われます。つまり、スクラムでは計画と調整が同時に実施されます。サイクル内の調整は、細かくは行いますが、期間が短いこともあり、リカバリを必死にやるより、計画（見積もり）精度を高めることが推奨されています。チームの人数（リソース）とサイクル期間は固定化されているため、サイクルの計画において調整できるのはスコープ（機能）しかありません。とはいえ、人数やチーム数の増減は可能なため、中期的にはリソースが調整要素となります。
特性を比較する
ウォーターフォールの特性は、初期の全体計画と段階的なフェーズです。中長期の見通しに対してフェーズごとのゲートをくぐりながら確実に進めていくことができます。ただし、計画の変更に対する柔軟性は高くありません。
よって、最初に立案する要件定義の計画精度が高い場合に効率的です。計画の達成に向けて最も効率的なリソースの種類や量を調達します。フェーズごとに専門性に合わせて分業し、そのスキルを持ったエンジニアを手配します。
そのためウォーターフォールは「全体計画が正しいことを前提に、最も効率的に開発するための手法」であると言えます。
対してスクラムの特性は定期的・短期的な計画と実行を無限に繰り返すことです。スクラムでは中長期の見通し管理はマネジメント手法の中心ではなく、作るべき対象が変化することに対して、いかに安全に対応するか、という点に注力されています。サイクル期間とチームメンバー（生産量）を安定させ、「動く機能」の開発をサイクルの中に押し込むことによって確実に改善を積み上げることができます。
B2CのECサイトのように「機能の価値」を判定する基準が社外ユーザーである場合、事前のヒヤリングだけに頼るよりも、仮説による小さな機能の実装と、その機能に対する定量的なフィードバックを元にすることが必要になります。スクラムは、こうした「試行錯誤」を安全に実現することに特化しています。
そのためアジャイル（スクラム）は「全体計画が曖昧であることを前提に、安全に開発対象の変更をするための手法」であると言えます。
適用対象について
前述の通り、それぞれの手法は異なります。特に計画に対する態度の違いは大きいです。ウォーターフォールは中長期計画が正しいことを前提にするため、その計画を達成するために最適な調達と実行を目指します。一方で、スクラムは中長期計画が曖昧であることを前提にするため、チームやサイクルを安定させて、計画の変更に安全に対応できることを目指します。そのため作るべき対象に対して最適な調達ができない場合もあります。
世の中を見渡すと、特殊な専門技術が必要な工程が含まれる場合、ウォーターフォール型のアプローチが必須になります。そうしないとリソース調達がおぼつかなくなるためです。たとえばマンション建設は、土木工事、杭工事、外壁工事、電気工事、内装工事と進んでいきますが、最近の人手不足もあり、工事によっては数年前からの要員調達計画が必要になります。この観点では、ITの場合、ERP導入などのプロダクトに強く依存する明確な専門性でもない限り、ウォーターフォールである必要性は薄れているはずです。
アジャイル（スクラム）が明確な全体計画プロセスを持たないことで品質やアーキテクチャへの課題意識が古くからあると思っています。品質については、DevOpsやSREのように実装以外の作業が自動化されていくことで段階的に問題が低減できていると思います（でも、テストプロセスも大事だね、というのが前回のブログ）。アーキテクチャについては、技術の進歩とともに、そこまでアーキテクチャに対する全体設計を重視しなくても十分な柔軟性が確保されるようになった表れでしょう。すごいぞ、クラウドコンピューティング。
とはいえ、全体計画を立案することの重要性が薄れたわけでもなく、未来を約束する（予測する）というのは資本主義の基本です。アジャイルにおいて中長期計画が軽視されても問題がないのは、事業運営が中長期のKPIを管理し、それを達成するために機能を考える、という前提があるからです。
価値との関係について
ITがもたらす価値に対して、双方のマネジメント手法は、どのようにアプローチするのでしょうか。
ウォーターフォールの場合は、最初の全体計画において価値を実現するための機能を定義してしまいます。そのため、その後工程では「機能を計画通りに計画すること」が目標になります。一般的には、スケジュールにシステムがもたらす価値（例えば売上）は記載しません。また、日本のSIerというビジネス環境では請負契約が「機能の実現」に対して行われるため、こうした動きが助長されます。
スクラムの場合は、試行錯誤をすることが前提になるため、常に価値への意識が向きやすくなっています。次のサイクルの計画する場合に「こういうデータが出たので、この機能が必要だ」という説明がしやすいのです。ただし、日本企業では事業部門とIT部門が分断されており、さらに、文化としてコンセンサス型の意思決定になることでスクラムの俊敏性に対して、事業側の意思決定のリズムが合わず、スクラムの良さを会社として享受できていない問題もあります。
というわけで、理論的にはスクラムの方が価値に対してフォーカスしやすいのですが、日本の文化やビジネス環境特性によって「北米的なスクラム」がうまく機能せず、むしろ、ウォーターフォール的な全体計画（入念な事前検討）が好まれる傾向があります。「日本のPDCAはPが大きすぎてダメだよね」というのは故 野中郁次郎先生をはじめ、多くの有識者が指摘するところであります。
評価
というわけで、フェアな評価としては「どちらも大事」ではあるものの「変化するビジネス戦略とITを強くリンクさせたいならアジャイル（スクラム）をもっと活用すべき」というところでしょうか。
DXやVUCAなど、"ビジネス環境の変化が激しくなってきた"中では、スクラムのようなサイクル型のアプローチを基本にした方がよくて、どうしても必要な時にだけウォーターフォール的なアプローチを取ることになると思います。
たとえば基幹システムの改修で、過去の経験から全体計画の精度が十分に高められるなら、ウォーターフォールの方が適しています。また、リリース後の障害リカバリが簡単にできないようなシステムの場合には、部分的にスクラムは活用できるものの、全体としてはウォーターフォール的な全体計画が必要になります。なので、「ウォーターフォールはもういらない」というわけにはいかない認識です（ただ、もっと割合は少なくていいと思います）。
僕は「事業戦略に関わるITについて、四半期サイクルで計画するのはアジャイルと言って良い」という主張をしていますが、これもアジャイルをベースにして物事を捉えるためです。定期的なミニウォーターフォールのことを積極的にアジャイルと呼べばいいと思っています（スクラムとはいいがたい）。
