ウォーターフローモデルの日本

ウォータフローモデルとは，IT企業がソフトウェアシステムの構築を行う際に古くから行われているポピュラーな開発手法を，ソフトウェア工学の研究分野で名付けたものである．
日本由来の言葉で分かりやすく言い換えると，「段取り」である．あらかじめ段取りを組んで，段取り通り進めていくというやり方が，ウォーターフローモデルである．

Wikipedia「ウォータフローモデル」には次のように説明されている

ソフトウェアシステム作りを抽象度の高い，要求定義から始め，外部設計（概要設計），内部設計（詳細設計），開発（プログラミング），テスト，運用，などの作業工程（局面、フェーズ）に分割し、原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にする．

「手戻り」が曲者で，最小限どころか，なし，または，ほぼなしにされることが多い．ソフトウェア発注者が作成者に，手戻りを求めると，大きな費用と，少なからぬ期間延長が発生しますよ，と脅されて尻込み，要求を引っ込める事が多い．

さらに同Wikipediaにはこうも説明されている．

ウォーターフォール・モデルの問題点は、『前工程に間違いがない』ことを前提または期待していることである。

経験のないプロジェクトであるならば、設計段階になって前工程の要求定義の不備不足が発覚するのは、むしろ当たり前であるはずなのに、ウォーターフォール開発においては、それが見越されていないことが多い。そのため、ウォーターフォール開発プロジェクトが成功するためには、過去に同じようなプロジェクトで一度失敗している必要があると言われている。

ウォータフローモデルは，ソフトウェアシステムだけでなく，もっと大掛かりなシステムである，社会システムについても言えるのではないかと最近気づいた．最近のわかり易い例は「原発システム」．単にモノを作る部分だけでなく，それ以前の，意思決定レベルも含めてである．

最近，いくつものIT企業と付き合ったり，話をしているうちに，日本の大手IT企業は基本的にウォータフローモデルに載らないソフトウェアシステムを作ることは大いに苦手とすることを思い知るようになった．おそらく，日本という風土，文化の中で，ウォータフローモデルは最も適したやり方で，それに即して日本の企業は適合・進化してきたのであろう．

しかし，「手戻り」を許さないシステムは危険である．そのことを今回の原発事故で我々は深く思い知らされている．

「ウォータフローモデル」が優れた面は確かにあろう．日本の今日の繁栄は「ウォータフローモデル」が成功した証でもあるかもしれない．しかし，日本が成功していない部分，および，今回の危機的な状況に至る原因の一つが「ウォータフローモデル」にあるのではないかということが現在の私の仮説である．

日本は「ウォータフローモデル」から解放されるべきである．