こんにちは。ディベロップメントテクノロジーセンターのつるだです。
アジャイル開発のプロジェクトにて、スクラムマスターとして複数チームを担当しています。
社内ではアジャイル推進として活動していますが、
組織としてウォーターフォールの経験値が豊富なことから、
アジャイルでやる必要があるのかといった疑問や、興味が薄いメンバーがいることも事実です。
アジャイル開発を実際に経験して感じた、ウォーターフォールとの違いを考察することで、
これらの疑問に回答し、社内外の方にアジャイルに興味を持って持っていただければと思います。
※考察なので、私見を多く含みます。

考察に当たっての立ち位置

宗教戦争を回避するための前置きですｗ
アジャイル推進の立場ではありますが、ウォーターフォールが劣っている/前時代的だ！とは考えていません。
むしろ、これまでのシステム開発を成功に導いた素晴らしい仕組みですし、
これからも、この成熟した仕組みを上手く利用することには、大きな価値があります。
具体的には、ウォーターフォールからアジャイルへの移行ではなく、
ウォーターフォールとアジャイルを共生/選択式にするのがよいと考えます。
また、『アジャイルソフトウェア開発宣言』の通り、ウォーターフォール的なプロセス/成果物を否定するものでもありません。

解決する課題の違い

まず、ウォーターフォールとアジャイルでは解決する課題が違います。
課題を分類する、クネビンフレームワークというものがあります。

単純：正解が存在し、解決策が明確
困難：複雑だが因果関係がある。正解が複数あるが、調べれば解決策が明確になる
複雑：問題が入り組んでおり、解決方法が分からない
カオス：問題が入り組んでおり、状況を理解することも難しい
無秩序：解決策がない

単純な問題は解決策が明確、困難な問題は解決策が予測可能なため、ウォーターフォール向きです。
複雑な問題、カオスな問題は解決策が予測困難なため、アジャイル向きです。

今回は、ここから解決する課題の違いによる、ウォーターフォールとアジャイルの特徴について考察します。

開発の工程、体制の違い

ウォーターフォールとアジャイルでは開発の進め方が違います。
ウォーターフォールでは解決する課題は単純な課題なので、まず作るものを決めます。
具体的には、全ての機能の要件定義を行いスコープを確定させます。
沢山の機能を実現するためには期間が必要ですが、多くの要員を準備し、
同時並行で作業することで期間を圧縮します。
作るものを細分化するために、V字モデルに沿って実現方法を詳細化していきます。
工程には基本設計、詳細設計、製作、結合テスト、統合テストなどがありますが、
工程によって工数は異なり、一番工数が大きな製作で要員数が最も多くなります。
参考: ソフトウェア開発データ白書2018-2019

一方、アジャイルでは複雑な課題に対して、解決のための仮説を立てます。
ただ、ウォーターフォールで扱う課題と異なり、仮説が合っているかは誰にも分かりません。
仮説が合っているかを検証する最も効果的な方法は、実際に作って検証することです。
そのため、仮説を立てたら、設計、製作を経てリリースまで行い、
仮説が正しかったのか検証し、そのフィードバックを得て次のアクションを考えることになります。
チームで設計からリリースまでという同じ作業を繰り返し行うため、
チームメンバーはプロダクトに対する知識や、技術スキルも繰り返し上がりやすくなります。
そのため、アジャイルではチームの成長のために、メンバーを変えないことが一般的です。

コストのかけ方の違い

ウォーターフォールでは、以下に要件定義で計画したこと通りに作るかが重要となります。
同時並行で作業すること、要員数が工程によって変動することから、
ウォーターフォールでは、誰が作っても同じになることを重視し、
結果として工程ごとに設計書を充実させる傾向にあります。(方式設計書、外部設計書、内部設計書、全体テスト計画書など)

アジャイルでは、実際に作ることを優先するため、設計書をどこまで充実させるかはバランスが重要になります。
特に、チームメンバーが固定化され、プロダクトへの理解度が高ければ、
ウォーターフォールと比べて、簡易な設計書で、十分な理解/共通認識を得ることができます。
また、同じ作業が繰り返し発生するため、自動化によりToilを減らしチームのリソースを有効活用できるようにすることが大事です。
1サイクルで1%ずつ改善しつづけると、複利計算で25サイクル目(1サイクル=2週間とすると、約1年)では28%も向上したチームになります。

特徴による制限事項や想定されるリスク

ウォーターフォールは始めにスコープを決めてしまうため、変更に弱いです。
ただ、実際の現場で何も出来ないかというと、変更管理の仕組みを設けてスコープを変更することが多いです。
しかし、影響範囲が大きい場合などは、対応が困難な場合もありますし、
開発後期に変更された場合、それまでのコストが無駄になる可能性もあります。

また、ウォーターフォールでは、要件定義からリリースまで時間がかかります。
リリース時には状況が変わり、期待した効果が生まれない可能性があります。
さらに、単純に利用されない可能性もあります。実に64%の機能が『ほとんど or まったく使われない』とするデータもあります。
苦労して組み込んだのに、アクセスログを見ると使われていないことを知ってしまう。という経験は無いでしょうか。

一方、最終的に作るプロダクトが全く同じ場合、アジャイルの方がコストがかかります。
具体的には、要件の変化によるリアーキやリファクタリング、サイクル開発での品質管理やリリースの繰り返しがコストになります。

また、優先順位を決める仕組みが上手くいかない場合、アジャイルでは作業が始められないというリスクもあります。

ウォーターフォールかアジャイルかを選択する

ここまで、ウォーターフォールとアジャイルの違いについて、『解決する課題の違い』をベースに考察しました。
最後に、現在それぞれの開発手法を選択している方に問いかけていきたいと思います。

ウォーターフォールを選択している方
本当に単純な課題でしょうか。課題を解決した場合の費用対効果は明確ですか。

アジャイルを選択している方
本当に複雑な課題でしょうか。実は、単純な課題にする努力が足りていないのではないですか。