「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

IT用語辞典なので別に触れなくても怒られない気はしますが、一応触れておきます。
一般的な意味では

何らかの「型」や「枠組み」

を意味する用語が「フレームワーク」です。

例えば「問題解決のフレームワーク」であれば「問題を解決するための型（決まりきった手順）」くらいの意味でしょう。
この手の横文字が好きな人は、ごほごほ（－ｑ－）



危ない危ない。
無用な敵を作るところでした。

よく分からなければ「体系だってまとめられた何か」程度の理解でも かまいません。
とにかく、何かを手順化してまとめられた「型」「枠組み」がフレームワークです。

前置き代わりに一般的な意味の「フレームワーク」に触れたところで、本題に入ります。

IT関係で「フレームワーク」の意味を調べている方は、プログラミングに関する何かで見かけたか耳にした人でしょう。
その前提で書きます。
もし違ったら、ごめんなさい。

プログラミング関連で出てくる「フレームワーク」は……ズバリ！

プログラムとかのひな形

です。

ぶっちゃけですね。
世の中にあるシステム、あるいは、これから作られるシステムの中で、本当の意味で独創的なシステムなんて稀です、稀。
同じようなことを実現するシステムは同じような機能が必要ですし、同じようなプログラムを書くことになるのです。

経理システムであれば、経理システムとして最低限必要な機能は決まっています。
どんなにオリジナリティの高い経理システムでも、収入・支出を入力する機能は必要でしょう。

顧客管理システムも同様です。
どんなにオリジナリティの高い顧客管理システムでも、顧客情報を入力する機能は欠かせません。

もっと突き詰めれば、システムである以上、絶対に削れない機能があります。
例えば、データベースを使うシステムであれば

・データベースにデータを入れる機能
・データベースからデータを持ってくる機能

の2つは最低限必要でしょう。
データベースを使う以上、削ることはできません。

どんなにオリジナリティの高いシステムであろうと、実際には、他の人も作りそうなプログラムの部品が組み合わさって出来上がっているのです。

その「他の人も作りそうなプログラムの部品」を用意してあげたよ～、みんなが使いそうな機能はすでに作り込んであるから、あとは足りない分を適当に追加してくれればシステムが出来上がるよ～、なプログラムのひな形がフレームワークです。

よく分からなければ、ホームページの世界におけるブログみたいなものだと思ってください。

ホームページを自分の手で一から作ると、面倒くさいです。
ブログには、あらかじめ必要な機能が用意されています。
あとは、それにオリジナリティを出す部分（記事）を組み込めば完成です。
記事を書けば、ホームページっぽく公開できます。

同じように、プログラムを自分の手で一から作ると、面倒くさいです。
フレームワークには、あらかじめ必要な機能が用意されています。
あとは、それにオリジナリティを出す部分を組み込めば完成です。
システム独自の処理を組み込めば、自分の手で一から作ったのと遜色ないシステムが出来上がります。

実際の中身は違いますけどね。

・みんなが必要になりそうな部分が、あらかじめ用意されている
・部分的な提供ではなく、全体的に面倒を見てくれる
・一から全部作るのに比べて、自由度は低い

ところが同じです。

プログラミングをするときにフレームワークを使うメリットは

１．汎用的な機能があらかじめ用意されている
２．複数人で開発するときにレベルを合わせやすい

です。

「汎用的な機能があらかじめ用意されている」は良いですよね。
今まで長々と書いてきた部分です。

「複数人で開発するときにレベルを合わせやすい」は補足しておきます。

フレームワークには使い方のルールがあります。
変数の名前は、こんなルールで付けなさい。
設定値は、このファイルに書きなさい。
共通処理を書いたファイルは、ここに置きなさい。

このルールには誰も逆らえません。
フレームワークを使う限りは、フレームワークのルールに従うしかないのです。

この「フレームワークを使うためのルール」が「プログラミングをする上でのルール」になります。
そのため、複数人で作っても、みんな似たような作り方になるのです。

必ず「フレームワークを使うためのルール」に沿った作り方になりますからね。
個性を排除できます。

他にもメリットはあるでしょうが、パッと思いつかないので次に行きます。

デメリットは

１．オリジナリティの高い処理を行おうとすると、余計に大変
２．フレームワークを使わない場合に比べて、性能面で劣る（場合がある）

です。

まずは「オリジナリティの高い処理を行おうとすると、余計に大変」から行きましょう。

先程も書きましたが、フレームワークには使い方のルールがあります。
そのルールから外れた処理は基本的に書けないのです。
ですが、無理やりにでも書かなくてはいけない場合があります。
どうしてもその処理を行わないと機能として成立しない場合です。
そんなときは漏れなく涙目になれます。

フレームワークが想定していない処理を作り込む必要が出てきたら地獄ですよ。
私も「これ、自分で一から作った方が、よっぽど楽だよなぁ」と思いながら調べ物をしましたもん。

「フレームワークを使わない場合に比べて、性能面で劣る（場合がある）」は、汎用的であるがゆえの弊害ですね。

フレームワークを使ったプログラムは、どんなに頑張っても余計な処理が入ります。
例えば、今回のシステムには不要な条件分岐があったりですね。
できるだけいろんなシステムが作れるように汎用化している以上、これは仕方がありません。

余計な処理が入っているプログラムと余計な処理が入っていないプログラム、どっちが速いかは考えるまでもないですよね。
あとフレームワーク自体の中身が微妙で、性能面でいまいちな結果になる場合も無くは無いです。
ご注意ください。

あくまで個人的な意見ですが、フレームワークを使うことが必ずしも良い結果につながるわけではないと考えています。
フレームワークは、あくまで「よくやることを楽にやれるための仕組み」です。
小規模なシステムの場合やオリジナリティの高い処理が多い場合は、フレームワークを使うことで余計大変になる可能性もあります。
「フレームワークは使うべき！」「フレームワークは使わない方が良い！」と決めつけるのではなく、状況に合わせて使うかどうかを判断してあげてください。