
ウォーターフォール型開発を推進する開発パートナー選びのポイント
「ウォーターフォール」という用語を聞いたことがありますでしょうか?「ウォーターフォール」とは、コンピューター・システムを開発する手法のひとつです。
「ウォーターフォール(Waterfall)」は、日本語で「滝」のことです。
「滝」のように上流から下流へ水が流れるようにプロジェクトをすすめる開発手法です。
「ウォーターフォール」型の開発手順は、要件定義→概要設計→基本設計→詳細設計→開発→検証→運用などのシステム開発のそれぞれの工程を、上流工程から下流工程へ順序立てて、すすめていく開発手法のことを示します。
「それぞれの工程が完了後に次の工程にすすむ」という開発手法です。
システム開発業務に参加する初心者でもイメージし易い開発手法です。
リリース・S日までの作業工程のスケジュールを決めてから着手します。
計画性をもって開発プロジェクトをすすめることができることが特徴です。
滝)と言われています。
「ウォーターフォール」型の開発は、計画通りにそれぞれの工程をすすめ易いことから、組み込みソフトウェア・通信システム等の「仕様変更を考慮しないシステム」「仕様変更が生じないシステム」の開発に向いています。
基幹システムなどの業務アプリケーションソフトウエア開発プロジェクトには不向きな開発手法といわれています。
これから「ウォーターフォール」型開発手法とは何か?「ウォーターフォール」型開発手法を取り入れるメリット・デメリットを紹介していきます。
目次
1.ウォーターフォールとは何か?
「ウォーターフォール」とは、コンピューター・システムを開発する手法のひとつです。
「ウォーターフォール」型開発手法は、従来のソフトウェア開発は職人芸的な製造方法から工業製品としての製造方法に変える手法として、1968年に提唱されました。
その原型となる手法は、製品の製造過程のように開発過程を工程と位置付けて適宜に分類・分割し、それぞれの工程の進捗を管理します。
ひとつの工程が完了したことを確認したあとに、次工程にすすめることでした。
「ウォーターフォール」型開発手法は、現在も活用されています。
システムの開発工程を「計画=要件の定義」「概要設計」「基本設計」「詳細設計」「開発=プログラムメイキング・コーディング」「検証=テスト」「運用=リリース・カットオーバー・S日」の工程に分割して、一つひとつの工程が完了したことを確認して、次工程にすすめる開発手法です。
「ウォーターフォール」型開発手法は、それぞれの工程が完了するまで、次工程にすすみません。
さらに、前に工程に遡及しない開発手法です。
それぞれの工程ごとに成果物(設計書・仕様書)を作成して、それぞれの工程のクオリティーを確保するという特徴があります。
それぞれの工程が「滝の水」が流れるようにすすみ、元の状態には戻らない手法であることから、「ウォーターフォール(日本語で『滝』を意味します。)」型といわれています。
2.ウォーターフォール型開発のメリット
「ウォーターフォール」型開発のメリットを紹介します。
第1にプロジェクト全体のスケジュールを立案し易いことです。
前章で紹介しましたが、プロジェクト発足時に「要件定義」をします。
その後の工程の「概要設計」「基本設計」「詳細設計」「開発」「検証」「運用」と続きます。
「要件定義」工程で、作業項目を洗い出して次工程のスケジュールを立案することができます。
全体の作業内容を把握して、作業工程別にタスクを分割・分配することで、プロジェクト全体の進捗管理が円滑に行うことができます。
さらに、それぞれの工程を完了してから、次工程にすすみます。
そのため、「詳細設計」「開発」「検証」工程には多くのエンジニア人材を要しますが、ピーク時の員数増強に対応に効果的です。
「要件定義」工程で、それぞれの工程の作業内容を明確にするので、プロジェクト員数変動も計画的に行うことができます。
第2に「ウォーターフォール」型開発手法は、開発プロジェクトのスケジュールを確定した時点から開発作業を計画通りにすすめることができます。
開発スケジュールが詳細に組み立てあるので、それぞれの工程を順序立ててすすめることができます。
それぞれの工程が完了した確認後に次工程にすすみます。
一般的なアプリケーション開発と異なり、仕様変更による後戻り作業が発生しないので、計画通りにすすめることができます。
第3に必要なエンジニア人材を確保し易いことです。
「要件定義」「概要設計」から「運用」までのプロジェクトのスケジュール計画が立てられています。
そのため、それぞれの工程で必要になる費用・エンジニア人材の員数を予想し易いことです。
そのため、ITエンジニア人材が慢性的に不足しているなかで、エンジニア人材を計画的のアサインすることができます。
開発プロジェクトがスケジュール通りに遂行できるポイントは、計画通りに必要な員数のエンジニア人材を確保できることといわれています。
3.ウォーターフォール型開発のデメリット
「ウォーターフォール」型開発のデメリットを紹介します。
第1に「要件定義」工程でスケジュールを立案するので、プロジェクトがスタートしてから仕様変更が生じたときに負荷が大きいことです。
「ウォーターフォール」型開発手法は、お客先様・ユーザーの要望を取り入れる工程が「要件定義」です。
ケースバイケースですが、「概要設計」工程でも取り入れることがあるようですが、基本的に「要件定義」工程で全てを確定することになります。
お客先様・ユーザーが、それぞれの工程の成果物・完成品を確認したときに、新たな発見があり仕様変更の注文が発生することがあり得ます。
仕様変更を取り入れると「要件定義」に工程に戻り、プロジェクトを再計画します。
そのため、リリース・カットオーバー・S日までの納期が長期化します。
「ウォーターフォール」型開発手法は、開発プロジェクトをすすめるエンジニアには効率的です。
プロジェクトがスタートすると、お客先様・ユーザーの意見が反映できにくい開発手法です。
お客先様・ユーザーは「要件定義」工程でニーズをまとめて指示することが求められる開発手法になります。
「ウォーターフォール」型開発手法は、エンジニアに効果的な開発手法です。
そのため、プロジェクト進行途中での仕様変更ができません。
それぞれの工程で完成した結果で、次工程にすすむので「少しだけやり直す」ということができないことが大きなデメリットです。
第2にそれぞれの工程で作業ミスが生じたとき、手戻り工数が大きくなるといわれています。
それぞれの工程は、直前の工程の成果物をベースにしてすすめます。
ある工程で作業ミスが発覚したときは、前工程の見直しをします。
前工程の見直しをしても作業ミスが解消しないときは、さらに前に工程に遡及して見直しをします。
前段階の工程(要件定義・概要設計)で作業ミスが発覚すれば、大きな工数を要さずに済みます。
「詳細設計」「開発」以降の工程で作業ミスが発覚すると、前工程の見直し作業に工数と手戻りコストが大きくなるようです。
4.ウォーターフォール型開発を成功させるための条件
「ウォーターフォール」型開発を成功させるための条件を紹介します。
第1に完成した姿が明確に決まっていることです。
「ウォーターフォール」型開発は機能・仕様を決めた「要件定義」工程から開発をスタートするため、予め完成した姿が明確に決まっている開発プロジェクトであることが条件です。
第2に仕様変更を前提としないことです。
開発プロジェクトの最初に全体スケジュールを明確にします。
一般的な開発プロジェクトは、工程の途中で仕様変更があると手戻り工数の負担が大きくなります。
「ウォーターフォール」型開発手法は、開発プロジェクト開始の時点で要求が確定していることが欠かせない条件です。
仕様変更を考慮しない手法です。
5.ウォーターフォール型開発を推進する開発パートナー選びのポイント
「ウォーターフォール」開発の推進は、現行の基幹システムの運用に影響を与えることはありません。
参考ですが、現行の基幹システムを開発したとき、開発パートナー企業が導入したシステム開発手法が何型であったか、営業担当またはプロジェクト・マネージャーに聞いてみてください。
自社の情報システム部門・IT関連部門で基幹システムのカスタマイズや新規サブシステムを開発するケースでは、参考になると思います。
「ウォーターフォール」型開発の推進状況を、企業・団体が導入している基幹システムの開発パートナーに聞いてみましょう。
大手電機メーカー、ITベンダー企業、ITベンチャー企業は基幹システムをする部門以外に「システム開発手法」をサポートする担当エンジニアを用意しています。
現行の基幹システムを導入した開発パートナーの営業担当やプロジェクト・マネージャーに相談してみましょう。
まとめ
「ウォーターフォール」型開発手法は、上流工程から下流工程へと順番に開発が進められていく手法です。
近年では臨機応変な対応に強みを持つ開発手法を取り入れる開発パートナー企業・ITベンダー企業が多い傾向にあるようです。
「ウォーターフォール」型開発手法はクオリティーを担保しやすいため、高いクオリティーを重視する開発プロジェクトでは今後も導入されるようです。
システム開発のITパートナー探しをされるのであれば
システム開発のITパートナー探しをされるのであれば「システム開発コンシェルジュ」で是非ご相談いただければと思います。
以下のフォームより開発でご相談いただきたい内容などご相談ください。