-Easyが売り、の問題

先に書くとして書かなかったエントリ。

世のフレームワークの中には簡単開発が売りで、それこそStrutsやHibernateなどの既存のデファクトっぽいフレームワークを組み合わせたうえ、技術的な選択の幅を狭めることによって技術習熟度の低いプログラマーでもほぼコピペの域でOKというものがあります。私は、これはダメだと思っています。量産やオフショアやバカ対策という内容で生産性、生産性と連呼していますが、果たして生産性があがってるのかなぁと。
プログラマーのやることを単純化するために、スタックを重ねることはたぶんフレームワーク実装者の考える幻想的な生産性であることが多いのではないかなと。たとえばStrutsを便利にするのにActionを至れりつくせりで数行POJOで書けばOKみたいなものをやったとして、使う側がモチベーション高くやれるかどうか。もちろんスタックを重ねることと利用者モチベーションの高低は直接因果関係の無いことなので全否定はしないのですが、たいていのEoD「だけ」が売りのうそ臭いJava製フレームワークはプログラマーを性悪説で御すのみでもっと他に努力しなければならない点を放棄している場合が多いような気がします。私の感想としてはモチベーションゼロのゾンビうごめく墓場みたいな現場を作ってるんじゃないですか？と。フレームワーク「ごとき」ではゾンビを救えないけど、バカ対策フレームワークがじわじわとプログラマーをゾンビ化することはあるように思います。フォード式のベルトコンベア生産が工場内規律を崩壊させたために、多能工によるセル生産方式が。。。なんて社会の教科書で教わったように思いますが、SI現場でベルトコンベアに乗せるだけを考えるのはどれだけ有効なのか（ま、セル生産方式という単語に反応されちゃうと正しくはないんだけど）。
フレームワーク実装で踏み込めるけど踏み込んでおかないほうがよいレベルというのを意識、考察してみてもいいんじゃないかな、と思う今日この頃です。利用者をバカにしている態度に未来はない、と思う。

追記：
トラックバックで竹添さんより。「手順通りに作業すればOK」を目指しているモノ、まさにそれです。