【ソフトウェアの開発プロセス】ウォーターフォールモデルとは

対象の読者

・これからソフトウェアを開発しようと考えている人
・ソフトウェア開発について基礎的な勉強したい人
・ウォーターフォールモデルについて詳しく知りたい人

このチャンネルを初めてご覧の方は以下の記事を一読いただけると幸いです。

はじめに

最近のソフトウェア開発(特に小~中規模の開発)では『アジャイルソフトウェア開発』が人気になっています。
「アジャイル開発に比べるとウォーターフォールは欠点が多い」といった表現も良くされています。

確かに比較的小規模なチームであれば、アジャイルソフトウェア開発のモデルを使うほうが柔軟に効率よく開発できるかもしれません。
しかし、これからソフトウェア開発を始めたいと考えている人は、まずは「ウォーターフォールモデル」について学習することをおすすめします。

ウォーターフォールモデルは、その性質から『ソフトウェア開発の工程を学習する』という点において非常に優れたモデルです。
基本的な工程の考え方においては、アジャイルなソフトウェア開発もウォーターフォールモデルの各工程を踏襲しています。

もし「ウォーターフォールモデルは古そうだから勉強はしないでおこう」と考えている人がいたら、まずはこの記事から読んでいただきたいです。

ウォーターフォールモデルの概要

ウォーターフォールモデルの概要については、前の記事にて説明しています。
まずは概要を知りたい方はこちらを参照ください。

ウォーターフォールモデルの工程(ライフサイクル)

ソフトウェア開発の工程は、ソフトウェアライフサイクルと呼ばれることもあります。
ここでは、ウォーターフォールモデルにおけるソフトウェアライフサイクルについて説明します。

ウォーターフォールのソフトウェアライフサイクルは、大きく分けると次のようになっています。

1.要件定義
2.外部設計(基本設計)
3.内部設計(詳細設計)
4.製造(プログラミング)
5.テスト
6.リリース 

1.要件定義

要件定義は、『現実世界にある問題やアイディアをどこまでシステムで表現するか』を定義する工程です。

存在する業務フローや、ユーザーの行動を分析し、どのような機能を開発していくのかを一つずつ洗い出していきます。

この後の工程では、ここで定義した要件を元に設計を進めていくため、この工程であいまいな内容が存在してはいけません。

2.外部設計(基本設計)

要件定義で決めた機能について、システムの外部からみた観点で設計を行います。外部とは例えば「画面の見た目の構成」や「データのフロー」「システムのフロー」などを指します。

データベースの設計や、プログラミングの具体的な内容など、技術的な詳細についてはここでは言及しません。
あくまで、開発したい機能をどのように表現したいのか？という部分に留まります。

最近のWebアプリやモバイルアプリの開発では、ワイヤーフレームやプロトタイプデザインのような、「システムがイメージできるデザインや図」をまず作成が多いですが、これらも外部設計に含まれます。

また、スケジュールの計画や人員計画など開発プロジェクトの基本的な設計もこの段階で行われます。

3.内部設計(詳細設計)

内部設計では、実際のシステム内部の設計を行います。

データベースのテーブル設計や、プログラミングのモジュール設計、アルゴリズム、外部システムとのやり取りなど技術的な内容を決めていきます。
詳細設計が完了した時点で「後は設計書を見ながら手を動かすだけ」という状態になっていることが理想です。

全ての機能を実装レベルまで設計することは非常に大変ですが、基本的に前工程に戻ることが難しいウォーターフォールモデルでは、内部設計に多くの時間をかけて詳細を詰めていきます。
工程を進むにつれて、システムの細かい仕様を正確に定義することが、ウォーターフォールモデルを上手く進める上では重要なのです。

4.製造(プログラミング)

製造工程では、内部設計の内容に沿って、実際にプログラミングを中心とした製造作業を行います。
ネットワークやデータベースの構築などプログラム以外の周辺技術についてもこの工程で構築します。

プログラミングを行なうときには、各プログラムの機能が正しく動いているかを確認するために『単体テスト』を行います。

単体テストは、専用のソフトウェアツールを使って、なんども自動でテストが実行できるように作成する仕組みを使うことが多いです。
これらのソフトウェアを使ったテストは「ソフトウェアテスト」と呼ばれることもあります。

