井上 研一 フレームワークによる開発の手法を考えてみようと思います。
まず、フレームワークについての概略ですが、「システムを開発する際にその開発する手法や方法論を実装よりから定義していったもの」ということが出来ると思います。（「フレームワーク」という単語には実は広い意味があって、例えばMicrosoftのMFCはフレームワークですし、COMやActiveX もフレームワークの一種といえます。ここではMFCに近いものを狭義のフレームワークとして単語を使用しています）
例えば、Javaアプレットだと、init()メソッドが呼ばれて、次にpaint()メソッドが・・・といったようなメソッドの呼ばれる順番に定義があり、そのメソッドだけを開発するという手法を取ります。まさに、このような手法が私がここでいっているフレームワークです。
このJavaアプレットとかWindowsアプリケーション開発用のMFCは、普通の（例えばDOS上のC言語での）アプリケーション開発とは異なり、 main()を実装することはしません。main()はご存知の通りプログラムの起点となる実に重要なメソッド、関数ですが、これを実装しなくて、どうしてプログラムが動くのか・・・？という疑問が生まれます。
ある種のフレームワークでは、main()は実装済みで隠蔽されています。間違いなくプログラムの起点として呼び出されるのですが、それをプログラマが実装する必要はないのです。
この「実装済みの部分」を「フローズンスポット」といいます。つまり凍結された部分なのです。ここで、システム全体のうちフローズンスポットを最大化すると、開発にかかる工数は（少なくとも実装作業としては）最小化します。一方、フローズンスポットの対義語として、プログラマが開発する部分を「ホットスポット」といいます。基本的に、ホットスポットが最小化すると、工数も最小化するわけです。
やりやすいところから再利用を
システム開発において、「再利用」は使い古されたキーワードです。
例えば過去の構造化プログラムにおけるモジュール分割や機能による関数分割であったり、最近ではオブジェクト指向プログラムにおけるクラス分割は、手法は違うとしても目的は再利用可能部分を最大化することが目的です。
しかし、再利用が上手くいっているというケースは多いとはいえないのではないでしょうか？特にビジネスロジックの部分（これを機能要件といいます＝クライアントがシステム化を希望する理由であり、かつシステム化を希望する部分です）の再利用は困難がつきまといます。機能要件はクライアントによって千差万別であり、クライアント企業のビジネスプロセスは同じといえるものはないからです。
システムを受託で開発するようなケースで、ビジネスロジックの開発をヒアリングから始めて実施するようなことは多いと思いますが、そこで再利用を前提とした開発を行うとなると、そのクライアントにとって不要な機能や、オーバースペックな機能を「再利用を前提とする」という旗印の下に実装しなければならないことになります。そして、それは無理が付きまといます。そのコストは？それによる納期の遅れをクライアントは待ってくれるのか？
だとしても、今後、システム開発における再利用は進化すると考えます。おそらく、それは「コンポーネントビジネス」として成り立つことになると思います。あくまで「それをビジネスにする」ことがポイントでしょう。システム開発会社が自社用に「おまけ」的に取り組む再利用ではなく、コンポーネント会社のようなものが多くの企業のシステム開発において幅広く使われるコンポーネントを、そのために作り、ビジネスとする。システム開発会社はそのコンポーネントをいかにクライアントの希望に沿うシステムと見比べてチョイスし、組み込んでいくという姿になるのではないでしょうか。それが実現可能な機能要件の再利用になるでしょう。
機能要件の対義語として「非機能要件」があります。システムをシステムとして成り立たせるためには機能要件だけでは不十分で、必ず非機能要件が必要となります。例えば、最大使用ユーザ数であったり、許容されるシステムダウンタイムです。そうした要件から、使用するデバイスであったり、ミドルウェアであったり、さらにはWebシステムなどのシステムの構成形態が決まります。クライアントはWebシステムを作りたいのではありませんし、特定のミドルウェアを使って欲しいのでもありません。あくまで「自分の要求を満たす機能をコンピュータシステムとして実現して欲しい」のです。（最近では、クライアント側が非機能要件を指定することもあります。例えば「Webシステムとして作って欲しい」であったり、「モバイルに対応して欲しい」など）
例えばWebシステムというシステム構成の非機能用件は、大抵の場合、構成が似通っています。モバイルに対応するために必要となる実装手段も、どんなシステムであっても似ています。これこそが、再利用の対象になるに違いありません。
こうした再利用しやすい部分をコンポーネントやフレームワークとして構築していくのが、再利用の実現可能な第一歩だと思います。