Webアプリケーションフレームワークとは何ですか？

俗的に言ってしまえば、Webアプリケーションフレームワークとは「Webアプリケーションの骨組み、枠組み、足場」となり、「Webアプリケーションを構築する上で元となる土台の部分を提供するもの」となります。

フレームワークという言葉が独り歩きしがちですが、「テンプレート化」とか「開発標準化・共通化」といえば、もう少しなじみやすいイメージでしょうか。

完全に私見になりますが、個々のプロジェクトにおいて、ユーザーの視点で見ると「Webアプリケーションフレームワーク」のメリットは非常に低いです。これは開発会社側の都合であり、自社の工数効率化や、パターン化がその目的となってしまっており、決してユーザーの業務要件が効果的に標準化されてものではありません。

私自身は、そもそもフレームワークの意義を感じていません。あくまでも業務要件、サービス要件から、たまたま部分的に使えるツールやモジュールが存在していたケースはありますが、自社の資産として構築していこうとしても、1年もすれば、あまり使い物にはならなくなります。

フレームワークを意識しすぎず、あくまでもサービス要件に対して、ゼロから開発しなくても実装できるものがないか?という発想を持つという意味では重要な考え方と思います。

フレームワーク信奉者の方もいるので、怒られそうですが、本当にそれで成功したプロジェクトは、たぶん、ないです(宣伝ニュースを除き)。

「Webアプリケーションフレームワーク」が、WEB アプリケーション開発に使う枠組みモデル・・という意味であれば、弊社は、PHPの開発においては、現在ethna を使っています。
ユーザの要件により、そのままではなく、若干、ethnaそのものの中もいじっています。

こういったものを利用してメリットがあるのは、主に開発側の話で、エンドユーザ、発注側にとっては、それほど、メリットを感じることは少ないかもしれません。

また、開発会社にとっても、プロジェクト単位で、フレームワークを替えていれば、習得コストが高くつきますから、プロジェクト単体で考えると、意味がないかもしれません。

弊社は、フレームワークの恩恵を随分受けています。ユーザに対してのメリットは、保守・運用の段階で、修正や追加の要望の際、フレームワークの枠組みを越すような大きなことでない限り、比較的少ない工数で、実現・応対できることでしょう。

以下は私見ですが、フレームワークは、そのものの中をいじれ、見通せる程度のサイズでないと、導入は危険と思っています。ユーザーの希望が特殊で、フレームワークに納まらない時、「フレームワークの限界でできません」と、エンドさんには言うわけにはいきませんから。