ウォーターフォール開発とは、システム開発やソフトウェア開発などで用いられている開発手法の一つです。プロジェクトの最初の段階で要件定義や機能、仕様、工程などの詳細をすべて決めた上で作業を進めていく点が特徴です。この記事では、ウォーターフォール開発の概要やメリット、具体的な進め方などについて解説しています。また、よく比較されるアジャイル開発との違いやウォーターフォール開発が時代遅れと言われる理由などについても取り上げているため、ぜひ参考にしてください。
ウォーターフォール開発とは
ウォーターフォール開発とは、主にシステム開発やソフトウェア開発などのプロジェクトにおいて用いられている開発手法の一つです。
ウォーターフォールは英語で「滝」を意味する「Waterfall」であり、その言葉の通り滝が上から下へと流れるように作業工程を上流から下流へと順に沿って行われていく点が特徴です。そのため、ウォーターフォールで開発を進める場合、要件定義を行った上で設計を行い、製造後にテストを行う手順で進みます。基本的に工程をスキップしたり入れ替えたりすることはありません。要件定義の段階でいかにしっかりと詳細を詰められるかどうかがその後の作業をスムーズに進められるかを大きく左右します。
現在の開発環境においては、より柔軟性の高いアジャイル開発が主流になりつつありますが、それでもウォーターフォール開発も様々なプロジェクトで採用されています。中でも規模の大きい開発やシステムの品質を特に大切にしている案件などです。
ウォーターフォール開発の歴史
ウォーターフォール開発は、1968年にNATOがドイツで開催された国際会議にて工業製品的手法で開発を行う方法として提案された開発モデルが原型とされています。その後1970年にWinston Royce博士が発表して論文で、ハードウェア開発で使用されている開発手法に似た開発プロセスが提唱され、これが現在のウォーターフォール開発へとつながっています。
ウォーターフォール開発とアジャイル開発との違い
ウォーターフォール開発とよく比較される開発手法の一つにアジャイル開発がありますが、両者はそれぞれ異なる特徴を持つものです。ここでは2つの開発手法はそれぞれどのように異なるのか、その違いを解説します。
開発工程の違い
ウォーターフォール開発は開発工程が固定されているのに対して、アジャイル開発はプロジェクトをいくつかの開発段階に分けて細かく進めていくため柔軟に対応できる点に違いがあります。
ウォーターフォール開発は、プロジェクトの最初の段階ですべての工程を決めており、一つの工程が完了すれば、事前に設定した次の工程へと進む仕組みです。一度終えた工程に戻って作業をやり直すことは基本的にありません。また、各工程においては担当者が決められています。
一方のアジャイル開発では、プロジェクトを機能やサービスなど様々な形で分類した上で開発を進めます。つまり、プロダクト全体を細かく分け、複数のサイクルでスピーディに進めていくものといえます。こちらは、分類ごとに開発を進めていくため、フィードバックなどを受けて小さな単位で改善を繰り返し行いやすい点が特徴です。
時間の違い
ウォーターフォール開発は比較的時間がかかるのに対して、アジャイル開発は素早く開発が進んでいく点で違いがあります。ウォーターフォール開発は、先ほども説明しているように、最初の段階ですべての工程などを細かく決めた上で作業を進めていくため、どうしても時間がかかってしまいます。また、工程単位で生活物に対する合意がないと次の工程に進めない点も時間がかかる要因の一つです。
一方のアジャイル開発は工程を細かく分類しそれぞれを進めていく形であり、優先順位の高い作業から順に取り組むため、開発全体の時間は短くなりやすいといえます。
担当者の役割
担当者の役割もウォーターフォール開発とアジャイル開発で違いがあります。ウォーターフォール開発は、各工程に担当者が割り当てられている点が特徴です。担当者は自分の割り当て分のみ作業を行います。特定の範囲でしか作業が発生しないため、集中して取り組みやすいほか、各担当者のスキルや得手不得手を踏まえた上での割り振りが可能です。
一方のアジャイル開発は、エンジニアは特定の専任担当とはならず、開発工程全般において様々な作業を担当します。カバーする範囲が広いため、マルチなスキルが欠かせません。
ウォーターフォール・アジャイル以外の開発手法
プロダクト開発においては、ウォーターフォールやアジャイル以外にも様々な開発手法があります。ここでは具体的にどのような開発手法があるのか解説します。
プロトタイプ開発
プロトタイプ開発は、その名の通りプロトタイプを一度制作した上でその後の開発作業を進めていく開発手法です。具体的には、要件定義ができしだいプロトタイプを開発し、それをクライアントに確認してもらった上で本格的に実装作業に入ります。プロトタイプ開発後に一度クライアントの確認が入るため、要件定義の不備を修正しやすいほか、プロダクトに対する認識の齟齬がないか早い段階で確認できる点が特徴です。開発工程の後半段階で修正しなければならなくなるケースが起こりにくいため、結果的に開発コストを抑えやすいといえます。
スパイラル型開発
スパイラル開発はプロダクトの機能単位で設計・開発・テストを行い、作業を進めていくものです。先ほど紹介したプロトタイプ型開発との違いは、システムの全体像の捉え方が異なります。一方のプロダクト型開発はプロダクト全体を設計した上でプロトタイプを作ります。最初の段階からプロダクトの全体像を意識している点で違いがあるといえます。
ハイブリッド開発
ハイブリッド開発とは、ウォーターフォール開発の特徴とアジャイル開発の特徴を組み合わせた手法のことです。ウォーターフォール開発同様、最初の段階では計画を入念に立て、基本的にはその計画に沿って進めていきます。しかし、アジャイル開発に倣い開発の途中段階でもクライアントからのフィードバックを受け取ることもあります。具体的には、基本設計まではウォーターフォールで行い実装やテストなどはアジャイルで行う流れです。双方の良いところを取り入れることで、経過に沿って開発を進めつつ、柔軟な対応ができる点が大きな特徴です。
ウォーターフォール開発の手順
ここではウォーターフォール開発を進めるにあたってどのような手順で行うのか解説します。ウォーターフォール開発は最初の段階で計画を明確にした上でそれに沿って作業を進めていくため、手順の正確な理解が非常に重要です。ウォーターフォール開発を業務で採用している方、今後採用する可能性のある方などはぜひ参考にしてください。
要件定義
ウォーターフォール開発で最初に行うのが要件定義です。要件定義は、開発するシステムがどのような機能や特徴を持っているのか、開発にあたってどのような条件があるのかを明確に決めることです。開発の指針といっても過言ではないため、要件定義が明確でないと、その後の開発工程やスケジュールなどにも大きな影響を与える可能性があります。そのため、要件定義に取り組む際は、ステークホルダーとすり合わせを行ってください。打ち合わせを通してどのような機能を求めているのか、プロダクトを通して何を実現したいのかがわかれば、要件定義もスムーズに進められます。
外部設計
要件定義ができたら、次に決めた内容に沿って外部設計を行います。外部設計とは、開発するソフトやシステムのUIやシステムアーキテクチャ、データ入力方法、画面操作イメージなどの設定を行うことです。要件定義で決められた機能を実現するためにはどのようなシステム構成にする必要があるのかを検討します。
内部設計
外部設計に続いて内部設計を行います。内部設計とは実際にプロダクトを開発するにあたって外部設計で決められた必要となる細部を決めることです。つまり、外部設計で決められたシステム構成を実現するためにどのような実装方法にすべきなのか、具体的に設計する工程だといえます。例えば、プログラムのモジュール化やアルゴリズムの設計、データ構造の設計などがこの内部設計に該当します。
実装
内部設計ができたら、引き続き実装を行います。この工程は、実際にプログラムの作成を行う段階です。内部設計で決められた設計に沿ってプログラミング言語などを使ってプログラムを書いていきます。規模の大きいプロジェクトとなると、実装段階で何人ものプログラマーで作業を分担しながら作業を進めていくケースが一般的です。
単体テスト
実装を行ったら単体テストを行います。これは、ここまでで作成したそれぞれのプログラムが要件定義で設定された機能や性能をクリアしているかどうかを確認する工程です。各プログラム単位でテストケースを用意した上で、問題なく動いているかどうかを確認してください。
結合テスト
単体テストを踏まえて結合テストを行います。これは、各プログラム単体でのテストが問題なければ複数のプログラムを組み合わせた状態でも問題なく動くかどうかを確認する工程です。単体テスト同様テストケースを用意し、実際の動作状況を確認します。結合テストでは、最初に行った要件定義の機能を満たしているかどうかも確認しなければなりません。
システムテスト
結合テストを経て、プロダクトが完成したらシステムテストを行います。これは、実際に開発したソフトウェアが要件定義の際に想定していた通りに動くかどうかを確認する工程です。システムテストはソフトウェアの品質保証を目的として行われます。ソフトウェアの構造は非常に複雑であり、プロダクトの規模が大きくなると開発過程で予期せぬ不具合が起こる可能性はゼロではありません。場合によっては、リリースをした後で不具合が発覚し、大きなトラブルにつながるケースも想定されます。そういったリスクを回避するためにも、開発が完了した段階でシステムテストを実行し、様々な角度からプロダクトの動作状況を確認しなければなりません。
リリース
システムテストでも動作などに問題がないようであれば、晴れてシステムリリースです。ただし、リリースして終わりではなく、リリース後もシステムが問題なく運用されているか保守・運用に気をつける必要があります。また、品質に関するフィードバックがあれば、適宜改善を検討し、より良いシステムの提供に努めていかなければなりません。
ウォーターフォール開発のメリット
ウォーターフォール開発には様々なメリットがあります。ここでは具体的にどのようなメリットがあるのか解説します。これからウォーターフォール開発を採用する可能性のある人はぜひ参考にしてください。
進捗状況を把握しやすい
ウォーターフォール開発のメリットの一つが、進捗状況の把握のしやすさです。これは、ウォーターフォール開発では事前にシステムの機能や作業工程、各担当者の役割などをすべて明確にしてから開発を始めることで、スケジュールの予想を立てやすく、どのタイミングで何をやっているかをある程度想像しやすいためです。
一定以上の品質を確保しやすい
品質を確保しやすい点もウォーターフォール開発の大きなメリットです。ウォーターフォール開発は最初の段階でどのような機能を備えた、どのような仕様のシステムを開発するのかといった細かい部分を決めた上で作業を始めます。そのため、事前に決めた内容通りに開発を進めていけば一定の品質以上のプロダクトを作れる可能性は高まります。品質の確保は、クライアントに満足してもらえる可能性が高くなるだけでなく、開発チームにとっても大きな手戻りなどが起こりにくいため双方にとって大きなメリットです。
予算や人員の手配を行いやすい
事前に入念な計画を立てることから、ウォーターフォール開発は予算や人員を手配しやすい手法だといえます。例えば、具体的な作業方法や内容が決まっていれば、どのくらいの人員がどのくらいの日数必要なのかも明確です。そのため、予算や人的リソースの事前手配が可能です。後になって追加でコストが必要になるケースは起こりにくいといえます。
人材育成がしやすい
ウォーターフォール開発は、各工程に担当者がつく形となるため、人材育成をしやすい手法だといえます。アジャイル開発の場合、様々な工程に携わることとなるため、知識やスキルがあり、柔軟に対応できなければなりません。一方のウォーターフォール開発は決められた作業以外は基本的に発生しないため、一つひとつの作業に集中して丁寧に取り組めるため、特定のスキルを身につけさせるときに有用です。
様々な開発に応用できる
ウォーターフォール開発は、長年にわたって用いられている手法であり、様々な開発に応用できる点が特徴です。プロダクトの開発要件が明確になっていれば、基本的にはどの開発にも対応できます。ウォーターフォール開発のやり方を押さえておけば、プロダクトに応じて開発手法を変更したり、新しい手法を調べたりする手間もかかりません。
ゴールが明確になる
ウォーターフォール開発では、最初にプロダクトの仕様などをすべて決めるためゴールが明確です。ゴールをプロジェクトチーム内で共有しておけば、認識の齟齬による作業のミスなどが起こるリスクも低くできます。常にゴールを意識して作業できる点も大きな特徴だといえます。
ウォーターフォール開発の注意点
メリットの一方でウォーターフォール開発にはいくつかの注意すべき点があります。ここでは具体的にどのような注意点があるのか解説します。メリットと合わせて覚えておいてください。
開発期間が長期化する恐れがある
ウォーターフォール開発は、最初の段階で入念に計画を立てるため、開発期間が長期化する可能性があります。また、各工程の成果物を担当者やクライアントなどが確認し、合意を得た上で次の工程に進む仕組みとなっているため、やはり時間がかかる傾向にあります。時間をかけて一定以上の品質のプロダクトを作る点は特徴ですが、スピーディにプロダクトを作りたいときには適していません。
臨機応変に対応しにくい
臨機応変な対応が難しい点にも注意しなければなりません。ウォーターフォール開発は、プロジェクト全体の流れや工程を最初にすべて決めるため、途中でトラブルが発生したり仕様変更の要望が入ったりしても柔軟に対応できない可能性があります。万が一仕様変更をしないといけなくなった場合、もう一度最初からやり直すかなど、時間とコストがかかってしまうため注意が必要です。最悪の場合、やり直すコストを捻出できないためにそのままの状態でシステムを作らざるを得ない状況にもなりかねません。
トラブル発生時のリスクが大きい
臨機応変な対応が難しい点にもつながる部分ですが、ウォーターフォール開発はトラブルが発生した後のリスクが非常に大きいといえます。これは、ウォーターフォール開発が工程やスケジュールなどをすべて決めた上で作業を進める手法であるためです。もし途中でトラブルが発生すると、その後のすべてのスケジュールに影響が出る恐れがあります。また、手戻しをするとなると、一からすべての作業をやり直さなくてはなりません。事前に決めた内容に沿って作業を進められる点は大きなメリットですが、万が一トラブルが発生したときのリスクもその分大きいため注意が必要です。
ユーザーの意見を取り入れにくい
ウォーターフォール開発は、開発途中での仕様変更が難しいため、ユーザーやクライアントの意見を取り入れにくい点に注意しなければなりません。細かい変更であれば取り入れられる可能性はありますが、大きな変更は困難です。アジャイル開発が変化を想定して開発に取り組むのに対して、ウォーターフォール開発は基本的に変化を想定していない点を覚えておいてください。
ウォーターフォール開発を行うポイント
ここではウォーターフォール開発に取り組む際のポイントを紹介します。これからウォーターフォール開発に初めて取り組む方はもちろん、すでに経験はあるものの、よりスムーズに開発を行えるようになりたい方もぜひ参考にしてください。
スケジュールは綿密に立てる
ウォーターフォール開発に取り組む上ではスケジュールを綿密に立てることが大切です。ウォーターフォール開発の場合、各工程の内容や順番、スケジュールなどを事前に設定した上で進めるため、最初の段階で綿密なスケジュールを立てていないと、作業がスムーズに進みません。具体的な工数を把握し、トラブルに備えてバッファを設けるなど、細かい部分まで検討したスケジュールを作成してください。
要件定義は明確にする
ウォーターフォール開発において、要件定義はその後の作業の方針となるものであるため、不明点を残さないようにしてください。顧客が何を求めているのか、システムでは何が必要なのか、などはっきりとわかりやすい形で文書に残す必要があります。不明点がある場合は確認し、クリアな状態にしてください。要件定義が明確であれば、その後の工程で作業の手戻りなどが発生するリスクを抑えられます。
各工程はドキュメントで残す
ウォーターフォール開発を構成する各工程はドキュメントで残してください。これは工程ごとに担当者が異なるウォーターフォール開発の場合、工程を跨ぐことで情報共有などが難しくなるためです。ドキュメントで工程の詳細を残しておけば、次の工程の担当者はそれを読むことで情報を引き継げるため、トラブルを回避できます。
工程別にテストを実施する
ウォーターフォール開発は、各工程でテストを実施する必要があります。先ほど紹介した単体テストや結合テストなどを各工程で行い、機能は正しく動作しているか、品質には問題がないかを確認した上で次の工程に引き継がなければなりません。このテストがないと、プロダクトの問題に気づかず、後々トラブルが発生する恐れもあります。
関係者と密なコミュニケーションをとる
関係者とのコミュニケーションは開発の成否を大きく左右する重要なポイントです。特にウォーターフォール開発の場合、最初の要件定義の段階で詳細を決めなければならないため、その時点での関係者との密なコミュニケーションは必要不可欠です。意見交換を通して、何を求めているのか、どのような機能が必要なのか、こちらができることとできないことは何かを擦り合わせておけば認識の齟齬によるトラブルは回避できます。
ウォーターフォール開発が向いている案件・向いていない案件
ウォーターフォール開発は、様々な開発プロジェクトに用いられますが、必ずしもすべての案件に適しているわけではありません。ここではウォーターフォール開発が向いている案件と向いていない案件はそれぞれどのようなものなのか解説します・
向いている案件
ウォーターフォール開発が向いている案件には以下のようなものがあります。
- 規模の大きい案件
- プロダクトの詳細が明確な案件・仕様変更を前提としていない案件
規模の大きい開発案件の場合、スケジュール管理の難易度が高く、少しでもズレが生じるとプロジェクト全体の遅延につながりかねません。そのため、最初の段階でスケジュールを細かく設定するウォーターフォール開発は大規模案件に適しています。いつまでに何をするのか、どういう順番で工程を進めるのかが明確になっていれば、基本的にはそれに沿って作業を進めれば良いため、スケジュールのズレは生じにくいといえます。
次に、プロダクトの詳細がすでに明確な案件、つまり作業途中での仕様変更が起こらない案件もウォーターフォール開発向きです。クライアントが最初の段階でプロダクトを開発する目的やプロダクトに必要な機能などを明確に決めていれば、要件定義の際にそれらの内容を落とし込めるためそのままプロジェクトをスタートできます。全体像が最初から明確であるため、手戻りのリスクも低いことから、ウォーターフォール開発が適しています。
向いていない案件
一方で、仕様変更が起こる可能性のある案件やクライアントの中でもプロダクトの仕様が明確になっていない案件などは、ウォーターフォール開発には適していません。ウォーターフォール開発は最初の段階であらゆる要素を明確にした上で作業を進めるため、不明確な部分が残っていると、後々の手戻りのリスクを伴います。このような案件に対しては、アジャイル開発やハイブリッド開発などが最適です。
ウォーターフォール開発が時代遅れと言われる理由
開発プロジェクトにおいて長年採用されてきたウォーターフォール開発ですが、近年では時代遅れと言われるケースも少なくありません。確かにウォーターフォール開発は規模の大きいプロジェクトなどで強みを発揮するなどメリットは少なくありませんが、その一方でアジャイル開発が普及するなどより柔軟性のある開発手法が注目を集めているのも事実です。特に現代の開発環境は変化やフィードバックに対するスムーズな対応を求められるケースが多く、事前にスケジュールを設定した上で進め、柔軟性が低いウォーターフォール開発ではクライアントのニーズに応えきれない可能性があります。このような背景からウォーターフォール開発を時代遅れと考える人もいます。
ただし、先ほどもメリットで紹介したように、大規模プロジェクトに向いているほか、無駄なコストを発生させずに済む点などはアジャイル開発にはない大きな特徴です。また、人材育成を行いやすい点もウォーターフォール開発ならではです。この点を踏まえると、必ずしもウォーターフォール開発が悪くて、アジャイル開発が良いわけではありません。それぞれに特徴や強みがあるため、プロジェクトに応じて使い分ける、もしくはハイブリッド開発のように併用する方法がおすすめです。
プロダクト開発にはLychee Redmineがおすすめ
ここまでウォーターフォール開発について解説してきましたが、プロダクト開発をスムーズに進めるためには、すべての作業を人手で進めるのではなく、適宜プロジェクト管理などができるツールの活用がおすすめです。ここではおすすめのプロジェクト管理ツールとしてLychee Redmineを紹介します。
Lychee Redmineは、これまでに7,000以上の会社で導入された実績を持つツールです。カンバン機能やガントチャート作成機能、タイムマネジメントなど、プロダクト開発プロジェクトにおいて役立つ様々な機能を備えています。
プロジェクト管理ツールのようなITツールの場合、うまく扱えない人が出てくるのではないかと不安になりますが、Lychee Redmineは使用頻度の高い操作はドラッグ&ドロップで対応できるなど初めて扱う人でも直感的に操作可能です。
プロジェクトメンバーのスケジュールも直感的に把握できるなど、リソースマネジメントにも活用できます。例えば、プロジェクトメンバーのうち誰に余裕があって、誰が忙しいのか、誰がどのようなタスクを抱えているのかといった点からリソースの再分配も可能です。
その他にも、Lychee Redmineにはコスト分析機能もついています。こちらは、作業工数に基づいて費用を算出できるものです。コストを踏まえて収支をリアルタイムで可視化できるため、常にコストを意識しながらプロジェクトを進められます。
このように、Lychee Redmineはプロダクト開発プロジェクトにおいて役立つ様々な機能を備えています。プロジェクトワークに取り組む方はぜひ導入を検討してみてください。
ウォーターフォール開発の特徴や進め方のポイントを押さえておこう
今回はウォーターフォール開発の概要やメリット、注意点、具体的な進め方などについて解説しました。ウォーターフォール開発は、プロダクト開発の最初の段階で要件定義や具体的な機能や仕様、工程、スケジュールなどを決めた上で作業を進めていく開発手法です。柔軟性の高いアジャイル開発に対して、一定以上の品質を確保しやすく、予算や人的リソースなどで無駄が発生しにくい特徴を持ちます。近年ではウォーターフォール開発が時代遅れと言われることもありますが、必ずしもそうではなく、プロジェクトに応じて適切な開発手法を選ぶことが大切です。また、プロジェクトをスムーズに進めるためには、プロジェクト管理ツールの導入も検討してみてください。
30日無料トライアルをはじめる
- 多機能ガントチャート/カンバン/バックログ/リソース管理/CCPM/レポートなど
- ・ クレジットカード登録不要
- ・ 期間終了後も自動課金なし
- ・ 法人の方のみを対象
このサイトはreCAPTCHAによって保護されており、Googleのプライバシーポリシーと利用規約が適用されます。