制約って変更できないと思い込んでいませんか

プロジェクトにおいてQCD（Quality, Cost, Delivery)とS(Scope)はプロジェクトに制約を課す要素です。

さて、この中で厄介なのがDeliveryの納期です。

例えば、要求品質を満たしていなければ、品質を要求レベルを満たすための活動が必要ですから、その活動分の時間とコストがオーバーランします。

次のケースは、コストがオーバーランしてしまえば作業が計画より多いことが想定できるので納期もオーバーランしてしまっていることが多いです。なんとか納期に間に合わせるために人海戦術で辻褄を合わせようとすれば納期は守れても品質に影響しているものです。

納期自体がオーバーランしてしまう場合、納期がオーバーランする原因はスコープのクリープや見誤りなどだったり、品質が要求レベルに達していなかったりすることが原因だったりします。それに友擦れとなってコストもオーバーラン…。

エンジニアはプロマネやSEリーダからタスクをアサインされることうを受け入れ、結果的に訓練されてきた結果、QCDの制約は変えられない、与えられるものだと思い込んでいるのではと思うのですが。

スケジュールの見通しが不透明、つまり、計画通りに出来上がる見通しが付いているのであれば、制約を変えることを考えてそのアクションをした方が良いです。

納期は法対応でもなければ、リスクを誰が持つかという問題はあります（基本は顧客ですが）が、全く余地がない訳ではないです。顧客の中での政治的な要因の方が多いです。

コストもそうです。顧客側（社内でも）リスク対策予算は持っているものです。品質は下げられないので、分割リリースにするという手段があります。

注意した方がいいのは、変えるなら変えたことにより他の制約が生じないかをプロジェクト全体の観点でサーベイすることです。

発注者のプロジェクトマネジメントと監査 ―システム開発トラブル未然防止の神髄に迫る―