フレームワークは外部設計時に決める必要があり、それを修正すると、コストが高い

　で、フレームワークとデザインパターンの違いで何が言いたかったかというと、
　フレームワークは入出力を決定してしまうものが多い（Ｗｅｂでやるとか、クライアントベースとか・・・）。

　ということは、ユーザーインターフェース決定前に、どのフレームワークを使うかを決め、そのフレームワークの範囲内のＧＵＩで行わないと、コストが高くなる。たとえば、Ｓｔｒｕｔｓなら、タグが用意されているものなら開発コストは低減するが、Ｆｌａｓｈ使わないと表示できないようなコンテンツなら、はじめっから、ＦｌａｓｈベースでＲＥＳＴで開発するフレームワークを使わないと、逆に開発コストは高くなる（めんどっちくなる）。

　一方、デザインパターンは、詳細設計レベルの話なので、外部設計のときには、意識しなくてもよい。
　さらに、仮にデザインパターンを利用しなくても、フレームワークほど、開発コストは高くない。なぜなら、開発の場合、上流工程の変更ほど、コストがかかるので、上流（ＵＩ）のフレームワークの変更のほうが、開発コストは高くなるはずである。

　なので、リスク面から考えると、デザインパターンより、フレームワークを教えて、「こういうユーザーインターフェースにしなさいよ、それ以外の画面に変えようとすると、このフレームワークでは（ハリウッドの法則もきいてくるし）大変だよ！」ということを伝えるべきなんだろうな・・・

・・・だれに？新人？
・・・というより、お客さんだよね。
Ｗｅｂだと、こういう画面にしないと、コストが高くなるよって！