システム開発におけるウォーターフォールとは？メリット・デメリットを解説

ウォーターフォール開発とは？

システム開発モデルのなかでも代表的な手法として、ウォーターフォール型があります。「水が上流から下流に流れる」ように、決められた工程を順番に遂行するシステム開発モデルです。

大まかに「要件定義」「設計」「開発・実装」「テスト」「リリース・運用・保守」を順番に進めます。ウォーターフォール型は、基本的に前の工程に戻ることは想定されていません。

各工程を並行に進めることはなく、1つの工程が完了・検証されてから次の工程に移る点がウォーターフォール型の特徴です。日本ではもっとも多く採用されているシステム開発モデルとして知られています。

ウォーターフォール型を採用する3つのメリット

ウォーターフォール型のメリットは次の3つです。

ウォーターフォール型には工程がわかりやすいメリットがあります。スタッフ全員の工程に対する認識に差異が起きづらくなります。

1. 工程全体がシンプルでわかりやすい

ウォーターフォール型のメリットの1つ目は、上流工程（要件定義）から下流工程（保守・運用）まで順に進める工程がシンプルでわかりやすいことです。1つの工程が完了・検証されてから次の工程に移り、基本的に後戻りはしません。

最初の要件定義でどのシステムを開発するかを細かく決めるため、最終目的もわかりやすく、全員が共通認識を持って進められます。システム開発初心者でも理解しやすいため、未経験者をシステム部門に配属する可能性がある場合にもおすすめの開発モデルといえるでしょう。

2. スケジュールの策定・進捗管理がしやすい

ウォーターフォール型のメリット2つ目は、スケジュールの策定・進捗管理がしやすいことです。同じ工程を繰り返さないため、納期が決まれば工程ごとにスケジュールを立てやすいでしょう。

開発着手後も、今どの段階まで進んでいるのか、どこで遅れが出ているのか、状況が把握しやすいです。工程ごとにタスクがあらかじめ決まっているため、無理のない範囲で人員配置できるのもメリットといえます。

3. 大規模システムや大人数でのプロジェクトに対応しやすい

ウォーターフォール型のメリットの3つ目は、大規模システムや大人数でのプロジェクトに対応しやすいことです。システム開発の規模が大きくなるほど人員も必要となります。あらかじめスケジュールが決定しているウォーターフォールモデルであれば対応しやすいでしょう。

決められたスケジュールどおり進められるため、段階ごとに綿密に品質を担保できるところが大規模開発に向いています。日本でもっともメジャーな開発手法のため、ほとんどの開発会社で対応してもらえることもメリットです。

ウォーターフォール型を採用する2つのデメリット

ウォーターフォール型のデメリットは次の2つです。

ウォーターフォール型にはリリースまで時間がかかるデメリットがあります。念頭に踏まえて事前に計画を練る必要があるでしょう。

1. 要件定義からリリースまでに長期間を要する

ウォーターフォール型のデメリット1つ目は、要件定義からリリースまでに長期間を要することです。同じ期間で複数の工程を同時に進めることはなく、ひとつずつ工程を綿密に進めるため、一般的には半年〜1年の開発期間を要します。

要件定義から順を追って開発を進めるため、担当者ごとに待ち時間が発生することもデメリットです。要件定義中はPGの作業が発生せず、プログラミング期間は他の担当者は動けません。空き時間が発生することを想定して人員配置を行いましょう。

2. 工程が進んでからの修正・変更に対応しづらい

ウォーターフォール型のデメリット2つ目は、工程が進んでからの修正・変更がしづらいことです。ウォーターフォール開発は上流から下流へ段階ごとに進むため、工程が進んだ段階で前の工程に手戻りすることはできません。

大きな変更や修正をおこなうとすべてのスケジュールがくるい、進めてきた工程がすべて無駄になる可能性があります。手戻りできない分、追加で修正や開発が必要な機能は一旦見送り、次回の開発の際に要件として組み込む対応が必要です。

要件定義のやり直しや、納期の大幅遅れによりクライアントに大きな迷惑がかかります。余分なコストが発生するリスクがあることを念頭においておきましょう。

