ウォーターフォール開発の流れを理解しよう！
- IT業界に興味がある方！
- IT業界初心者の方！
- システム開発業務に興味がある方！
- これからシステム開発業務に携わる予定の方！
システム開発には、いくつかの開発手法があります。その中でも長年主流となっている手法がウォーターフォール開発と呼ばれる手法です。
最近ではアジャイル開発の割合が急速に増えているため、アジャイル開発しかやったことない方もいるでしょう。しかし、システム開発の基本はウォーターフォール開発と言っても過言ではありません。
ウォーターフォール開発の知識があれば、今後どのような手法が出てきても必ず応用できますし、システム開発を成功に導く手助けとなりますので、しっかりと理解しましょう！
今回は初級編として、ウォーターフォール開発の流れについて、開発工程の内容を確認しながら解説していきます。
ウォーターフォール開発とは
- 古くから活用されている最も認知度の高い開発手法！
- 開発フェーズは一度進んだら基本的に戻らない！
- 流れる滝のように1方向に進むことからウォーターフォール（滝）！
ウォーターフォール開発は、システム開発手法の１つで、古くから活用されている最も認知度の高い手法です。戻ることなく1方向に進む開発手法であることから、流れる滝を連想して、ウォーターフォール（滝）開発と言われています。
システム開発は、大きく分けて４つのフェーズに分類されますが、ウォーターフォール開発は、要件定義から試験まで、戻ることなく1方向に進めていきます。
各フェーズについて、軽く説明しておきます。後程、もう少し具体的に解説しますので、まずはイメージだけ持っておいてください！
- 要件定義フェーズ：どんなシステムを作るのかを決める
- 設計フェーズ：どうやって実現するのかを決める
- 製造フェーズ：実際に作る（プログラミング）
- 試験フェーズ：想定通り動作するのか確認する
V字モデル
システム開発のフェーズとして４つのフェーズを紹介しましたが、実際の開発では、フェーズを少し詳細化した開発工程と呼ばれる単位で管理されます。
そして、ウォーターフォール開発の流れを表現する際に、V字モデルと呼ばれる図で表現されることが多いため、V字モデルについて解説します。
まずは、実際にV字モデルの図を見てみましょう。
要件定義から始まり、総合試験までの７つの工程があります。「外部設計」と「内部設計」は、設計フェーズから詳細化された工程。「単体試験」、「結合試験」、「総合試験」は、試験フェーズから詳細化された工程になります。
ウォーターフォール開発では、矢印の実線に沿って、開発を進めることになります。
「作る工程」と「確認する工程」を結んでいる点線は、どの試験で何を確認するのかを示しています。例えば、単体試験では、内部設計通りの動作となっているかを確認します。
作る工程は抽象的なところから詳細にしていきますが、確認する工程はその逆で、具体的な（細かい）ところから順に確認を進めるため、確認対象を結んだ時にV字となる訳です。
品質が担保されない状態で、いきなりシステム全体の試験をしても動かないことがほとんどです。まずは最小単位（１つの処理）で確認し、足元を固めながら少しずつ確認範囲を広くしていくイメージです。
確認対象の大きさを図にすると以下のようになります。
作る時は①→②→③→④の順に、確認する時は④→③→②→①の順になります。
これを開発工程で表したものがV字モデルになります。
開発工程の概要解説
ここまでの説明で、ウォーターフォール開発は開発工程という単位で、戻ることなく1方向に進める開発だと言うことが理解できていればOKです。
ここからは、各開発工程で何をするのか、例を挙げながら説明します。
説明のためのサンプルシステム
身近で簡単なシステムを例に説明を進めた方がイメージしやすいので、今回は「簡易電卓システム」と呼ばれる仮のシステムを題材にして説明を進めていきます。
「簡易電卓システム」はWebページで計算式を入力すると、答えを表示してくれるシステムとします。
つまらないシステムだと思うかもしれませんが、今回は実用性よりも分かりやすさを重視しますので、細かいところは気にせず、イメージとしてとらえてください。
では各工程の説明に進みましょう！
要件定義
要件定義では、どんなシステムを作るかを明確にします。決まったことは要求仕様書と呼ばれる設計書にまとめます。
「簡易電卓システム」の例だと、以下のようなことを決めていきます
- Webページ上で動くシステムとする
- 四則演算ができる計算機能を具備する（足し算、引き算、掛け算、割り算）
- 計算履歴を表示する機能を具備する
- 計算履歴はクリア出来ることとする
- 同時に利用できる人数は１人のみとする
このように、どんな機能を持つシステムにするのか、どのくらいのユーザー数を想定したシステム性能とするか。など、ユーザーが求めていることを文書化し、これから作るシステムの認識合わせをすることが目的です。
ここで、ユーザーとは、とある企業の経理担当と仮定しましょう。
ユーザー側がITに精通し、システム要件を決められるのであれば良いのですが、経理の方は、経理のプロでありITのプロではありません。
そこで、ITのプロであるSEの出番です。ユーザーからの要望を正確に理解し、実現可能なシステム要件を考えることがSEには求められます。
もしここで、ユーザー要望を無視した構想を立てたり、実現不可能な要望に対しても無責任に出来ると言ってしまうと後々トラブルに繋がってしまいます。
要件定義では、利用する側と開発する側の両者が納得し、認識違いが無い状態にすることが大切です。
この要件定義の業務内容がSEでコミュニケーション能力が必要と言われている理由の１つでもあります。
外部設計（基本設計）
要件定義によって開発するシステムの全容が明確になったので、次にシステムの外装となる部分の設計に入ります。システムの外装のことを外部インターフェースと言い、外部設計書として設計書を作成します。
要件定義の段階では、まだシステムの詳細イメージは固まっておらず、簡易的なシステム構成図や、処理フローの形になっていることが多いです。外部設計では、システムを「見える化」することが目的です。
例えば、画面デザインです。ユーザーが目にする画面デザインは、システムの顔とも言える重要な外部インターフェースの１つです。
デザインと言っても、見た目だけではありません。いくつの画面に分けるのか、各画面でどのような内容を表示させるのか、ユーザーにどのような操作をさせるか。と言った使い勝手についても、ここで定義していきます。
「簡易電卓システム」の例だと、以下のようなことを決めていきます
- 画面上部に計算式を表示し、画面下部に答えを表示する
- 計算履歴は5件まで表示する
- 計算式はキーボード入力とする
- 計算の実行は「計算」ボタンを押すことで実行され、計算内容は計算履歴に表示される
- 計算履歴のクリアは「履歴クリア」ボタンを押すことで実行され、計算履歴は全て削除される
- 画面レイアウトの作成（ボタンの位置や文字の大きさなどを決める）
外部設計の内容も、直接ユーザー要望が反映されるべきものが多いため、設計内容はユーザーに直接見てもらい、コメントを反映させることが大切です。
そのため、要件定義と同様、レビューアーはユーザーとなることが一般的で、ユーザー側とのコミュニケーションが不可欠となってきます。
SEとしては、実現性の考慮はもちろん、今後のシステム拡張も見据えた汎用性やセキュリティなんかも考慮し、システム開発のプロとして、より最適な形を提案することが大切です。
ここでは、イメージしやすい画面設計について触れましたが、設計対象は画面だけではありません。入力された情報を保持するDBの設計や、他システムとの連携方法も外部設計の範囲となります。
V字モデルで、外部設計に当たる部分を「基本設計」と呼ぶこともあります。
また、要件定義と外部設計の間に別工程として「基本設計」が入れられることもあれば、要件定義の中で基本設計まで実施される場合もあります。
基本設計というのは、要求仕様書の内容を具体化し基本設計書として作成されます。内容としては、機能要件の具体化や、サーバー構成の具体化、性能・セキュリティなどの非機能要件（※）具体化などが含まれます。
今回の例では、基本設計に該当する内容を、要件定義に含める前提とします。
ただし、全ての要素を詰め込むと混乱するので、性能要件の一部として、1人利用の前提を記載しています。
※ 非機能要件とは、機能要件以外のものです。システム上で直接見えない要件と言い換えると分かりやすいでしょうか。
内部設計（詳細設計）
外部設計が完了した時点で、「どんなシステムを作るか」が明確になりましたが、「どのように作るか」については、まだ定まっていない状態です。
内部設計では、具体的にどのように作るか明確にすることが目的で、内部設計書として設計書を作成します。
外部設計までは、ユーザー要望に関わる内容なので、ユーザーが関与していましたが、内部設計以降の工程では関与することは基本的にありません。そのため、内部設計書は開発側が主幹となってレビューも実施します。
「簡易電卓システム」の例だと、以下のようなことを決めていきます
- プログラムモジュールは「Web画面機能」「計算機能」、「履歴表示機能」、「履歴削除機能」の4つに分割する
- 計算履歴は「文字列型変数」として保持し、画面表示の際は、その変数を読み込み表示させる
- 掛算、割算は、足し算、引き算の繰り返しではなく、「×（*）」、「÷（/）」演算子を使用する
【補足】
- 「*」、「/」は、プログラムで掛算、割算を表す演算子
- 内部設計書はプログラムモジュール毎に作成することが一般的なので、ここでは、４つに分けて作成されるイメージ
後の製造工程では内部設計書に従って実装を進めるので、内部設計書では、よりプログラミングに近い論理的な表現で作成されます。 例で示した「文字列型」のようにプログラムのデータ保持形式を指定しているのは、その一例です。
内部設計の考え方
具体的にどんなことを考慮しながら設計するのか、紹介しておきます。
今回の例で、掛算、割算は「×」、「÷」で計算するなんて当たり前で違和感ありますよね。その点を使って説明します。
掛算、割算は、それぞれ足し算、引き算の繰り返しでも計算出来ますよね。このように、システム開発にも実現方法は複数考えられることが多くあります。
そこから、難易度、コスト、性能、メンテナンス性など様々な要素を考慮し選定していきます。そして、なぜその設計にしたのか、論理的に示すことが必要となります。
そのため、内部設計は、要件定義、外部設計に比べて、よりITスキルが求められることになります。
今回、「×」、「÷」で計算することを選んだ理由ですが、例として性能とメンテナンス性を考えてみましょう。
ここで、「×」の処理1回と「＋」の処理1回、どちらも１秒の時間がかかると仮定します。（そんな遅いシステム無いですが、例え話です。）
すると、 2×５では１秒、 2+2+2+2+2では４秒となり、性能面では明らかに「2×５」が優勢です。
メンテナンス性という面でも、 「2×５」の方が見やすく、プログラムもシンプルなものとなり、他の人でもすぐに理解できるでしょう。
このように、論理的に根拠を持って設計を進めることが大切です。
V字モデルで、内部設計に当たる部分を「詳細設計」と呼ぶこともあります。
また、内部設計と製造工程の間に「プログラム設計」が入る場合もあります。
「プログラム設計」は、見れば迷うことなく製造（プログラミング）作業を進めることができる形のプログラム設計書を作ります。
今回の例では、内部設計に含めており、計算方法や型の指定がその一部です。
実際の現場でも、内部設計に含まれる場合もありますし、各設計書でどこまで細かく書くかはプロジェクトによっても違うので、方針に沿って対応することが大切です。
製造
製造工程は実際にシステムを作る作業になります。分かりやすい例だと、プログラミングは製造作業になります。
どのように作るのかは設計工程で明確になっているはずなので、設計書通りに製造を進めます。
内部設計書は、プログラムに近いレベルで細かく書かれていることもあれば、日本語の表現のみで、どのような作りにするかは、ある程度作る側に裁量がある場合もあります。
設計書に書かれていることは神様なので、もっと良い方法を発見したとしても、良かれと思って設計書の内容から勝手に変えてしまうのはNGです。どうしても変更する必要がある場合は、仕様変更として適切な手続きを踏んで対応すべきです。
製造工程においてもソースコードレビューを実施し、机上で発見できるバグは製造工程で取り除きます。
単体試験
製造工程で作成したプログラムを実際に動かし、期待通りの動きをするかテストする工程です。
「単体」と言うのは、１つの機能を指します。
単体試験は複数機能を同時にテストするのではなく、まずそれぞれの機能を個別にテストし、機能単体での品質を担保することが目的です。
試験項目は、内部設計書を確認し全ての処理を網羅的に確認できるように抽出します。
試験対象の機能が、別機能の実行結果を入力として使用する場合でも、単体試験では疑似的に試験データを直接入力するなどして、機能単体でのテストが可能です。
「簡易電卓システム」の例だと、
- 「Web画面機能」「計算機能」、「履歴表示機能」、「履歴削除機能」それぞれの機能を個別で確認する
- 例）「計算機能」で、四則演算が正しい答えを出すこと、計算式以外が入力された場合にエラーを表示させること など
結合試験
単体試験では各機能を個別にテストしましたが、結合試験では関連機能を横断的にテストします。
機能単体での品質が担保された状態なので、１つ範囲を広げて２つの機能を繋げ合わせて確認していきます。
試験項目は外部設計書を確認し、機能間インターフェースのパターンが漏れ無く確認出来るように抽出します。
「簡易電卓システム」の例だと、
- 「Web画面機能」の「計算ボタン」を押すと、入力した計算式が「計算機能」によって正しく計算されるか
- 「計算機能」によって計算された式が「履歴表示機能」によって、正しく表示されるか
- 「Web画面機能」の「履歴クリアボタン」 を押すことで、「履歴削除機能」が実行され、「履歴表示機能」に反映されるか（履歴が削除されるか）
このように、複数機能間を横断し、機能間で受渡されるインターフェースに問題無いかを確認します。
総合試験
試験工程も最終段階です。最後に要求仕様書の内容が満たされているか確認します。
そのため、試験項目は要求仕様書の内容を満たすように、利用パターンを組んでテストします。
「簡易電卓システム」の例だと、以下の流れを通しで確認します。
- 簡易電卓システムのWebページを開く（画面表示に問題ないか）
- 四則演算それぞれを複数回実施し、計算履歴が5件表示されることを確認する
- 不正な計算式の場合、エラー文が表示されることを確認する。
- 履歴クリアを実行し、履歴がクリアされることを確認する
- 計算と履歴クリアを複数回繰り返し、連続利用できることを確認する
このように一連のシナリオを組んでテストする試験を、シナリオ試験と言ったりもします。
また、処理速度や耐久性を確認する性能試験や、セキュリティ試験などの非機能試験も、ある程度システムが動く状態である結合試験完了後に実施すべき内容なので、総合試験工程の中で実施されることが多いです。
受入試験
今回のV字モデルには記載していませんが、開発を委託されている場合に、納品前にユーザー側で実際に使用して確認する試験があります。
試験内容はユーザー側で決めるべきですが、総合試験の中から、代表的なシナリオ試験をピックアップすることもあります。
システムは既に完成状態なので、受入試験で新たに確認する観点は基本的にはありません。
ここで大切なのは、「実際にユーザーに確認してもらうこと」です。
受入試験に問題が無ければ、晴れて納品という形になります！
【おまけ】よくあるトラブル（開発費用の見積り）
今回の例では、外部設計の段階で、入力方法はキーボード入力とすることが、すんなり決まったことになっていますが…
こんなことが起きることがあります。
ユーザー側：
開発側：
システム開発では、要求仕様書を見て開発費用を見積もることも多く、開発側はキーボード入力のみの前提で見積もりをしてしまうと、ボタン入力の方は開発コストに含まれないため、想定以上の人的コストによる利益減や納期遅延のリスクが生まれることになります。
要求仕様書で定められた仕様が神様となりますが、今回のように要求仕様書に明記されていない状態で契約を結ぶ場合は、注意が必要です。
例えば、見積書に「入力方法はキーボード入力のみとする」と前提条件を明記した上で進めることでトラブルを回避することができます。
もし、それでも追加で実装して欲しいとなれば、見積り範囲外の要件になるので、別途、見積りから実施し、金額や納期を合意した上で、別契約の締結や元契約の変更を取る形が望ましいです。
ウォーターフォール開発では、工程を後戻りすることがタブーなので、このように事前にグレーゾーンを潰す対応は、開発を成功に導く重要な要素です！
この考え方は、どの工程でも応用できますので、ぜひ意識してみてください！
まとめ
今回はウォーターフォール開発の流れについて学習しました。
システム開発の基本が詰まった開発手法なので、考え方を理解するだけでも立場や役割に関係無く、必ず役立ちます。初級編だけでも、是非しっかりと習得していってください！
今回お伝えしたかった内容をまとめます。
- ウォーターフォール開発はシステム開発の基本が詰まった王道な手法！
- 開発工程を1方向に進める手法で、足元を固めながら確実に作る考え方！
- 開発工程の流れはV字モデルで表される！
- 作る工程は段々細かく、確認する工程は細かい範囲から段々範囲を広げる！
- 開発工程の名称はプロジェクトによって違う場合もある！
ウォーターフォール開発について、更に知りたい場合は中級編や上級編としてページを用意するので、ぜひ学習してみてください！
