ひがやすを技術ブログ

電通国際情報サービスのプログラマ

スーツなSpringとギークなSeasar2

国産のOSSについて見てみると，Rubyは「◎」，Seasar2は「♪」，運用管理ツールのHinemosは「♪」，Rubyベースのバグトラッキング・システム影舞は「○」，プロジェクト管理ツールのProject Keeperは「♪」となっている。

正直なところ、大手SIerがSpringではなく、Seasar2を選ぶ可能性は少ないでしょう。
一番の理由は、Seasar2は、電通国際情報サービスの影響が強いように見えること。競合する可能性ある会社の影響の強いフレームワークは、よほどのことがない限り選ばないと思います。
某N社の幹部が「Seasar2は、電通国際情報サービスが開発しているから、使わない」といっていたと、風のうわさで聞いたことがあります。「電通国際情報サービスが開発している」ってのは、はっきりいって間違いです。うちの会社は、何人かのコミッタに給料を払っていて、就業時間中にSeasar2の開発活動をすること認めているだけで、開発そのものにはまったく干渉しません。ただ、そうやって勘違いする人もいるでしょうね。私が、電通国際情報サービスの社員だということは間違いのない事実だから。
2番目の理由は、社内標準フレームワークの存在です。大手SIerは、大規模でも、標準的に開発できるようにするために社内標準フレームワークを持っていることが多いと思います。この社内標準フレームワークは、次のパターンが多いでしょう。

大手SIerの社内標準フレームワークは、生産性よりも、「誰がやっても失敗しないこと」が求められるので、Seasar2の特徴である「さくさく間のある開発」「流れるインターフェースによる可読性・生産性の高さ」などは、あまり大きな意味を持ちません。
さらに、世界中で使われているSpringではなく、あえて、Seasar2を選んで失敗したときに、責任を取らされるのがいやなので、無難にSpringを選ぶというのもあるでしょう。
この社内標準フレームワークが、下請けを苦しめることもあるんだけど。

最近うんざりしているのは、自ら作った(or用意した)フレームワークを案件にバーターしてくるSIerがいることだ。
SIerから仕事を請けているソフトウェアハウスの多くは、コンペで低く抑えられた発注金額や単価を生産性や熟練度でカバーするために自社又はOSSのフレームワークを採用することが多いのだが、プラットホームやミドルウェアならまだしもフレームワークまで押し付けられると、こういった目論見がパーになるのである。

豪華客船型フレームワークは作るのに時間がかかるので設計が大袈裟で古い。(大抵は3?4年前の設計だ)また、特定のオーサリングツールや開発環境にロックインしているフレームワークはその部分が陳腐化するのが早い傾向にある。(対象にしているツールのバージョンも古いことが多い)

いろいろ大手SIerが、Seasar2を使わないわけを書いてきたけど、実際のところは、記事に出てくるSIerのほとんどは、実案件でSeasar2を使っています。何で知っているかって?Seasar2の商用サポートサービスを買っているから。後、MLで聞いてくる人もいる。生産性が重要な案件では、Seasar2を使うケースもあるということでしょう。
実際に使っているのにもかかわらず、「今後評価が進む見込み」になっているのは、東京以外の案件のため、実際に知らないんだと思う。Seasar2の商用サポートやコンサルは、東京以外のほうが多いんですよ。理由は、良くわからないけど。
Springの採用は、技術的ではなく、政治的に決まることが多いということをJSUG(日本Springユーザグループ)の人が言ってました。コードを書くのではなく、プロジェクト管理をしているスーツに好まれるのがSpring、ギークに好まれるのがSeasar2だと考えると、大体あっているんじゃないのかな。
だって、舶来信仰の強い日本で、Springじゃなくて、Seasar2を使っている人って「かなりとんがった人」だと思うな(笑)。