アジャイル開発のデメリットとは？DX時代にウォーターフォール・モデルを考える

2022年8月5日

ウォーターフォールは終わったのか？

DXを始め、IT導入が叫ばれる中、様々なプロジェクトが進められるようになりました。突然プロジェクト・マネジャーに抜擢され、急いでプロジェクトマネジメントの勉強をしている人も多いのではないでしょうか。
プロジェクトマネジメントの勉強をしていると「ウォーターフォール・モデル」や「アジャイル開発」という言葉を目にします。
いずれもプロジェクトの進め方に関する用語ですが、本によっては「複雑化するプロジェクトにはウォーターフォール・モデルの開発手法では対応できなくなったため、アジャイル開発が採用されるようになってきた」というように書かれているため、ウォーターフォール・モデルを過去の存在と認識している方も少なからずいます。

しかし、アジャイル開発はウォーターフォール・モデルの上位互換の開発手法ではありません。
むしろ、プロジェクトマネジメントの経験があまりない人や組織であれば、アジャイル開発よりもウォーターフォール・モデルのほうが導入しやすいでしょう。

今回はアジャイル開発が叫ばれる今、同手法の欠点を見つめ、ウォーターフォール・モデルのメリットを改めて考えていきます。

ウォーターフォール・モデルとアジャイル開発

詳しい話の前に、簡単にウォーターフォール・モデルとアジャイル開発の説明をしていきます。
ウォーターフォール・モデルとは、予測型プロジェクトマネジメントのことで、プロジェクトの初期段階で計画を綿密に練り、その計画に沿って段階的にプロジェクトを進めていくという方法です。一般的に「プロジェクトマネジメント」と聞いて思い浮かべるものが、このウォーターフォール・モデルだと思います。
ウォーターフォール・モデルはプロジェクトを「フェーズ」に区切って進行していき、原則完了したフェーズに戻ることはありません。水が流れ落ちるようにプロジェクトを進めていくことから「ウォーターフォール」という名前が付けられています。

ウォーターフォール・モデルは長く用いられてきた手法でしたが、計画の変更に弱いという弱点があり、複雑化するプロジェクトに対応しづらくなってきました。
その中で注目されているのがアジャイル開発です。アジャイル開発ではウォーターフォール・モデルほど詳細な計画は立てず、早期にプロトタイプなどを開発し、手直しや修正を繰り返していきながらプロジェクトを進めていきます。プロジェクトが変更されることを想定しているので、不測の事態に強いのがアジャイル開発の特長です。

ウォーターフォール・モデルとアジャイル開発については、下記の記事で詳しく説明していますので、よろしければご覧ください。

簡単には導入できないアジャイル

ウォーターフォール・モデルとアジャイル開発を比べると、たしかにアジャイル開発のほうが不測の事態に強いことから、優れた進行方法のように思えます。仕事をしていると「私たちが今までプロジェクトに失敗していたのは、アジャイル開発ではなかったからだ！」と話される方がいらっしゃいますが、その気持ちもわかります。
たしかにアジャイル開発を上手く組織に導入できれば、開発期間を短縮でき、不測の事態にも対応できるようになります。

しかし、上述のとおり「アジャイル開発」というのはあくまで開発体制、つまりサッカーのフォーメーションのようなもので、それを変えたからといって「プロジェクトの成功」に直結するわけではありません。また、プロジェクトに慣れていない組織がアジャイル開発を採り入れるには、いくつかの問題点があると思われます。
ここからはアジャイル開発を組織に導入する上での問題をいくつかお話ししていきます。

アジャイルには精鋭部隊が必要

アジャイル開発を採り入れる難しさの１つは、精鋭部隊が必要だということです。
「アジャイル開発」というのはあくまで「プロジェクトをこのように進めていこう」という思想です。そのため、アジャイル開発といっても、具体的にどのように進めるかは明確に決まってはいないのですが、アジャイル開発の思想を実務に落とし込んだ「スクラム開発」というものがあります。

「スクラム」というと屈強なラグビー選手を思い浮かべる方も多いかと思います。そのイメージどおり、スクラム開発はラグビー選手がスクラムを組むように、チームが一丸となってプロジェクトに取り組みます。

千変万化するプロジェクトを、強固なチームワークで乗り切ろうとするのがスクラム開発ですが、チーム・メンバーの知識や技術、経験が乏しいと、効果を発揮することができません。

また、外部のベンダーにアジャイルで開発を依頼するという場合であっても、依頼者側のプロジェクト・メンバーにもアジャイルへの理解とその開発体制への準備が必要です。
たとえばスクラム開発では「デイリースクラム」と呼ばれる、日々のミーティングがあります。もしアジャイル開発を採用するのであれば、依頼者側もこうしたミーティングには参加することが望ましいです。

