ウォーターフォール型開発とは?非常に分かりやすく解説します!

開発

2021.04.22

システムの開発の手法として、古くから世界中で使用されてきたウォーターフォール型開発があります。
今回はウォーターフォール型開発の定義や、ウォーターフォール型開発の流れ、メリット・デメリットなどについて紹介します。

特に下記の方にこの記事を一読していただきたいです。
・ウォーターフォール型開発を学習したい方
・ウォーターフォール型開発で開発している方
・ウォーターフォール型開発の理解を今以上に深めたい方

 

 

 

1.ウォーターフォール型開発とは?


ウォーターフォール型開発とはについて解説していきます。
ウォーターフォール型開発とは、システム開発で用いられる開発手法の1つであります。

 

1968年、NATO後援の国際会議にてソフトウェア開発を職人芸的な作成方法から工業製品としての作成方法に変える方法として、ウォーターフォール型開発の原形が提唱されています。
これは、システムの開発工程を「計画(要件の定義)」「外部の設計」「内部の設計」「プログラム自体の設計」「プログラミング」「テスト」などの工程に分けて、一つ一つを完了させ、順番に進行する方法です。

 

各工程が終わるまで次には進まず、かつ前の工程には戻らないという開発手法で、各工程ごとに成果物を作り、各工程の品質を確保するという特徴があります。
工程が水が流れるように進み、元の状態には戻らない性質から、ウォーターフォールと呼ばれています。

 

ウォーターフォール型開発の開発事例は、アクセンチュアのMethod1、IBMのADSG、富士通のSDEM90などが挙げられます。

 

 

 

 

2.ウォーターフォール型開発の3つのモデルとは?


ウォータフォール型開発には3つのモデルを紹介します。

 

V字型モデルモバイルアプリ開発スキル
ウォータフォール型開発の「テスト」に着目して、開発プロセスが決められたモデルになります。

 

プログラミング開発を折り返し地点として、上流工程とテストを対等になるようにテストを行います。
各テスト工程では対応する開発工程が完了しているか確認し、最終段階の受け入れテストは「要件定義に正確なシステムができたのか」を確認します。

 

✔詳細設計 → 単体テスト
✔基本設計 → 結合テスト
✔要件定義 → 受け入れテスト

 

 

プロトタイピングモデル
プロトタイピングモデルは簡単な試作品(プロトタイプ)を開発し、ユーザーによるプロトタイプの評価が行われてから本格的な設計を開始する開発モデルです。

 

「プロトタイプの開発」と「ユーザーによるプロトタイプの評価」は、ウォーターフォールモデルにおける要件定義工程と基本設計工程の間に組み込まれます。
プロトタイピングモデルはユーザーの要件と開発者側の認識の齟齬や技術的な課題を早期に解決できるため、 開発工程終盤での大きな手戻りを防ぐことが可能です。

 

 

スパイラルモデル
スパイラルモデルとは、設計、実装、テストの一通りの工程を繰り返してシステムの質を高めていく開発手法の事です。

 

スパイラル型開発ではソフトウェアのプロトタイプとなる品質が高くない状態のものを顧客・ユーザーに見せ、ソフトウェアがどのように動くかのイメージをプロジェクトの早い段階から共有します。

設計とプロトタイプ作成を繰り返していくことでソフトウェアの品質を上げていきます。
グルグルと螺旋階段を登るようなイメージなので、スパイラルモデルと名付けられています。

 

 

 

3.ウォーターフォール型開発の流れとは?


ウォーターフォール型開発は、どのような手順で具体的に進むのかを解説します。

 

要件定義
ウォーターフォール型開発における最上流工程です。

 

要件定義では、ヒアリング調査でクライアントが実装してほしい機能や性能を明確にしていきます。整理した情報をもとに、新しい業務フローやシナリオをクライアントに伝え、認識に齟齬がないか確かめます。
このフェーズにおける成果物は要件定義書となります。

 

要件定義は、ウォーターフォール型開発において最も重要です。クライアントが要求する機能、開発側が実現可能なものを明確にしておくことにより、その後のフェーズ全ての手戻りの量が左右されます。

そのため、クライアントが本当に解決したい問題の洗い出しや想定され得る懸念点・齟齬発生時の対応指針などをしっかりと決定しておきましょう。

 

 

基本設計
基本設計では、クライアントの要望を満たす機能や製品作成方法を決定します。

 

