仕事で他社製のフレームワークの評価をすることになった。
そんなときちょっと覗いたスレがこれ。
日本製Java Frameworkの駄目さ加減を語り合うスレ
玉石混淆なのは2chの常ですよっと。


今評価してるのが古式ゆかしきMVCモデルを採用したフレームワークで、J2EEベースっつーかぶっちゃけServlet+JSP+開発ツールな感じのもの。
ぱっと見生産性なんかはそれなりに高そうだし、値段も安くは無いにせよまぁまぁの費用対効果が出せるんじゃないかなって感じのレベル。
悪くは無い。決して悪くは無いんだけど何かが引っかかる。
引っかかるルーツは結局 前述のスレでも言われてるところの

業界標準になりえないようなローカライズしたシステムに乗ることの是非

なわけだ。
フレームワーク自身は生産効率向上であるとか、生産物の品質向上であるとか、再利用性の確保であるとかそんな感じの目的で作られてる。
まぁそれは否定するポイントでもないんだけど、フレームワーク自体は常にColdSpot(変化の少ないポイント)って性質を持ってるがゆえに、時代の変化に対応できるかどうかってのが焦点になってくると。
変化に対応しないでそのまま枯らすならソレはソレとして、時代を追従するなら更に1歩踏み込んで、フレームワーク自身がどれだけ追従性と柔軟性を持ってるかって話になるわけで、それは突き詰めるとソース公開されてないことには何とも判断できん。
（ブラックボックスから類推することもまぁアリだけどそれはおいといて。）
でもソース公開をしてもらおうとすると製品を買うだけじゃなくて会社対会社でアライアンス契約とかって話になって動く金額の桁がもりっとでかくなるわけで。
そうなるといざ中身が腐ってた時に身動きが取れなくなるわけだ。
そう考えると、話がコンフリクトしちゃってにっちもさっちもいかないんで、視点を変えてStrutsであるとかTurbineであるとかみたいなApache.orgのフレームワークとはナニが違ってどれだけ優れてるのかっちゅー話で。
そう考えるとメリットってのは日本語でQA対応してくれるスタッフがいるとか日本語ドキュメントが揃っているとかの話になりつつ。
何だよ結局英語いやーんってだけの話じゃねーかと。
簡単な英語の読み書きすらできないでITエンジニアですかおめでてーな。ってことで一件落着。
・・・するわけもなく。

つーかIT業界で数年も働けば好む好まざるに関わらず英語で書かれたドキュメントを読む機会なんてのは星の数ほどあるはずで、それなりの量を辞書を片手に読んでりゃ自然とそれなりに理解できるようになるはずなんだが。
俺自身もそうやって読めるようになってきたんだし。
と、ふと周りを見回してみると英語のドキュメント読まない、読んでないエンジニアの多いこと多いこと。
最新の動向のチェックはitmediaと@itとインプレスで十分ですか。そうですか。
W3C勧告やらRFCやらは翻訳出るまで待ちますか。そうですか。
うーむ。
この辺のスタンスの違いは何じゃらほい と考えをめぐらせてみると、フレームワークって枠組みの中でぬくぬくと育ってそこから1歩も出たことないってのがあるんかなと。
ある程度優秀なフレームワークの上で育った生粋のエンジニア達は結局そのフレームワークだけが自分の技術的基盤になっちゃってるから、その外側の動向にもその基盤になってる技術にも目が行かないと。
んでフレームワークが時代に取り残されたときに初めて自分の立ってた足場が如何に脆いものだったかを知る。
で、他のフレームワークに移っておんなじ歴史を繰り返すと。
ぬう。
んで原題のフレームワークのジレンマで、

フレームワークが優秀であればあるほど、それのみを技術基盤とするエンジニアのスキルは低くなる

ということなのかと。

ウチの会社は8年ぐらい前から自社製の開発フレームワークを持ってて、それ以降に入社したエンジニアのほとんどがこれを基盤に育ってきてた。
んで、ここ1-2年ぐらいでフレームワーク自身に限界が来てて事実上発展しなくなった。
そんな時にまわりを見回してみると酷いエンジニアの量がハンパじゃねぇ。

自分で確保したメモリの後始末もできてねぇ。
（余計なとこからガベージコレクションとか聞いてきて妄信してる。つかお前が使ってる言語にGCはついてねぇよ）
簡単な論理演算もできねぇ。
( （A or B) and not( A and B)って何だ。(A xor B) じゃだめなんか）
とりあえず全部メモリに溜め込んでスピードアップですか。
（メモリ使用量100Mって何だ。）

そうなったときに目先優先で使うフレームワークだけ変えてスタンスシフトを図ったところと、長期的なビジョンから思い切ってパラダイムシフトを図ったところにわかれて、前者がそろそろ限界に達してきてる。
そこで、ってわけでもないんだけど今の新しいフレームワークの評価って話が出てきてるわけで。

さてさて、困った。
1エンジニアとしての俺から見ると、短期的な効率は棄てて今こそ（遅すぎるぐらいだけど）パラダイムシフトをせにゃならんでしょと思いつつ、マネージャー視点から見たところの俺は現状それほど体力の残ってるわけでもない会社の状態で短期的な効率を棄てることは会社自体にリスクを背負わせることになるんちゃうかと。
でもそれは同時に、今パラダイムシフトをしていないリスクを先延ばしにするだけなんちゃうんかと。
んじゃ折衷案で、プロジェクトごとにフレームワークを切り替えつつ緩やかにパラダイムシフトを図るのはどうよってなりつつ、でもそれは毎回新しいフレームワークの評価をしつつそれを開発者が使える状況にせにゃならんのかって訳で正直ご免こうむりたい。

さぁ。どうやって報告書書いたもんかな。
あー。めんどくせぇ。
なんで人のケツ拭くのにこんな苦労してんだかな。