5.テスト

製造が完了すると、実際に完成したシステムをテストします。
テストにはいくつかの種類が存在します。

■ 結合テスト
システムの機能と機能が正しく結合しているかどうかのテスト

■ 総合テスト
要件定義で定義された機能が、はじめに計画されたとおりに動作しているかのテスト

結合テストや総合テストの一部は、単体テストと同様にソフトウェアテストが使われることもあります。一方で「テスト項目書」を元に実際にテスター(人間)がシステムを動かしてテストすることも多いです。

テスト中に出た不具合は、この工程で修正され再テストされます。
ソフトウェアのシステムでは基本的に不具合が発生することが前提であり、テスト計画によって予め不具合の発生率などが計画され、改修期間も含めたスケジュールが立てられています。

6.リリース 

テストの工程で発生した不具合が規定の基準まで修正された後は、システムを世の中に公開します。

開発会社がソフトウェア開発を請負で開発しているような場合は、ソフトウェアのソースコードを発注側企業に納品するといった工程になることもあります。

ウォーターフォールモデルでは、リリースの工程が完了すると開発プロジェクトが完了となります。

上流工程と下流工程

ウォーターフォールでは、「要件定義」「外部設計」「内部設計」までの実際に製造に入るまでの工程は『上流工程』それ以降の工程は『下流工程』と呼ばれることがあります。

大規模なシステム開発では、上流工程と下流工程で企業やチームが異なる場合があります。

この辺りの明確な区分はなく、要件定義を専門とする企業や、要件定義と外部設計を専門とする企業、テストのみを専門とする企業など様々です。

後述しますが、このように工程ごとに担当するチームごと入れ替えが可能というのもウォーターフォールモデルの特徴です。

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

■ メリット
・初期段階でシステムの全てを設計するためプロジェクトの全体像を把握しやすい
・工程が順番に進むため引き継ぎが容易

ウォーターフォールでは、上流工程の段階でシステム全体を設計するため、プロジェクトの全体像が早い段階で把握できるというメリットがあります。
これにより、スケジュールやリソースの計画が早い段階で立てられます。

また、上流工程から下流工程へ一つずつ順番に工程が進むため、プロジェクトの区切りがつきやすく、設計書などの成果物も工程ごとに作成されることから、メンバーの交代や他チームへの引き継ぎが比較的容易であるといえます。

■ デメリット
・複雑性が高いシステムや大規模システムでは難易度が高い
・前工程への手戻りがしにくい

ウォーターフォールモデルでは、上流工程の段階でシステム全体を詳細まで設計します。

そのため、複雑な要件やトライアンドエラーが必要な難易度が高い要件については、設計の難易度が高くなります。
また、大規模なシステムについても同様で、設計工程に大きなコストがかかることに加え、関係者が多いためプロジェクト進行の管理コストが高くなる傾向にあります。
このような条件のシステムでは、プロジェクト経験が豊富なメンバーが必須となります。

また、各工程が一度しか行われないため、後半で発生した問題ほどプロジェクトに与える影響が大きくなります。
たとえば、テスト段階で要件定義上の大きな問題が発生した場合は、上流工程まで遡り各工程をやり直さなくてはならないため、他工程よりも修正コストが高くなります。

まとめ

ウォーターフォールモデルは、ソフトウェア開発の基本を学ぶためには体系立てられた優れたモデルといえます。

また、システム全体が初期段階から把握しやすく、全体像を早めに見積もる必要があるプロジェクトには適しています。

一方で、各工程の比重が高く手戻りがしにくいため、上流工程のプロジェクトの成熟度が求められるモデルともいえます。

採用する場合は、規模が小さく、難易度が低いシステムでノウハウをチームで習得したのち、徐々に大規模システムに適用するのが良いと思います。

実践的な内容については、多くの書籍や情報が存在しますので、採用する前により深く勉強しておきましょう。

アンケートのお願い

このチャンネルでは、これから提供していくコンテンツやサポートの内容を改善していくために、アンケートをお願いしています。
ぜひアンケートにご協力ください。

アンケートはこちらから