ソフトウェア工学発展史 −ウォーターフォール（落水）モデルの錯覚・誤用・悪用の30年− 　前回までは、ソフトウェア工学の優れた知見を解説してきたが、今回は劣悪な知見、ソフトウェア開発の現場に30年近く災害を撒き散らしてきた知見の一つに触れよう。 ソフトウェア開発プロセスの最初のモデルは、1970年のウインストン・ロイスの「ウォーターフォールモデル」であった。これは、開発プロセスを、 仕様分析定義　→　設計　→　プログラミング　→　検査　→　出荷　→　保守 のように、順番に定める＜線形性＞を仮定したモデルである。当初、ロイス自身は、正当にも、逐次的ではあっても各工程ごとにフィードバックが必要であるとした。 　しかし、これが国防総省の軍規格 DOD-STD-2167 にいたって、このフィードバックが欠落したのだった。そして、軍や公共プロジェクトで、フィードバックなしのウォーターフォールプロセス開発がはびこった。フォードの自動車工場におけるアセンブリー（組立て）ラインの再来である。 　結果は、周知のごとく、ほとんどの大規模プロジェクトで、納期の遅延、コストの高騰、機能の欠落、プロジェクトの崩壊をもたらしたのだった。 この解決に奮闘した現場のまともなプログラマたちは、当初から、仕様確定の困難さあるいは不可能性、線形モデルの非現実性、非線形性をこなすフィードバックの明示的取り込みの必要性に気づいていた。そして、ラウンドトリップ（周遊）モデルやプロトタイプ（雛形）モデルやインクリメンタル・モデルを提唱したのだった。 しかし、国防総省を始めとする発注者や現場の管理者は、現場を上っ面だけ理解した気分になればよいとする皮相性、発注や外注のもっともらしさの形式性、いかにも管理をやっているという錯覚などから、ウォーターフォールモデルにとびついたのだった。米国や日本の大手民間企業の情報システム部門もご同様であった。 　1988年にいたって、軍規格が DOD-STD-2168A に改訂され、逐次プロセスに、フィードバックが加わったが、プロセスやプロダクトの複雑性にたいする皮相的理解を依然として引きずっている。そういうわけで、いまだに落水モデルが日本でも米国でもはびこっているのが現状だ。 　なぜそうなるのかについて堅苦しいことを言えば、欧米人（とくに米国人）の閉鎖的論理性が主因である。イエスかノーかあるいは0か1かという二分法の信奉、悪名高い三段論法の過用つまりは閉鎖的論理学の過信、ひいては西欧的な還元主義の悪弊に基づいているのだ。 　ヴィットゲンシュタインなら、要素還元主義の欠点にとっくに気づいていたのだった。町場の日本人なら、寅さんではないが、「いろいろあらあーな」という現実をよくよく弁えている。ところが、大組織や役所では、線形思考が蔓延るのは洋の東西を問わない。 結果は、1990年代に至っても、大規模プロジェクトの失敗事例に事欠かないわがソフトウェア産業となっている。近くは、大手都市銀行の不始末を見れば、わかりやすい。 もっとも、事態はさらに悪化していると判断される傾向もあるのが新世紀初頭である。つまり、「パソコンおたく」や「サーバーおたく」の場合、ソフトウェア開発の分析・設計・実現あるいは分析・モデリング・組立てという＜プロセス＞自身に、気づいていないのではないかという危惧が散見されるのである。 　プロジェクトのプロセスについては、最近「プロジェクトマネージメント知識体系（PMBOK：ピンボックなどと発音する）」をマスターした「プロジェクトマネーメント技術者」を、国家資格化としようとする動きもあるので、現場のプログラマも一度じっくり勉強したほうがいいかもしれない。 　とりあえず、XP（エクストリーム・プログラミング：軽いプロセスに基づくプロジェクト管理）などを試行するのもよいであろう。