多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。
そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。
※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとんどでした。
しかしながら、ソフトウェアというのは実装してみないとわからないことが多く、実装前に完成の形を予測するのは難しいものです。そのため、適切にソフトウェアを構築したいのであれば、事前に作成された設計に完全に従うことは求めず、実装にともなって変更が加わっていく前提にする必要があります。もし設計にたいして忠実に実装できて価値があるソフトウェアになることを保証したいのであれば、実装相当の検証作業が必要になるはずです。
けれども、上で書いたように設計というのは契約の一部であり作業指示です。そうなると、そのとおり忠実に作ることが前提であり、修正は例外という扱いになり「もし変更が必要になれば差し戻す」という感じになります。変更するには上位存在の承認が必要ということもあったりします。
その結果、多少の不備であればいびつな実装になろうとも従ったほうがマシとなり、大きな変更の必要性に気づいたとしてもそれを差し戻していたら作業開始が遅れるのでそのままにするということも起きかねません。
不備であれば差し戻すとしても、よりよいアイデアが浮かんだからといって、わざわざ差し戻すインセンティブはありません。ソフトウェアのアイデアは実装時に浮かびがちにもかかわらず。
また設計側でも、実装しながらの試行錯誤をしないのであれば実装確度の高い前例踏襲で無難なものになりがちで、やることにあわせた特別な設計は行われにくくなると思います。
実装者に創造的能力を期待せず裁量をもたせず責任をもたせず設計通りにやることを求めるということであれば、「PG」という職種は取り換え可能なコーダーということになりますね。
その結果、価値のあるソフトウェアを開発するというモチベーションは失われ、よいソフトウェアを作ることではなく、契約どおり仕様書どおり設計どおりプロジェクトを完了することが目的化します。
それは、「「実装者が設計を勝手に変えてはいけない」というのはダメでは」のようなことを書いたときに「勝手に変えるのはダメ」という反応がいくつかあったものが、それではよいソフトウェアにならないというものではなく、トラブルなく契約を遂行してビジネスをまわすためにダメという指摘であったことからも伺えます。
その設計では使えないソフトウェアになることがわかったとしても、実装者には責任がなく、むしろそれを指摘して設計やりなおしになると実装開始が遅れるものの納期は変わらなかったりするので、価値をうまないソフトウェアをそのままつくるほうがビジネス的に正しいという、モラルハザードのようなものも発生しがちです。
このように、多重下請け構造ではプロセス自体がソフトウェアの性質を反映してよいものを作れるようになっていないために、よりよくビジネスをまわすことがよりよいソフトウェアにつながっておらず、むしろちゃんとまわそうとすると いいソフトウェアを求めてはいけないビジネス形態になっていて、よりよいものを作ることにインセンティブが働かず、構造的にいいソフトウェアが作れなくなってると思います。