「現状のソフトウェア開発は間違っていないか？」（プロセス編）：ソフトウェア開発の匠（3）（1/3 ページ）

萩本　「皆さんは、ソフトウェアを開発するときに、どのようなプロセスを踏んでいますか？」

多くの人たち　（シ〜ン）

萩本　「例えば、最初に要件定義をし、基本設計をして、詳細設計に進むとか」

何人か　（自信なさげに手を挙げる……）

　これは、講演での筆者の質問に対するお客さまの一般的な反応である。最近では、開発者が開発のプロセスを意識しなくなっている気がする。第2巻では、開発者に開発プロセスを意識させる試みを通じて、匠（たくみ）の技を見つける手掛かりを探してもらう。

ウォーターフォール開発とは

　今回は、中規模・大規模開発で使われている開発プロセス「ウォーターフォール開発」を改めて考える。ウォーターフォール開発とは、名前のとおり工程（フェイズ）が滝のように流れる開発手法である。つまり、上流工程で作業をしっかり進め、後戻りしないことを“お約束”としている。しかし、実際にはどんどん後戻りすることを常とする不可解な開発方法である。

　ウォーターフォール開発のイメージを図1に示す。ここで示す工程名は、別の名前で呼ばれていたりもする。例えば基本設計や詳細設計が、外部設計、内部設計というふうにだ。名前ではなく、上流工程が終わらない限り下流工程を始めない開発が、ウォーターフォール開発なのである。

　ウォーターフォール開発は、多くの問題を抱える手法だ。しかし、IT業界では、いまだにこのやり方がメジャーなのである。ウォーターフォール開発がメジャーであり続ける限り、IT業界はどんどん無価値化していくと私は考えている。どうしてメジャーであり続けるか、そして、なぜそれがIT業界をダメにするのかといった理由は後で書くことにする。

図1　ウォーターフォール開発

ウォーターフォール開発の失敗

　ここでは、まずウォーターフォール開発の失敗例をいくつか取り上げ、その中からウォーターフォール開発の問題点を整理していく。

ウォーターフォール開発の歴史

　ウォーターフォール開発プロセスは、開発プロセスの基礎知識と考えるとよい。ウォーターフォール開発は、旧来のCOBOL/PL?などを使ったメインフレーム開発で主流の開発プロセスだった。1980年代から始まり、現在でも使われている。昔は、それぞれの企業が独自の開発手法（ウォーターフォール開発がベース）を用意していた。当時の開発者は、その開発手法をしっかり勉強して開発を行うというのが常識だったのだ。

　このころの開発者は、設計する前にしっかりと要件定義をしていたし、実装する前にきちんと設計をしていた。つまり「要件定義とは何か」「設計とは何か」ということを学んでいた。

　このようなウォーターフォールの開発スタイルは、メインフレーム開発では比較的うまくいっていたように思うし、筆者もメインフレームでのCOBOL言語を使った開発では、しっかりと要件定義を行い設計すれば、ほとんど実装ができるという感覚を持っていた。