ウォーターフォール型開発手法は、システム開発の手法としてもっとも多く取り入れられている開発手法ですが、一方では時間とコストがかかる手法といわれたり前時代的だと揶揄されることもある手法です。
システム開発へのニーズが多様化している今、時間とコストの両面でムダなく自社システムを開発するためには、自社の環境に最適な開発手法を採用することがとても大切になります。
この記事では、ウォーターフォール型開発について説明するほか、ウォーターフォール型開発の具体的な工程、他の開発手法と比較してのメリットなどをお伝えします。
この記事を読むことで、自社のシステム開発にウォーターフォール型を採用すべきなのかどうかが分かるようになります。
是非ご一読ください。
ウォーターフォール型開発とは、システム開発の全体工程をいくつかの工程に分割し、それぞれの工程を順番に進めていくシステム開発の手法のことを指します。
滝(Waterfall)のように、上流(工程)から下流(工程)へと開発作業を進めていくことからこの名前がつけられています。
1968年には原型が提唱されていたウォーターフォール型開発は、もっともポピュラーなシステム開発モデルとして古くから活用されている開発手法といえます。
ウォーターフォール型での開発工程は、要件定義>基本設計>詳細設計>プログラミング>単体テスト>結合テスト>総合テスト>システム運用という流れになるのが一般的です。
この工程のうち、要件定義から詳細設計までを上流工程と呼び、基本的にはシステムエンジニアが担当します。
プログラミングからシステム運用までが下流工程と呼ばれ、ここではプログラマーがその工程を担当します。
それぞれの開発工程ではトップダウン形式で進められるのが特徴といわれており、ひとつの開発工程を100%完了させてから次の工程に移るやり方で進められます。
それぞれの内容についてご説明します。
要件定義とは、発注者がシステムに求める機能・技術・ハードウェアなどの必要な条件を明確にし、発注側が解決したいと考えている問題をクリアできるシステムとは何かを考え、システムに求める要件を定義(整理・明確化)し、要件定義書へと落とし込んでいく工程です。
要件定義はウォーターフォール型での開発工程の中では最も重要な工程といっても過言ではありません。
この段階で発注側と開発側の認識が十分にすり合わされていないと、下流工程に進めば進むほど認識のずれが生じるおそれがあります。
何を求めているか、何が求められているかを、しっかりと打合せしながら進めていく必要があります。
基本設計とは、要件定義書の内容を、より具体的な設計書レベルまで落とし込んでいき、基本設計書をつくりあげる工程のことを指します。
様々な事柄をより明確にしていく作業といっていいでしょう。
要件を満たすソフトウェア(ミドルウェア)・ハードウェアは何か、システムに必要な機能と役割は何か、機能間の関連性や全体的な業務の処理方法をどうするのか、既存システムとの連携が必要な場合はデータやり取りの方法や連携画面をどうするか、などを決定していきます。
詳細設計とは、基本設計書でより具体化された内容について、システムエンジニア・プログラマーがどう作りこんでいくのかがわかるよう、設計書に落とし込んでいく工程を指します。
詳細設計では、プログラマーへの指示書ともいえる詳細設計書を機能ごとに作成します。
この詳細設計書をもとに多数のプログラマーが作業にあたるため、クラス設計書、コード設計書、コーディング規約、単体テスト仕様書なども作成されます。
完成した詳細設計書をもとに、実際のシステムを開発(プログラミング)する工程に移ります。
プログラミング言語を含め、作業に必要な設計書・情報はすべて揃っている状態であるため、それぞれの機能ごとにひたすらプログラミング作業を進めていきます。
プログラミングのことを「コーディング」ということもあります。
単体テストとは、開発の完了したプログラムを文字通り「単体」で動作確認するテストのことを指しています。
ウォーターフォール型開発では、ひとつの工程が100%完了するまで次の工程に移らないことが基本ですが、単体テストは機能ごとに開発期間が変わることがあるため例外となっています。
テストで不具合が見つかれば、不具合がなくなるまで修正して再テストを繰り返します。
基準になるのは詳細設計で作成した単体テスト仕様書になります。
単体テストと詳細設計が紐付けられているのはこのためだといえるでしょう。
結合テストとは、単体テストで合格したプログラム同士を結合し、画面遷移やデータの受け渡しなどでシステム間の連携がとれているかを確認することを指しています。
基本設計で確定した業務フロー図をもとに、実際の業務と同じようにプログラムを走らせ、想定通りのアウトプットが得られるかどうかを確認していき、不具合が見つかれば、不具合がなくなるまで修正して再テストを繰り返します。
総合テストとは、結合テストをパスしたシステムを発注側と同じ環境において実施するテストのことを指しています。
機能要件を満たしているかどうかはもちろん、パフォーマンス・障害時の処理・外部システム連携などの非機能要件を満たしているかどうかもチェックします。
総合テストをパスしたら実際に発注企業に使用してもらい、問題はないかチェックしてもらいます。
これをユーザーテスト、あるいは受入テストと呼びます。
すべてのプロセスに問題がなければ、システム運用が開始されます。
新規システム開発・導入であれば特に問題はありませんが、旧システムからのリプレース案件であれば、データ移行をはじめとした移行作業が必要になります。
一気にリプレースを実施する一斉移行、徐々に新システムに移行する順次移行という2つの方法が考えられます。
ウォーターフォール型開発では上流工程への手戻り作業は想定されておらず、前工程には問題がないということを大前提として進められます。
このため「イレギュラーな事態に対しての対応力に欠ける」「開発に時間がかかるためしっかりと予算枠がとられていないと対応できない」などのネガティブな意見も少なくありません。
しかし長くもっともポピュラーな開発であったウォーターフォール型開発には様々なメリットがあります。
代表的な3つのメリットをご紹介しましょう。
ウォーターフォール型開発では、要件定義からテスト、システム運用までを段階的に進めていくため、全体をスケジューリングしやすいのがメリットのひとつです。
後の工程やスケジュールや仕様が変更される開発手法では最初からプロジェクト全体を見渡すことが難しくなります。
これに比べると、ウォーターフォール型開発はプロジェクト全体を見渡し、スケジューリングしやすい開発手法だといえます。
ウォーターフォールの開発工程では、単体テストや結合テストなど、何度も繰り返し手直しをし、100%完成したものを次の工程に引き渡す、という下流工程があるため、品質を担保することができるのもメリットのひとつといえます。
まずは短期間で納品し、後日修正しながら品質を高めていく他の開発手法と比べると、ウォーターフォール型開発でつくられたシステムは常に高品質で納品することができるのです。
開発工程・手順がシンプルで理解しやすく、システム開発の基本的な手法でもあるウォーターフォール型開発は、さまざまなプロジェクトに適用させやすい汎用性の高いシステム開発モデルです。
詳細な設計書をもとに開発されるため、SE・プログラマーのスキルに差が生じにくく、人材を確保しやすいのもメリットといえます。
もっともポピュラーなシステム開発モデルであるウォーターフォール型開発は、ほとんどのシステム開発会社が対応できることもメリットとしてあげられます。
確立された手法であるがゆえ、プロジェクトを安定的に遂行できる強みがあります。
この記事では、ウォーターフォール型開発とは何かについて説明したほか、ウォーターフォール型開発の具体的な工程をそれぞれご説明しました。
またウォーターフォール型開発が持つメリットについてもお伝えしました。
ウォーターフォール型開発は、時には前時代的だと批判されることもありますが、その開発実績や安定的な手法という意味ではシステム開発の基本をなすものともいえます。
ウォーターフォール型開発について知ることで、自社に必要な開発工程についてご検討を深めていただければ幸いです。