フレームワークは何がいい？

ってよく聞かれる。これってすごく不思議な質問です。アジャイルな開発手法なら別ですが、まだまだ、メジャーなウォーターフォールだと、フレームワークを選ぶだけのお話では終わらないです。
よく言われるフレームワークは、Strutsとかの開発で使う部分を指しています。で実際に開発で適応しようとすると
Strutsを使う
→詳細設計書あたりに、ActionとかFormだとかStruts-configに展開できるような設計書がいる
→詳細設計書を書く人はそんなの知らない。
→基本設計（概要設計？）あたりの方式設計で書いているはずの、画面遷移やらクラスタとかに関することを詳細設計で書く。
→Strutsにない機能が多くて嘆く。
んでもって、結局、適当に作って、お決まりのデスマになって、何とか納品して、フレームワークの技術を習得したと誤解する。
→次の開発でも以下同文
→時が過ぎて、バージョンがあがって、今まで書いていたコードが要らない時代がきても、そんなの関係ない！

という、恐ろしいスパイラルになる。たとえばStrutsを導入するとするなら、詳細設計でMVC・・少なくともM-VCにやりたいことを分けて、何を相互に渡せばよいのかを定義する。
とか
システム共通として、たとえば画面間での受け渡しや入力チェックをActionFormを使うのかどうするのかを定義しておおむね困らないようにする
とかしておかないといけない。

あと、一番大事なのは「１００％この方針でやる！」なんて考え方を捨てること。大規模開発だとたくさんの人でやる必要があるから、って言うのはわかるけど、必要なソースのうち、８−９割くらいが方針通りになっていれば、要員的に困らないはず。残りの特異なコードは、どうせ特異な人しか組めないしわからないんだから変なルールは無視してもいいと思う。特異な人はたいてい、コメントとかちゃんと書くし、ソースも読みやすい・・はず。

ってことで、フレームワーク導入は、設計とかからちょっとづつ変えないとあまり幸せにならない。
逆に言うと、設計スタイルを変える気がないのなら、「言語・フレームワークなんて何を使っても同じ」って意見は１００％正しい。