ITアーキテクトの視点（日経SYSTEMS 2009年5月号)にもあるとおり、フレームワークで開発コストが下がるのは、ケースバイケースである。
フレームワークというのは、直訳すれば「枠組み」で、簡単に説明するといつも行われる紋切り型の処理をひとまとめにしたものである。プログラムでいえば、サブルーチンや関数の集まりともいえる。例えば、ブログのシステムを考えると、データベースのアクセス、投稿の表示、投稿記入、コメント記入などひとかたまりの機能が用意されていれば、簡単にブログを開発することができる。MicrosoftでもVisualStudioなどで開発しているとデータベースのリスト表示など、フレームワークの恩恵にあずかることは多い。
しかし、どんな機能にも対応できる、完全に汎用なフレームワーク存在しない。全て調整できるというのは、すでに、型にはめた処理ではないのである。型に集約したことによって、簡素化したメリットが失われてしまう。その結果、各フレームワークによって、得意な処理と不得意な処理がある。日経SYSTEMSの例では、不幸なことに、まったく、対応できず、途中で採用をあきらめたということであるが、弊社でも同様に感じる。
そこでフレームワーク採用時の注意点をまとめてみた
- 画面表示に細かい指示がある開発 – Smartyなどで必ず回避できるなどと安易に考えず、十分な注意が必要
- ワークフロー（動作の流れ）が非常に複雑な指示がある場合 – フローの部分をプログラム化することは当然だが、思わぬ所に制限がある可能性もある。
- 向いているのはアイデアを早く試してみるとき – 細かい指定が不要。開発期間は短く押さえられ、実証テストがすぐ始められる。
端的にはそのフレームワークの使用例が多いアプリケーションや紹介サイトでのチュートリアルで使用されているアプリケーションが最も向いていると言うことになる。