ウォーターフォール型システム開発の開発例　

ウォーターフォール型システム開発の開発例は以下のとおりです。

ウォーターフォール型システム開発の典型的な開発例は、組み込みソフトウェア・企業の基幹システム・および大規模なソフトウェア開発プロジェクトです。

以上のプロジェクトでは、ウォーターフォールモデルが適しています。段階的で予測可能な進行が要求される大規模な開発に有益です。

1. 家電や産業機器などの組み込みソフトウェア

家電や産業機器の制御ソフトウェア開発では、要件が固まりやすく変更が少ないため、ウォーターフォールモデルが適用される場合があります。ハードウェアとの統合が重要で、プロジェクトを異なる段階に分割して進めることが効果的です。

2. ERPシステムや基幹システムの導入

ERPシステムや企業の基幹システムの導入プロジェクトでは、事前に明確な要件が整理されて変更が難しいため、ウォーターフォールモデルが採用されることがあります。大規模かつ複雑なプロジェクトに適しています。

3. 大規模なソフトウェアの開発

大規模なソフトウェア開発プロジェクトでは、要件が十分に明確であり、変更が難しい場合にウォーターフォール型が利用されます。大規模な開発プロセスを段階的に進め、品質を確保することに適しています。

ウォーターフォール型システム開発の工程10ステップ

ウォーターフォール型の主な手順は、以下のとおりです。

1. 要件定義

ウォーターフォール型システム開発で最上流の工程にあたる「要件定義」フェーズは、どのようなシステムを開発するのかを決定する根幹作業です。クライアントの目的・ニーズに応じて、必要な機能やハードウェアを含む環境、運用方法などを細かく策定します。

要件定義があいまいな場合や内容に漏れがあった場合は以降すべての開発工程に支障をきたします。クライアントとシステム開発側の間で認識のズレが生じないよう、円滑なコミュニケーションを意識しましょう。

システム開発するうえでの現状課題の洗い出しや、解決するためにあわせて開発しなければいけない機能などをこの段階ですべて伝えます。

2. 基本設計（外部設計）

ウォーターフォール型の2つ目の工程では、要件定義書を元にシステムの大枠を設計する「基本設計」フェーズに移ります。

インターフェース・レイアウトなどのユーザーの目に見える部分を中心に、実装する機能・ハードウェア・セキュリティなどの機能面を決定する工程です。外側の大枠を固める作業であることから「外部設計」とも呼ばれています。

最終的な納期や開発コストを決定する段階でもあるため、クライアントとの認識の食い違いが起きないよう、しっかりすり合わせることが大切です。クライアントが設計書を理解できるよう、専門用語は極力使用せず、噛み砕いた表現で作成しましょう。

3. 詳細設計（内部設計）

3つ目の工程は、実際にプログラミングできる段階までに落とし込んだ指示書として、設計図を作成する「詳細設計」フェーズです。基本設計がクライアント向けであるのに対し、詳細設計は開発会社内部のエンジニア・プログラマー向けに作成します。

具体的な作業は、各機能の仕様書・プログラミングのルール・データフロー図など、実装における専門資料の作成です。作成にはシステムに関する専門知識が必要であるため、システム開発会社の作業が中心となります。

4. プログラミング（開発・実装）

ウォーターフォール型の4つ目の工程は、システムを開発・実装するための「プログラミング」のフェーズです。詳細設計書を元に、システム開発会社のエンジニア・プログラマーがプログラミングをおこないます。

詳細設計で分割された機能（モジュール）ごとに、チームで作業にあたるケースもあれば、1つのチームがモジュールを順番に開発するケースもあります。

5. 単体テスト

ウォーターフォール型の5つ目の工程は、モジュール単体ごとに問題なく動作するか、要件定義を満たしているかをテストする「単体テスト」フェーズです。

エンジニア・プログラマーが担当する場合や、選任のテスターが担当する場合もあります。テスト結果をフィードバックしながら、不具合の修正作業もおこないます。

6. 結合テスト

