Seamとプログラマーのスキル？
今日、会社の上司から「Seamの上にラッパーとなるフレームワークをかぶせて形式化することで、大部分Javaの初心者からなるチームでも使えるようにできますか？」というような趣旨の質問をされていまいました。私の会社のようなSIerといわれるような会社では、大量のプログラマー（多くは協力会社）を投入して開発するというモデルが一般的な収益モデルからも大切なので、開発モデルの量産化、画一化は重要なことです。ただし、これが実はなかなか難しいところですね。処理のパターンごとに規約を決めてあげることで選択肢の幅を狭くすることは重要だと思いますし、日本語化対応なども含めてOSSで足りていない機能を使いやすいように改善することもできると思います。ただ、頭をあまり使わなくてよいような部分はseam-genのカスタマイズなどで大部分事足りてしまい、結局残った仕事は会話のスコープの適切な設定だったり、業務知識とJPAを駆使したドメインモデルの設計だったりするわけですよ。こういうところを知識経験の浅い初心者でもというのは無理があります。
従来のStrutsに比べてSeamやJPAが敷居が高いとはいわれますが、よくよく考えてみると同じレベルの機能を実現しようとしたら結局どちらでも考えなくてはならないことの総量は一緒かと思います。*1単にStrutsだと型変換やDTOの詰め替えなどの頭を使わない配管コードの実装に多くのステップ数を費やしていたため、プログラマーのスキルが少なくてもよいように見えているだけで、きちんと考えなくてはならないポイントが存在していること自体は変わりません。Seamに限らずですが最近のOSSフレームワークは、やはり世界中の達人と呼ばれる人々が考え出したベストに近いアイデアをどんどん取り込んで、無駄なコードを極力減らす方向で改善されているため、初心者でできるようなコーディングはほとんど残らず、残りの難しい部分のみが残ってしまっているという傾向があるかもしれません。さらに、裏でいろいろな機能がブラックボックス化されてしまっているため問題解決しようとしたら仕組み的なことについては相当理解している必要があります。手を動かす代わりに頭を動かす必要があるということかと思います。
ですので、Seamなどの新しいフレームワークを使って、かつ、初心者をたくさん集めて労働集約的にアプリケーションを作るという発想自体が実態とマッチしていないような気がしてなりません。プログラマーの雇用を保護し、人月ビジネスの売上げ確保ためにあえて冗長で無駄なコーディングを続けるか、最新フレームワークを使いこなせる少数精鋭チームを育成して、それでも収益が上がる仕組みを作るかどちらかだと思いますが。