作成すべき機能を洗い出し、どのようなハードウェアやミドルウェアを組み合わせることで機能が実装できるか明確にしておきましょう。
実装すべき機能は要件定義書を参考にします。このフェーズにおける成果物は基本設計書です。
基本設計書をクライアントと共有し、仕上がりのイメージに齟齬がないかヒアリング調査します。

 

 

詳細設計
詳細設計では、クライアントと共有する機会が多い基本設計書とは異なり、開発者や内部者に向けて書類を作成していきます。

 

基本設計では見えていない要件や基本設計段階ではまだ不完全なものがあれば詳細設計フェーズで修正を行い、仕様を確定させます。

また、機能が正常に動作した場合と異常が見受けられた場合の処理方法も記載しておくと良いでしょう。特に異常時に関しては詳細に処理フローを記載しておきましょう。
プログラマーはこのフェーズにおける成果物の詳細設計書をもとにしてプログラミングします。
そのため、詳細設計の作成はクライアント目線ではなくプログラマー目線で行うことを心がけましょう。

 

 

実装
実装では、実際にプログラマーやエンジニアがプログラミングをしていきます。

前フェーズで作成した基本設計書や詳細設計書をもとにして、機能を実装していく段階です。

このフェーズにおける成果物はプログラムコードです。開発の多くが実装と次のフェーズ単体テストを同時に行います。

 

 

単体テスト
単体テストでは、プログラミングして完成した機能単体がエラーなく動作しているかどうか、性能を評価します。

 

想定通りに作動していることを証明するエビデンスをとる必要があり、成果物もまたエビデンスです。
異常が発生した場合、詳細設計書に記述してある通り、異常発生時の処理フローに従って異常を解決していきます。
簡単なテストの場合はテストスクリプトを作成し自動テストツールでのテストを行って効率化を図ります。

 

 

結合テスト
結合テストでは、単体テストのフェーズで想定通りに作動した機能同士を連携させ、正確に作動するか確認して性能を評価します。

 

機能を連結させた際プログラムがエラーなく動作するかどうか確認することが目的です。
結合テストでも、プログラムが想定通りに動作したことを証明できるエビデンスをとり、成果物とします。

 

 

総合テスト
総合テストでは、システム全体を連結させてその性能を評価します。

全体を連結させてもエラーなく作動するかどうか確認することが目的です。作動の様子を示すエビデンスを成果物とします。
異常が発生した場合、前フェーズに戻りエラー箇所を捜索する必要があります。スムーズに機能が動作する確認が取れれば、次フェーズに進みます。

 

 

受入テスト
受入テストでは、本番環境でエラーなく作動するかどうか確認します。

エビデンスとなるのはシステム本体です。受入テストまで進んでから仕様変更があった場合には、変更に対応する必要があり開発工数が余分に発生します。
本番環境でエラーが生じた場合には、機能が動作しない理由を探るために前フェーズに戻る必要があります。

このフェーズは導入テストとも呼ばれ、特に注意を払い本番環境でテストします。

 

 

リリース
新システムを本番環境にリリースします。

 

 

運用・保守
システムの運用・保守を行うフェーズです。
実際に新システムを使用し、不具合があった場合は速やかに修正を行います。

またクライアントより新しい機能要求が挙がる可能性もあります。その場合は追加開発などを行ってシステム保守を行います。

 

 

 

4.ウォーターフォール型開発のメリット・デメリットとは?


次に、ウォーターフォール型開発のメリット・デメリットについて解説します。

 

ウォーターフォール型開発のメリット
 

ウォーターフォール型開発のメリット①:スケジュールを立てやすい
ウォーターフォール型開発はプロジェクト全体のスケジュールを立てやすい点がメリットです。

 

プロジェクトスタートと共に要件定義をし、基本・詳細設計に取り組んでいくため、早期段階でやるべきことを明確にして計画を立てます。
俯瞰してプロジェクトを把握でき、各工程ごとにタスクを担当者に割り振るためプロジェクト開始後の進捗を管理しやすい点もメリットです。

 

また前工程を完了後、次フェーズに進むこと、各工程のタスクが既に割り振られていることを考量するとプロジェクトの参加者が変更された場合も、引継ぎを行いやすい点もメリットです。

 

 

ウォーターフォール型開発のメリット②:予算やシステムエンジニアの手配がスムーズに行える
ウォーターフォール型開発では、プロジェクトの開始当初に見積もった計画通りに各工程を遂行します。

 

