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

弊社が提供しているアジャイルトレーニングの講義中、「ウォーターフォール開発」と「アジャイル開発」の違い、何がどれに向いているのか?といった質問を良く受けます。そこで、従来型の開発手法であるウォーターフォール型開発と、近年注目されている「アジャイル開発」をメリット・デメリットを含め比較しながら解説していきたいと思います!

Joe Justice

この記事でわかること

  • ウォーターフォール型開発とは?概念
  • ウォーターフォール型とアジャイル型の違い
  • ウォーターフォール型開発のメリットやデメリット
  • ウォーターフォール型開発の手順
  • ウォーターフォール開発は時代遅れ?向き・不向き

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

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

ウォーターフォールモデルとは、一つひとつの開発工程を完了させて進めていくシステム開発モデルです。

段階的に進めていくシステム開発手法
開発の工程は「要件定義」「計画」「分析」「実行」「テスト」「展開」という流れで実行されていることが多く、ウォーターフォールモデルでは、この一つ一つの工程を順番に進めていきます。「ウォーターフォール」とは、滝のように水が流れ落ちていく様を表しています。つまりいったんその工程を過ぎ次の工程に進むとほとんどの場合、各工程が完了すると前の工程にさかのぼることはありません。

ウォータフォール開発モデルの歴史

ウォーターフォール開発モデルは、もともと製造業や建設業で生まれました。高度に構造化された物理的環境では、事後の変更は不可能ではないにしても、非常に大きなコストがかかると考えられていました。そして、1956年のハーバートD.ベニントンと1970年のウィンストンW.ロイスの論文によって、ソフトウェア開発のための工程使用が説明されました。これがソフトウェアのウォーターフォール開発モデルの最初と言われることも多いですが、実際には誰がいつ「ウォーターフォール」と定義をしたのかは不明とされています。

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

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

ウォーターフォール手法では、チームが一連のステップに従い、前の工程が完了してから、次の工程へと進みます。成果物が最初から定義しやすいプロジェクトに適した仕組みです。

プロジェクト全体から見た計画が立てられる

ウォーターフォールモデルは、上流工程(要件定義)から確実に開発を進めていく手法のため、要件定義を終えた段階で、開発スケジュールの全容を把握することができます。開発する内容やスケジュールをしっかりと決めてからプロジェクトが進むため、計画を実行しやすいでしょう。

予算やリソースの見積もりが立てやすい

より詳細な計画を作れると人員の確保もしやすくなり、プロジェクトの最初の段階で「開発には何が必要」で「何が足りないのか」が分かりやすくなります。また、工程ごとに取り組むべきことが明確なため、開発者の入れ替わりが発生しても引き継ぎが簡単です。これにより、プロジェクトをストップせずに進められるでしょう。

進捗の管理がしやすい

ウォーターフォールモデルは、全ての工程を把握した状態で開発が進んでいきます。工程ごとに仕様書やタスクが決まっているため、進捗率を管理・把握しやすく、タスクのアサインが可能です。進捗管理を適切に行っていれば、トラブルが発生した際にも柔軟に対応することができます。

構造がシンプルわかりやすい

ウォーターフォールのステップは、他の手法と比べると、非常に明確に定義されています。構造はシンプルで、どのプロジェクトも以下のステップで進みます。

ウォーターフォールの流れ
  1. 要件収集とドキュメンテーション
  2. システム設計
  3. 分析
  4. 実行
  5. テスト
  6. 展開
  7. メンテナンス
Joe Justice

各フェーズの詳細は、ウォーターフォールの手順で詳しく解説しています。

チームが次のステップに進むには、その前のステップを完了しなければならないため、何か障害があれば、それがすぐに判明します。未完成のプロジェクトが完成されないまま取り残されるというリスクも低く、プロジェクト完了時の完成度や洗練度も高くなります。

成果物の目標・ゴールが明確である

ウォーターフォール手法で特徴的なステップのひとつが、最初の時点で最終製品、目標や成果物にコミットするというものです。チームはこういった初期段階で決定したコミットを極力達成するよう力を尽くします。

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

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

それでは、ウォータフォール開発のデメリットはどのようなものがあるのでしょうか。

仕様変更・要件変更など手戻りに柔軟に対応できない

最初に全体像を明確にした状態で開発が進められるため、急な仕様変更といった臨機応変な対応には向きません。手戻りが発生する場合であっても、ウォーターフォール開発では現在の工程のみをやり直すということができず、各工程をさかのぼってやり直すことになります。

顧客のレビューを取り入れにくい

