目次
数あるシステム開発の手法の中で、最も認知度が高いと思われるのがウォーターフォールモデルです。大規模開発を行う際など、アジャイル開発が不向きといわれるシステム開発の現場で採用されている手法です。
本記事では、ウォーターフォールモデルの概要やメリット・デメリット、ウォーターフォールモデルの工程と流れについて解説します。アジャイル開発との違いについても触れています。ぜひ参考にしてください。
ウォーターフォールモデルとは?
ウォーターフォールモデルとは、上流工程から下流工程へという流れでシステム開発を行う手法です。「ウォーターフォール」とは日本語に訳すと『滝』を意味します。工程を策定し、細かく分け、川上から川下に向かって流れる滝のように、上流工程から下流工程へ順次移行していく開発手法であることからこの名がつけられました。
品質を重視したシステム開発に適している、大規模開発と相性がいいなどの理由から現在でも広く採用されている手法です。
「ウォーターフォール型開発」とも表現されますが、同じ意味です。関連するキーワードとして「V字モデル」や「W字モデル」があげられます。これらのモデルにおけるそれぞれの工程はウォーターフォールの工程そのものです。上流工程がどのテスト工程(フェーズ、レベル)に対応しているのかも明確になっています。
ウォーターフォールモデルとV字モデルの違い
V字モデルとは、システム開発の工程をある段階でV字にし、並べたものを指します。上から下へ滝のように工程が下がっていくウォーターフォールモデルの発展型といえるもので、向かって左側の工程に対してそれらに対応するテストが右側に並びます。以下の図がV字モデルです。
V字モデルで表すことで、テストのレベルとその対象範囲が可視化できるというメリットがあります。
ウォーターフォールモデルとV字モデルは、別のものではなく、ウォーターフォールモデルを発展させた形がV字モデルと捉えるのが良いでしょう。V字モデルをさらに発展させた開発方法にW字モデルもありますが、V字モデルで一つずつ進めていた開発工程とテスト工程を同時進行にしたものであり、こちらもウォーターフォールモデルの一種といえるでしょう。
ウォーターフォールモデルとアジャイル開発の違い
ウォーターフォールモデルと比較する形で、アジャイル開発という手法を耳にする機会も増えてきました。アジャイル開発は大まかな計画を細分化して要件定義・設計・実装・テストを何度も繰り返す開発手法です。2000年代から注目・導入された開発手法で、ウォーターフォールモデルからアジャイル開発に切り替える開発チームも増えています。
ウォーターフォールモデルとアジャイル開発にはいくつかの違いもあり、開発規模の適性も異なります。それぞれの違いを以下にまとめました。
ウォーターフォールモデル | アジャイル開発 | |
メリット | ・全体スケジュールが立てやすい ・予算や人員確保がしやすい |
・開発スピードを速められる ・仕様変更やトラブルに柔軟に対応できる |
デメリット | ・トラブルや仕様変更に手間や時間、 コストがかかる ・完成までに時間がかかる |
・開発の方向性がぶれてしまうことがある ・全体のスケジュールが把握しにくい |
向いているプロジェクト | ・基幹システムなどの大規模開発 | ・アプリやゲームなど要求や変化に素早い 対応が必要な開発 |
ほかにも次のような違いがあります。
・企画段階における違い
ウォーターフォールモデルでは、最初の企画段階ですべての機能を決定します。クライアント次第では要求によって仕様変更をすることもありますが、基本的には企画段階での仕様を優先して開発を進めていきます。一方、アジャイル開発ではイテレーションごとの開発になるため、新たな要求が発生した際には次のイテレーション以降でその要求に対応するか否かを決定する必要があります。
よく「アジャイル開発は計画がない」という誤解がありますが、実際はイテレーションごとに計画しているので、より計画的といえる側面もあります。
・開発段階における違い
開発工程によって分業するウォーターフォールモデルでは、要件定義からリリースまで一連の流れを見届けるメンバーの方が少ないです。一方、アジャイル開発ではチーム一丸となって開発するため、企画からリリースまでチーム全員で行うことが多いです。
関連サービスについて
ウォーターフォールモデルの特徴
ウォーターフォールモデルは各開発工程がトップダウン形式(上流から下流への一方通行)で進められることが前提となっているため、基本的には一つの工程を完了させてから次の工程に進みます。手戻りは想定されていないため、万が一逆戻りしなければならない場合は大変ですが、常に当初定めた要件通りになる開発が行われます。
特に大規模な開発においては完成した成果物の品質が求められるケースが多いため、ウォーターフォールモデルが採用されます。
ウォーターフォールモデルの将来性
ウォーターフォールモデルの登場から半世紀が経過し、さらに最近ではアジャイル開発と呼ばれる新しい開発モデルも普及し始めました。これらの影響からウォーターフォールモデルは時代遅れという声を聞く機会が増えているかも知れません。
確かにウォーターフォールモデルは、提案された当時と比較するとソフトウェア・ハードウェアの需要が拡大したことで応用しにくい側面があるのも否定はできません。
しかし、大規模開発に適していたり、機能や予算を明確にできたりというメリットもあります。開発に時間を要するのは事実ですが、反面アジャイル開発よりもある程度品質を担保しやすいという面でウォーターフォールモデルは優位性を保っていることも忘れてはいけません。
将来性が疑問視されることもあるウォーターフォールモデルですが、今後もアジャイル開発と並行して活用し続けられるでしょう。新しい手法であるアジャイル開発がウォーターフォールモデルのすべてを代替できるわけではなく、ウォーターフォールモデルの特徴が生かせる場面で活用されるものと考えられます。
ウォーターフォールモデルのメリット
ウォーターフォールモデルは以下のメリットから採用されている手法です。
・進捗管理が容易である
・一定の品質を担保できる
・予算やリソースの計画と確保がしやすい
・ゴールが早い段階で決まる
それぞれ詳細を見てみましょう。
進捗管理が容易である
ウォーターフォールモデルでは、要件定義で必要なタスクを洗い出し、設計、テストを行います。行うべきタスクが明確になっているため、進捗がわかりやすいのがメリットです。また、どこのタスクで時間がかかるのか明確にできるので、事前の人員調達も容易となります。
一定の品質を担保できる
ウォーターフォールモデルは開発に入る前に詳細なスケジュールを決定しており、各工程であらかじめタスクが決められているため、一定の品質を担保することができます。基本的に大きな変更や手戻りは起きないという前提で開発が進むため、各工程を完成させてから次の工程へ進む必要があります。そのため、よく対比されるアジャイル開発よりもある程度の品質を担保しやすいことも特徴です。
予算やリソースの計画と確保がしやすい
前述のとおり、ウォーターフォールモデルは、上流工程において入念に計画を立てた上で進行します。そのため、初期段階から何をどのくらいの期間で作り、どのくらいの工数がかかるのかが明確になり、先々の予算やリソースの計画と確保がしやすいというメリットがあります。
ゴールが早い段階で決まる
ウォーターフォールモデルでは初期段階で最終的な目標が明確になります。それは、チーム全体の目標として機能し、常に目標を意識しながらプロジェクトが進行するため、方向性がブレることを避け、想定する成果物により正確にコミットすることが可能になります。
プロジェクトを個々のイテレーションに分割して行うアジャイル開発とは違い、チームで同じ目標を意識して開発を行います。
ウォーターフォールモデルのデメリット
メリットが多いウォーターフォールモデルですが、一方でデメリットの存在を無視してはいけません。
・途中の仕様変更がしにくい
・実際に動く成果物ができるまでに時間がかかる
・世の中の変化やユーザーのニーズに対応した開発が難しい
・手戻りなどによる工数が増加しやすい
途中の仕様変更に対応しにくい
ウォーターフォールモデルは、プロジェクト全体の流れやすべての工程が最初から決まっているため、仕様変更が難しいというデメリットがあります。要件定義が命といわれることもあり、原則として開発途中の仕様変更などは発生しないという前提で開発計画と要件定義を実施します。
そのため、仕様の変更や追加があった場合、本来の順序に逆らって前の工程に戻さなければなりません。その結果、工程が複雑化してしまい、最終的な成果物がクライアントのニーズを満たしていないということも起こり得ます。仕様変更が起きないようにするためには、要件定義の段階でユーザーやクライアントとの検討を重ね、認識を一致させる必要があるでしょう。
実際に動く成果物ができるまでに時間がかかる
設計の後にならないと開発工程に進めないため、成果物の確認までに時間がかかってしまいます。「途中の仕様変更に対応しにくい」でも触れた通り、要件定義をしっかりと決定したうえで開発を行います。
加えて、開発開始後もそれぞれの工程を終えてからでなければ次の工程には進めません。性質上、時間がかかるのはデメリットといえるでしょう。
世の中の変化やユーザーのニーズに対応した開発が難しい
開発が始まってからの仕様変更が難しいため、企画からリリースまでの間に世の中の状況が大きく変化してしまったり、ターゲットとするユーザーのニーズが変わってしまったりすることもあります。デジタルデバイスの普及やIT化・DX化はすさまじい勢いで進化しており、その速度に合わせてソフトウェアもハードウェアも進化することが求められています。
例えば、スマホアプリや関連するシステム開発においては、変化についていけないとユーザーの満足度を落としかねません。
しかし、大前提としてウォーターフォールモデルはこれらの変化を考慮しない開発モデルです。採用するのであれば頻繁に変更が生じるような開発は避けるべきでしょう。
手戻りなどによる工数が増加しやすい
どんなに上流工程で綿密に作られた仕様でも、開発をする中で仕様変更が発生したり、仕様通りにできていないことが発覚したりすることがあります。
仕様変更や手戻りが発生すると、前の段階からやり直しとなり、工数やコストが発生します。計画を前提とするウォーターフォールモデルの開発では、仕様変更や手戻りによって想定以上の工数がかかる場合があります。結果、全体のスケジュールに影響をおよぼすこととなるため、成果物の納品も後ろ倒しになります。
完全に抜けや漏れを防ぐのは不可能ですが、要件定義の段階で十分に検討を行い、関係者の間で認識を揃えておくことはできます。手戻りが発生した場合は、クライアントに伝え、納期やコストに関する相談をする必要があるでしょう。
アジャイル開発白書
近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。
近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。
関連サービスについて
ウォーターフォールモデルの流れ・工程
基本的なルールとして、工程を飛ばして作業することはなく、開発担当者や責任者、クライアントが各工程の成果物を共に確認し、双方の合意を得たうえで各工程を完了と見なした際に、次の工程へと進みます。そのため、基本設計の後に詳細設計が終わっていない状態でテストを行うことはありません。しかし、作成するソフトウェアの仕様変更があった場合などには、前の工程に戻って作業することがあります。
ウォーターフォールモデルの開発工程は次の通りです。
1.要件定義
2.基本設計
3.詳細設計
4.コーディング
5.テスト
6.リリース
続いて、以下で各工程の詳細を解説します。
①要件定義
ウォーターフォールモデルにおいて、要件定義は非常に重要なウェイトを占める部分です。目的は開発するシステムの目的とゴール、およびニーズを明確化するためです。ひと口に要件といっても、業務要件とシステム要件の2つに分けることができ、さらにシステム要件を機能要件と非機能要件の2つに分けて定義する必要があります。
・業務要件:システム利用者が要求する業務の在り方と運用をふまえて業務手順や入出力する情報(画面、帳票、ファイル)などを定義したもの
・システム要件:システム化する部分としない部分を決める
→機能要件 :開発するシステムに必要な機能を決める
→非機能要件:パフォーマンスや拡張性などの機能とは別で定義するものを決める
上記の4項目を決めて要件定義書へと落とし込みます。この段階でクライアントと開発側での認識不足や価値観のズレが発生すると、後々手戻りなどの負担が発生する可能性があります。クライアントも開発側も積極的に意見交換し、要件定義書を作成しなければなりません。
②基本設計
要件定義書に記載された情報をもとに、ユーザーが使用するレベルになるまでのイメージを設計図に落とし込む工程です。要件定義はあくまでも完成時の姿を言語化したものであり、詳細な設計はされていません。そのため、基本設計の作成をもって、完成させるまでにどのような開発や関連する要素として何が必要なのかを整理する必要があるのです。
基本設計書に落とし込むのは以下の通りです。
・業務フロー図
・機能一覧
・ネットワーク図(構成図)
・テ―ブル協議書
・ER図(実態関連図)フローチャート
・画面レイアウト(ヘッダー、ボディ、フッター など)
・帳票レイアウト(HTML、PDF など)
・データの入出力(Excel、CSV など)
・規約(命名規約、コーディング規約 など)
具体的にはシステム操作画面をイメージし、作成していきます。完成後はクライアントからのフィードバックを受け、修正を経てから詳細設計へと移ります。要件定義から見える完成予想図が、大きく逸脱したものになっていないかを確認するための重要な工程です。
③詳細設計
基本設計をさらに現場での開発レベルに細分化する工程を詳細設計といいます。エンジニアやプログラマーが何をするのかを明確にする工程で、開発者側が動きやすくするために必要な工程です。
詳細設計の際には詳細設計書が作成されますが、大別すると次のような設計書が必要となります。
・機能設計書
・Webサーバー設計書
・データベース設計書
・バッチ処理設計書
上記以外にも必要な設計書や仕様書があれば、別途作成します。詳細設計以降の開発は外注されることも多いため、入念な作りこみが必要となります。
④コーディング
詳細設計が完了したらいよいよ開発に移ります。実装やコーディングと呼ばれており、要件定義で定められたプログラミング言語を使用して開発を開始します。
⑤テスト
コーディングによって完成したプログラムコードが問題なく稼働するか、機能の使用中にエラーは発生しないかを評価する工程です。ここで当初の計画通り稼働しないようであれば、詳細設計書に記載されている処理フローに従って対処します。
テストには、次の4つの種類が存在しています。
・単体テスト
完成した機能が単体で正常に動作するかを確認するテスト
・結合テスト
単体テストをクリアした機能を連携させて正常に動作するかを確認するテスト
・システムテスト(総合テスト)
システム全体を連携させて正常に動作するかを確認するテスト
・受入テスト
本番環境でもエラーが発生しないかを確認するテスト
各テストで不具合が見つかれば、前段階に戻る必要があります。
⑥リリース
テストが完了し、問題なく動作することが確認できてはじめてリリースとなります。
ウォーターフォールモデルの活用方法
ウォーターフォールモデルのメリットでも記載したとおり、ウォーターフォールモデルでは、開発の計画や予算の見積もりが容易になります。
人員調達も容易になるため、大規模なプロジェクトに向いています。また、工程ごとに決められた基準を満たしてから次の工程に移るため、ある程度の品質を担保しやすくなるでしょう。
しかし、プロジェクト期間中の要件の変更には手戻り工数が多くかかるため、途中の変更が多く予定されているプロジェクト(ユーザーの声を取り入れながら開発するプロジェクト)などにはウォーターフォール開発はあまり向いていません。こういった背景からか、特に組込みシステム開発ではウォーターフォールモデルが主流となっています。
開発・テストの相談はSHIFTグループにお任せ
ウォーターフォールモデルは最も一般的な開発手法の1つです。しかし、メリット・デメリットがあり、プロジェクトや状況、企業の体質、メンバーのスキル・成熟度といったさまざまな要素を考慮したうえで開発手法を選択することがプロジェクト成功のカギとなるといえるでしょう。
SHIFTではテスト工程での支援(テスト計画、テスト設計、テスト実行)はもちろん、上流工程から参画して仕様書の欠陥を早期発見し、コスト超過を防止するインスペクションや、プロジェクト運営支援や開発・テストプロセス標準化といったさまざまなサービスを展開しています。
ウォーターフォールからアジャイル開発への移行支援も行っていますので、気になるサービスがありましたらお気軽にお問い合わせください。