フレームワークの使い方を表層的にマスターするだけでも，アプリケーションの開発ができないわけではありません。しかし，フレームワークについて深い知識があれば，アプリケーションの構造が分かるので見通しよく開発できるようにになります。
Part1では，まずフレームワークの本質を理解します。そのうえで，エンタープライズ（業務）アプリケーションの基本的なアーキテクチャと，その中でフレームワークがどのように使われるのかを説明します。
日本の少子化問題を解決する方法を提言しなさい――突然，このような課題を与えらた場合，すぐに課題解決のための作業に着手できる人はどのくらいいるでしょうか？
人間はどんな課題を解決しようとするときも，アプローチの切り口や物事の考え方を示されなかったら，何をしてよいかわからず途方に暮れてしまうものです。そこで登場するのが，一般的な意味での「フレームワーク」です。フレームワークとは「枠組み・体制」を表す言葉で，人々が考えたり行動したりするうえでの基本的な仕組みや方針のことを意味します。課題に取り組むための，一つの切り口を提示するものです。
例えば経営戦略の分野では，漠然とした難しい問題に取り組むための切り口として，多様なフレームワークが考案されています。事業の将来性を判断するために，顧客（Customer），競合（Competitor），自社（Company）の三つの視点から分析する「3C分析」などが代表的な例です。
フレームワークを用いることで，対象となる問題解決のアプローチに悩むことなく，効率的に課題解決に取り組むことができます。解決のアプローチを我流で考えた場合に比べて，重要な検討事項を見過ごしてしまうことも少なくなります。
本講座では，フレームワークの中でも，ソフトウエアにおけるフレームワークとはなにかを説明していきます。
ソフトウエアのフレークワークとは
ソフトウエア開発で用いられるフレームワークも，意味合いは冒頭で述べた一般のフレームワークと同じです。「アプリケーションはこのように開発すべし」という基本的な設計方針を，再利用可能なクラスによって示したものです。プログラマはフレームワークの決まりに従って所定のクラスを実装していくだけで，一定の品質をもったアプリケーションを作り上げられます。
どんなアプリケーションの開発にも使える，万能のフレームワークというものはありません。Webアプリケーションを作るにはWebアプリケーション・フレームワーク，デスクトップ・アプリケーションを作るにはデスクトップGUIフレームワーク，プログラムの単体テストを開発するにはテスティング・フレームワークというように，すべてのフレームワークが対象とする専門領域をもっています（表1）＊1。
フレームワークの本質は「制御の反転」にあり
フレームワークは再利用可能なクラスだと説明しました。それでは，フレームワークと同じく再利用可能なクラスの集まりであるライブラリとはどこが違うのでしょうか。それは，ライブラリが単にコードの再利用を狙ってているのに対して，フレームワークはアプリケーションの設計レベルの再利用を目的としているのです。
フレームワークの場合には，アプリケーションの骨組みとなる部分が既にフレームワークの中に用意されています。骨組みとなる部分とは，アプリケーションをどのような役割のクラスを組み合わせて構成するか，といった設計作業のことです。つまり，フレームワークはアプリケーションの半完成品，テンプレートと言い換えられます。もっとも難しいアプリケーション設計上の決断が，フレームワーク開発者によってすでになされており，プログラマは単にそのひな型に肉付けをしていくだけになります。
一方のライブラリは，汎用的な機能を提供する再利用可能なクラス群です。数学関数を集めたライブラリ，プログラムの動作ログを記録するためのライブラリなど，どんなアプリケーションでも使われる機能が中心です。ライブラリをどういった順番で組み合わせて，どんなアプリケーションを構築するか，という設計上の判断はプログラマに委ねられています。
両者の違いは，プログラマが書いたユーザコードと再利用可能なコード（フレームワークやライブラリ）との間の関係の違いにはっきりと表れます（図1）。
ライブラリの場合，それを呼び出すのはユーザーのコードです。プログラムをどう動かしていくかという，プログラムの制御に関する主導権は，ライブラリではなくユーザー・コードにあります。メイン・プログラムから始まる通常のプログラミングでは，ユーザー・コードがプログラムの制御を握っているのは，当たり前といえば当たり前です。
ところがフレームワークでは，ユーザー・コードはフレームワークから呼び出されます。設計を再利用するということは，フレームワークがメイン・プログラムとなり，ユーザー・コードへの制御を行うことを意味するのです。
このように，プログラムの制御がユーザー・コードから再利用コードのほうに移っている現象を，「制御の反転」（Inversion of Control，IoC）と呼びます。そして，「制御の反転」こそがフレームワークの本質であり，定義とさえ言えます。制御の反転は，「ハリウッドの原則」（Hollywood Principle）と呼ばれることもあります。“Don't call us, we'll call you.”（我々に電話をかけて来るな，必要ならこちらから電話する）という，ハリウッドの映画プロデューサと俳優との関係から名づけられた原則です。
ちなみに，「制御の反転」という言葉で最初にフレームワークの本質を説明したのは，Ralph Johnson氏とBrian Foote氏が書いた1988年の論文「Designing Reusable Classes」（http://www.laputan.org/drc/drc.html）とされています。Ralph Johnson氏は，有名な『デザインパターン』の著者GoF（Gang of Four）の1人です。また「ハリウッドの原則」は，1980年代初頭に，米Xeroxのパロアルト研究所の研究者らによって発案されたと言われています。
