仕様変更と認識の違いで変わる開発費用

開発の途中で「これは仕様変更なので追加費用が発生します」と言われ、困惑した経験を持つ発注者は少なくありません。追加請求が正当かどうかの判断基準と、あらかじめ備えておくバッファの考え方を整理します。

仕様変更と認識の違いは別物

追加費用をめぐるトラブルの多くは、「仕様変更」と「認識の違い」の混同から起きます。

仕様変更：発注者が後から要件を追加・変更した場合。「やっぱりこの機能も追加してほしい」「最初と違う動きにしたい」は仕様変更です。追加費用が発生するのは正当です。

認識の違い：発注者は最初から伝えていたつもりなのに、開発会社の理解が足りていなかった場合。これを発注者側の「仕様変更」として請求するのは問題があります。

この2つは、契約時の仕様書・議事録・メールのやりとりで判断します。

以下を確認することで、請求の正当性を判断できます。

1. 契約書と仕様書を照合する：請求の対象となっている機能・変更が、当初の仕様書に含まれていたかどうかを確認します。含まれていれば、追加費用の請求には根拠がありません。

2. 変更を依頼した記録を確認する：メール・チャット・議事録で、発注者側から変更を依頼した記録があれば仕様変更です。口頭での依頼を記録していない場合は、双方の主張が食い違いやすくなります。

3. 変更前に合意があったか確認する：正当な仕様変更の場合でも、費用が発生することを事前に合意してから作業を進めるのが適切な手順です。作業後に突然請求される場合は、手続きの問題があります。

トラブルを未然に防ぐためには、契約前の仕様固めが最も重要です。

仕様をどれだけ丁寧に固めても、開発を進める中で「やっぱりここは変えたい」「実際に使ってみたら使いにくかった」という変更はほぼ必ず発生します。これは発注者・開発会社どちらのせいでもなく、システム開発の性質上避けにくいものです。

対策として有効なのが、最初から予算と期間にバッファを設けておくことです。目安として、開発費の 15〜20% を変更対応の予備費として確保しておくことをおすすめします。要件が固まっていない段階での発注や、初めて取引する開発会社の場合は、20%以上を見ておくと安心です。

期間についても同様です。「この日までに絶対リリース」というハードデッドラインがある場合は、スケジュールに2〜4週間程度の余裕を持たせた上で開発会社と合意しておきます。バッファがない状態で変更が発生すると、品質を犠牲にして間に合わせるか、リリースを延期するかという二択になります。

話し合いで解決しない場合は、以下の手段があります。

最も避けたいのは、感情的なやりとりで関係が壊れることです。事実に基づいて冷静に確認・交渉することが、解決への近道です。