ウォーターフォールは本来社内向けのプロセスのため、エンドユーザーや顧客のプロジェクトへの関与はあまり重きが置かれていません。ソフトウェア開発においては大きな問題はありませんでしたが、それ以外の業界では、顧客がプロジェクト中に関与し、意見を追加したり、プロジェクトの進行に合わせて要望を明確にしてくることもしばしば発生します。そのような場合、柔軟に顧客やステークホルダーの要望に対応する必要が出てきます。

成果物のリリースまでに時間がかかる

ウォーターフォール開発では、各工程の成果物が必要となります。そのため、プロジェクトの規模が大きければ大きいほど、ドキュメントの量が多くなります。手戻りが生じた場合には、作成した書類も作り直すことが必要になります。

また、リリースまでに時間がかかる点もデメリットと言えるでしょう。システム開発に何年もかかることがあり、完了までに時間がかかるため、市場やニーズの変化があり仕様変更などの急なアクシデントが起こることがあります。

テストのタイミングがプロジェクトの完了時であること

プロジェクト後半になるまで製品のテストをしないとリスクが高くなりますが、ウォーターフォール手法では、6つのステップのうち4つ目でようやくテストを行います。ソフトウェア業界以外の世界では、テスト工程には、多数の作業が含まれます。大きな修正が発生すれば大幅な遅延につながる可能性があります。

書類(ドキュメント)の制作が多い

成果物作成に時間がかかる、という点があります。ウォーターフォール開発では、各工程の成果物が必要となります。大量のドキュメント作成が発生します。また、手戻りが生じた場合にも、作成した書類も作り直す必要があるのです。

ウォーターフォール開発の手順

ウォーターホール型開発の手順

ウォータフォール開発ですが、以下の工程をひとつづつ実行していきます。

要件定義(要件収集とドキュメンテーション)

この工程では、顧客へのヒアリングをもとにクライアントが実装してほしい機能や性能を明確にしていきます。整理した情報をもとに、クライアントとの認識に齟齬がないか確認します。これはウォーターフォール型開発において最も重要な工程になります。

設計

基本設計

設計の工程では、クライアントの要望を満たす機能や製品をどのように作るか決めます。作成すべき機能を洗い出し、どのような技術を組み合わせることで機能が実装できるか明確にしておきます。

実装すべき機能は要件定義書を参考にします。この段階の成果物は基本設計書となります。基本設計書をクライアントと共有し、完成イメージに齟齬がないか確認します。

詳細設計

クライアントと共有する機会が多い基本設計書とは異なり、開発者や内部者に向けて書類を作成する工程です。実際にどのような開発を行いプログラムを動作させるかを決めていきます。

実装

実装の工程では、実際に実行・実装をしていきます。以前の工程で作成した基本設計書や詳細設計書をもとにして、クライアントの要望を叶える機能を実装していく段階です。

テスト

テストには色々な種類のテストが存在します。(ソフトウェア開発の例で言うと単体テスト、結合テスト、総合テストなどがあります)。

テストでは完成した機能単体が問題なく作動しているかどうか、性能を評価します。想定通りに作動していることを証明できるエビデンスをとっていく必要があり、成果物もまたエビデンスとなります。

異常が発生した場合は、詳細設計書に記述してある通り、異常発生時の処理フローに従って異常を解決していきます。

異常が発生した場合は、前の工程に戻ってどこに問題があるのか確認する必要があります。スムーズに作動することができれば、次の工程に進みます。

最終段階のテスト(受入テスト等)まで進んでから仕様変更があった場合には、変更に対応しなければいけないため、工数が余分にかかってしまいます。

運用・保守メンテナンス

プロダクトがリリースされた後は、運用・保守を開始します。プロダクトの安定稼働やさらなる改善を目指し、基本的にそのサービスが終了するまで、継続的にバグの修正やアップデートといった運用・保守を行います。

ウォーターフォール開発は時代遅れ?向き・不向き

ウォーターホール型開発は時代遅れ・向き・不向き

Vucaの時代(未来の予測が難しくなる状況)と言われる昨今、「ウォーターフォール開発は今後使われなくなっていく」という事を聞くことがあります。それでは、どのようなケースがウォーターフォール開発に向いていて、どのようなケースが向いていないのでしょうか。

ウォーターフォール開発が向いているケース

一般的に以下のような場合、ウォーターフォール開発が向いているケースと言われます。

要件が定まっていてゴールが明確なプロジェクト

あらかじめ要求事項が固定されており、原則として変更されないような開発に向いていると言えます。つまりウォーターフォール開発は、前述した通り手戻りをしないことが前提になるため、「仕様変更がない」開発に向いています。ウォーターフォールモデルでは、仕様変更をせずに済むように入念な要件定義をしなければなりません。

