なぜウォーターフォール開発は「建設業的」なのか
IT業界で働く30代・40代の社会人、特にエンジニアやプロジェクトマネージャーの皆さんは、一度は「ウォーターフォール開発」に頭を悩ませたことがあるだろう。
要件定義から設計、実装、テスト、リリースへと進むあの直線的なプロセス。進め方は分かりやすいが、ちょっとした要件変更で全体が崩壊する。まるでジェンガを積んでいるような緊張感だ。
この記事では、ウォーターフォールがなぜ“ゼネコン文化”に強く影響を受けたのかを解説する。結論を先に言うと、「ウォーターフォールは建築業の思想をソフトウェアに輸入した結果」だ。そして、その背景を理解すると、現代のプロジェクトマネジメントにどう活かせるかが見えてくる。
結論：ウォーターフォールの本質は「建築的思考の輸入」である
ウォーターフォールモデルは、ソフトウェア開発のために自然発生したものではない。
建築や土木の世界で使われていたプロジェクト管理手法を、そのままソフトウェアに持ち込んだところから始まっている。
ビルや橋を建てるとき、設計図を引いて、資材を調達し、工事を進め、最後に検査を行う。この流れをソフトウェアに当てはめれば合理的に見える。だが問題は、ソフトウェアが「設計図通りに作れば完成するもの」ではなかったことだ。ここに悲劇と喜劇が同居している。
ウォーターフォールがゼネコン文化に染まった理由
1. 設計図至上主義の影響
ゼネコン業界では、設計図が絶対的な存在だ。施工現場で「やっぱり壁を曲線にしましょう」と言い出したら現場監督に怒鳴られる。ソフトウェア開発も同じように「最初に仕様を完全に決めてから作るべき」と考えられた。
だが現実はどうか。ユーザーは触ってから「ここ使いにくい」と言い出す。まるで家を建てた後に「やっぱりキッチンは2階がよかった」と言われるようなものだ。
2. 工期と予算の考え方
ゼネコンの世界では、契約時に工期と予算をガチガチに決める。ソフトウェアも同様に「完成は6カ月後、予算は5000万円」と設定される。しかしソフトウェアは目に見えない分、進捗が測りづらく、予定通りに終わらないことが多発する。
「あと3日でコンクリートを流し込む」とは違い、「あと3日でデバッグが終わる」と言われても誰も安心しない。
3. 大人数前提の体制
建設工事は数百人単位の大規模プロジェクトが当たり前。だから「役割分担」「階層的な指揮命令系統」が強調される。ウォーターフォールも同じく、要件定義担当、設計担当、実装担当と分業が進んだ。
しかしソフトウェアは10人程度のチームでも十分開発できる。そこで過剰に「お役所的な工程管理」を持ち込んでしまった。
4. 事例で見る「建設的ウォーターフォール」
例えば、ある病院のシステム導入案件。最初の要件定義では「患者情報を登録する画面」としか決まっていなかった。
ウォーターフォール的に進めると、設計者は「入力フォーム20項目」と図面のように作りこみ、実装者は忠実に再現した。
ところが現場の医師が使った瞬間、「入力が多すぎて回診中には使えない」と不満を爆発させた。
建設的発想では「図面通りに建てたのだから問題ない」だが、ソフトウェアはそれでは通用しない。
ウォーターフォールをどう活かすか
ウォーターフォールが完全に悪というわけではない。
要件がほぼ固定しており、長期間変わらないシステム（例えば銀行勘定系や基幹系）は、ウォーターフォールで進めたほうが安全な場合もある。
重要なのは、ウォーターフォールを「万能モデル」と誤解しないことだ。
| ウォーターフォールが向く場面 | ウォーターフォールが向かない場面 |
|---|---|
| 要件が固定されている | ユーザー要望が頻繁に変わる |
| システムの寿命が長い | 市場の変化が激しい |
| 安全性や法規制が厳しい | UXが重視される |
つまりウォーターフォールは、工事現場での「足場」のようなものだ。大きな建物を建てるには必要だが、遊具を作るときに足場を組むのは大げさすぎる。
まとめ：ウォーターフォールを歴史的文脈で理解する
ウォーターフォールは、建築や土木の文化を背景にソフトウェア開発へ持ち込まれた。
その結果、「仕様書が設計図」「工期は絶対」「分業体制が当たり前」という前提でプロジェクトが進められるようになった。
だが、ソフトウェアは物理的な建物とは違い、完成してからも容易に形を変えられる。
この柔軟性を無視してウォーターフォールを適用すると、現場は苦しむ。
読者に提案したいのは次の3点だ。
- ウォーターフォールを「絶対的な手法」と思わないこと
- 案件の性質に応じて、アジャイルやハイブリッド手法を検討すること
- ゼネコン文化の影響を歴史的に理解し、手法を使い分ける目を養うこと
最後に一言。
もし「ウォーターフォールは古い」と感じるなら、それはあなたがソフトウェアを「建築物」ではなく「生き物」として捉え始めている証拠だ。生き物に設計図はない。だからプロジェクトも柔軟に育てていく必要がある。
