これまで、多くのシステム開発に携わってきましたが、規模が大きくなるほど開発には遅れが発生します。
納期が遅れないにしても、
・予定した機能の一部をフェーズ２以降に先送りする
とか
・マニュアルの作成は、別納品とする
など、納品時期を変更するということはよくあるお話ですね。

システム開発の遅れの原因は様々です。
システムを利用する側の都合によることもありますし、経済状況や運用のことを考えて戦略的、発展的に遅らせる、ということもあります。中には、遅らせる、というより、しばらく開発を見合わせる(ペンディング)という場合もあります。
ここでは、「開発自体の遅れ」について考えて見ましょう。
つまり、開発側で「納期に間に合わせることが物理的に不可能」という状況になってしまう原因についてです。

開発が遅れる原因で最も多いのは、上流工程がスケジュールどおりに進まない、ことによるものです。
システム開発は、通常、以下のような流れで進めます。
1.要件定義
2.設計
3.製造
4.テスト
5.納品
細かく分けるとたくさんあるのですが、大まかに書くとこんな感じです。
上の流れは、この順番で進んでいきます。
若干、期間が重なることはありますが、順番が入れ替わることは基本的にはありません。
なぜかというと、順番どおりに進めないと開発ができないからです。

スケジュールどおりに進まない上流工程、というのは「2.設計」の部分です。
設計が遅れると、製造が始められません。
また、設計の遅れをその後の製造とテストで取り戻す、ということはとても難しいのです。
ですので、設計が遅れると、システム開発全体が遅れてしまいます。
では、なぜ設計が遅れるのでしょうか?

設計が遅れる理由は、主に以下の二つです。

1.要件が明確になっていない

　要件をまとめられないと言った方がいいのかも知れません。
　要件は、お客様と開発会社の双方が協力して明確にするものです。
　要件自体は、お客様の業務の中に眠っています。
　これを引っ張り出し、明確にしてどうシステム化するかを決めるのが要件定義なのです。
　しかし、この「要件」はお客様の協力抜きに引っ張り出すことは不可能。
　でも、お客様は開発会社に任せきりで知らん顔。
　開発会社が頑張って、担当者はとても大変な作業(勉強と調査)を行なうことになりますが、残念ながら中途半端な要件しかまとまりません。
　外部の人間だけで要件をまとめるのは、とても難しいのです。

　中途半端な要件で設計を始めると、設計中に「残りの要件定義を行なう」ことになりますから、当然、予定した期間では終わりません。
　この部分が遅れになります。

2.設計途中での仕様変更要求

　要件定義が終わって設計に入っているのに、
　・この機能がないとダメ、と上から言われた
　・やっぱりこうしてほしい
　などと、仕様の追加や変更を要求してくるお客様がなんと多いことでしょう。
　多少の変更は対応できますが、開発途中(すでに設計もほぼ固まっている状態)なのにこういうことが頻発してしまうことがよくあります。
　設計の大幅手戻りが発生するような大幅変更は、さすがにお客様もあきらめざるを得ませんが、やっかいなのは小さな変更の積み重ねです。
　ひとつひとつは小さなものですしスケジュールへの影響も少ない(ように見える)ので比較的簡単に了承されてしまうのですが、これが「チリも積もって」遅れを引き起こします。

　平気で要求するお客様もよくないのですが、断ることもせずに受けてしまう「ダメPM」が諸悪の根源です。
　頻繁な仕様変更は、仕様を汚くしますし、開発者の士気も低下させます。
　すなわち、スケジュールだけでなく最終的なシステムの出来も悪くなるのです。

上の二つについては、原因はお客様と開発者双方の「考えの甘さ」にある、と言えると思います。
システムは、最初に開発したものをベースに、手直ししながら「育てて」いくものです。
最初に、しっかりしたものを作っておかないと、「育てる」どころか途中で「倒れて」しまいます。
このためには設計が大事です。
お客様も開発者も、この点を肝に銘じておかなければなりません。