ウォーターフォール開発が向いていないケース

ターゲットとする市場やニーズの変化が多く、またその変化が早い場合や、ユーザーからのフィードバックを取り入れながら開発を進めるような開発工程の途中での変更が多く発生する開発などはウォーターフォールは向いていません。

Joe

ウォーターフォール型開発の向き不向きと合わせて、ウォーターフォールとアジャイル開発の違いも理解しておいてください。

まとめ

ウォーターフォールのこうした原則に対応するために作られたのがアジャイル手法です。アジャイル開発が主流の開発手法となりつつある近年において、ウォーターフォール開発は古い開発手法であるとみなされることもありますが、ウォーターフォール開発にも利点はあります。

一般的にはウォーターフォール開発はプロジェクト開始後の変更が少なく、高い品質を担保しやすいという特徴があることから、変化が少ない、または変化に対する柔軟性を重視しない場合はウォーターフォールの方が適していると言えます。
一方で、開発の途中での変更が見込まれる場合や、ユーザーからのフィードバックを得ながら開発を進めていきたい場合はアジャイル開発の方が適しているでしょう。

ウォーターフォール開発とアジャイル開発は、それぞれの開発手法のメリット・デメリットを理解した上で、開発手法を適切に決めていくことが求められます。

Agile Business Institute

Joe Justice指導の人気講座

  • 認定スクラムマスター(CSM)
  • 認定プロダクトオーナー(CSPO)
  • JoeDX
  • Executive Agile Transformation

認定スクラムマスター(CSM)

認定スクラムマスター/Certified ScrumMaster®は、Scrum Alliance®が提供する認定資格です。 この認定は、スクラムフレームワーク、チームメンバーの活動や役割などを深く理解するのに役立ちます。この認定を取得することで、スクラムチームが協力して効果的にプロセスを実行できるようになります。

認定プロダクトオーナー(CSPO)

認定スクラムプロダクトオーナー/Certified Scrum Product Owner®は、Scrum Alliance®が提供する認定資格です。プロダクトオーナーは顧客の視点からプロダクト価値の最大化を考えます。スクラムを機能させるためのフレームワークに加えて、プロダクトの価値を向上させるために必要なスキルを学びます。

JoeDX

JoeDXは、Agile Business Instituteが提供する資格です。
ハードウェア開発のためのアジャイルプロセスについて学べます。アジャイルハードウェア開発には、イノベーションのスピードを上げるためのエンジニアリング、マネジメント、ビジネスプラクティスが含まれています。

Executive Agile Transformation

「メンバーとエグゼクティブ、エンジニアと顧客との間で『共通の解釈』を持つ、つまり『ナレッジ化』が出来れば、組織や開発の現場はより発展するだろう」このような開発現場からのリアルな要望からEAT(エグゼクティブ アジャイル トランスフォーメーション)は誕生しました。企業の組織力の向上に大いに貢献するクラスです。

Joe Justice指導の人気講座

  • 認定スクラムマスター(CSM)
  • 認定プロダクトオーナー(CSPO)
  • JoeDX

認定スクラムマスター(CSM)

認定スクラムマスター/Certified ScrumMaster®は、Scrum Alliance®が提供する認定資格です。 この認定は、スクラムフレームワーク、チームメンバーの活動や役割などを深く理解するのに役立ちます。この認定を取得することで、スクラムチームが協力して効果的にプロセスを実行できるようになります。

認定プロダクトオーナー(CSPO)

認定スクラムプロダクトオーナー/Certified Scrum Product Owner®は、Scrum Alliance®が提供する認定資格です。プロダクトオーナーは顧客の視点からプロダクト価値の最大化を考えます。スクラムを機能させるためのフレームワークに加えて、プロダクトの価値を向上させるために必要なスキルを学びます。

JoeDX

JoeDXは、Agile Business Instituteが提供する資格です。
ハードウェア開発のためのアジャイルプロセスについて学べます。アジャイルハードウェア開発には、イノベーションのスピードを上げるためのエンジニアリング、マネジメント、ビジネスプラクティスが含まれています。

Executive Agile Transformation

「メンバーとエグゼクティブ、エンジニアと顧客との間で『共通の解釈』を持つ、つまり『ナレッジ化』が出来れば、組織や開発の現場はより発展するだろう」このような開発現場からのリアルな要望からEAT(エグゼクティブ アジャイル トランスフォーメーション)は誕生しました。企業の組織力の向上に大いに貢献するクラスです。