ウォーターフォール型開発は、コンピューター技術が発展すると破綻する・・はず（＾＾；）

　システム開発は、要求分析→外部設計→詳細設計→プログラミング→単体テスト→結合テスト→総合テストという工程で進んでいく。

　このとき、ウォーターフォール開発では、その工程が終わり、次の工程に行ったら、その工程あるいはその前の工程には絶対に戻らない。また、工程によって担当者が違うこともありえる（要求分析は上級ＳＥ，プログラミングはプログラマなど）

　ここで、ビジネスモデルは、要求分析の機能要求を出してくるところで決定する。一方、実装は、外部設計からはじまり、プログラミングで実装する。

　昨今、コンピューター技術が進むにつれて、さまざまなデバイスが現れてきた（ケータイなど）。しかし、これらのデバイスはすべての機能が使えるわけでなく、制約がある。その制約はプログラマしか知らないことも多い（ＢＲＥＷにおけるＨＴＭＬ表示など）。
　ということは、外部設計からプログラミングまでの段階で、実装上無理！ということが分かったり、　結合テストでパフォーマンスが出ない！ということも考えられる。

　こうなると、方法を変えるしかない・・・が、それはビジネスモデルを変えることであり、ウォーターフォールでは、行ってはいけないことになる。

　では、要求仕様のときに、そういう問題をつぶせばいいということになるが、ウォーターフォールでは上述のように、担当者が変わることも許される。このとき、要求分析は上級ＳＥが担当することになるが、それら上級ＳＥがＢＲＥＷの制約といった、ＣやＣ＋＋の実装を知っているとは限らない（というより、知らないのがふつう）。

　つまり、実装上の問題が起きた時、それに伴うビジネスモデルの変更が出来ないウォーターフローは、破綻してしまう。

---

　具体例を１つ。

　ある会社では
　　　営業所１０箇所＝受注を行う
　　　物流センター１箇所＝出荷を行う
　であったとする。現在は

　　　１．営業所が受注したら、
　　　　　　　注文請書、出庫指図書、納品書、受領書
　　　　　の４枚カーボンコピーした伝票を記入

　　　２．営業所では受注の確認、承認をした後、
　　　　　注文請書をはずし、発注者へ送った後、
　　　　　のこりの伝票を物流センターに送る

　　　３．物流センターでは、センター長が、出庫指図書の内容を元に、
　　　　　出庫担当者に指示を出す

　　　４．出庫担当者はピッキング、出庫指図書をはずして残りの伝票を
　　　　　出庫する箱に貼り付け、出庫する

　という流れだとする。

---

　一般に、このシステムをコンピュータ化し、リードタイムを減らそうとする場合、

　　　１．営業所が受注したら、受注入力し、
　　　　　注文請書を出力

　　　２．営業所では受注の確認、承認をした後、
　　　　　注文請書を、発注者へ送る

　　　３．物流センターとネットワークでつながっているため、
　　　　　センター長が、即座に受注内容から、出庫指示を出し
　　　　　出庫担当者に指示を出す

　　　４．出庫担当者は出庫指示画面をみてピッキング、
　　　　　納品書、受領書を出庫する箱に貼り付け、出庫する

　こうすると、

・受注から即座に出庫までいける
・在庫状況が把握できる
・出庫指図書がデジタル化され、紙をださなくてすむ

　ので、この方法がいいように思えて、設計、実装に行く。

---

　しかし、この方法は、危険である。

　営業所１０箇所の注文を、１つの物流センターで帳票印刷することになる。
　仮に、営業所が２時間かけて印刷するとしたら、２時間Ｘ１０＝２０時間
　印刷していなければならず、印刷処理のために、出庫がとまる。

　もちろん、プリンターを多数用意すればいいが、そうすると、費用がかさむ。

　無難なのは、いままで、営業所から伝票が来ていたのだから、その流れは崩さず、
　営業所で受注入力してプリントアウトすることだが、それは、ビジネスフローが
　変わるので、ウォーターフォールでは許されない上、そもそも、

・受注から即座に出庫までいける
・出庫指図書がデジタル化され、紙をださなくてすむ

　の目標は何一つ達成しない。ここでの効果を期待して予算をとってしまった場合、費用分の効果は出ず、まったくの失敗ということになる。

---

　では、アジャイルならどうなるか。

１、まず、受注部分を開発し、プリンタから出るようにする
　　→ここで、印刷に何時間くらいかかるか検証する

２．物流センター側にデータを転送し、出庫入力システムを
　　作成する
　　→ここで、在庫確認できるかどうか検証する

３．最後に、出庫指図書のペーパーレス化を考える。

　このように部分的に投資していけば、問題があるところで変更・開発中止
できるので、ウォーターフォールのように、大失敗することは少ない。

---

　１０年以上前、とくにＣＯＢＯＬ全盛のときには、

１．上級ＳＥも、どのような感じで実装できるか、概略をつかんでいたし
２．そもそも、入出力が限られていたので、まずそこで問題は起こらなかった

　なので、ウォーターフォールでも、実装した時に急に問題になることはなかった。

しかし、現在のように、コンピューター技術が発展し、実装してみないと、どうなるかわからない。知っている人はプログラマーだけ・・・という状況で、ビジネスフローを決めてしまうのは危険だし、さらに、コンピューター技術のメリットも出し切れない（こういうデバイスがあるから、こういうフローにしようというのは、ありえる）

　ということで、

ウォーターフォール型開発は、コンピューター技術が発展すると破綻する・・はず（＾＾；）