ソフト開発をやっているのであれば、ソフト開発プロセスというものがあることをそのうち知ることになると思う。
大だっぱに言えば、要求、仕様、設計、コーディング、単体テスト、結合テスト、システムテストという工程を実施して、ソフトウェアを完成させるというプロセスのことである。
これらを左から順番に実施する開発のやり方をウォーターフォールモデルという。
ウォーターフォールモデルには欠点があって、各工程を完全に実施することを前提としている点である。完全とは瑕疵がないことを意味していて、瑕疵がないならば前に進めるということで一方方向にしか進まない。ウォーターフォール（滝）が一方方向にしか流れないことに似ているということでつけられた名前なのかもしれない。
現実はそんなことがなくて、各工程は完全にはできず、後の工程になって要求が不明確だとか、仕様が間違っているとか、設計がだめだ、とかいろいろ発生する。そうなった場合には、元の工程にもどって修正することになるのであるが、工程を戻ることになるので、それはウォーターフォールモデルではなくなってしまう。あまりにも不完全なモデルである。
そもそも、ウォーターフォールモデルを是として推進している人なんているのであろうか。ウォーターフォールモデルを説明した本など存在しないし、だれも推進する人はいないように思える。
ところが現実にはウォーターフォールモデルの改良版（手戻りしたときにどうするかを考えて）を勝手に作って運用することを行っている。どうするかというと、例えば、テストをしているときに
仕様が足りないことが分かったとする。すると仕様作成の工程に戻って仕様書を修正する。仕様書を改定するのである。すると改定した部分の設計をやり直して、設計書を改定する（設計書を作らないことも多い）。続いて変更された仕様と設計に対応してコーディングを修正や追加をする。テストケースも追加してテスト工程にようやく戻る。これをテストが終了してバグをすべて修正するまで繰り返す。これが現実的なウォーターフォールモデルであろう。
実際、手戻りがあるに決まっているので、ウォーターフォールという名前はふさわしくない。そろそろ別の名前を考えたらどうだろうか。といって、すぐに提案できる名前が思いつかないが、従来のやり方という意味で いにしえモデル、伝統モデル、古い開発モデル・・・なんかいい呼び方ない？
問題なのは、これをやると時間がかかることになる。バグの数だけ繰り返しが発生するので、できるだけ時間をかけないようにするには、各工程の完成度を上げることに尽きる。そうすれば、下流工程で発見されるバグが少なくなるので、繰り返しを少なくすることができる。
このやり方が一番、手っ取り早いし、しかも教育がなくても自然に理解できるので、一番普及している方法なのであろう。
実はまだまだこの方法には問題があるので、それは後述する。
ウォーターフォールモデル（以降WFモデルと略す）に対してアジャイルという開発手法がある。これはWFモデルのさらなる欠点を解決するための手法である。さらなる欠点とはWFモデルは要求が明確であることが前提条件であるため、要求がはっきりしないような曖昧なプロジェクトには適用が無理だということである。要求がはっきりしない場合は、要求をはっきりさせるということを実施しなければならないが、それは要求を明確にする作業、要件定義の工程で実施することはできない。
なぜなら、要求を出す人が自分でも要求がなんなのかわからないからである。したがって、いくらヒアリングをしても要求は明確にならないので、そこでプロジェクトは停滞する。これがWFモデルの限界である。
これを乗り越えるには、曖昧な要求のまま試作をして試作品を見せてこれがあなたの欲しいものですか？と聞くことになる。いや、違うよ、このイメージではない・・・という意見を聞くことができる。
人間というものは具体的なものになってみてはじめて自分の要求が少し明確になるものであるようだ。
「わかりました。次はこれとは違う形のものを作ってきます。あるいはこの部分を変更します。」と言って、要求元が満足するまでこれを繰り返すのである。
WFモデルが手戻りという繰り返しをできるだけ少なくしようと努力するのに対して、アジャイルの
の場合は、積極的に繰り返しを行う。繰り返し自体を管理するのである。繰り返しを管理した結果
繰り返す回数をあらかじめ計画した回数（期限）で打ち切ってリリースする。打ち切るのであるから
できなかった要求も存在することになる。通常は、優先度の高い要求から実装するのでできなかった要求は優先度が低いことになる。それでも要求元（お客さん）は優先度の高い要求が明確になって自分の欲しいものになっているので満足度が高いことになる。
これがアジャイル開発である。
コメント