こんにちは。
「ウォーターフォール開発」はソフトウェア開発現場でよく用いられる開発手法の1つです。特にSIerの請負開発ではデファクトスタンダートと言ってもよいほど、よく用いられています。
しかし、「ウォーターフォール開発の名前をよく聞くけれど、実際のところはよく分からない」というエンジニアも多いのではないでしょうか？
この記事では、ウォーターフォール型開発とアジャイル開発の違い、ウォーターフォール開発の工程、メリットと問題点について解説します。
目次
ウォーターフォール開発とアジャイル開発
ソフトウェア開発の方法には、主に「ウォーターフォール開発」と「アジャイル開発」があります。
それぞれの開発方法について、以下で概要を説明します。
ウォーターフォール開発
ウォーターフォール開発は、設計、プログラミング、テストなど、各開発工程を時系列に並べて開発を進める開発方法です。
SIerなどが行う請負開発でよく用いられる開発方法です。
特徴としては以下の通りです。
- 開発工程の完了をもって、次の工程に進む（工程を1つずつ終わらせる）
- 核開発工程では成果物（開発ドキュメントやプログラムなど）を作成し、次工程以降のインプットとする
- 前の工程に戻らない前提で開発を進める
ソフトウェア開発手法としては古典的な手法で、前の工程に戻ることなく滝のように落ちるイメージから「ウォーターフォール」と呼ばれています。
「前の工程に戻らない」という前提で進めるため、成果物についてはレビューを通じて抜け漏れがないことを厳しくチェックします。そして、責任者や開発者と依頼者が双方で確認し、合意の上で次の工程に進むという前提で開発を進めていきます。
とはいえ、仕様相違や仕様変更で前の工程に戻ることがあります。これを「手戻り」と言います。
アジャイル開発
「アジャイル開発」は、機能単位など、小さな単位で開発とテストを繰り返し、開発を進めるソフトウェア開発手法です。なお、「アジャイル（Agile）」とは「素早い」、「機敏な」という意味です。
ウォーターフォール開発が「設計、コーディング、テストと開発工程単位で開発を進める」のに対し、アジャイル開発は「機能単位で設計、コーディング、テストで進め、小さなサイクルでそれを繰り返す」という特徴があります。
アジャイル開発は小さなサイクルで開発を進めるため、手戻りが発生しても少ない影響範囲で対応することができ、リスクを小さく抑えながら開発を進めることができるメリットがあります。
ウォーターフォール開発の工程
ウォーターフォール開発は、「要件定義」、「基本設計」、「詳細設計」、「コーディング」、「単体テスト」、「結合テスト」、「総合テスト」、「受入テスト」、「移行・リリース」の9つの工程を順番に進めます。
それぞれの工程について解説します。
要件定義
「要件定義」は、クライアントにヒアリングしながら、業務分析、開発対象の機能、性能などを定義します。そして、要件定義書としてまとめ、認識に齟齬がないかをクライアントとレビューを通じて確認し、双方合意の上で次の工程に進みます。
なお、要件定義のポイントは、「開発対象の機能要件や性能要件など、要件をどれだけ明確に定義することができるか」です。要件定義書が基本設計のインプットとなるため、要件定義が曖昧だと、設計以降の工程で多くの手戻りが発生します。
また、クライアントの言葉をそのまま要件定義書に記載するのではなく、言葉の裏に隠れた「本当に解決したい課題」や、「想定される問題点」を要件定義書に盛り込むことで、手戻りが少なくなります。
基本設計
「基本設計」は要件定義で洗い出された要件(機能や性能など）を実現するためのベースとなる設計を行う工程です。
要件定義書をインプットとして、主に以下のことを設計します。
- データベース設計（オブジェクト構成や項目定義など）
- 機能設計（機能一覧、各機能の相関関係、各機能の動作概要、共通クラスの動作概要など）
- ミドルウェア設計（DBなどの各種ミドルウェアの設定値など）
これらの設計をまとめたドキュメントが基本設計書です。基本設計書は以降の工程のベースとなるため、矛盾が生じないよう厳しくレビューします。
そして、クライアントとのレビューで双方合意したら基本設計の終了となります。
詳細設計
「詳細設計」は、開発者やプロクマラマに向けて、プログラムの動作や処理内容、エラーや例外が発生したときの処理方法などを詳細設計書としてまとめます。
プログラマは詳細設計書をもとにプログラムを作成します。このため、プログラマ目線で詳細設計書を作成することが必要で_す。
コーディング
「コーディング」はプログラマが基本設計書や詳細設計書わもとに、実際にプログラムを作成する工程です。成果物はプログラムコードとなります。
プログラム作成後には、バグ（不具合）を除くため、上級プログラマと一緒にソースコードレビューを行います。
単体テスト
「単体テスト」は、プログラムが詳細設計書に書かれた通りの処理を行うかどうかをプログラム単体でテストします。成果物はテスト結果のエビデンスとなります。
特に例外処理は後工程ではテストを行うことご難しいため、ツールを使って単体テストでしっかりと行うことが必要です。
結合テスト
「結合テスト」は、単体テストでOKとなった機能同士を結合させ、仕様通りに動作するかを確認する工程です。
テスト仕様書は基本設計書をもとに作成します。また、成果物はテスト結果のエビデンスとなります。
機能間でのパラメータのバグなど、単体テストでは問題のなかった動作も、結合テストで発見されるバグが多くあります。また、機能間の認識相違などに起因したバグも多く、仕様の見直しなどの「手戻り」も発生します。
総合テスト
「総合テスト」は、システム全体を結合させて要件定義に基づき、以下の観点でテストします。
- 業務要件通りに業務を回すことが出来るか？
- 性能などの非機能要件を満たしているか？
ここでの不具合は、基本設計の見直しなど、手戻りが大きいものとなります。完了基準を満たすと、次の工程に移ります。
受入テスト
「受入テスト」は、クライアントがテストを実施し、開発されたシステムを受け入れ可能かどうかを判定するためのテストです。
ここでの不具合は要件定義の見直しにつながるなど、スケジュールに大きな影響を及ぼす場合があります。このため、慎重に対応する必要があります。
受入テストが完了基準を満たすと、いよいよ最終工程の「移行・リリース」です。
移行・リリース
「移行・リリース」は、開発したシステム、そして顧客などのデータを旧システムから新システムへ移行する工程です。休日などを使って一気に切り替える、または徐々に移行するなどの方法があります。
移行を行うにあたっては、トラブルを起こさないために、あらかじめ「移行計画」を立て、「移行リハーサル」を行うことが必要です。そして、移行リハーサルで発生したトラブルは、移行計画を修正します。このように、移行時にトラブルを起こさないよう、慎重に対応します。
そして、移行が完了したら、ユーザーに開発システムをリリースして本番稼働となります。
ウォーターフォール開発のメリット
ウォーターフォール型のメリットは、「全工程を通じて計画を立てやすい」のが最大のメリットです。
要件定義で開発するシステムの機能要件や性能要件を洗い出すため、工程全体で必要な開発工数やスケジュールを見積もることができます。
あらかじめ必要なタスクを洗い出しておいた上で開発を進めるため、「進捗管理を行いやすい」のもメリットの1つです。また、工程を完了させてから次の工程に移る為、コーディング工程など、「開発者を多く必要とする工程に要員が参画しやすい」メリットもあります。
このため、開発工程全体を請け負い、開発を行うSIerがよく用います。
ウォーターフォール開発のデメリット
一方、デメリットは、「要件定義は最初しか行わず、前の工程に戻らない前提で進めるため、変更が生じたときに手戻り工数が大きくなる」点です。特に総合テストや受入テストで変更が生じた場合、基本設計や要件定義まで戻る必要があります。こうなると、場合によってはスケジュールの延長やクライアントとトラブルにつながることがあります。
「少しだけ戻るということができない」ことが、ウォーターフォールの弱点です。
まとめ
この記事では、ウォーターフォール型開発とアジャイル開発の違い、ウォーターフォール開発の工程、メリットとデメリットについて解説しましたが、いかがでしたか？
ウォーターフォール開発は、開発プロセスを工程毎に区切り、後戻りしない前提で計画を立てて開発を進めます。あらかじめ開発工数や要員計画を立てるため、開発全体のスケジュールを見通すことができ、要員調達も計画的に可能となる点がメリットです。そのため、SIerの請負開発や大規模プロジェクトではよく用いられます。
その一方で、ドキュメントをしっかりと書かないと完了できないため、作業工数が膨れる傾向にあります。また、後工程になればなるほど、変更が発生すると手戻りが大きくなる点がデメリットです。
開発要件、開発規模によって、ウォーターフォール開発は適・不適があります。要件に合った開発プロセスで進めていきましょう。
