ウォーターフォール型の開発とは、システム開発の工程を

• 「要求分析」
• 「仕様決定」
• 「分析」
• 「設計」
• 「プログラミング」
• 「テスト」
• 「保守・運用」

の工程に分けて順次完成させていくものです。

うまくできれば良いのですが、プログラミングの段階まで来たところで
お客様から「こんなシステムじゃなくてもっと派手なやつがほしい」
と言われると、手戻りをしなくてはなりません。
そのため、雨後の筍のように新しいサービスが次々と生まれるweb界隈などでは、
決定した仕様に基づいて設計⇒プログラミングと進めている間に
世の情勢が変わってしまってお蔵入り、ということにもなりかねません。
そういうわけでこの方式はころころ仕様が変わったりしないシステムの開発には
強みがありますが、仕様変更に柔軟に対応して開発するシステムには向きません。

もう1つの欠点として、上流と下流を別の人間が担当する場合に
意思の疎通がとりにくい場合があります。
これはいわゆる「伝言ゲーム」と揶揄される由縁です。

システムアナリストやコンサルタントなどと言われる
経営にもITにも精通した人物が全体的なシステム化計画を作り、
経験豊富なSEが全体の構成を描き、
主戦力のSEが各サブシステムを設計し、
プログラマがコーディングをする、
というスタイルではプログラマとアナリストの距離感がありすぎます。
自分がコーディングをしながら、この部品がどこでどう活躍するのか
理解できないほど細分化されてしまうことも珍しくありません。

そういった問題点から、ウォーターフォール開発が広く行われつつ、
今もなお様々な開発手法が生まれては消えている次第です。

さて、これと似たものに「バリューチェーン」という言葉があります。
こちらはシステム開発とは似ても似つかぬマーケティング用語です。

• 材料調達
• 製造
• 出荷
• マーケティング
• サービス

という過程を経て、商品は価値（バリュー）を積み足されていきます。
最終的にお客様が商品を購入して、「わぁ。この商品良いわ。」と
価値に感動するのは、購買し、製造し、出荷し、
マーケティングリサーチし、サービスされたる過程において
お客様を感動させる価値が積み上げられたからです。

この各工程において、それぞれの担当者は「価値活動」と言われる
価値を生み出す行動を行います。ここで生み出された価値は、次の工程に引き継がれます。
全員が自分に回ってきたバケツに水を足しながらバケツリレーをするイメージです。
そして最終的にその合計分の価値が付加された商品がお客様に届けられると考えるのが
バリューチェーン、すなわち価値の連鎖です。
価値の連鎖⇒階段連鎖⇒ファイアー⇒アイスストーム⇒ダイ・アキュート⇒ばよえーん⇒バリューチェーン
というように連想するのも良いでしょう、というのは冗談です。

バリューチェーンの考え方で重要な点は、自社の強みがどのような工程の
どのような部分にあるかを分析し、他社はどの工程が強い／弱いかと合わせて
戦略を立てるところにあります。それはマーケティングの話なので置いておきます。

各工程で「価値活動」を行うという点に注目すると、
ウォーターフォール開発では各工程で何か価値を生み出そうとしているか？
という思いが頭をよぎります。

システム開発のプログラミング工程やテスト工程では、
価値を創造するというより不具合を作りこまないという点に重きが置かれます。
各個人が「ここはこうしたほうが良いだろう」と思って手を出した部分が
重大なバグを招くかもしれません。自分で設計したものなら良いですが、
上で述べたように各工程の担当者がバラバラになっていると事情は違います。
自分が作る部分が他の部分に対してどのような影響を及ぼすかが読めなければ、
上の工程から降りてくる情報をいかに劣化させずに次の工程に引き渡すか、
という点が勝負になってしまいます。結果として自由にできるのは上流のみで、
下流に行くほど自由が無くなってしまいます。

精神論になってしまいますが、それでも各工程で自分の価値を発揮するという意識は
大切なものだと思います。設計なら拡張性や保守性に優れた設計をしたり、
プログラミングなら処理性能が高く、変更も加えやすいプログラミングをしたり、
テストなら処理性能、例外処理、セキュリティなど様々な観点からテストをしたりすることで
みんなで力を合わせて良いものを作ろう、という意思を共有できるのではないでしょうか。

自分はこんなに設計がんばったから、後はプログラミングを頼んだぞ、
という形で次の工程に引継ぐことができれば、プログラマさんも頑張れると思います。

「意味不明な要件を押し付けられたから自分なりにアレンジして設計しました。
性能に問題出るかもしれないけどプログラマさん達の腕で乗り切ってね」
という調子では頑張れるものも頑張れません。

そのように考えると、成功するウォーターフォール開発で引き継がれるのは
ドキュメントとプログラムソースだけでなく、お客様に価値あるものを提供したいという
意思そのものなのかもしれません。