正直、内作だろうがＯＳだろうがメーカー謹製だろうが同じ。

　トラックバックしないように、コソっと言ってみる小心者。

イトウ アスカ blog 　　2009-03-11　から

個々のプロジェクトに合わせたフレームワークを作成するためのフレームワーク。
つまり、メタフレームワークとして活躍できるフレームワーク

　正直メタフレームワークなんて言葉は知りませんでしたが、そのとおりなんじゃないかなと思います。ただ、前日のエントリの流れ上内作が悪って風に読めるので、ここは言ってみたいと思ったのですが、（たくさんブックマークが付いている記事に物申すなんて世間の隆盛が自分には見えないんだなぁって思うわけですが）

　正直、内作だろうがＯＳだろうがメーカー謹製だろうがそのフレームワークのプロジェクトにあった形がなんであるかプロジェクト単位で見極めるってことは必ず必要で、別に内作がどうのって話じゃないような気がする。フレームワーク使えば万事ＯＫみたいな人が上でやっているってのが問題で。少なくともエントリの最後の方ではそんな感じもする。内作が悪って話から、日本ではどんなフレームワークが良いかって話か？

　Click FrameworkだろうがWicketだろうがStrutsだろうが要件にあった基底クラスは作って提供するよ。それこそ内作のフレームワークでも客先にこうしたほうがいいよ！って提案して使うよ。まさに冒頭の引用に従えば僕は経験上フレームワークをメタフレームワークとしてしか認識していなかったってことなんだけど（自分が投入される時期によるけど）フレームワークってそんなもんだよね。軽量、重量なフレームワークって表現があるけど何にしても要件と乖離があるのが常だからパターン化したりして差を埋めてあげる必要性がある。

　カスタマイズってのが、フレームワーク自身をいじってコンパイルしなおすってことなのか、基底クラスを作るレベルなのかがわからないのですが、この話で内作の不幸ってのは、内作フレームワークのカスタマイズの権限が要件を完全に掌握した開発者に近い人ではなく、要件をさほど掌握できない雲の上の人にしかないってことで、それによってプロジェクトが遅れる。でもこの場合追加見積か期間の延長とかって話になるんだろうけど、金で解決するか期間で解決するかデスマで解決するかその辺はどちらかと言うとＰＭの問題のような。

　まぁ、単純に自分が内作のバカ専フレームワークに楽したことがあるのでこう思うだけの話なんですが、なんか、書いていてわかんなくなってきたので、やめる。トラックバックもしていないので誰も見んでしょうし。