システム開発においては、今や切っても切り離せない程、「フレームワーク」が当たり前となっています。
そんな「フレームワーク」に関する間違いや思い違いを、筆者の視点で書いていきたいと思います。
■フレームワークって、何？
そもそも、フレームワークとは何でしょうか。
調べると、「雛形」「枠組み」などと解釈されています。
では、何の「雛形」や「枠組み」なのでしょうか。
おおよそは、「アプリケーションの雛形」とか「Webシステムの枠組み」となっていると思います。
しかし、実際は「システム（アプリケーション）を作るための本質的な枠組み」です。
「標準」とか「骨子」と言っても良いでしょう。
例えば、家を作るのに、土台や柱を組んで、家を建てていきます。その為に「『なんたら工法』で、丈夫で早く、高い品質」となります。
現在のフレームワークは、この「なんたら工法」を示しています。
しかし、筆者が言うのは、家を立てるために、ユーザーから要件を聞き、必要な強度設計や各部屋の配置、材料選定や、実際の工程の管理、出来上がった後のフォローや改築などの、一連の手順や方法をフレームワークとする、と言う事です。
この認識が違うため、フレームワークを使ったのに、生産性が上がらなかったり、品質が確保できなかったりします。
そういったことを踏まえて、書いていきたいと思います。
なお、万能なフレームワークはないと思いますが、筆者の言うフレームワークなら、「システムを開発する」という点で、広範囲にカバーできると思います。
■フレームワークの実情
現在、沢山のフレームワークは存在していますが、結局のところ、「製造」工程でしか活用できていません。
「設計」ではフレームワークに従った設計をしているように見えますが、多くの場合、それは偶然です。
実際に経験した人も多いと思うのですが、設計書を見た時に「これって、どうやって実装するの？」と、悩むことがあると思います。
なぜならば、フレームワークを意識しないで設計し、それを「フレームワーク部品（筆者は世の中のフレームワークを、この様に呼んでいます）」に当てはめようとするからです。
つまり、フレームワークの本質を理解せずに、システム開発でフレームワークを無理に使おうとしているわけです。
これだったら、昔ながらの「共通部品（ライブラリ）」と、何ら変わりません。
余談ですが、かつてどこかのSIerが「広義のフレームワーク」「狭義のフレームワーク」と話をしている事を、インターネットで読んだことがあります。
例えば、.NETは狭義のフレームワークだと。
当時は、納得したのですが、今思えば、「広義」「狭義」の表現は、不適切だと思います。
フレームワークとして考える際のレイヤーの違いだと思います。
なので、表現するなら「低水準フレームワーク」「高水準フレームワーク」です。
ただし、筆者の言うフレームワークと、本質的に違うと思います。
部品レベルのフレームワークにこだわる限り、ブラック・プロジェクトは、なくならないでしょう。
■フレームワークはどうあるべきか
冒頭でも示したとおり、「システムを開発するため」にフレームワークはあるべきだと思っています。
では、フレームワークには何が必要なのか。
もちろん、現在の数多ある「フレームワーク（部品）」が示すように、システムを構成する要素を、抽象化した部品は必要です。
それによって、プログラムする際に、部品をカスタマイズすることで、簡単に欲しい機能が作れます。
しかし、これの根本的な問題は、部品の使い方がわからない場合に、悩む必要があり、それに多大なエネルギーを必要とすることです。
多大なエネルギーを必要とする理由は、「システムを開発するために必要な、システムの一部である。」ものとしての抽象化が中途半端な事が要因です。
例えば、テレビのリモコンの使い方を悩む人は少ないと思います。
なぜなら、「電源を入れる／切る」「チャンネルを指定する」「ボリュームを変える」ことができるのが、テレビのリモコンとして最低限備わっているものであり、リモコンの形状を見て、直感的に操作できるからです。
フレームワークにも同様に、直感的に分かる事ができれば、簡単に扱うことができます。
ただし、勘違いしてはいけないのが、ＴＶのリモコンと違って、フレームワークを扱う人は、専門家であり、その道に精通する（もしくは、精通しようとしている）人たちです。
つまり、考え方に方向性がある人達です。
そういった人達が、感覚的に（もしくは、自然に）思考して想像が付くようなところまで、抽象化していなくては行けないと思います。
VisualBasicによって、テキトーにプログラムしてもテキトーにシステムが動く様になってしまった関係で、そういったプログラマが増えてしまいました。
また、そう言ったプログラマに乗じて、設計者の責務を果たさないSEが増えてしまいました。
そんなSEばかりなので、ポリシーもなく要件定義して、上流がグダグダになってしまい、結果、下流が燃え盛るプロジェクトが多くなっています。
結局、荒れないプロジェクトも、蓋を開ければ、ユーザーに我慢をさせる事で、凌いでいる現状ではないでしょうか。
フレームワークのあるべき姿は、こういった現状に対する枠組みとなり、整然としたシステム開発ができるためのもの、であるべきだと思います。
それは、フレームワークを部品レベルで考えていては、できることではありません。
補足しますが、現存するフレームワークがダメなわけではありません。
ただ、抽象化が足りないですし、機能面やトレンドにこだわりすぎです。
よく「MVCフレームワーク」とか言いますが、それは、「なんだかよくわからないが、MVCなら、良いらしい」としか判断できないエンジニアを煽っているだけに過ぎません。
MVCなのは当たり前です。情報→判断→動作（結論）がそうであるように、アウトプットがあるものはすべて、この構成（仕組み）になります。
空気がないと人が生きていけないのと同じくらい、当たり前です。
それを、フレームワーク（と言っても、部品）の売りにしている時点で、根本的に間違っています。
■最後に
タイトルの意味をわかって頂けたでしょうか。
多分、言われるまでもなくわかっている人は多いと思います。
ただ、よくわかってない人やSIer、そういった人やSIerに変に教育されてしまった人やソフトハウスのエンジニアもまた、非常に多いと思います。
今（もしくは、過去）、携わっているプロジェクトが、なにか違うと思った人は、考え方の一つとして、参考にしていただければと思います。