きしださんの一連のエントリ読んで考えた
http://d.hatena.ne.jp/nowokay/20070825
Javaにだってシンプルで使いやすいフレームワークは結構あるわけだし、特定の用途ではServlet直接書いてもいいはず*1。そういう選択肢も検討しないで、よくわからんお仕着せのフレームワークとかを押し付けられるからJava嫌いになってしまう気がする。
結局、言語やフレームワークではなく、「チーム」に問題があるんじゃないかと思う。例えばフレームワークを選ぶ標準化チームと業務チームが分断されてるパターンとか*2。 言語への憎しみは、実はこういう状況の不満が別の形で現れているだけだと思っている。チームのメンバが同じ方向を向いてフレームワークを選ぶ状況なら、JavaEEとかRailsとか関係なく生産的になれるはず。
余談だけど、業務プログラマの本業は、基盤(フレームワークやプロセス)を作り上げることだと思う。アプリケーションロジックも重要だけど、そこは理想的な状況なら、本来ユーザが実装すべき箇所だと思う。もちろん現状ではありえないけど、近づけるように努力すべきかなと。手紙の代筆みたいな仕事はいつか消えるだろう。
業務プログラマから、基盤に対する自由度を奪うとやる気が失せる。業務プログラマは、本質的なアプリケーションロジックのみだけ実装すべきみたいな考え方は無意味だ。SI企業の差別化要因は「基盤を作り出す能力」にあって、それは外から買ってきたりダウンロードできるものじゃないと思う*3。
つーわけで、「せっかくだからRailsを超えるフレームワークつくっちゃおうぜ!!」ぐらいの心意気が必要だと思う。まあせめて心意気だけでも。
・・・と、書きながらも自分自身がスランプ気味なので説得力ゼロなんですが。
補足1: 基盤という言葉の使い方がよくなかったので、補足です。 id:PoohKidさんの所に書いたコメント
俺の基盤という言葉があんまし良くなかったかもと思いました。 基盤とかエンジンといったときに、顧客特有の上層と汎用的な下層の2層があって、 その2つの「基盤」の上にアプリケーションロジックが載るイメージです。 # 理想的にはそのロジックをお客さんが自由にカスタマイズできるように # 作るべきなんだけど、それは少し遠い将来の話でしょう。 Poohkidさんが言うとおり、汎用部分はブラックボックスであるべきですね。 特有部分に関しては、、ある程度開放すべきだと思います。 ただ顧客特有の部分の「基盤」をきちっと作るという視点が欠けていて 汎用のフレームワークにおんぶにだっこ、あとは気合でガンガン作ればいいじゃん、 だってフレームワークの生産性が高いから大丈夫! という態度だと、どんなフレームワーク使ってもはまるかなーという感じです。
補足2: 顧客軽視じゃないのという意見に対して
お客をお客と思っていないわけじゃなくて、プログラムは本来使う人が作るものだと思っている。例えばデザインパターンだって本来は、「ユーザ」が自身でプログラムを作るための道具だったわけです。そもそも建築分野のパターンランゲージだって実際に住む人たちが自身の環境を設計するためのものだし*4。職業プログラマはそのための環境とか基盤とか前提を作り上げる人なんじゃないかと。
もちろんその試みは一部の例外(HyperCardとか表計算ソフトとか)を除いて失敗しているんだけど、長期的な視点として常に意識することが重要だと思ってます。
