締切直前の仕様変更は本当に困りますよね。私も経験があります。以前、金融系の案件で2日前に「計算ロジックを変更してほしい」と言われたことがありました。

その時は、まず依頼者と30分ほど話して、変更内容の優先度を整理しました。すべてを対応するのは物理的に無理だと判断したので、「今回の変更で必ず必要な部分」と「次回でも対応可能な部分」に分けてもらうようにしました。意外とクライアント側も全部が急ぎだと思い込んでいたケースが多くて、整理するだけで作業量が半分以下になることもあります。

その上で、変更に関わる部分の既存テストが無駄にならないか確認しました。既にテスト済みの領域を大きく変えると、その分の検証時間が必要になるので、影響範囲を最小化することを心がけました。

個人的に感じるのは、「完全な完成品」を目指すより「信頼できる状態での納品」を優先した方が、後々のトラブルが減るということです。仕様変更に完全に対応できなかった部分については、納品時に明確に伝えることで、クライアント側の心構えも変わります。完璧を目指して納期を破るより、事実を伝えて調整する方が、実務的には上手くいくことが多いですね。