基本情報技術者の勉強 ウォーターフォールモデルのメリットとデメリットについて

ウォーターフォールモデルについてもっと詳しく知りたい方のために詳細を紹介していきます。

ウォーターフォールモデルとは

 

 システムの開発プロセスは大きく分けて

1. 要件定義
2. 設計
3. プログラミング 
4. テスト

となっています。

ウォーターフォールモデルではこの一連の開発プロセスを上流工程から順番に行なっていきます。

各工程が終了するまでは次の工程には進めず、作業が完了した段階で次の工程へと進んでいきます。

また、終了してしまった工程には後戻りができないという特徴も持っています。

絶対に後戻りをしてはならないというわけではありませんが、後戻りはしないという前提のもとになっています。もし後戻りが発生してしまうと、プロジェクト全体の進展に大きな悪影響を及ぼすでしょうね。

そのため各工程で成果物を作り、各工程で適切な評価を下していくことによって品質の管理をしていきます。

 その様子が滝のようだったためウォーターフォールモデルという名前が付けられました。

 ウォーターフォールモデルでは、上流工程の出力がそのまま下流工程の入力になります。

 要件定義の結果をもとに設計を行なったり、設計の結果をもとにプログラミングを行なっていきます。

 そのため、上流工程に不備があるとそのまま下流工程に引き継がれてしまいますし、さらにはその下流工程にまで影響が及んでしまいます。

 それではウォーターフォールモデルのメリットデメリットについて見ていきましょう。

ウォーターフォールモデルのメリット

まずはウォーターフォールモデルのメリットについて紹介していきます。

ウォーターフォールモデルのメリットは大きく分けて4つあります。

1. プロジェクトの計画を立てやすい

2. プロジェクトの進展管理がしやすい

3. プロジェクトの人員確保がしやすい

4. 各工程の成果物をベースにして開発を行える

これらの4つについて順番に紹介していきます。

プロジェクトの計画を立てやすい

ウォーターフォールモデルの一番の魅力は何と言ってもプロジェクト全体の計画を立てやすいということでしょう。

システムの要求定義を開発の一番初期に行うのはどの開発手法でも共通していますが、ウォーターフォールモデルの場合は、この段階で詳細に要求事項を決定します。

つまり、プロジェクトの一番初期の段階で最終的に作り上げる成果物を明確にしたうえで開発に取り組んでいきます。

最終的に作り上げる成果物が明確になっていれば、それを達成させるために必要な事項などもより正確に把握できます。

「この作業には何日かかり、この作業には何日かかる」と見積もりができたりなど、全体にかかる日数も把握しやすくなります。

基本的に後戻りをしないことを想定しているためこのようにできますね。

プロジェクトの進展管理がしやすい

先ほど同様に、プロジェクトの初期の段階で全体像を確認できるため、その後の進展の管理がしやすくなります。

この工程にはこれほど時間がかかるとか、また各工程の中でもどの部分にどれほどの時間がかかるのか、把握しやすくなります。

各工程は終わってから次の工程に進むため、現在が全体のどの程度の作業が終了しているのかもわかりやすいですね。

プロジェクトの人員を確保しやすい

実際にシステムを開発してみると、自社の社員だけでは間に合わないこともあるでしょう。

人員が足りずに納期に間に合いそうになければ、外部のエンジニアを雇う必要があります。

急に人員を確保しようとしても、そうそう都合よく確保できるわけではありません。

何度も言うように、ウォーターフォールモデルはプロジェクトの初期の段階で全体像を正確に把握しておきます。

そうすることでどの工程にどれほど人員が必要かあらかじめ見積もることができますし、早めのうちに外部のエンジニアさんたちに手配を出すこともできるため、人員の確保がしやすいです。

各工程の成果物をベースにして開発に取り組むことができる

ウォーターフォールモデルでは各工程での作業を完結させて次の工程に進んでいくため、各工程で明確な成果物が出来上がります。

ですので、それらの成果物を見れば引き継ぎ作業が速やかに行われスムーズに開発を行えます。

また、各工程の成果物を次の工程のベースとするため、プロジェクト全体を通して一貫性が保たれます。

ウォーターフォールモデルのデメリット

 続いてウォーターフォールモデルのデメリットについてご紹介していきましょう。

ウォーターフォールモデルのデメリットは、大まかに言って次の3つが挙げられます。

1. 上流工程でしか要件定義ができない

2. 仕様変更、工程の手戻りの影響

3. ユーザーが実物に触れられるのは終盤だけ

これらをひとつづつ見ていきましょう

上流工程でしか要件定義ができない

まずは上流工程でしか要件定義ができない点です。

先ほどは、上流工程で要件を詳細にすることによるメリットを紹介しましたが、デメリットも合わせ持っています。

プロジェクトの初期の段階で要件定義を行いますが、それ以降は行いません。

ですので、実物がユーザーの元に届くのは、すでに過去のものになってしまいます。

完成形が出来上がるまでに長い時間がかかれば、その間にユーザーの欲しいものが変化してしまうかもしれません。

そうなってしまっても、プロジェクトの途中で要件を定義し直すことができないのが、ウォーターフォールモデルのデメリットでしょう。

仕様変更、工程の手戻りの影響

ウォーターフォールモデルでは、各工程での成果物を次の工程のベースとします。

そのため、各工程での成果物に不備があったり、設計ミスがあったりすると、その後の工程すべてに影響が及びますし、手直しのため前の工程に戻らなければなりません。

このように後からの仕様変更や設計のミスなどはプロジェクト全体の計画を狂わせ命取りとなってしまいます。

計画を立てやすいのはメリットですが、計画通りに行かなかった場合の影響がとても大きいです。

ユーザーが実物に触れられるのは終盤だけ

そしてユーザーが実物に触れられるのはプロジェクトの終盤だけということです。

いくら正確に要件定義を行い、詳細に設計を行なっても、開発を行うのはユーザーではなくエンジニアです。

また、ユーザーは素人である場合がほとんどなので、開発者との認識のズレも当然生じてしまうことになります。

そうすると、完成物をユーザーに試してもらって初めて思っていたものとは違うことに気づくのです。

こういった認識のズレをなくすためにも丁寧に要件定義を行う必要がありますね。