仕様変更きたら大丈夫？

「仕様変更」何という悪魔的響きでしょう。この言葉が走る度、職場は絶望と運命を感じ、今日は決して帰ることができない事を覚悟するのです。

仕様変更はすべきではないという意見は確かにそのとおりなのですが、人間が仕事をする以上、出来上がりを完全に予測する事は不可能であり、また開発中に事情が変わることも否定できません。

極力仕様変更は控えるべきですが、現実問題しなくてはならない場合もあるので、開発は地震や台風に対するように備えなくてはなりません。

テストやチェックをした後で他部署やプロデューサから様々な事情で仕様変更を要求されることがままあります。

とゆうか、必ずあります。

ゲームとして完成されていても、売れる商品として完成されているのかは別の問題です。作られた商品を見て、改善する箇所があるのならば改善するべきです。

もちろん十分な時間と費用があればの話ですが。

では仕様とシナリオの両方で仕様変更があったとします。

両方とも一日で変更可能な作業内容だとします。

ガンチャート1の場合は、一人で仕様変更作業を行いますので、作業日数は分担して行うガンチャート2の倍かかります。

商品として完成させる為に、仕方なくスケジュールを伸ばし納期を遅らせてしまうと、その分営業的な機会損失となりますし、他部署の作業工数が余計にかさみ、結局は損をしてしまうことがよくあります。

販売延期を繰り返し、その都度損失を取り返そうと売り上げ目標が上がり、それを満たす為に内容を修正し、結局販売延期をせざるを得なくなる悪循環が発生します。

もちろん、「ここいらでクオリティアップの手を止める」という決断も必要なのですが、スケジューリングや開発管理においては事前にこういった必然的な案件もおりこんで考える必要がありますね。

～続く～

ゲーム開発の見積りについて考察　[7]