ウォーターフォールモデルとは

ウォーターフォールモデルとは、ソフトウェア開発のプロジェクト管理手法のひとつです。
ウォーターフォールとは「滝」を意味しており、水が上から下に流れていくように、ソフトウェア開発の工程を細かく策定し、各工程を階層的に進んでいくように開発が行われていきます。
ウォーターフォール型開発モデルとも呼ばれます。品質を重視したシステム開発に適しており、伝統的な手法ですが、大規模開発などによく用いられています。
ウォーターフォールモデルでは、1つの工程が完了してから次の工程が開始されます。
おおまかな流れは、要件定義→基本設計→詳細設計→コーディング→テスト→リリース→保守といった流れです。

ウォーターフォールモデルの開発工程

ウォーターフォールモデルの開発工程では、前述したように、①要件定義 → ②基本設計 → ③詳細設計 → ④コーディング → ⑤テスト → ⑥リリース → ⑦保守という流れで開発が進められます。
要件定義から実装までを上流工程、テストから保守までを下流工程と呼ぶことがあります。

①要件定義

設計図があってはじめて家が建つように、どのような開発でも要件定義が必要です。
開発側と発注側とで求める要件をすり合わせていきます。このとき考慮される要件には大きくわけて２つあります。
業務要件とシステム要件です。システム要件はさらに２つにわけることができます。
機能要件と非機能要件です。これらの語句の簡単な説明は以下です。

業務要件	開発されるサービスが果たす目的を明確にします。システム利用者が求める業務のニーズやシステムの利用状況をふまえて、業務手順や入出力する情報を定義します。
システム要件	特定の業務要件を果たすためにシステムに求められる要件のこと。システム化する部分としない部分に分かれる。
機能要件	発注側が求めるシステムに絶対必要となる機能を決めること。
非機能要件	機能要件以外の機能。つまり機能面以外の要件全般のこと。パフォーマンスや拡張性、セキュリティなど、機能とは別で定義されるもの。

②基本設計

要件定義書をもとに、ユーザーの要件定義（システムに求める役割）を実現するため、開発側でシステムに実装する機能を明確にしていく工程です。
基本設計の作成をすることで、完成させるまでにどのような開発が必要で、関連する要素は何かということが整理されていきます。
開発側から顧客側に提示されるので外部設計と呼ばれることがあります。
成果物としては、業務フロー図、機能一覧、ネットワーク図、画面レイアウト、画面遷移図などが挙げられます。（ここに挙げたのは一部です）

システム操作画面をイメージして作成されます。ユーザー側からの意見を受けて、修正をしてから次の詳細設計の工程へと移ります。

③詳細設計

基本設計をもとに、現場で活躍するエンジニアのために、どのように機能を実装するのかを明確にしていく工程です。
エンジニアが何をするのかがはっきりし、開発側がプロジェクトを進めていくために必要なもので、内部設計と呼ばれることがあります。
成果物は、一部の例として、機能設計書、Webサーバー設計書、データベース設計書、パッチ処理設計書、処理フローなどがあります。
詳細設計以降の開発は外注されることもあるため、入念かつ理解しやすいものにする必要があります。

④コーディング

この工程で開発段階に入ります。要件定義で定められたプログラミング言語でコーディング（実装とも呼ばれる）が始まります。

⑤テスト

完成したプログラムコードが問題なく稼働するか、機能の使用中にエラーが発生しないかを確認していく工程です。
ここで、計画通りに稼働しないのであれば、詳細設計の際に定められた処理フローに沿って修正することになります。
合格するべきテストは４つあります。実装した各機能が単体で計画通り稼働するか確認する、単体テスト。
単体テストで合格した機能を連携させてテストする、結合テスト。
全体の機能を連携させて確認する、システムテストがあります。
最後に、本番環境でもエラーを起こさないか確認する受け入れテストがあります。
これらの４つのテストはどこかで不具合が見つかれば一つ前の段階に戻ってテストが行われます。

⑥リリース

テストが終わり、問題なく稼働することが確認されればリリースとなります。
新規案件でない場合は既存のシステムからの移行となります。
ユーザーが使えるように必要に応じてマニュアルの作成やトレーニングが行われます。