ウォーターフォール型の6つ目の工程は、単体テストの完了したモジュールを複数結合した「サブシステム」をテストする「結合テスト」フェーズです。結合したサブシステムに不具合がないか、モジュール同士が正常に連携できるかを確認します。

サブシステム内部の結合テストはもちろん、サブシステム外との連携をチェックする外部結合テストの実施も重要です。

7. システムテスト

ウォーターフォール型の7つ目の工程は、システム全体の動作を総合的にテストする「システムテスト」フェーズです。すべてのプログラムが問題なく動作するかを確認します。

要件定義を満たしているか、アクセスが集中したときの耐久性・処理速度は問題ないかなど、あらゆる側面を考慮に入れてテストすることが大切です。

8. 運用テスト

ウォーターフォール型の8つ目の工程は、最終的なテストを実施する「運用テスト」フェーズです。リリースして問題ない品質かどうかを確認する段階であり、ユーザー側で使用する環境にシステムを移行してテストを実施します。

要件を満たしているか、操作性・機能性に問題はないかを、ユーザー（クライアント）の視点に立って確認することが重要です。運用テストでは、実際にシステムを使用するユーザー（クライアント）が参加します。

9. リリース

ウォーターフォール型の9つ目の工程では、完成したシステムをリリースします。はじめてシステム開発する企業・組織であれば、完成したシステムを本番環境へリリースして完了です。

旧システムからのリプレイス・再構築であれば「移行作業」が必要となります。一気に旧システムから切り替える「一斉移行」のほか、徐々に新しいシステムに切り替える「順次移行」があります。

10. 運用・保守

リリースされたシステムは安定的に稼働させていかなければいけないため、システムを利用している間は運用・保守が必要です。

具体的には、以下の2つの業務にわかれます。

• システムがダウンしないようにトラブル対応・メンテナンスする保守業務
• 不具合の改修やシステムのアップデートに関連する運用業務

一般的には、開発を担当したシステム開発会社が掛け持ち、もしくはメンテナンス専門会社にアウトソーシングするケースが多いです。ただし、クライアントも運用・保守に携わる必要があります。業務を停止させないためにも、綿密なコミュニケーションを心がけることが重要です。

ウォーターフォール開発を行う際の3つのポイント

ウォーターフォール型開発を行う際の重要なポイントは以下の3つです。

ウォーターフォール型ではリリースまでに時間がかかるほか、各工程が直線的に進行します。正確なスケジューリングを行いましょう。

1. 各工程でのドキュメントを作成しておく

ウォーターフォールモデルでは、開発プロセスが段階的に進むため、各工程でのドキュメント作成は重要です。要件定義・設計・実装・テストなどの各段階で適切なドキュメントを作成し、プロジェクトの進捗や成果物を明確に管理します。

開発者や関係者がプロジェクトの全体像を理解しやすくなり、コミュニケーションの向上や問題の早期発見が可能となります。

2. 工程ごとにテストを実施する

ウォーターフォールモデルでは、各工程が独立して進むため、各工程の終了時には適切なテストを実施することが重要です。要件定義が終われば、機能やシステムの設計に移る前に適切な検証を行います。

同様に、実装やテストフェーズでも適切なテストを実施し、品質を確保します。バグや問題を早期に発見しやすくなり、後工程への影響を最小限に抑えることができるでしょう。

3. 正確なスケジューリングを行う

ウォーターフォールモデルでは、各工程が直線的に進行するため、正確なスケジューリングが不可欠です。各工程の開始と終了時点を明確に計画し、リソースや期限を考慮してスケジュールを策定します。

遅延や予期せぬ問題の発生に備え、柔軟性を持った計画を行うことが重要です。正確なスケジューリングにより、プロジェクト全体の進捗管理が容易になり、タイムリーに課題を対処できます。

システム開発における3つのモデル

システム開発には複数のモデルがあり、それぞれ開発の進め方が異なります。企業によっては独自の開発手法で進める場合もありますが、いずれかのモデルにあてはめて開発を進める形が一般的です。ここでは主な開発モデルを4つ紹介します。

