最近読んだミステリ小説『ブラックペアン1988』（海堂尊著）の中に、
外科医が使う器具として「スナイプ」というものが登場しています。

この器具を使えば、優秀な外科医でなくとも、
リスクを少なくして難解な手術を成功させることができるのです。

ところが、若手の外科医がこれを使って手術したときに、
使用法を間違ってしまい、患者の命を危険にさらしてしまいます。

手馴れた優秀な外科医がすぐ入れ替わって手術したために、
事なきを得ます。

このとき、院長がスナイプを強く推した医者に言う言葉があります。

　「お前はいっていたな。
　あのオモチャが広く世の中に受け入れられれば
　外科の世界が一層広がる、と」

　「お前の企ては自己破綻している。
　このオモチャが一般化するためには、今日のような失敗をしたときに
　リカバリーできる外科技術があることが前提だ。
　だが、オモチャが一般化した場合、
　外科医からそうした技術習得の機会を奪うことになる。
　この自家撞着をどうするつもりだ」

　（講談社　『ブラックペアン1988』より抜粋）

これを読んだときに、
巷でウォーターフォール型の開発について言われていることを
考えずにはいられませんでした。

ウォーターフォール型の開発とは、上流から下流までを、
工程別にスコープを区切って開発する手法を言います。

前工程までが正確に完了していることを前提として次工程に進むため、
当然のごとく最上流の工程である「要求分析」が最重要となります。

そのため、上流工程だけを行うSEが、もてはやされる傾向があります。

又、工程ごとの成果物としては、
ドキュメントの作成がOUTPUTとなるため、
別名「ドキュメント駆動型のシステム開発」とも呼ばれているようです。

システム開発の書籍でも、
「要求分析」や「ドキュメントの書き方」が人気が高いのは、
こういう理由があるんですね。

別の観点から見ると、
「ウォーターフォール型」は旧来型のシステム開発の手法であり、
「下請構造型のSIerが行う開発に非常に適したものなのだ」
という皮肉な意見があることも事実です。

こういった意見が出る場合には、
「プロトタイピング型」
「オブジェクト型システム開発」
「アジャイル開発」
といったものが、
ウォーターフォール型の対抗馬として唱えられているようです。

ウォーターフォール型が最適であるか時代遅れなのかどうかは別として、
システム開発を家業とする当社では、システムの規模が大きくなればなるほど、
また、難易度が高くなればなるほど、
ウォーターフォール型をより細かなプロセスで遵守した方が
良い結果が出ていることは事実です。

「下請型」の日本のIT開発に適した・・・。

という悪口をそのまま受け入れて考えてみましょう。

例えば、一つの会社のプロパー（正社員）のみでの開発であったとしても、
また、大規模であれ小規模であれ、
システム開発を成功させる評価点は、常に共通です。

それは、
「品質が良くて、原価割れせず、納期に間に合うこと」
これのみなのです。
まさにQCDです。

しかし、技術者と呼ぶ場合、私たちは、
常に一定の水準以上の技術者を想像しますが、
現実は、全員が一定以上の水準ということはありえません。

なぜなら、技術者として数年以内（例えば2年）のキャリアで
一定の水準以上の技術を持つことはありえないからなのです。

本人の資質や教育だけでなく、経験や仕事の現場が人を育てる部分が、
確実にあるのです。

ウォーターフォール型開発には、
この成長途中の技術者にも十分にその役割を担うことができるように
分担ができているのです。

これが技術者を育てようとする会社にとっては、魅力なのです。

また、大きなものから小さなものへ分解していくやり方や、
プロセスごとにドキュメントを成果物としてきちんと残して
追っていくやり方は、論理的な思考能力と理解に適しているのです。

まだまだ捨てたものではない開発手法。
言い換えればシステム開発の基本形をなすのが
ウォーターフォール型なのです。

「型を覚えてから崩す」
応用編は、いくらでもあるでしょう。