ウォーターフォールモデルは衰退しアジャイル開発が主流になる日が来るのか

システム開発の基本はウォーターフォールモデルでの開発だと、システムエンジニアを目指す人なら、学生時代に必ず習うのではないでしょうか。

要件定義をこなし、基本設計、詳細設計を用意して、プログラミングしてテストを行うのが一連の流れです。上流から下流へ水が流れるように作業が進み、後戻りすることは基本許されません。各フェーズで仕様凍結してしまえば、最も効率のよい開発手法となるでしょう。

しかし今後はウォーターフォールでの開発が減少し、アジャイル開発という新たな開発手法が一般的になっていくかもしれません。

手戻り作業が発生すると工数が一気に膨らむ

ウォーターフォールモデルの最大の難点は、手戻り作業が発生すると開発工数が大幅に膨らんでしまうことです。「受託開発案件で赤字が出てしまった」というのはよく聞く話ですが、その要因として多くの場合は、この手戻り作業の発生が原因でしょう。

ウォーターフォールモデルでは下流の工程で不具合が発生すれば、上流の工程にさかのぼって対応を行わなければなりません。そのためいかに上流工程で穴のない設計ができるかというのが、ウォーターフォールモデルでの開発が成功するかどうかの鍵になってきます。

上流工程を適当にこなしてしまうと、工程表上ではオンスケで進んでいるかもしれませんが、後々になって大幅に工程遅れが発生してしまいます。だからこそ上流工程を担当するエンジニアほど、経験豊富でコミュニケーションのしっかりとれるエンジニアを確保しておきたいものです。

各フェーズではこまめにお客様確認を

しっかりと仕様をつくりこんで、テストを行って品質を確保したとしても、お客様から「こんなシステムは頼んでいない」と言われてしまえば、その時点で終了です。最上流の要件定義までさかのぼって作業をやり直さなければならず、エンジニアにとっては過酷な労働が待ち受けています。

会社にとっても開発予算は大幅に上振れしてしまい、赤字覚悟でまずは納期に間に合わせることを優先しなければなりません。

ウォーターフォールモデルをうまく進めるには、要件定義や基本設計といった各フェーズで、必ずお客様に作業内容の確認・承認をしてもらうことを忘れてはいけません。

簡単なようで難しいウォーターフォールモデル

工程管理と品質確保、それからお客様とのコミュニケーションさえしっかり取れていれば、ウォーターフォールモデルでの開発もうまく進みます。非常に簡単なことのように聞こえるかもしれませんが、実際の現場ではうまくいっているプロジェクトが少ないのが現実。どうしても手戻り作業が多くなって、予定通りに工程が進まないケースは多くの現場で見受けられます。

そこでウォーターフォールモデルをしっかりとこなせるよう努力する動きから、新たな開発モデルでプロジェクトを進めようという動きが盛んになっています。それが昨今話題なることが多いアジャイル開発です。

アジャイル開発とは

アジャイル開発を簡単に説明すると、システムの各機能ごとに設計⇒PG⇒テストを行い、機能ごとにリリースを行っていく開発手法です。

図書館のシステムを例にあげるなら、会員管理の機能で設計⇒PG⇒テストを行い、それが完了したら貸出・返却管理で設計⇒PG⇒テストを行い、最終的にひとつの図書管理システムができあがるようなイメージです。

機能ごとに切り分けて開発を進めるため、ウォーターフォールモデルよりも開発に柔軟性が出るのが強みです。またお客様はリリースされた機能を、画面を確認しながら指摘ができるので「こんなシステムになるはずでは・・」という不幸な結果を招くことなく、その都度システムの全容を変えながら開発が行えます。

ウォーターフォールモデル最大の弱点である、手戻り作業を極力減らすような形で開発に取り組むことができるのです。

ウォーターフォールモデルよりも開発工数が膨らむ危険性も

柔軟性の強いアジャイル開発も、その柔軟性ゆえにウォーターフォールモデルよりも開発工数が膨らんでしまうという危険性がはらんでいることも忘れてはいけません。

機能ごとにリリースしていきながら、システムの形を変えていくため、思いもよらない方向に話が進んでしまい、開発工数が膨らんでしまうのです。ウォーターフォールモデルなら、上流工程でシステム全体の要件を固め、仕様を決めて凍結してしまえば、手戻り作業が生まれない限り当初の工程通りに開発を終わらせることができます。

システム開発を依頼するお客様の立場からしてみれば、どうしても開発の途中で「この機能はもっとこう改善してほしい」とか、「あの機能はやっぱり修正してほしい」というように、追加要望をしたくなるものです。アジャイル開発を進めていくと、お客様の要望を満たすという点では作業にキリがなくなってしまうので、どこでお客様との要件で折り合いをつけるかということがポイントになってくるでしょう。

 

おわりに

現在は主要な開発モデルであるウォーターフォールモデルも、近い将来はアジャイル開発が主流になる日がくるかもしれません。しかしどの開発モデルを採用したとしても、開発工数が膨らんでしまう危険性はゼロにはならないでしょう。

開発手法も大事ですが、やはり根底はエンジニアの質を高めるということが、ITエンジニアにとっての永遠の課題なのかもしれません。