ウォーターフォールとは？新人SE＆未経験でも分かり易く解説！

「ウォーターフォール」という言葉を聞いたことがあるでしょうか？今後、SEやプログラマーとして活躍したいと思う方には、避けて通ることは出来ない程、重要なアプローチモデルとなります。

今回は、ウォーターフォールについて詳細に解説します。

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

「ウォーターフォール型開発（Waterfall Model）」は、ソフトウェ開発における、最も有名な開発手法です。ウォーターフォールとは、「滝」の意味であり、ソフトウェア開発の工程が、さながら上から下へ段々に水が進んでいくような姿から名付けられています。

ウォーターフォールは、ソフトウェアの設計から開発・顧客への納品までに至る工程を、以下のように分割し、管理します。

この中でも要件定義や基本設計までを「上流工程」といい、残りの詳細設計、プログラミングやテストを「下流工程」といいます。

要件定義とは？

ウォーターフォールでは、まず上流工程の作業から行います。その中でも、最初に行うのが「要件定義」です。要件定義では、以下の3つの目的を遂行します。

これらの目的遂行のために作成する「要件定義書」は、「顧客に同意していただく仕様書」となります。要件定義書について詳細に知りたい方は、以下の記事をご覧ください。

Beエンジニア

 

1 Pocket

要件定義書とは何？任されたら花形SE！詳細に理解しよう！

https://www.pmi-sfbac.org/requirement-definition-document

「要件定義書を作成するSEは、花形SEである」と言っても、過言では有りません。それだけに、「要件定義書は大切な存在である」と言えます。そこで今回は、要件定義書に関連する、以下の事項を解説します。「要件定義書」とは何か?「要件定義書」は誰がいつ作るのか?「要件定義書」はどんな内容を書くのか?要件定義書は誰がいつ作るの?要件定義書は、基本的にはSEが作成します。しかし、規模の大きい企業や部署においては、要件定義を専門に請け負う部門や担当者も存在します。この要件定義書は、ソフトウェア開発工程において、主に「...

基本設計とは？

「基本設計」とは、ウォーターフォール型開発において要件定義の後に行う設計作業であり、主にSEが行います。この基本設計・外部設計までのフェーズを「上流工程」と呼びます。

「下流工程」との違いは、成果物の内容が「発注者側（指示者）」の目線であるか否かの違いです。つまり「上流工程」における成果物は「発注者側」の意見を元に、仕様を書面化したものとなります。

この設計作業では、主に「システムの概要的な設計」を行うため、「概要設計」と呼ばれることもあります。同様に他のシステムとデータの受け渡しが必要な場合の設計や、利用者の操作などに応じた挙動などを設計するため「外部設計」と呼ばれることもあります。

Beエンジニア

基本設計書とは？ ポイントを抑えて分かりやすく解説！

https://www.pmi-sfbac.org/basic-design-documents

「SE（システム・エンジニア）」は、顧客目線が大切です。その上で、社内でシステムを実際に開発する「PG（プログラマー）」へ、開発する内容を伝えることも重要です。そのために作成するのが、今回解説する「基本設計書」です。そこで今回は、基本設計書に関連する、以下の事項を解説します。「基本設計書」とは何か?「基本設計書」は誰がいつ作るのか?「基本設計書」はどんな内容を書くのか?基本設計書とは?「基本設計書」は、顧客が求める機能を実現するために、そのシステムの概要を記述するものです。基本設計書には、顧客が使用...

詳細設計とは？

ウォーターフォール型開発において、詳細設計・内部設計からは「下流工程」と呼ばれます。「詳細設計」とはウォーターフォール型開発において、基本設計の次に行う設計作業です。

「下流工程」からは「発注者側（指示者）」の意見は入りません。逆に、この段階で「発注者側（指示者）」の意見が入る様では、いつまでたっても仕様が固まらずプロジェクトは崩壊します。

主にSEが主導しますが、場合によっては一部にプログラマーを迎えて、共同で設計作業を行うこともあります。詳細設計では、外部設計で定義した「利用者の操作に応じた設計」をより詳細に定義したり、外部とやり取りを行うデータの詳細を設計したりもします。

詳細設計ではシステム内部の処理を中心に設計を行うため「内部設計」とも呼ばれます。

Beエンジニア

詳細設計書とは？SE＆PGそれぞれに必要な設計書！

https://www.pmi-sfbac.org/detail-design-documents

「SE（システム・エンジニア）」は、システム開発において、顧客と開発者を結びつける重要な存在です。もちろん、SEだけではシステムは作れませんし、「PG（プログラマー）」だけでも作れません。両者の連携があってこそ、システム開発は成り立ちます。その際に必要となるのが、今回説明する「詳細設計書」です。そこで今回は、詳細設計書に関連する、以下の事項を解説します。「詳細設計書」とは何か?「詳細設計書」は誰がいつ作るのか?「詳細設計書」はどんな内容を書くのか?詳細設計書とは? 誰がいつ作るの?「詳細設計書」とは、「...

実装とは？

実際に仕様書に基づいて、プログラマーがプログラミングをおこないます。

基本的にPG（プログラマー）主導でのプログラミングフェーズになりますが、会社によっては、システムエンジニアも加わりプログラミングすることもあります。

テストとは?

テストとは文字通り、作ったシステムのテストをおこなうことです。そのシステムに不具合や「バグ」と呼ばれる問題がないかや、システムに欠けているものが無いかなど入念にチェックします。

システム開発をする以上は不具合・バグはつきものなので、テストフェーズ次第でクライアントに納品するものの質が変わってきます。テストは概ね以下の3つに別れ、PGやテスター、SEに加えて、顧客の担当者がそれぞれ行います。

新米システムエンジニアの方はこのフェーズに関わることが多いです。

メンテナンス

ウォーターフォール型開発における「メンテナンス」とは「保守運用業務」のことです。

すべての設計・開発（プログラミング）・テストを終えるとシステムは顧客へ納品されます。しかしシステムが納品されたからといって、開発が即座に停止するわけでは有りません。

実際には、メンテナンスは数年単位・数十年単位で行われることが通例です。サポートは通常は、別チーム（別部署）が担当しますが、SEやPGが担当することもあります。

このとき必要となるのがこれまで解説してきた仕様書（設計書）です。正しい仕様書であれば、メンテナンスに役立ちます。

利点と欠点

ウォーターフォールには多くの利点はありますが、最も大きな利点は「構造がシンプルで簡単」という点です。そのため殆どのSEやPGが改めて教育する必要がないくらいに浸透しており、スムーズに開発を行えます。そして初めて覚えようとする方にも、比較的簡単に覚えられます。

対して欠点としては「不具合が発見されると、修正のための後戻りが難しいこと」です。

なぜなら、「ウォーターフォール型開発は、各工程が正しいことを前提に進める開発手法」だからです。そのため不具合が前工程で見つかった場合、修正にスケジュールを要したり、余計なコストが掛かります。この溝が広ければ広いほど、重大になってしまいます。

したがって、ウォーターフォール型開発では、「十分な設計を心がけ、顧客と密に連携すること」が最も大切といえます。

まとめ

ウォーターフォールは開発の基本ですが、失敗もつきものです。ウォーターフォール型開発で失敗しないためには、「十分な設計を心がけ、顧客と密に連携すること」です。