ウォーターフォール開発は、要件定義から設計、実装、テストへと、前工程で合意した成果物を次工程の前提にして進める開発の進め方です。Webサービスやスマホアプリの開発では、手法名だけで選ぶのではなく、要件をどこまで早く固められるか、変更や早期検証がどれほど起こり得るかを見極めることが重要です。
この記事では工程ごとに決めることと品質確認のつながりを整理し、アジャイル開発との違い、向き不向きの判断条件を解説します。案件条件から、ウォーターフォール中心・アジャイル中心・組み合わせ型を検討できるようになります。
ウォーターフォール開発は、前工程で合意した成果物を次工程の前提にする進め方です。変更と品質確認の扱いを含めて、案件条件に合う進め方を検討します。
01Sectionウォーターフォール開発とは
ウォーターフォール開発とは、企画・要件定義、設計、実装、テスト、リリースといった工程を、前工程の成果物をもとに順に具体化していく進め方です。各工程の節目で、対象範囲、仕様、成果物、担当範囲、品質確認の方法を合意し、次工程へ進む判断を行います。
前工程の成果を次工程の前提にする進め方
この手法の目的は、単に工程を固定することではありません。複数の部門、利用者、開発担当、外部連携先が関わる案件で、「何を作るか」「どの状態なら完了とするか」「誰が確認するか」を成果物として共有し、進捗と品質を管理しやすくすることにあります。
工程の呼び方は組織や契約によって異なります。「基本設計」を「外部設計」と呼ぶ場合もありますが、名称よりも、その工程で何を具体化し、次の工程で何を確認できる状態にするかを押さえることが大切です。開発全体の一般的な流れは、システム開発の流れでも確認できます。
見直しが必要になったときは変更として管理する
ウォーターフォール開発でも、法令改正や業務変更、外部連携先の仕様変更、認識差などにより、要件や設計を見直すことがあります。
ただし、見直しを口頭で処理すると、設計、実装、テスト、移行、受入条件への影響が追えなくなります。変更する場合は、影響範囲、費用、日程、品質、優先順位を評価し、判断者が合意してから反映します。関連する要件・設計・テスト計画も更新します。
02Sectionウォーターフォール開発の主な工程
工程名や成果物は案件によって変わりますが、各工程で決めた内容をレビューし、次工程で確認可能な状態にする点が重要です。
ここでは、Webサービス・スマホアプリ開発で用いられることがある6工程を例に、各工程の目的と確認点を整理します。実際の成果物や承認方法は、案件の規模、体制、契約条件に合わせて定めます。
工程別レビュー表の見方
表で特に確認したいのは、「次工程へ進む判断」です。成果物が提出されたかだけではなく、重要な未決事項、例外処理、受入条件、判断者が整理されているかを確認します。
| 工程 | 主な目的 | 代表的な成果物例 | 発注側・利用部門の確認点 | 次工程へ進む判断 |
|---|---|---|---|---|
| 企画・要件定義 | 課題、対象範囲、要件、受入条件を定める | 要件定義書、業務フロー、機能一覧、受入条件 | 対象外、優先順位、例外処理、連携、性能・セキュリティ | 重要な未決事項と決裁者が明確である |
| 基本設計 | システム全体の構造と外部接続を定める | 画面一覧、データ設計、API・連携仕様、権限設計 | 業務運用、連携先との責任分界、権限、監査 | 要件を満たす全体像と制約が確認済みである |
| 詳細設計 | 機能・部品ごとの実現方法を定める | 処理設計、画面遷移、入力チェック、例外処理 | 業務例外、データ項目、帳票・通知条件 | 結合時に確認する仕様を追跡できる |
| 実装 | 設計に基づき構築する | ソースコード、設定、単体テスト結果 | 通常は開発側が確認する。重要な仕様変更は発注側も判断する | 単体レベルの確認が完了している |
| テスト | 要件・設計との整合を確認する | テスト計画・ケース・結果、不具合一覧 | 受入条件、業務シナリオ、未解決事項、合否基準 | 合否基準と残課題の扱いが合意済みである |
| リリース・運用移管 | 利用開始と安定運用を準備する | 移行計画、切替手順、運用手順、連絡体制 | データ移行、切戻し、教育、保守範囲 | 稼働判定条件を満たしている |
要件定義で受入条件まで意識する理由
テストや受入は、完成後に初めて考えるものではありません。要件定義の段階から、「誰が、どの業務シナリオで、何を満たせば受け入れるのか」を整理しておくと、設計・実装・テストで確認すべき対象を追跡しやすくなります。
外部連携や権限管理、性能、障害時の運用が要件に含まれるなら、確認環境、テストデータ、合否基準、残課題の扱いも早い段階で検討します。
03SectionV字モデルで要件とテストの対応を確認する
V字モデルは、要件や設計で決めた内容を、対応するテストで確認するための整理方法です。テスト区分や実施体制は案件条件に合わせて定めます。
V字モデルは、左側で具体化する要件・設計と、右側のテストで確認する対象を対応付ける整理方法です。テストを「完成後の不具合探し」にとどめず、要件や設計で決めたことを確認する活動として計画する際に役立ちます。
V字モデルは案件ごとのテスト設計に合わせて使う
工程名、テスト名、実施主体、性能・セキュリティなどの非機能要件を確認する区分は、対象システム、組織、契約、受入条件、テスト計画によって変わります。受入テストと検収の関係も固定ではないため、契約書、受入条件、テスト計画で確認してください。
V字モデルは確認漏れを防ぐ整理例
IPA「SEC journal No.21」には、要件定義と受入テスト、基本設計とシステムテストなどを対応付けるV字モデルの掲載事例があります。以下は、その考え方を確認対象ごとに整理した原則例です。
| 左側：具体化する工程・成果物 | 右側：対応するテスト | 主な確認対象 | 主な実施主体・留意点 |
|---|---|---|---|
| 要件定義・受入条件 | 受入テスト | 業務・利用者要求、受入条件、合否基準を満たすか | 発注側・利用部門が主導する場合がある。主導者と検収との関係は契約・受入条件・テスト計画で確認する |
| 基本設計 | システムテスト | システム全体、外部連携、性能、セキュリティ等が要件に適合するか | 主に開発側が担うことがある。非機能要件は単一のテスト区分に固定しない |
| 詳細設計 | 結合テスト | 機能、モジュール、API等の連携が設計どおりか | 主に開発側が担うことがある。結合対象とテストデータを設計段階から確認する |
| 実装 | 単体テスト | 個々のプログラム・部品が仕様どおりか | 主に開発側が担うことがある。完了基準と確認結果を定める |
非機能要件は複数の確認機会に分ける
性能、可用性、セキュリティ、監査ログ、障害対応などの非機能要件は、特定のテスト工程だけで完結するとは限りません。要件定義で受入基準を置き、設計で実現方法を確認し、必要なテストや運用確認で検証します。リスクに応じて、複数工程に確認を配置することが重要です。
04Sectionウォーターフォール開発のメリット・リスクと抑え方
ウォーターフォール開発の利点は、対象範囲、成果物、役割、マイルストーン、品質基準を整理しやすいことです。一方で、上流の認識ずれや変更が後工程で判明すると、影響が設計・実装・テストへ連鎖しやすくなります。
IPAの機能要件に関する資料でも、上流工程での合意形成を重要な論点として扱っています。文書を承認した事実だけで認識がそろったと考えず、利用部門を含む確認を設計することが必要です。
利点を生かし、リスクを抑えるための確認ポイント
工程・成果物を定める
役割分担、進捗、承認の状況を追いやすくなります。一方で、文書上の承認だけで業務理解がそろったと誤認するおそれがあります。業務部門のレビュー、画面試作、確認観点の明文化を組み合わせます。
上流で要件を具体化する
見積もり、テスト、受入条件を計画しやすくなります。要件の誤認が後工程で判明すると影響範囲が広がりやすいため、例外処理を含むレビューと、受入条件の早期定義を行います。
変更を正式に扱う
範囲・予算・日程の統制を保ちやすくなります。口頭変更や承認待ちの滞留は計画の不整合につながるため、変更台帳、影響評価、決裁者、判断期限を定めます。
テストを計画する
要件・設計に対応した品質確認を行いやすくなります。受入条件が曖昧だと合否や残課題の判断が難しくなるため、テストケース、合否基準、未解決事項の扱いを事前に合意します。
05Sectionウォーターフォール開発とアジャイル開発の違い
比較の前提として、どちらの手法でも、目的、対象範囲、予算枠、品質条件、主要な制約、関係者の役割を整理する必要があります。アジャイル開発は初期計画や品質条件が不要な進め方ではなく、全体の方向性と優先順位を置いたうえで、直近の単位を詳細化していく考え方です。
デジタル庁のアジャイル開発実践ガイドブックでも、リリースプランニングで全体計画を作り、開発の進行やフィードバックに応じて見直す考え方が示されています。
| 比較軸 | ウォーターフォール中心 | アジャイル中心 | 共通して必要なこと |
|---|---|---|---|
| 詳細要件の具体化 | 開発前・工程開始前に全体を具体化しやすい | 優先順位を置き、直近の反復単位で詳細化しやすい | 目的、対象範囲、予算枠、品質条件、制約を整理する |
| 変更の取り込み | 影響評価、再見積もり、承認後に計画へ反映する | 優先順位を見直し、次以降の反復へ反映しやすい | 変更内容、理由、影響、決裁を記録する |
| 利用者確認 | 要件・設計レビュー、受入テストなど節目で行いやすい | 動く成果物を短い周期で確認しやすい | 利用者・決裁者の参加方法と判断権限を定める |
| リリース単位 | 全体または大きな機能群を計画しやすい | 小さな機能単位で段階提供しやすい | 運用、移行、品質、リリース制約を満たす |
| 統制方法 | 成果物、工程完了、レビューで管理しやすい | 反復計画、レビュー、動く成果物で管理しやすい | 全体計画、マイルストーン、品質・リスク管理が必要 |
ウォーターフォール中心でも、画面試作や節目での利用者レビューを取り入れることはできます。反対にアジャイル中心でも、外部連携、セキュリティ、移行、リリース日など、早期に合意すべき制約がなくなるわけではありません。
領域ごとに不確実性が異なる場合は、基盤・外部連携・データ移行を計画駆動で管理し、UIや新機能を反復的に検証する組み合わせ型も検討できます。
06Sectionどの案件に向くか：時代遅れではなく適合性で選ぶ
開発手法は新旧ではなく、要件の確定しやすさ、変更、検証、統制、リリースの条件を踏まえて選びます。領域ごとに進め方を組み合わせる選択肢もあります。
ウォーターフォール開発が時代遅れかどうかは、手法の新旧だけでは判断できません。要件を早期に具体化できるか、変更をどの程度許容するか、いつ利用者確認が必要か、統制とリリースの制約がどの程度強いかで判断します。
初期に要求を確定しにくく、利用者や市場の変化を踏まえた検証を重視する領域では、反復的な進め方が選択肢になります。IPAの非ウォーターフォール型開発に関する資料も、変化への対応を重視する場面での適用観点を紹介しています。
5条件で進め方を検討する
- ✓
要件確定度：対象範囲、業務ルール、受入条件の多くを開始前に具体化できるなら、ウォーターフォール中心を検討しやすくなります。基盤・連携は確定している一方でUXが未確定なら、組み合わせ型が候補になります。
- ✓
変更頻度：法令、業務、優先順位、利用者要望の変更が比較的少ないなら、前工程での合意を生かしやすくなります。変更が継続的に起こる領域は、アジャイル中心または反復レビューを検討します。
- ✓
早期検証：節目でのレビューと受入確認で足りるか、動く画面・機能を短い周期で利用者に確認する必要があるかを整理します。後者が強い領域は反復的な進め方に向きます。
- ✓
統制要件：外部連携、データ移行、監査、セキュリティ、性能、承認の条件を早期に整理する必要が強いなら、全体の計画と成果物管理を重視します。
- ✓
リリース制約：一括切替、固定日、停止可能時間などの制約が強いか、機能を段階的に提供できるかを確認します。基盤切替は計画駆動、機能追加は段階提供とする設計も可能です。
この確認は絶対的な判定ではありません。同じ案件でも、全体統制が必要な領域はウォーターフォール中心、利用者体験を確かめたい領域はアジャイル中心というように、条件ごとに進め方を分けることがあります。
発注・検収前に確認すること
- ✓
見積もりは金額の前に、対象範囲・対象外、工程・成果物、前提条件を各社でそろえて比較する。
- ✓
変更は口頭で処理せず、影響評価と費用・日程への影響、決裁者の承認を記録してから反映する。
- ✓
受入テストと検収の関係、合否基準、残課題の扱いを、契約書と受入条件で確認する。
Webアプリ・SaaS開発の相談先を比較する
要件の整理、開発手法の選定、見積もり比較を進める際は、対応領域や支援範囲を確認しながら、開発パートナーを比較できます。
Webアプリ・SaaS開発4593社掲載
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。