日々のミーティングの中で発生した疑問や問題をその場で解決できるからこそ迅速な対応ができるため、「依頼者に聞かないとわからないし、いつ聞けるのかわからない」という状況であれば、アジャイルで進める意味がありません。

こうしたことから、プロジェクトに慣れていない組織が下手にアジャイルの手法を採り入れようとすると、大して効果があげられず、かえって状況を悪化させてしまうこともあります。

ウォーターフォール・モデルに比べてコストがかさむ

ウォーターフォール・モデルに比べて、アジャイル開発はコストがかさむことも難点です。両者の費用の違いは見積もりの出し方が関係しています。

ウォーターフォール・モデルでは、開発の金額は対応する作業にかかる工数で見積もられます。一方で、アジャイル型では一般的にプロジェクトの期間で見積もられます。
たとえば、Webサイトの制作を外部の制作会社に依頼するとします。ウォーターフォール・モデルのプロジェクトであれば、「デザイン費が40万円、コーディング費が全部で20万円、ディレクション費が20万円」というように、項目で金額を出します。

一方で、アジャイル型で進める場合は「今回のWebサイトの規模を考えると、３ヵ月は制作に必要なため、ディレクター・デザイナー・コーダーの時間を３ヵ月分確保します。彼らの月々の料金は１人80万円ですので、月240万円になり、それが３ヵ月分なので、料金は720万円です。」というように、金額を出していきます。

制作プロジェクトに慣れていないと「え！？そんなに人の料金って高いの！？」と思われるかもしれません。最近ではフリーランスエンジニアの案件広告を各所で見ますが、月70万円以上の報酬を謳っているものも多くあります。デザイナーであれコーダーであれ、技術者を確保するというのはかなりのお金を必要とします。
そのため、往々にしてアジャイル型はウォーターフォール・モデルよりもコストがかさんでしまいます。

アジャイルは自社内に開発チームがいることが前提

ここまではアジャイル開発を採り入れる際の難点を紹介してきました。
アジャイル開発はGoogleなどのようにスキルのある開発スタッフが社内にいるのであれば有効ですが、組織内にノウハウが少なく、外部に依頼をしなければならない場合は実現が難しい開発手法かもしれません。
そのため、問題があったとしてもウォーターフォール・モデルでプロジェクトを進めるというのが、多くの日本の組織の実情ではないでしょうか。

ウォーターフォール・モデルをおススメする理由

多くの組織がウォーターフォール・モデルを採用せざるを得なくても、大きな問題はありません。世の中のほとんどのプロジェクトはウォーターフォール・モデルで十分対応可能で、むしろウォーターフォール・モデルでの進行を勧めることも多々あります。
上述のとおり、アジャイル開発では精鋭部隊を用意するのが難しかったり、外部に委託するのに料金がかかってしまったりします。その点、ウォーターフォール・モデルではあらかじめ作業を予測し、適切な体制を組むことができます。
そして何より、アジャイル開発でなければいけないほど「未知」のプロジェクトに取り組むことが少ないということが、ウォーターフォール・モデルでも問題がない最大の理由です。

たとえば「ユーザーに喜ばれる新しいSNSを作ろう！」というように、誰も見たこともないものを生み出すプロジェクトであればアジャイル開発のほうが適しています。
しかし、「会社に会計システムを導入しよう」や「Webサイトを新しくしよう」というプロジェクトは、あなたや所属する組織がその道に詳しくなくても、世間で豊富な経験と知識を持った人はいます。そうした専門家の力を借りれば、プロジェクトの不確かな要素を少なくすることができ、ウォーターフォール・モデルのプロジェクトマネジメントでも十分対応可能になります。

まずはウォーターフォール・モデルを身に着ける

今回はアジャイル開発のデメリットと、ウォーターフォール・モデルでも問題がない理由を解説してきました。
アジャイル開発は経験が少ない人や組織が採用するには難しい開発手法であり、多くの場合、ウォーターフォール・モデルでプロジェクトを進めるようになります。
しかし、よほど未知のプロジェクトに取り組むのでもない限り、ウォーターフォール・モデルの進行でも大きな問題はありません。
もしプロジェクトマネジメントに慣れていなければ、まずは事前の準備と計画を念入りに行うウォーターフォール・モデルの考え方や進め方を身に着けることが大切です。

今回お話ししたウォーターフォール・モデルやスクラム開発については、下記の記事でも解説していますので、よろしければご覧ください。