そのため、開発のための費用、システムエンジニアやプログラマーの必要人員数が予測できる点がメリットです。
仮に自社システムエンジニア不足がおきた場合、パートナー企業から派遣してもらうなどしてリソースを確保する必要があります。

必要人員数を把握していることにより適任者を早い段階で見つけられる可能性があります。

 

 

ウォーターフォール型開発のデメリット

 

ウォーターフォール型開発のデメリット①:進行中に問題発生した際の手間が大きい
プロジェクト開始時にしか要件定義の機会はありません。

つまり要件定義や基本設計でしか要望をヒアリングできません。

そのため、プロジェクト進行中や成果物を見た後に仕様変更が生じた際には大きな手間がかかります。
やり直しにかかった工数分やさらに最終的な成果物の納品も遅くなります。テストの工程に進むまでクライアントが実物を確認する機会はなく、仕様変更が生じる可能性もあります。

 

 

ウォーターフォール型開発のデメリット②:WBSの作成に時間がかかる
各工程で分業しているということは、計画管理資料であるWBS(Work Breakdown Structure:作業分解構成図)の作成にも時間がかかるということです。

また、スケジュール変更や仕様変更が発生した場合、再度WBSを作成する必要があります。

 

 

ウォーターフォール型開発のデメリット③:成果物作成に時間がかかる
ウォーターフォール型開発では、各工程の成果物が必要となります。

そのためシステムの規模が大きいほどドキュメント量は膨大になりやすく、その作成や管理稼働に大きな負荷がかかります。
工程が進んだ後に仕様が変更された場合には、その成果物のドキュメントも修正する必要があります。

 

 

 

5.ウォーターフォール型開発を使用することが多い開発とは?


ここでは、ウォーターフォール型開発が向いている開発ケースについて説明します。

 

品質を重視するシステム
銀行のATM開発など、障害の発生が許されないケースがあります。

そのような場合には、リリースの早さではなく、確実性を求めるウォーターフォール型開発が好まれる傾向にあります。
ウォーターフォール型開発は、テストを繰り返しするため「障害発生率を限りなく0%に近づける」というクライアントの要望に応えやすくなっています。

 

 

大規模システム
大規模システムになればなるほど、人員数が必要となります。

 

ウォーターフォール型開発では事前に各工程ごとに必要となる人数の把握が出来ます。

人手が必要となっているタイミングで、大量に人員を確保して開発をスムーズに進められます。
また人手が充当している場合は、人員確保する必要がなく、必要な人員だけを稼動する事も出来ます。

 

 

 

6.まとめ


今回はウォーターフォール型開発の概要やウォーターフォール型開発の流れ、メリット・デメリット、ウォーターフォール型開発に向いている開発について解説してきました。

 

ウォーターフォール型開発とは、プロジェクトを各工程に分け、確実に工程を進めていく開発手法のことです。エンジニアの間では古くから使用されてきました。
品質を重視するケースや人員を大量に確保しなければいけないケースで活躍し、テストを重ねて行うため、手戻りが発生した場合はその分手間や工数が余分にかかってしまう点が特徴です。

各工程の成果物を丁寧に作成しておけば、次フェーズに進みやすくなるでしょう。

 

現在では、ウォーターフォール型開発よりもアジャイル開発のスクラム開発を採用する企業なども多く見られます。
この記事をご一読いただいた方はどちらの開発手法がより優れているかではなく「どんなプロダクトを開発したいか」「どのように開発していきたいか」で手法を選択出来るようにしましょう。

 

フリーランスエンジニア専門の求人・案件一括検索サイト「フリーランススタート」に少しでも興味がある方は是非ご登録ください。

 

なお、フリーランススタートはiOSアプリ版やAndroid版をリリースしています。

通勤しているエンジニア・デザイナーでちょっとしたスキマ時間で手軽にフリーランス求人・案件を検索したい、開発言語の単価が知りたい、フリーランスを将来的に検討している方などは是非インストールしてみてください。

 

フリーランススタートのアプリを有効活用して、フリーランスとして第一線で活躍しましょう!

 

フリーランススタート iOSアプリのインストールはこちらから

 

フリーランススタート Androidアプリのインストールはこちらから→

 

 

本記事が皆様にとって少しでもお役に立てますと幸いです。

twitterでシェア
facebookでシェア
facebookでシェア

フリーランスお役立ち記事を検索

新着フリーランス求人・案件

おすすめフリーランス求人・案件