アジャイル型は柔軟性と継続的な改善を追求し、プロトタイプ型は試作品を通じてユーザーの要望を具体的に確認する手法です。スパイラル型はリスク管理に焦点をあて、プロジェクトを螺旋状に進めていく柔軟性を持つモデルです。

1. アジャイル型

ウォーターフォール型と並ぶ代表的なシステム開発モデルに、アジャイル型があります。「要件定義」「設計」「開発・実装」「リリース」の工程を、機能ごとの小さい単位で繰り返しながら開発するシステム開発モデルです。

ウォーターフォール型が「システム全体」を見越して開発を進めるのに対し「俊敏」と訳されるアジャイル型では、機能単位でリリースする点が特徴です。修正や変更が生じることを前提に、柔軟に開発できるモデルといえるでしょう。

2. プロトタイプ型

プロトタイプとは「試作品」を意味し、開発の初期段階でプロトタイプを作成する開発モデルです。はじめに試作品を作成することで、目に見える指針ができるため、担当者間での認識ズレ防止につながります。

プロトタイプ作成後の工程は、ウォーターフォール型と同様です。大型開発の場合はプロトタイプを作成するだけでも工数や時間がかかるため、小さい規模のシステムを開発する際に向いているモデルといえるでしょう。

3. スパイラル型

システムを各機能（サブシステム）に分割し、サブシステムごとに設計・開発・テストを繰り返す開発モデルを、スパイラル型といいます。1サブシステムごとにプロトタイプを作成し、クライアントからフィードバックをもらって次のサブシステムに移る点が特徴です。

サブシステムごとに計画が進むため、途中で仕様変更があった場合でも柔軟に対応できる点がメリットです。一方で、各プロトタイプの作成に工数がかかるため、サブシステムが多い開発ではコストが高くなるデメリットがあります。

まとめ

システム開発の工程にはさまざまな開発モデルがありますが、代表的な手法はウォーターフォール型です。工程全体がシンプルでわかりやすいですが、前工程に戻ることが想定されていないため、工程が進んでからの修正・変更に対応しづらいです。

本記事では、システム開発の主な工程や代表的な開発モデルなどを紹介しました。システム開発会社の選定でお困りの場合は『比較ビズ』に相談してみてはいかがでしょうか。

「比較ビズ」では、必要事項を入力する2分程度の手間で、システム開発に詳しい専門家をスピーディーに探せます。どの専門家に相談すべきなのか迷うようなことがあれば、ぜひ利用してみてください。

監修者のコメント

株式会社GeNEE

代表取締役 日向野卓也

東京工業大学環境・社会理工学院卒業。慶應義塾大学大学院経営管理研究科修了。MBA（経営学修士）取得。国内最大手SIerの株式会社NTTデータで大手法人領域（大手流通企業、大手小売企業）の事業開発、事業企画等の業務に従事。米国スタンフォード大学への研修留学を経て、システム/モバイルアプリ開発会社の株式会社GeNEEを創業。

詳しく見る

システム開発のプロジェクトを成功させるためには、発注者と受注者が適時適切なタイミングでしっかりとコミュニケーションを取ることが重要になります。実際にシステム開発を行うのはシステム開発会社側の受注者になりますが、システムの完成形イメージを持つのはお客様側の発注者です。

お客様側がシステム開発会社側に誤った指示や伝達をしてしまうと、システムの完成形も変わってしまい、結果としてシステム開発のプロジェクトが失敗に近づいてしまいます。そのような事態に陥らないためにも、双方の意識合わせの時間や擦り合わせの時間がとても重要になるのです。

もし仮に方向性を誤った場合でもそれを放置することなく、すぐにコミュニケーションの場を設けるべきです。内容によってはプロジェクト期間が長引く可能性も十分に考えられますが、システム完成後に「イメージと違った。」、「もっとこうしたかった。」、というようなリスクを未然に防止することができるからです。

執筆者

比較ビズ編集部では、BtoB向けに様々な業種の発注に役立つ情報を発信。「発注先の選び方を知りたい」「外注する際の費用相場を知りたい」といった疑問を編集部のメンバーが分かりやすく解説しています。