Seasar2、三菱東京UFJで採用
三菱東京UFJ銀行，オープンソースのJava開発フレームワークSeasar2を大規模システムの構築に採用：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20060719/243685/
Seasar2、三菱東京UFJで採用 (MYCOMジャーナル)
http://journal.mycom.co.jp/news/2006/07/19/341.html
かなり出遅れたけど、当事者なので貼っておきます。
今回､堅い銀行での採用が決まるには､銀行が納得するだけの根拠が必要でした。例えば､オープンソースは今の流行だから使いましょうはありえないわけです。
- 生産性の高さ
- サポート力
が重要なポイントでした。生産性の高さという点では､
- 設定ファイルが少ないこと
- 実装コードが少ないこと
が客観的に判断できるものとして使われています。「工数がこれくらい減ったよ」があればいいのですが､同じ開発を二回やることは普通できないので､工数的な比較はできませんでした。
無設定S2Struts + Seasar2.3 + S2Dao1.0.x VS Struts + Spring1.x + Hibernate2.xが比較の対象です。
素のStrutsと無設定S2Strutsとでは、struts-configを書く量が全然違うので、S2Strutsの良さを認めてもらいました。
Seasar2とSpringでは、Seasar2のコンポーネントの自動登録機能を利用すると設定ファイルをほとんど書かなくても良いので､Seasar2の良さを認めてもらいました。
S2DaoとHibernate2では、設定ファイルを書く量が全然違うので､S2Daoの良さを認めてもらいました。
実装コードの少なさでは､WebとDIの部分では変わりませんが､S2DaoとHibernateを比較するとS2Daoは実装コードを書かなくても良いので､S2Daoの良さを認めてもらいました。
どんなに生産性が高くても、サポートが悪ければだめなんですが､私自身も何度か出向いてお話したし､ISIDの商用サポートもあったので､信頼してもらえたようです。
パフォーマンスについても､Seasar2 VS Springのパフォーマンス比較の記事があったので、客観的な話ができました。
そういえば、2chで、私が何か説明するときに､他のフレームワークと比較しながら話をするのを快く思わない人がいるようですが､何かを説明するときに､同じ分野のものと比較するのは､非常にポピュラーな方法です。別に相手をさげすんでいるわけではありません。比較するときは常に客観的な指標にもとづくように気をつけています。
