SIerなどシステム開発の現場でよく用いられるウォーターフォール型開発について、近年注目されているアジャイル型開発と比較しながら解説します。
ウォーターフォール型開発を採用するメリットやデメリット、進め方や手法まで解説するので、システムエンジニア初心者やIT業界に転職を考えている方は基礎知識として参考にしていただけたらと思います。
目次
ウォーターフォール型とアジャイル型の違い
まず始めに、ウォーターフォール型開発とアジャイル型開発の違いについて解説します。
ウォーターフォール型開発とは
ウォーターフォール型開発とは、開発現場でよく用いられる手法で、開発手順を1つずつ確認しながら工程を進めていく手法のことです。開発を各工程に分けて進めますが、次のフェーズに進んでしまうと後戻りができない手法でもあります。
開発担当者や責任者、クライアントが各工程の成果物を共に確認し、双方の合意を得たうえで各工程を完了と見なしていきます。ウォーターフォール型開発の特徴は、ひとつひとつの工程に抜け漏れがないかどうか厳重に管理しながら進めていくことです。
クライアントに丁寧なヒアリング調査を行い、要件定義が完了次第作られる基本設計を土台にして詳細設計のフェーズへと進んでいくため、前の工程に欠陥があっては次へと進めません。
アジャイル型開発とは
アジャイル型開発とは、クライアントの要望に応えるシステムをできる限り素早くリリースしようという考えに基づいている開発手法です。クライアントのビジネスの始動を早めようという目的があります。
リリースを早くするには、搭載する機能を最低限の状態にする方法が取られるケースが多いです。アジャイル型開発では、開発メンバーがシステムにおける優先度に順位をつけ、短い期間での納品を目指して動きます。
システムの優先順位を決めるためにミーティングを毎日行い、チーム内でスムーズに連携をとる「スクラム」という手法が主に取られます。
ウォーターフォール型開発のメリット
次に、ウォーターフォール型開発を採用するメリットについて解説します。この開発手法には、主に2つの利点があります。
スケジュールを立てやすい
最大の利点は、プロジェクト全体のスケジュールを立てやすいことにあります。プロジェクトスタートと共に要件定義をし、基本・詳細設計に取り組んでいくので、早い段階でやるべきことを明確にして計画を立てられるのです。
俯瞰的にプロジェクトを把握できるため、各工程ごとにタスクを担当者に割り振れるので、プロジェクト開始後の進捗を比較的管理しやすい点も利点です。
要件定義が完了した段階で、ベテランのエンジニアはシステムの全容や、各工程にかかる工数を見積もれます。そのため、計画通りに開発を進めやすくなっているのです。
また、前の工程を完了させてから次のフェーズに進み、かつ各工程のタスクも前もって割り振られているため、プロジェクトの参加者が変更された際にも、引継ぎを行いやすい点が魅力だと言えます。
工程管理とスケジュール管理を効率的に行いたい場合はガントチャートが便利です。
============================================
関連機能: ガントチャート | 機能 | Backlog
============================================
予算やSE（システムエンジニア）の手配がスムーズに行える
ウォーターフォール型開発では、プロジェクトの開始当初に見積もった計画通りに各工程を遂行していきます。そのため、開発のための費用や、SE（システムエンジニア）やプログラマーの必要人員数が予測できます。
自社のシステムエンジニアで足りない人員は、パートナー企業から派遣してもらうなどしてリソースを確保しなければなりません。適任者を早い段階で見つけるためにも、必要な人員数を把握することは大切なことです。
各工程の計画通りにプロジェクトを完了させていくには、ウォーターフォール型開発は適した手法だと言えます。
ウォーターフォール型開発のデメリット
計画通りにプロジェクトを進行させられるウォーターフォール型開発ですが、デメリットもあるため、ここで解説します。
進行中に問題発生した時に手間がかかる
プロジェクト開始時にしか要件定義の機会はありません。要件定義や基本設計でしか要望をヒアリングできません。そのため、プロジェクト進行中や成果物を見た後に仕様変更が生じた際には大きな手間がかかってしまいます。
やり直しにかかった工数分、最終的な成果物の納品も遅くなってしまいます。テストの工程に進むまで、クライアントが実物を確認する機会はありません。そのため、後々仕様変更が生じる可能性も低くはないのです。
前段階のものをベースにして開発を進めていくため、手戻りが発生した場合には各工程をさかのぼってやり直さなくてはいけません。現在のフェーズだけをやり直すという選択肢がない点がデメリットです。さかのぼる工程が多ければ多いほど、問題は深刻なものとなってしまいます。
WBSの作成に時間がかかる
各工程で分業しているということは、計画管理資料であるWBSの作成にも時間がかかるということです。各工程のタスクごとに作成する必要があるからです。また、スケジュールに変更が生じた場合には、もう一度WBSを作り直す必要があります。
仕様変更などで手戻りが生じた場合にも、WBSを見直さなくてはいけません。作成者に負荷がかかるのは言うまでもないでしょう。
成果物作成に時間がかかる
ウォーターフォール型開発では、各工程の成果物が必要となります。そのため、プロジェクトの規模が大きければ大きいほど書類の量は膨大なものとなります。手戻りが生じた場合には、作成した書類も作り直す必要があるのです。
また、リリースまでに時間がかかる点もデメリットと言えます。中には何年もかけてシステムを開発することがあり、完了までに時間がかかるため、仕様変更などのアクシデントが発生しやすくなります。
ウォーターフォール型開発の手順
ウォーターフォール型開発は、具体的にどのような手順で進められるのか解説します。
1.要件定義
このフェーズでは、ヒアリング調査でクライアントが実装してほしい機能や性能を明確にしていきます。整理した情報をもとに、新しい業務フローやシナリオをクライアントに伝え、認識に齟齬がないか確かめます。
しかし、開発側にとって実装が難しいものは、難しいと伝える必要があります。安請け合いをして中途半端な成果物を納品することはゆるされません。このフェーズにおける成果物は要件定義書となります。
このフェーズは、ウォーターフォール型開発において最も重要なフェーズです。このフェーズでクライアントが求める機能はなにか、開発側が実現できるものはなにか、ということをどれだけ明確にしておくかによって、その後のフェーズ全ての手戻りの量が左右されます。クライアントが直接語る要望をそのまま要件とするのではなく、要望の裏に隠れている本当に解決したい問題を洗い出したり、想定される懸念点や齟齬が発生した際の対応指針などをあらかじめ共有・合意しておくのも良いでしょう。
2.基本設計
基本設計のフェーズでは、クライアントの要望を満たす機能や製品をどのように作るか決めます。作成すべき機能を洗い出し、どのようなハードウェアやミドルウェアを組み合わせることで機能が実装できるか明確にしておく必要があります。
実装すべき機能は要件定義書を参考にします。この段階の成果物は基本設計書となります。基本設計書をクライアントと共有し、仕上がりのイメージに齟齬がないかヒアリング調査します。
3.詳細設計
クライアントと共有する機会が多い基本設計書とは異なり、開発者や内部者に向けて書類を作成するフェーズです。実際にどのような開発を行いプログラムを動作させるかを決めていきます。
プログラマーはこのフェーズでの成果物である詳細設計書をもとにしてプログラミングしていきます。そのため、クライアント目線ではなくプログラマー目線で書類を作成しなければいけません。
機能が正常に動作した場合と、異常が見受けられた場合の処理方法も記載していく必要があります。特に異常時に関しては詳細に処理フローを記載しておきましょう。
4.実装
実装のフェーズでは、実際にプログラマーやエンジニアがプログラミングをしていきます。以前のフェーズで作成した基本設計書や詳細設計書をもとにして、クライアントの要望を叶える機能を実装していく段階です。このフェーズでの成果物はプログラムコードとなります。
5.単体テスト
単体テストでは、プログラミングして完成した機能単体がエラーなく作動しているかどうか、性能を評価します。想定通りに作動していることを証明できるエビデンスをとっていく必要があり、成果物もまたエビデンスとなります。
異常が発生した場合は、詳細設計書に記述してある通り、異常発生時の処理フローに従って異常を解決していきます。
6.結合テスト
結合テストでは、単体テストのフェーズで想定通りに作動した機能同士を連携させ、きちんと作動するか確認して性能を評価します。機能を連結させてもプログラムがエラーなく作動することを確認することが目的です。
結合テストでも、プログラムが想定通りに作動したことを証明できるエビデンスをとって、それを成果物とします。
7.総合テスト
総合テストでは、システム全体を連結させてその性能を評価します。全体を連結させてもエラーなく作動するか確認することが目的です。作動の様子を示すエビデンスを成果物とします。
異常が発生した場合は、前のフェーズに戻ってどこにエラーがあるのかを探らなければいけません。スムーズに機能が作動するようであれば、次のフェーズに進みます。
8.受入テスト
受入テストでは、本番環境でもエラーなく作動するかどうか確認します。エビデンスとなるのはシステム本体です。受入テストまで進んでから仕様変更があった場合には、変更に対応しなければいけないため、工数が余分にかかってしまいます。
本番環境でエラーが生じた場合には、機能が作動しない理由を探るために、前の段階へ戻る必要があります。このフェーズは導入テストとも呼ばれ、特に注意を払って本番環境でテストしなければなりません。
ウォーターフォール型が好まれるケース
ここでは、ウォーターフォール型開発が向いている開発ケースについて説明します。
品質を重視するケース
銀行のATM開発など、障害の発生が許されないケースがあります。そのような場合には、リリースの早さよりも、テストを数多く重ねて確実性を求めるウォーターフォール型開発が好まれます。
ウォーターフォール型開発は、テストを繰り返しするため、「障害発生率を限りなく0％に近づける」というクライアントの要望に応えやすくなっています。
プロジェクトの規模が大きいケース
プロジェクトで開発するシステムが巨大なものであればあるほど、人員数が必要となります。事前に各工程ごとに必要となる人数を見積もれるため、1番人手が必要となっているタイミングで、大量に人員を確保して開発をスムーズに進められます。
逆に人手が十分に足りている場合は、エンジニアやプログラマーを動員する必要がないため、必要な人員だけを残すことができます。
まとめ
ウォーターフォール型開発とは、プロジェクトを各工程に分け、確実に工程を進めていく開発手法のことです。エンジニアの間では古くから用いられてきました。
品質を重視するケースや人員を大量に確保しなければいけないケースで活躍し、テストを重ねて行うため、手戻りが発生した場合はその分手間や工数が余分にかかってしまう点が特徴です。各工程の成果物を丁寧に作成しておけば、次のフェーズに進みやすくなるでしょう。
現在でもよく使われる手法なので、エンジニア初心者やIT企業へ転職を考えている方は抑えておきたい知識です。
▼ウォーターフォール型開発に関連する記事
こちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com