設計と実装って・・・

一人でシステムを構築するなら、設計と実装は同時並行というか実装だけでも作れちゃいます。
自分の頭の中にやりたいことが整理されてさえいれば、お客様との合意のための文書と納品のための文書以外は無くったって困りません。（この文書群から、外部設計書とか試験仕様書とか試験結果資料とか無いように決めれればですが）

多人数で設計部隊と実装部隊を分けるのなら、設計文書は実装部隊との合意のための文書になるので必須です。
全部が完成している必要は無いですが、完成していないと困るものがあります。

例えば、お客様が業務として定型的に行っている作業とかを業務共通としてまとめておくこと。
例えば、画面の大まかなつくり・・・業務としての排他とかシステムとしての排他、トランザクションの保持期間とか、メッセージの出し方とか、名前の付け方とかいろいろをシステム共通としてまとめておくこと。

前者は権限とかで動作を変える場合などのあらわし方で、ある程度整理して、システム共通として定義したりします。
製造部隊からみると、どのクラスやオブジェクトのメソッドにどんな情報を渡せばよいかを把握しておけばよいことになります。

後者が決まっていないと、製造部隊は物を各自の経験に基づいてばらばらに作ることになります。チームの文化として共有できていれば何とかなるのですが、急ごしらえだと、ばらばらになります。
設計書はメモ書きでもサンプルが無いと伝わらないです。

所謂、共通設計ってのができていないと、製造はとまります。とまらない場合、後で戻ります。
しかもこの戻りは、製造部隊のモチベーションを大幅に下げるものです。（どーせ、今書いても、また変わるんだからなぁってね）

業務仕様が変わって変更するのもきついですが、お客様からのご要望だし、予期できることでもないから、これは、ある意味納得いくものです。でも、設計での共通化での漏れと戻りは度重なると結構ダメージが大きいです。

忙しいのはわかるけど、やることができていない(タスクにすらあがっていない)ってのは困るのよねぇ。
オープン系って設計でも製造考慮結構いるし、製造でも設計わかっていないと矛盾修正できないから
設計・製造って分ける意味って当初担当くらいのほうがいいんだけどなぁ。

困ったものです。