ウォーターフォールモデルとは?
ウォーターフォールモデルとは何かについてまずは解説します。ウォーターフォールモデルと並び代表的な開発手法のアジャイル開発についても説明します。
ウォーターフォールモデルの定義
ウォーターフォールモデルとは、要件定義・設計・開発・テスト・リリース・運用というシステム開発の各工程を順番にこなしていく手法であり、多くの企業で導入されています。ウォーターフォールは日本語で「滝」という意味であり、上から下まで水が流れる滝のように、システム開発を上流工程から下流工程まで順番に行います。
ウォーターフォールモデルには、工程を飛ばさない、各工程が正常に完了していることを確認したうえで先に進める、というルールがあります。たとえば、要件定義を済ませた後も要件定義書を作成し、次の設計へと移って良いか顧客や上層部に確認を取る必要があります。
もし設計に入った段階で問題があると判明した場合、再度要件定義からやり直さないとならず、工数が多くかかってしまいます。そのため、ウォーターフォールモデルでは各工程を丁寧に行う必要があります。
アジャイル開発との違い
アジャイル開発とは、要件定義からテストまで短いスパンで何度も繰り返し行う手法であり、Web系企業などで多く導入されています。ウォーターフォールモデルと並んで代表的な開発手法です。アジャイルとは日本語で「素早い」という意味であり、開発を素早く行うことに主軸を置いたやり方と言えます。
アジャイル開発では、要件定義からテストまで1周した後、システムの顧客やユーザーに公開しシステムの改善点を指摘してもらいます。その後、指摘された改善点を盛り込んだうえで要件定義を再度行い、システムの完成度を高めていきます。
アジャイル開発は顧客やユーザーの意見を取り入れやすいのがメリットです。反面、納得するまで要件定義からテストまで繰り返すため、プロジェクトがいつ終了するのか見積もりを立てにくいのが難点と言えるでしょう。
ウォーターフォールモデルの各工程について
ウォーターフォールモデルは各工程を1つずつ順番にこなしていくのが基本です。ウォーターフォールモデルの各工程で具体的に何の作業を行うのかについて解説します。
要件定義
要件定義とはシステムに欲しい機能を定義し要件定義書にまとめることです。顧客や上層部と打ち合わせを行い、どのようなシステムにしたいのか、最低限必要な機能は何か、競合サービスと差別化を図るために必要な機能は何か、などをヒアリングします。
エンジニアはその機能が実現可能なのか、あるいはもっと良い機能はないのかなどを助言します。何度か打ち合わせを行い、システムの機能を完全に定義します。
設計
続いて、要件定義書を元にシステムの設計を行います。設計は外部設計と内部設計に大きく分かれます。外部設計ではシステムの目に見える部分の設計を行います。たとえばWebアプリなら、各Webページにどのような情報を表示させるか、どのようなボタンを追加するか等を決めます。
内部設計では、システムの裏側の設計を行います。たとえば、Webページに表示させる情報を作成するためのプログラムやデータベースを設計します。
設計した内容は設計書にまとめます。設計書をどの程度細かく書くかは企業にもよりますが、プログラマーが迷いなくプログラミング作業を行えるように記述するのが基本です。
開発
続いて、設計書を元にプログラマーがプログラミングを行います。アルゴリズムやソースコードの読みやすさも意識しつつ、各プログラムを作成していきます。設計書が問題なく作成されていれば、開発作業自体はすぐ終わることがほとんどです。
テスト
プログラムが一通り完成したらテストフェーズに移ります。最初に1つのプログラムやモジュール単位で正常に動くか確かめる「単体テスト」を行い、次に2つ以上のプログラムが正常に連携やデータ渡しを行えているか確かめ、最後にすべてのプログラムを統合し実際にユーザーが使うことを想定して確認する「結合テスト(統合テスト)」を行います。
バグやユーザーにとって使いにくい点が見つかった場合、すぐに修正を行います。修正したら再度テストを行い、問題が解決しているか、他の箇所に影響を及ぼしていないか確かめます。
受け入れテスト
開発企業内でテストとして問題なければ、次は顧客の環境で受け入れテストを行う必要があります。受け入れテストでは実際のサーバやデータを使って確認しなくてはいけないため、顧客に協力してもらわなくてはいけません。
リリース
受け入れテストまで行い問題なければリリースします。事前に作成したリリース手順書に従って、他のシステムやサービスに影響を及ぼさないよう慎重にプログラムを公開します。リリース後は再度テストを行い、問題が見つかればすぐに公開を中断して修正を行います。
運用・保守
システム開発後は運用・保守を行う必要があります。運用・保守ではシステムが正常に動作するか検証したり、問題のある箇所や問題が起きそうな箇所を修正したりします。基本的に、システム開発を行った企業が運用・保守まで継続して担当する場合が多いです。
以上が、ウォーターフォールモデルの基本的な流れとなります。ウォーターフォールでは要件定義から運用・保守まで順番にこなしていき、途中で順番を替えたり後戻りしたりすることはありません。
ウォーターフォールモデルのメリット
ウォーターフォールモデルを導入するメリットを解説します。ウォーターフォールモデルは多くの開発企業で導入されていますが、それは次のようなメリットがあるためです。
見積もりを立てやすい
ウォーターフォールモデルでは各工程をシンプルにこなしていくため、プロジェクト開始前に見積もりを立てやすいです。各工程でどの程度の期間がかかるか想定しやすく、納期に間に合いそうか判断できます。もし納期に間に合いそうにない場合、開発の一部を他企業に外注したり、従業員を増やしたり事前に対策が取れるのもメリットでしょう。
また、開発にかかる予算も算出しやすいため、システム開発を依頼する側からすれば、想定以上に予算がかかってしまう心配が少ないのもメリットです。
手戻りを減らせる
ウォーターフォールモデルは各工程の終了時に問題がないか確認を取るため、手戻りを減らせるメリットもあります。システム開発では、開発途中で設計に無理があったり技術的に不可能な機能があったりすることに気がつき、要件定義からやり直さないといけない場合もあります。
その場合、開発が納期に間に合わなくなったり、開発コストが多くかかることで、顧客満足度を下げることに繋がりかねません。ウォーターフォールでは手戻りを減らせるため、こういったリスクをなくすことが可能です。
作業を分業化しやすい
ウォーターフォールモデルは各工程の見積もりを正確に立てられるため、作業を分業化しやすいのもメリットです。各工程にどの技術が必要かも事前に分かるため、適切に人材を割り当てることができます。
作業の分業化が上手くいかないと、特定の従業員の業務量が増えすぎたり、向いていない仕事を任せてしまう恐れもあります。
ウォーターフォールモデルのデメリット
続いて、ウォーターフォールモデルのデメリットについて解説します。システム開発の種類によってはウォーターフォールモデルでは相性が悪く、アジャイル開発など他の開発手法を取り入れた方が良い場合もあります。
顧客の意見を取り入れにくい
ウォーターフォールモデルはシステムが完成してから顧客に見せるため、顧客の意見を取り入れにくいのがデメリットです。一方アジャイル開発では、何回も顧客に見せて改善点を指摘してもらえるため、顧客の意見を反映したシステムにしやすく、顧客満足度の向上が期待できます。
ウォーターフォールモデルを導入する場合、要件定義の時点でしっかり顧客の要望をヒアリングし、本当にこの機能で問題ないか確かめる必要があるでしょう。また、顧客がシステムの仕様を正しく理解していない可能性もあるため、システムについてイラストや図を用いてわかりやすく説明することも大切です。
工数がかかる
ウォーターフォールモデルの場合、1つ1つの工程を順番にこなしていくためどうしても工数がかかります。各工程が終了する度に上層部に確認を取る必要があるため、フットワークが軽いとは言えないでしょう。
そのため、開発スピードが要求される分野とウォーターフォールモデルは相性が悪いです。たとえばWebアプリ開発は、トレンドに合わせて柔軟にサービスを改良しないといけないため、ウォーターフォールでは開発の遅さがネックになる可能性があります。
ウォーターフォールモデルの今後について
「ウォーターフォールモデルは古い」という意見もあります。確かに昨今はIT技術の進化により、ユーザーの意見をよりシステムに取り入れられるようになったため、アジャイル開発を採用する企業も増えています。たとえばゲーム開発分野でも、最近のスマホゲームはリリース後にSNSでの評判も取り入れて改良を重ねていくことが多いです。
とはいえ、ウォーターフォールモデルが必要ないものになる可能性は低いでしょう。長年使われ続けてきた手法ですし、確実性の高いプロジェクトに対して有効なことは変わりません。エンジニアの方は、ウォーターフォールでもアジャイルでも対応できる柔軟さを持つことが肝心と言えるでしょう。
ウォーターフォールモデルはシステム開発の代表的手法
本記事ではウォーターフォールモデルとは何かについて解説しました。ウォーターフォールモデルの各工程やメリット・デメリットなどがお分かりいただけたかと思います。
ウォーターフォールモデルはシステム開発の代表的手法であり、多くの企業で導入されています。Webアプリやスマホアプリなど仕様変更が多発する開発には向いていませんが、その他の大規模開発には適した方法と言えるでしょう。本記事がウォーターフォールモデルについて知見を深めたい方にとって有意義なものとなれば幸いです。
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから