ウォーターフォールモデルとアジャイルの大きな違い
ここで扱いたい違いとは、ウォーターフォールモデルは「前の工程に戻れず」や「大規模開発向け」なモデル、アジャイルは「ユーザの意見を取り入れやすい」モデル、といったものではありません。もっと根本的な違いとして、筆者は以下のような点を考えています。
- ウォーターフォールモデルとは、「コスト(原価)」を最小化したい場合の考え方
- アジャイルとは「バリュー(売上)」を最大化したい場合の考え方
この観点から2つの違いを説明していきます。
どうしてアジャイルは普及しないのか
開発現場では、仕様変更が要件定義後の工程にかかわらず発生したり、できあがった後に追加要件が生じたりするにも関わらず、どうして、会社や顧客はアジャイルに賛同してくれないのだろうという気持ちがある方もいるはずです。
アジャイル思想を理解してもらえれば、それが最適だと分かるはずなのにとも思うでしょう。
しかし、採用していないことにも理由があります。それは、システム開発の大きな目的の1つにコスト軽減があるためです。
業務委託でのシステム開発において、利益を最大化したいなら「コストの最小化」は確実な方法の1つです。また、業務委託でなく社内開発であっても、システム化の要望自体がコスト部署からであれば「バリューの最大化」よりもコストに向くのは自然です。そういう現場ではアジャイルという考え方が普及しにくいのは仕方がないことだと思います。
ただし、実際のプロジェクトでは、コストの最小化とバリューの最大化という目的は、同時に存在します。そのため、アジャイルへの期待が生まれてくるのだと思います。
しかし、アジャイル手法の採用が難しいケースでは、コスト面から生じる制限が非常に大きいため、採用がし難いと感じているのだと思います。
コスト構造からみる違い
ここで、コスト構造の違いがよく分かるように、ウォーターフォールモデルとアジャイルモデルの違いを考えてみます。例えば、図7のようなウォーターフォールモデルでの開発スケジュールがあったとします。
話を単純化するために、各工程(1つの四角)は一人だけが対応するものとし、全体の工数は6.5人月かかるものとします。
これを、アジャイルの目的の1つである短いリリースを繰りかえし、短い期間でフィードバック可能なように細かいサイクルで図8のように計画することとします。
しかし、これでは現実に即さない机上の理論のみで、無理矢理つくったという感じが否めません。そして、現場では図9のように実態が近付いていくはずです。
このスケジュールの場合には、工数は25人月になります。
続いて、実際のスケジュールとは異なり、図10のように実際に開発がはじまってから要件変更があるケースを想定します。
当初、「業務API開発」と「UI開発」では、期間を2カ月で工数としては3.5人月を見込んでいましたが、こちらが6カ月伸びると、12人月が増えますので、全体として18.5人月かかります(実際には、開発者以外の関係者工数も含む必要がありますが、単純化のために省略しています)。
このような状態になってしまった場合、多くの方が失敗したプロジェクトと感じるでしょう。しかし、プロジェクトの優先度が価値の最大化よりもコスト最小化のほうが高いならば、プロジェクトの結果としてはアジャイルで行う25人月のプロジェクトよりも良いと言えてしまうのです。
実際にはこんな単純に比較できませんが、表面上はアジャイル管理はコストがかかるプロジェクトというように見えるはずです。
また、最小から比べると、大きく予算が膨らむわけですから、予算を出す側の理屈では、できあがる価値の確証がとれないと支出を許容しにくくなります。もともと、作る物をよりフレキシブルにして将来のニーズを導入しやすくするモデルであるにもかかわらず、予算制限の面から見た場合にはウォーターフォールモデルよりも、より将来価値の確実性を高めないと採用しにくいという状況を作ってしまいます。