こんにちは、Webディレクターのともぞうです。
「ウォーターフォール」や「アジャイル」というのは、システムやソフトウェアの開発手法のことです。さまざまな開発手法がある中でも、この２つは特に代表的なもので、二大開発手法と呼ばれることもあります。
この記事では、ウォーターフォール開発やアジャイル開発の違いや特徴を図解も用いながら比較し、どのようなプロジェクトに向いているのか初心者の方にもわかりやすく解説しています。
また、両者を組み合わせたハイブリッド開発についても合わせて解説しているので、ぜひ参考にしてみてください。
💡テクノロジーコンサルタントがおすすめするアプリ開発会社13社
目次
※2023年12月に最新情報を踏まえ編集部で校正・更新しました。
ウォーターフォール開発とアジャイル開発の違い
さっそくですが、ウォーターフォール開発とアジャイル開発の違いについてみていきましょう。
開発工程ごとの違いと、メリット・デメリットをそれぞれ比較しながら解説します。
開発工程における違い
まずは各開発工程ごとに、どのような違いがあるのか見ていきましょう。アジャイル開発とウォーターフォール開発の違いを工程別にまとめると、以下の通りです。
| ウォーターフォール開発 | アジャイル開発 | |
|---|---|---|
| 要件定義 | 細かいところまで固めた要件仕様書を作成し、それをもとに開発を始める。 途中での変更は想定していない。 |
詳細な要件は決めず、開発チームが顧客ニーズの理解を深めることを重要視する。 プロトタイプやモックアップなどの仮の成果物を作成し、 顧客からフィードバックを受け取りながら調整を行う。 |
| 開発 | 作成した要件仕様書をもとに、 上流から下流までの各工程を1つずつ完了させながらプロジェクトを進める。 |
機能単位での小さな開発（企画〜リリースまで）を繰り返しながらプロジェクトを進める。 |
| テスト工程 | プロジェクトの開発フェーズの最後にテストを行う。 | 機能単位での開発毎にテストをおこなう。 |
| コミュニケーションの とり方 |
顧客と開発チームのコミュニケーションは、要件定義などの上流工程で多くなり、 それ以降は比較的少ない。 |
顧客と開発チームが密にコミュニケーションをとりながら開発を進める。 また開発チーム内でも密なコミュニケーションが必要となる |
ウォーターフォール開発は、まず初めに要件定義をしっかりと固め、それに従って各工程を1つずつ完了させていく手法です。
アジャイルと比較してプロジェクトの全体像を把握しやすいですが、途中での変更が難しいというデメリットがあります。
顧客と開発チーム間でのコミュニケーションは、主に上流工程で多くなり、下流工程になれば少なくなるのが一般的です。
アジャイル開発は、顧客ニーズや市場変化にあわせて、柔軟に開発を進めていく手法です。
開発を始める段階では要件定義は大枠で決めるのみで、開発を進めながら方針を定めていきます。そのため、顧客の要求が変化しやすいプロジェクトや、スピーディーな開発が求められるプロジェクトに向いています。
顧客と開発チーム間でのコミュニケーションはもちろん、開発チーム内でのコミュニケーションも密にとる必要があるため、チームメンバーのコミュニケーション能力やモチベーションが高い場合は適用しやすく、逆に低い場合はかなり進めにくくなります。
開発費用の違い
システム開発の費用は、主に人件費（工数）に左右されます。そのため仕様を最初に決定するウォーターフォール開発では、あらかじめ費用を算出しやすいです。
一方でアジャイル開発では、市場感や顧客の反応を見て開発を進めていくため、最終的にどれくらいの費用になるのかを算出するのはむずかしくなります。
両開発手法のメリット・デメリットを比較
ここまで紹介してきたような違いから、各開発手法では以下のようなメリット・デメリットがあります。以下に比較表を作成しましたので参考にしてみてください。
| ウォーターフォール 開発 |
アジャイル開発 | |
|---|---|---|
| ○メリット |
|
|
| ×デメリット |
|
|
ウォーターフォール開発では、要件定義のフェーズで完全に要件を把握し、それを基に設計・開発を行うため、要件に対してのバグは少なくなります。
一方で、変化に弱く、一度完了した工程に問題や漏れがあった場合は、前工程から再スタート・見直しをすることが提唱されています。
（前工程は戻れない、と勘違いされることが多いのですが、戻ることは可能です。いつからか戻ることはできないと理解されるようになってしまいました……）
また、発注者側は最初に多くのドキュメントを理解する必要があり、結構な労力が必要になるのもデメリットといえるでしょう。
さらに、アジャイル開発では機能ごとに開発を進めるため実際に動くものを早く見ることができるのですが、ウォーターフォールの場合は、プロトタイプの制作予定がない限り、実際に動くものを触るまでには時間がかかります。
アジャイル開発では、機能単位で開発を進めていき、１つの開発期間はウォーターフォールモデルよりも短期間になります。そのため、市場の変化にも対応しやすく、要求変更があったときも柔軟に対応することができるというメリットがあります。結果として、無駄な機能を開発する可能性も低いのが特徴です。
一方で、全体像を把握しにくく、スケジュール管理や予算の見通しをすることが難しいというデメリットもあります。また、スプリントごとに目標を設定してレビューや調整をおこなうこととや、開発中に変更が起こることがあるため、ウォーターフォール開発よりもコミュニケーションコストが発生しやすいという点も注意が必要です。
どっちの開発手法を選ぶべき？
アジャイルとウォーターフォールの使い分け
ここまで解説してきた通り、アジャイル開発はプロジェクト進めながら柔軟に仕様を変更していく開発手法で、ウォーターフォールは予め固めた要件仕様書をもとに各工程を一つずつ順番に進めていく開発手法です。
それぞれ向き不向きがあるため、ここでは各開発手法はどのように使い分けるべきなのか、改めて解説していきます。
ポイントは「仕様変更があるか」
結論、開発手法を決めるポイントは、仕様変更があるかどうかです。
ウォーターフォール開発は最初に要件仕様を明確にし、それをもとに開発を進めていきます。そのため、作りたいものが決まっており仕様変更の可能性がない場合に適した開発手法であると言えるでしょう。例えば、大規模なシステム開発や建設プロジェクトなど、作業が明確に定義されている場合、コーポレートサイトやメディアサイトなどの一般的なWebサイトの場合はウォーターフォール手法での開発が向いています。
- ウォーターフォール開発が向いているプロジェクト
-
- 要件が明確で変更がないプロジェクト（基幹システムのリプレース等）
- リリース期限が明確に決まっている
- 大規模なシステム開発や建設プロジェクトなど、作業が定義されている
- コーポレートサイトやメディアサイトなどの一般的なサイト
一方、アジャイル開発は、最初に要件を固めず、ユーザーや顧客の反応を見ながら開発を進めていく手法です。そのため、仕様変更の可能性があるシステムやソフトウェアを開発する場合に適した開発手法と言えるでしょう。
例えば、作りたいもののイメージはあるがプロジェクトを進めながら固めていきたいケースや、優先度や作るものに変更の可能性があるケース、最初に一部の機能をリリースしてその後機能を拡張させていきたいなどの場合は、アジャイル手法での開発が向いています。
また、アジャイル開発はその特性上、プロジェクト開始時にスケジュールやコストの見通しがつきづらいです。そのため、リリース期限が明確に決まっているシステムや、予算が厳しいプロジェクトでは避けた方がよいでしょう。
- アジャイル開発が向いているプロジェクト
-
- つくりたいもののイメージはあるが、要件は不明瞭である
- スケジュールや予算が厳しくないプロジェクトである
- 比較的、小規模なプロジェクトである
- 優先度やつくるものが変わる頻度の高いビジネスである
- ユーザーの意見を反映させながら開発を進めたい
- 会員機能やフルスクラッチ開発が必要になりそうなWebサービス
両開発手法を組み合わせた「ハイブリッド開発」の検討もおすすめ
ウォーターフォール型とアジャイル型は相反するような開発手法のようにも思えますが、実は両者のメリットを取り入れた「ハイブリッド開発」というものがあります。
ハイブリッド開発では、要件定義と設計の段階ではウォーターフォール型のように段階的にプロジェクトを進めていき、その後の開発プロセスで、アジャイル型のようなスプリント単位での開発に切り替えます。開発プロセスでは小規模な開発チームで、各機能の開発〜テストまでを行うのが一般的です。
なお、スプリント間では、ウォーターフォール型の要素を取り入れて、チームが進捗管理や品質管理を行います。
ハイブリッド開発は、ウォーターフォール開発における変更への対応が難しいといったデメリットや、アジャイル開発における予算やスケジュールの不明確性といったデメリットを解消できるとして、多くの企業で採用されている開発手法です。
ウォーターフォール開発とは
ここまで紹介してきた内容のおさらいも兼ねて、ウォーターフォール開発とはどんなものなのか改めて見てみましょう。
ウォーターフォール開発はとても一般的な開発手法で、開発工程を上流工程から下流工程へ順番に進めていく開発方法です。水が下に落ちていく様を模し、ウォーターフォールという名前になっているそうです。
一般的には以下のような工程を経て、開発が進んでいきます。
| 要求定義 | 実装すべき機能や納期、必要な人員（工数などをまとめる） |
|---|---|
| 外部設計 （概要設計） |
システムの大まかな構造やユーザーインターフェース、データの保存や取得方法などを設計する |
| 内部設計 （詳細設計） |
外部設計で定義されたシステムの詳細な実装方法(プログラミング方法)を計画する |
| 開発 （プログラミング） |
設計内容を実装する |
| テスト | 作成したプログラムが正常に動くかをテストする |
| リリース | 旧システムから新システムに切り替える |
ウォーターフォール開発では、はじめに要件定義を詳細まで固め、その後は定義した内容をもとに順に開発を進めていきます。
例えばトップのデザインを作ってOKが出たら実装へ進むといったように進んでいき、同時に進めたりOKが出る前に実装を進めることは基本的にしません。
（ちなみによくウォーターフォールモデルはWFと略されることがあります。WFはワイヤーフレームの略語でもよく使われるので、注意が必要です。略語って難しいですね……）
このような進め方をするウォーターフォール開発は、開発の全体感が見えやすい・無駄な費用が発生しにくいなどのメリットがある一方で、最初に要件を固めるため後戻りがしづらい点や、実際に動くものを触れるまでに時間を要するといったデメリットがあります。
アジャイル開発とは
Agile（アジャイル）は、日本語で「素早い」や「敏捷」という意味があります。アジャイル型の開発ではスプリント（またはイテレーション）と呼ばれる、機能単位での「企画→設計→開発→実装→テスト」といった開発工程を繰り返して、短期間で素早く開発を進めていきます。
スプリントの期間は開発チームによって設定が変わりますが、1〜4週間程度が一般的です。
アジャイル開発では、あらかじめ厳密に仕様を決めないため、プロジェクトを進めながら柔軟に仕様変更・修正ができます。したがって顧客ニーズや市場変化が変わるケースでは、アジャイル開発が適していると言えるでしょう。
このような特徴から、開発チームは顧客ニーズを的確に捉える必要があり、プロジェクト進行時は密にコミュニケーションをとることが求められます。
さいごに
ここまで、ウォーターフォール開発とアジャイル開発の特徴や違いについて解説しました。
開発手法は一種のフレームワークですが完全に踏襲する必要はあまりなく、実際は企業の性質や案件によって若干のカスタマイズを行うことの方が多いと思います。
また、ウォーターフォールモデルは叩かれがちという印象がありますが、これは市場の変化が大きいのだと思います。刻一刻と変化する市場に対してウォーターフォールモデルではなかなか対応しにくくなってきていることが批判を生む要因の1つだと感じます。
いまのご時世だと日々変わるビジネス要求に対して、素早く開発も応えていけるようにする必要があります。これが、アジャイル開発が注目されている理由です。
ただ、ウォーターフォールモデルが完全にダメかというとそれは違います。
ビジネス要求の反映が重要で、ユーザーの意見が重視されるWebサービスやエンタープライズ向けの開発には向いていないかもしれませんが、コーポレートサイトやメディアサイトのようなデザイン性が重視されるものであれば、実装を並行しておこなわずともProttなどのプロトタイプツールを使うことで、擬似的に動くものを早い段階で確認してもらうことができます。
そのためウォーターフォールモデルを採用することで、確実にプロジェクトを進めることができます。
「どちらのほうが優れているか」というよりも「何をつくりたいのか」や、「どのようにつくっていきたいか」で手法を選択していくことが重要です。
LIGでは、制作するサイトのタイプによって手法を変えています。これまでの実績では、タイプは大きく下記の2種に分かれます。
- コーポレートサイトやメディアサイトなどの一般的なサイト
- 会員機能やフルスクラッチ開発が必要になりそうなWebサービスとなるサイト
前者ではウォーターフォールモデルを採用することが多く、後者だとアジャイル開発手法を取り入れることもあります。
案件の比率的には、コーポレートサイト制作やメディアサイト制作が多いため、ウォーターフォールモデルでの開発が多い印象ですが、完全にウォーターフォールモデルを踏襲しているかというとそうではなく、クライアントの承認フローや要望・納期などにあわせて柔軟に対応しています。
開発を検討中でしたら、ぜひお気軽にご相談ください。
ご相談はこちらから
関連記事
【同業者推薦】アプリ開発会社おすすめ18社の特徴と実績まとめ システム開発会社おすすめ18社｜大手・Web系など分野別で紹介
Michitoshi Kudo
Michitoshi Kudo
