「動くコードがあるなら設計書はいらない」という考え方を耳にすることがあります。しかし、業務システムの現場では、その考え方は非常に危険です。
設計書の役割は、単に仕様を記録することではありません。誰が見てもシステムの構造や意図が分かる状態を作ることにあります。たとえば、入力チェックの条件、DB更新の流れ、例外時の挙動などは、コードだけでは読み解きに時間がかかります。特に保守フェーズでは、設計書があるかないかで調査コストが大きく変わります。
また、設計書はチーム開発における共通言語でもあります。開発者、テスター、運用担当、場合によっては顧客も、設計書を通じて同じ認識を持つことができます。
もちろん、設計書は作ればよいというものではありません。現実に使われない分厚い資料を作るのは非効率です。重要なのは、「将来の自分や他人が困らないレベル」で整理されていることです。設計書は成果物であると同時に、開発を安定させるための保険でもあります。