⑦保守

システムの運用をサポートします。
トラブルシュートや改修、仕様変更に伴う改善対応などを行っていきます。

ウォーターフォールモデルとV字モデル

ここではウォーターフォールモデルと関係が深いV字モデルについて説明します。V字モデルは以下の図のように表されます。

左側に上流工程である開発、右側に下流工程であるテスト工程が表されています。
開発の流れはウォーターフォールモデルと変わりありませんが、各開発工程と各テスト工程を関連づけて表記されることで、テストのレベルと対象範囲をわかりやすくしています。
これがあれば工程ごとに検証作業を効率よく進めることができ品質の向上につながります。

Ｖ字モデルを発展させたW字モデルもあります。これは、開発工程とテスト工程を同時進行していくものでウォーターフォールモデルの一種です。

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

ウォーターフォールモデルに対して、近年アジャイル開発という手法がよく用いられています。
アジャイル(Agile)には素早い、機敏という意味があります。
アジャイル開発とは、2000年代から導入されてきた開発手法で、大まかに計画を細分化して、要件定義・設計・実装・テストを何度も繰り返す手法で、あまり厳密な要件を定義せずに機能と仕様を大まかに決めていきます。
イテレーション（iteration）（もしくはスプリント（sprint））という小さな単位で、計画→設計→実装→テストの反復サイクルを繰り返し行っていきます。
イテレーションの期間はおおよそ1週間から2週間ほどで、短期間で機能をリリースして、ユーザーの要望をとりいれつつ品質を高めていきます。

アジャイル開発では、小さなサイクルを繰り返すため、修正や仕様の変更に素早く対応できますが、開発期間全体のスケジュール管理は難しくなる特徴があります。

アジャイル開発はソフトウェアの開発とリリースのサイクルを早めるために用いられます。
故に、開発中に仕様の変更や追加が予想されるプロジェクトに向いています。
具体的にはアプリやゲームなどのニーズが早いスパンで変化するようなプロジェクトです。
一方、ウォーターフォールモデルは要件が明確で、変更が少ないプロジェクトで引き続き用いられています。
具体的には、大規模な基幹システム開発などです。

以下はウォーターフォールモデルとアジャイル開発の具体的な違いを表にまとめたものです。

	ウォーターフォールモデル	アジャイル開発
手法	上流工程から下流工程へという流れで開発が行われる	大まかな計画を細分化し、要件定義・設計・実装・テストを繰り返す
メリット	きめ細かな要件定義を行えるので ・予算や人員確保がしやすい ・全体スケジュールが管理しやすい ・プロジェクトを安定して進められる ・多くの開発ベンダーが対応できる	・開発とリリースのサイクルを早めることができる ・仕様変更やトラブルに対応しやすい
デメリット	・トラブル修正や仕様変更に時間、コストがかかる ・開発途中で顧客の要望を取り入れにくい ・完成までに時間がかかる	・開発期間全体のスケジュールが管理しにくい ・開発の方向性がぶれることがある
適しているプロジェクト	基幹システムなどの大規模開発	開発中に仕様の変更・追加が予想されるプロジェクト

ウォーターフォールモデルとアジャイル開発にはほかにも次のような違いがあります。1つ目は、企画段階における違いです。
ウォーターフォールモデルでは、最初の企画段階ですべての機能が決定します。
場合によっては顧客の要求によって仕様変更することがありますが、基本的には企画段階での仕様を優先して開発が進みます。
対して、アジャイル開発ではイテレーションごとの開発サイクルとなるため、新たな要求が登場した場合は、次のイテレーションで対応するかどうか決めていきます。

２つ目は開発段階での違いです。
ウォーターフォールモデルでは、開発工程によって分業がされているので要件定義からリリースまでを見届けるメンバーは少ないですが、
アジャイル開発では、企画からリリースまで開発メンバーが変わらないことが多いです。

ウォーターフォールモデルのメリット

ここではウォーターフォールモデルのメリットを4つ紹介します。

