なぜIT業界がきついのか

　ウォータフォールモデル開発では、プログラムを作る前に仕様書（基本的に紙）という形でユーザに設計を承認して貰うわけですが、グラフィカルな画面を紙で表現されてもユーザには完全にイメージできるものではありません。というよりも、「書いている本人でさえイメージできているのか？」と疑問を持つことすら多いです。しかし、開発を進めるためには承認作業は必要で、曖昧なイメージで承認された仕様書（設計）で進めて行くことになります。

　ウォータフォールモデル開発では承認されたものは正しいという前提になりますが、その前提を覆す仕様変更が起きたときに、前工程に遡る大規模な手戻りが発生することが最大の問題です。しかし、ユーザは曖昧なイメージで承認している訳ですから、そもそも承認されたものは正しいという前提は壊れている。余程、ユーザの要望がはっきりと分かりやすい場合を除き仕様変更は必ず発生します。

　開発の終盤になって、実際のプログラムをユーザが見てイメージとのギャップを口にしたとき、それをユーザが「仕様変更」である、つまり「自分たちの承認が間違っていた」と認めて、「納期延長と追加費用」を認めてくれた場合か、運良く「仕様変更」が当初の見込み分ぐらい（普通、ある程度のバッファをもって見積もる）しか発生しない場合は、そのシステムは成功したことになります。しかし、ユーザが「仕様変更」（納期延長と追加費用）を認めてくれなかった場合は、いわゆるデスマーチという状態になります。現実問題としてほとんどの場合、予想以上の仕様変更が起こり、高い確率で「納期延長」が認められることはありませんから、IT系の仕事は長時間労働が常態化しいわゆる３Ｋ職と言われるわけです。

　それでも、抜本的な解決策を講じることなく、デスマーチの後には「ユーザが仕様変更を認めざるを得ないドキュメントを作るべきだった」という反省を行い、解決策としてドキュメントが増えていきます。ドキュメントが増えれば更に工数が掛かりますが、増えたドキュメントは良いシステムを作るために生まれたドキュメントではなく、「仕様変更」という言い逃れをするためのドキュメントに過ぎませんから、生産性には何も貢献しません。