システム開発プロジェクトの途中で要件が膨らむというのは、プロジェクトが失敗する代表的なパターンである。上流の要件定義が甘く開発途中で隠れた要件が判明したり、利用部門の追加要求というゴリ押しにIT部門が抗しきれなかったりと、色々とバリエーションはあるが、要件の膨張はプロジェクトを大炎上させる“王道”だ。私が「極言暴論」でプロジェクト炎上をネタにするのは、大概このパターンだ。
要件の膨張を言い換えると、スコープ（システム化の範囲）の膨張という。なぜ言い換えるかというと、スコープの縮小でシステム開発が失敗するパターンも結構あるからだ。もちろんスコープの縮小は、要件の縮小でもあるはずだが、本来の要件は縮小していないはずなのに、スコープ、つまりシステム化の範囲のみが縮小するという摩訶（まか）不思議な現象が、特に大企業で多発しているのである。
というわけで今回の極言暴論では、システム開発プロジェクトを大失敗に終わらせる「スコープの膨張」と「スコープの縮小」という正反対の現象について比較し、論じたいと思う。正反対の理由とはいえ、大元の原因は同じだ。極言暴論で書くぐらいだから、既にピンと来た読者も多いだろう。つまり、現場任せの社長、主体性の無いIT部門、ワガママな利用部門といった愚か者が織りなす喜悲劇の帰結だ。
読者の中には、「スコープの膨張でプロジェクトが破綻したという話はよく聞くが、スコープの縮小でシステム開発が失敗したという話を聞いたことが無いぞ。そもそもプロジェクトの途中でスコープが縮小するなんてことが起こり得るのか」と疑問に思う人もいるかもしれない。そんな読者はおそらく、利用部門が「あれも作れ、これも作れ」とゴリ押ししたくなるシステムだけを想定しているはずだ。
だが、企業が導入するシステムはそんなシステムばかりではない。つまり、こういうことだ。「部分最適のためのシステムは、開発プロジェクトの途中でスコープが膨張する。一方、全体最適のためのシステムは、途中でスコープが縮小する」。お分かりいただけただろうか。それでは、この正反対の失敗パターンについて詳しく書くことで、日本企業のIT投資のアホさ加減について改めて示すことにしよう。