■進捗管理がしやすくなる

ウォーターフォールモデルでは、要件定義で必要とされるタスクが洗い出されます。
行うべきタスクが明確になっているので、進捗が把握しやすく、どのタスクで人員が必要になるのか事前に判断できるため人員調達もしやすくなります。

■高品質を保ちやすい

ウォーターフォールモデルでは、開発前に詳細なスケジュールが決定しており、各工程であらかじめタスクが決められているので品質を高く保つことができます。
機能・予算・納期が明確になっており、プロジェクトを安定して進められるからです。また、開発者の交代があっても引継ぎをスムーズに行うことができます。
また古くから使われている手法なので多くの開発ベンダーが対応できます。

■予算やリソース計画がたてやすい

ウォーターフォールモデルでは、上流工程で入念な計画が立てられるので、開発の初期段階から、各工程の開発やテストにかかる期間や工数が予想しやすくなります。

■開発の方向性がぶれにくい

ウォーターフォールモデルでは、開発の初期段階から最終敵な目標が明確になっています。
そのため、開発チーム全体が最終的な目標を意識しながらプロジェクトを進めることができるので、方向性がぶれることを避けられます。

ウォーターフォールモデルのデメリット

ここではウォーターフォールモデルのデメリット・弱点を３つ紹介します。

■開発途中で要件または仕様を変更しにくい

ウォーターフォールモデルでは、プロジェクト全体の流れや工程が最初に決まっています。
原則として開発途中の仕様変更は発生しないという前提で開発計画や要件定義が実施されます。
そのため、顧客から仕様の変更や追加があった場合には、本来の順序に逆らって工程をもどさなければならず、工程が複雑になり、最終的な成果物が顧客のイメージと違うということが起こることがあります。
こうした事態を避けるためには、要件定義の段階で顧客との認識を一致させておくことが必要です。

■実際に動く成果物ができるまでに時間がかかってしまう

ウォーターフォールモデルの性質上、実際の開発は設計を完全に終えてからになるので、実際に動く成果物を確認するまでに時間がかかってしまいます。
また、開発が始まっても、それぞれの工程を終えてからでなければ、次の工程に進めないので、全体的に時間がかかってしまいがちです。
現在は、顧客のニーズが日々変化していく時代です。開発途中での仕様変更が難しいウォーターフォールモデルは、顧客の要望が変化しやすいスマホアプリ開発などには不向きといえます。

■手戻りによる工数の増加

ウォーターフォールモデルでは、上流工程で綿密な仕様が設計されますが、仕様通りにできていない「抜け」が発覚したり、開発途中での仕様変更が発生することがあります。
仕様変更や手戻りが発生すると、前工程に戻ることになるので、工数やコストが余計に発生します。本来の順序に逆らうことになるので、ウォーターフォールモデルでのプロジェクトでは、想定以上に工数がかかる可能性があります。
結果、全体のスケジュールが遅れ、成果物の納品が後ろ倒しになることがあります。
手戻りが発生した場合は、顧客に伝え、納期やコストを相談する必要があります。

まとめ

ウォーターフォールモデルは、水が上流から下流に流れていくように、各工程を階層的に進めていきます。
①要件定義 → ②基本設計 → ③詳細設計 → ④コーディング → ⑤テスト → ⑥リリース → ⑦保守という流れを踏みます。
要件や仕様の変更が少ない大規模開発に向いています。
人員の調達の容易さや予算・工数計画の立てやすさといった、ウォーターフォールモデルのメリットを活かしていくなら、ある程度の品質を担保しやすくなることでしょう。
一方で、手戻りが発生した際の工数の増加を考慮すると、要件や仕様の変更が多いプロジェクトには向きません。
現在は、ウォーターフォールモデルとアジャイル開発を組み合わせたハイブリッド開発も注目を集めています。
ハイブリッド開発では、ウォーターフォールモデルの計画の立てやすさを活かして、検証工程での品質を担保し、アジャイル開発の顧客のニーズを取り入れる特徴を活かして、開発側と発注側の認識の齟齬を減らすことができるようになります。

お問い合わせはこちら