システム開発の世界では「下流工程よりも上流工程に時間をかけろ」という言葉をよく耳にする。これは本当に正しいのだろうか。
「要件定義や設計などの上流工程に資源を集中的に投入し，この段階でバグの芽を摘んでおくことで，コーディングやデバッグ，テストといった下流工程の負担を軽減すると同時に，予想外の手戻り作業を撲滅する。そうすれば，開発期間を短縮できるだけでなく，品質の向上にもつながる」。これが冒頭の言葉の意味するところである。
確かに，デバッグやテストの段階で，設計や要件定義のフェーズまでさかのぼる重大なバグが検出された場合，スケジュールの大幅な見直しを迫られる。ところが，プロジェクトの終盤になってカットオーバーを遅らせるのは現実問題として難しいので，結局デバッグやテストのフェーズが突貫工事になってしまう。そうなると，焦りと疲労が災いしてメンバーがミスを犯しやすくなり，泥沼状態に陥る。これでは，たとえ無理をして予定通りにプロジェクトを完了しても，出来上がったシステムの品質は低くなってしまう。
しかし，それでも筆者はあえて言いたい。「上流工程に時間をかけるな」と。そう考えるのは，筆者自身がそうであるように，人間は基本的に楽な方に流れる動物であり，機械のように常に一定の速度で走ることは不可能だからだ。早い話，人間は“タイムリミット”が迫らないと本気になれないのである。
例えば，全工程が1年のプロジェクトがあって，半年を上流工程，残りの半年を下流工程に充てたとしよう。このスケジュール通り，整斉粛々とプロジェクトが進行するのなら，それは理想だ。
しかし，たいていのプロジェクトでは，そうはならない。なぜならプロジェクトの序盤では，SEは時間的にも精神的にも余裕がありすぎて，楽をしてしまうからだ。要件定義や全体設計の重要性は認識していても，「カットオーバーまでまだ1年もある」などと考えてしまい，なかなか根を詰めて働く気になれない。しかもコーディングやテストのフェーズと違い，上流工程では進ちょく状況を定量的に把握するのが難しい。
筆者はSE時代にこんな経験をしたことがある。要件定義の期間を3カ月に設定したあるプロジェクトで，最初の2カ月が過ぎてから，成果物についてユーザーと合意がとれていないことが判明した。それまでは，メンバーからの報告を聞く限り「オンスケジュール」だったのだが，あっという間に「2カ月遅れ」に変わってしまった。
しかし面白いことに，このプロジェクトは最終的にはオンスケジュールで完了した。なぜなら，ユーザーとSEが本気になって頑張ったおかげで，要件定義を残り1カ月で無事に終えたからである。逆に言えば，1カ月あればできる作業に，3カ月充てていたということになる。
こういうケースは意外に多い。筆者が「上流工程に時間をかけるな」と言うのは，そういう意味である。上流工程に十分な時間をかけたいという気持ちは分かるが，逆に「こんなの無理だよ」というくらいきついスケジュールを作成して，メンバーが“追い込まれた”と感じる状況を作るべきだ。つまり，上流工程では飛ばせるだけ飛ばして，できるだけ早く下流工程の物量勝負に持ち込む。そうすれば，いざ下流工程で重大な問題が発生しても，何とか巻き返せるだけの時間的余裕が生まれ，突貫工事やスケジュール見直しという最悪の事態を避けられる。
上流工程で楽をしないこと，させないこと。そして，できるだけ早く物量勝負，体力勝負に持ち込むこと。これがプロジェクト成功の秘訣だと筆者は思う。時間があればあるほど楽をしたがるのが人であり，時間がなければないほど真剣になるのが人なのだ。
え？ それは筆者だけだって？
