三菱東京UFJ銀行でオープンソースのフレームワークSeasar2が採用される 119
ストーリー by mhatta
大変結構なことなんじゃないでしょうか 部門より
大変結構なことなんじゃないでしょうか 部門より
d'Arc曰く、"国産のオープンソースのJava開発フレームワークであるSeasar2が、三菱東京UFJ銀行のシステムに採用されたことが先日発表された。日経ITProの記事によると、Seasar2を採用することによりPOJO(Plain Old Java Object)で開発でき、複雑なAPIを覚える必要がないため、5日間程度の集中講義を行っただけで,初めてJavaを使う技術者でも問題なく開発を行っているという。また、MYCOMジャーナルの記事によると、「三菱東京UFJ銀行の大規模リスク管理システムにおけるSeasar2の採用は、オープンソースのもつイノベーションをビジネスに生かす先進事例であるといえる」と述べられている。"
Seasar2って (スコア:5, 参考になる)
また、日本のプロジェクトなのに日本語ドキュメントが少ないとか、サイトをどう歩けばいいのかわからないとか(これは最近だいぶ改善されました)、まったくコメントのないソースファイルを追うのは面倒だとかまぁ問題は山積みです。
せっかく日本のプロダクトなのにまったく同じ技術のSpringのほうが採用されることが多いです。実績とかの違いも多いですがドキュメントの差が大きいですね。
結局ひが氏のサポートがないと使えないようにわざとしてるように取れます。何のためのオープンソースなのかなぁと。
せめてメソッドの頭に1行コメントくらいつけてよ。
Re:Seasar2って (スコア:1, 興味深い)
> まわるのやめれば使うという人は多いですね。
同感です。まぁ、議論しようとしているのかもしれま
せんが。
端から第三者として見ているとプロジェクトメンバー
で気に入らない人を袋だたき(表現は悪いですが)にし
ているようにも見えてしまいます。
公開されているところでの売り言葉に買い言葉的な応
酬はマイナスにしかならないと思うのですが。
まぁ、プロジェクトの中心メンバーが率先している現
状では改まらないかもしれませんね。
Re:Seasar2って (スコア:1, おもしろおかしい)
Re:Seasar2って (スコア:1, 興味深い)
引用
># habuakihiro 『ないですよ>愛(w ぶっちゃけ殺し合いだから。先に手袋を投げつけたのは相手だしね。
というか、そもそも相手を低く見てませんか? 裏にどんな味方がついてるかわからないじゃないですか。有能な弁護士を雇ってくるかも知れないわけですよ。煽って馬脚を現してくれるほうがいいです。
tpircsさんが読んでて不快になるのは当然です。やってる当人が不快なんだから(^^; だから当事者以外は見ないほうがいいんですよ。
まともな議論になることを期待するほうが間違ってるんです。みんなそういう幻想を持ってるからデスマがなくならないんです。』
Re:Seasar2って (スコア:2, 参考になる)
出てきましたよ。
tpircs’s diary 「2006-07-05 すい。」 [hatena.ne.jp]
コメント欄のところですね。
た、確かにすごい…。
Re:Seasar2って (スコア:3, 参考になる)
[java.fw.seasar]Spring vs Seasar [tdiary.net]
内部の人間ってwww? 09:04 [hatena.ne.jp]
Seasar 中心メンバーのひがさん、はぶさんがこのノリってどうなの?? と正直思いますね。 当事者では無いので実害は無いのですが、何となく Seasar プロジェクト全体に対するマイナスイメージを持ってしまいます。
Seasar プロジェクトの人は何か変なコンプレックスがあるのでしょうか?? 素晴らしい活動をされていることは周知の事実ですし、もう少し泰然自若として欲しいですね。
Re:Seasar2って (スコア:2, すばらしい洞察)
わざと書いているのかは分りませんが、
ウェブサイト [seasar.org]の構成があまり良くないことと、
中心メンバーが「それは冒涜だ」式の抗議活動に手を染めていることは、
同根の問題だと思います。外部からどう見えるかを
コントロールする人材が不足しているのではないでしょうか。
「報道官」のなり手がいなかったら衰退するでしょうね。
Re:Seasar2って (スコア:2)
性格を占う上でほとんど参考にならないでしょう。
先ほど私は「『それは冒涜だ』式の抗議活動」、と書いたけれど、
フェアかどうか検証できないので撤回させてください。
なにしろ他人を憤激させるようなことをブログに書いておいて、
抗議のコメントがたくさん付いたから自分の文章だけ削除しました、
というのでは抗議内容が妥当か過剰か検証できません。
当該ブロガーの意図とは関係なく、一種の罠みたいな状況だったと
推定せざるを得ません。
Re:Seasar2って (スコア:2, 興味深い)
Re:Seasar2って (スコア:1)
このニュースで初めてSeasar2なるものを知り、
サイトを見に行ったもののいったい何をやっているか分からない。
面白そうなことをやっているのに「Mottainai」。
Re:Seasar2って (スコア:1)
背景に・・・ (スコア:4, 興味深い)
ある意味、自社製品?のいい叩き台かな・・・いい導入事例になりそうですが。
-- gonta --
"May Macintosh be with you"
Re:背景に・・・ (スコア:4, 参考になる)
Re:背景に・・・ (スコア:2, 興味深い)
客観的にとてもよいSeasarの宣伝になるはずなのに。
正直何度か仕事で使うことも考えたんですが、圧倒的にドキュメントが少なくて断念したことも。少々性能がアレでもspringのほうが導入は楽かなぁと。バージョン間の互換性もspringのほうが積極的に維持しているようですし。
# ドキュメントを書くモチベーションはお金だけ、ってことかな。
Re:背景に・・・ (スコア:1, 参考になる)
もちろんドキュメントが不十分だとか実績が少ないだとか
コメントがないだとか生産性が悪化するだとか所詮は単なる
試作社内フレームワークにすぎないだとかという問題もありますが、
それ以上に設計思想がJavaに向いていない。
「木に竹を接ぐ」というか「新しい酒を古い革袋に」とか
そういう感じ。とにかくアレはJavaのことを分かってない
人が作ってますよね。
「東京三菱」には好意的だっただけに今回の一件は残念です。
Re:背景に・・・ (スコア:2, 興味深い)
それはどのへんがですか?
DIそのものが?(だったらSpringも駄目ですよね)
「設定より規約」なあたりが?(便利だと思うがなあ)
設定ファイルが少ないあたりが?(多いことにメリットなんて無い気がするが)
>「木に竹を接ぐ」というか「新しい酒を古い革袋に」
新しいのはどっちですか?Javaが?Java以外の要素が?
確かにJavaで「設定より規約」をやるのは、RubyOnRailsに比べれば不恰好に見えるのも確かです。
ただ、そこまでして(させて)Javaにしがみついてるのは、どっちかというと顧客のほうなんじゃないかと?
#まあ、スターロジック界隈が言う「与件」という言葉には、用心したほうがいいけどさ。
Re:背景に・・・ (スコア:1)
>どっちかというと顧客のほうなんじゃないかと?
Java が昔の COBOL の地位に進出してるってことかな。
# いいんだか、わるいんだか知らんけど
初めてJavaを使う技術者 (スコア:3, すばらしい洞察)
プログラマー1年生の
熟練の C++ 使いの
○×△の
技術者
さて、トレーニングが5日間で済むのは誰?
Re:初めてJavaを使う技術者 (スコア:2, おもしろおかしい)
Re:初めてJavaを使う技術者 (スコア:3, おもしろおかしい)
Re:初めてJavaを使う技術者 (スコア:1)
×は何?
#オフトピごめん
Re:初めてJavaを使う技術者 (スコア:2, おもしろおかしい)
Re:初めてJavaを使う技術者 (スコア:2, 興味深い)
だろうな普通。
C++やVBなんてのを下手に長い時間やってるとあの言語の癖が体に染み着いてやがる。
そんなもんだったらJavaをやるのも初めての方が恐ろしく奇麗なソースを書いてくれる。
なまじ銀行系ってC++/VB出身者が多いから新しい技術への関心少ないし。
とりあえずVB技術者は危ない。ホント。
デスマが発生する予兆を見ているよ…
# 同じ金融系で似たような技術採用してる中の人なのでAC
Re:初めてJavaを使う技術者 (スコア:1, 興味深い)
タレコミにあるような動きは「技術者」が採用できない業界でどうするか、という諦めの境地ではなかろうか。採用担当の方々、心中お察し申し上げます。
#前いた金融系がSIerに成ろうとしてコケたのでAC
Re:生産性はいかほど? (スコア:1)
まぁ、金融系全体が最近人をかき集めているみたいですが。
#かき集められた一人だけどあえてID
一番早いのはC#技術者 (スコア:1, 興味深い)
という冗談はさておき、
>熟練の C++ 使いの技術者。理由は、C++ のサブセットが Java。
マルチスレッドがない。
ガベージコレクションがない。
動的最適化がない。
ついでにメモリモデルもない。
APIやフレームワーク類ももちろん異なる。
これだけでも、並のC++技術者を混乱させるには十分ですね。
http://cappuccino.jp/keisuken/logbook/20060702.html#p01
本当に熟練プログラマーならば、既存の言語がC、C++、VB、
Rubyなどのいずれであろうと、それなりに短い期間で参加する
ことは可能でしょう。問題なのは使っている言語よりはその
個人の資質の方が重要であるにもかかわらず、本当の熟練
プログラマーが極めて少ないこと。
相手がベテランであろうと1年生であろうと、C++を使っていても
オブジェクト指向のイロハも知らないとか、VBがオブジェクト
指向言語だと思っているとか、ポインタと参照の違いが分からない
だとか、Javaを使っているのにGoFも知らないだとか、そういう人
に一から教えるのが難しいことは変わりありません。
あえて違いを挙げるならば、VBやPHP技術者だと熟練技術者の
比率が非常に低いことくらいかな。
S2Daoについて (スコア:3, 興味深い)
とありますが、実際に採用された現場の人たちの感想を聞いてみたいです。
S2Daoでは、親子関係(1:N)にあるテーブルを1回のSQLでJOINすると、クラスにN:1でマッピングされるため、子(N)のクラスのListが返却されてくる仕様なのですが、これをチームメンバーに理解して使いこなしてもらうのに、とても時間がかかりました。
しかも、この場合で親を複数件取得したい場合はN:1だとマッピングが複雑すぎて、使いこなしがとても難しかったです。
その上、1:N:Nのような3階層以上の構造を持つテーブルを1回のクエリでマッピングすることはできないため、何度もクエリを発行しなおしてマッピングせざるを得ませんでした。
iBATISだと、1:Nでマッピングできて親のクラスを戻り値として受取ることができるので、親を複数件取得するのも簡単です。また、1:N:Nのような構造でも1回のSQLでマッピングできます。
マッピングファイルがXMLで書かれるのでSQLだけでテストしたい際には、SQL定義を編集しないと実行できないっていう手間はありますが、一度実行してログを出力させてしまえばすむ話です。
個人的に、こういうフレームワークが大規模案件で採用されることは、フレームワークのその後の品質向上や、少ないドキュメント関係の問題解消に繋がる可能性があるので、とても喜ばしいのですが、「一般に「S2Daoを使いたい」」ってところだけが、ものすごく疑問に思いました。
Re:S2Daoについて (スコア:1, 興味深い)
http://laplace.4.dtiblog.com/blog-entry-26.html
複雑なSQLを使用しなければいけない場合SQLをそのまま記述できるみたいですし
ただ、自分も個人で触っているだけなので大規模案件でS2DAOがどのように使用できるのかはすごく気になります。
S2DAOについているサンプルコードがすごく単純なものなので大規模案件の場合どうしたらよいか疑問点は多くあるので。
今回のシステムをオープンソースに・・・・
ってのは無理だろうケド
その辺のノウハウを公開して欲しいと切実に思っています
Re:S2Daoについて (スコア:1, すばらしい洞察)
iBATISって、そうじゃなくSQLよりのDAOマッパーなので、SQLをどう使うかを細かく指定できるという意味では、そういう差は生じて当然って感じですよね。
でもそのトレードオフとして「面倒なSQLを書かされる」機会は増えてしまうわけで。
もともとOOPとSQLはインピーダンスミスマッチが激しいんだから、両方の良いところを十分に活かせて、しかも自動化できる、っていうマッパーは、なかなか作れないですよね。
>1:N:Nのような3階層以上の構造
すみません。それを一気に取得するってのを考えたこともありませんでしたm(__)m
確かに、遅延取得をしかけるんでもない限り、一気取りできるほうが(速度的に)優位ですね。
ただ、「多層のマッピングを自動化する」のも、Framework自体の開発段階で念頭に置いておけば、出来ないわけでもなさそうですね。ふむ。考えてみるか。
過信だったら大変 (スコア:2, 興味深い)
と思ってるだけで実はかなりいい加減なことをやらかしてたら・・・とか思うと怖いですね。
Javaが初めてだろうと、別言語での経験があれば、言語間の差なんて誤差レベルだと思うのは#982975 [srad.jp]のコメントの通りなのですが。
木に竹を継いでも (スコア:3, 興味深い)
こういったフレームワークって, 大前提として前工程のシステム設計を, オブジェクト指向なりなんなりの比較的現代的な手法で行わないと効果半減なんですよね. 一方, 銀行業務システムを設計する人って, 多くが20年前の第二次オンラインの時のシステムに縛られているんで, 20年前の設計手法(フローチャートとレコード定義のレベル)に留まっている人が多いってのも事実で.
ですから, この場合
のどちらかってことになると思います. 前者は, まあ言ってみれば設計のやりなおしですから, 出来れば理想的なんですが, 現実には難しいです. ということで, 普通は後者のパターンに行っちゃうことが多いです.
で, 最終的に出てきたコードを見ると, 使用言語にかかわらず, 20年前のCOBOLと同一パターンで
なんて具合になっています. もうこうなると言語仕様がどうこうなんてレベルじゃないですね. Prologぐらい根本的な思想の違いがなければ, 100年ぐらい変わらないんじゃないですかね.
Re:木に竹を継いでも (スコア:2, 興味深い)
Javaでこれやっちゃうとぬるぽと配列の境界値制限超えでプログラムから例外が数多く出ることになります。
1000行のうちの最初の100行がnullと空文字列チェックのif文とログ出力のコピペが延々と続くのをよく見ます。
引数がクラスであればメンバがほぼ全てString、クラスでなければほぼStringなわけです。
いいかげんになんでもIDにしてしまう設計を見直さないと生産性向上とか品質向上ができないと思うのですが、皆様の開発現場ではどうでしょうか?
ログ出力ならともかくソースコード上で延々とIDを見せられるとデバッグに余計な集中力がいってたまりません。
Re:木に竹を継いでも (スコア:1)
それがさー、
微、妙~にコピペじゃなかったりするんですよー。
(以下5万行の愚痴削除)
Re:木に竹を継いでも (スコア:1)
あと、設計もSeasarプロジェクトからだしてるgoyaという手法を使えば大丈夫・・・なハズなんですよ。なんですけど多分そんなわけないですよね。おっしゃりたいことはよくわかります。
#いまやってるシステムがちょうどそういう感じのソースコードなので恨みを込めてID
Re:過信だったら大変 (スコア:1)
こういう明らかなインチキに対して、この技術基盤を選択した人がどういう態度を取るべきか。私は、そういう誤解をといていって、その上で、そのフレームワークを使うことの具体的な効能を説明できるようにしておくことが必要だと思いますよ。
オープンソースの味方になってくれそうな人だったり記者だったりしたとしても、間違いは細かく言って、それでも間違いを続ける人だったらオープンソースコミュニティの支持者であったとしても「迷惑だからあんまりあれこれ言わないでください」とお願いするしかないでしょう。
フレームワーク、フレームワークと言うけどさ…(スコア: -1, フレームのもと) (スコア:2, すばらしい洞察)
元下請けプログラマーより。
Re:フレームワーク、フレームワークと言うけどさ…(スコア: -1, フレームのもと) (スコア:1, 興味深い)
ごめんなさい。
でもでも、フレームワーク書いてるあの人が
ドキュメントとかマニュアルとか書いてくれないんですよ。
あ、いえ、Seasarの話じゃなくて身内の話ですんで
# どう考えてもAC(;´Д`)
# 俺たちも困ってんだyoーーー!!!!!!!!!!!
Re:フレームワーク、フレームワークと言うけどさ…(スコア: -1, フレームのもと) (スコア:1, 興味深い)
元下請けプログラマーより。
昔、中の人だったのでAC
Re:フレームワーク、フレームワークと言うけどさ…(スコア: -1, フレームのもと) (スコア:1)
なんだってわざわざフレームワークなんか使うのか? がおーっ!!!
Re:フレームワーク、フレームワークと言うけどさ…(スコア: -1, フレームのもと) (スコア:1, 興味深い)
そういえば、「従来型のウォーターフォールプロジェクト」に最適だと自称してるフレームワーク「blanco」は、どうなんでしょう?
http://d.hatena.ne.jp/igapyon/20060215
http://hp.vector.co.jp/authors/VA027994/blanco/blanco.ja.html
Excelで仕様書(^^;を書いて、それをコンバートしてJavaソースにする、というスタイルなので、
Excel仕様書駆動(わら)な有り勝ちなプロジェクトにフィットしやすいとか、
呼び出すフレームワークJarが一切ないとか、
そういう後ろ向き(^^;なところを遭えて狙ったのだそうです。
補足 (スコア:2, 参考になる)
Open Tech Press | 三菱東京UFJ銀行がミッションクリティカルシステムにオープンソースを採用 [opentechpress.jp]
というのに個人的には感心したり。金融系って先進技術は使わないというレッテルを貼られがちですし。
Re:補足 (スコア:2, 参考になる)
UFJのLinux採用事例 [itmedia.co.jp]のいくつかの [hp.com] 導入事例 [ctc-g.co.jp]や
当時の担当者のインタビュー [nikkeibp.co.jp]をどれか一つくらいリンクしたほうが良かった。
オープンソース採用のネックとなるのは、なんといっても品質保証で、
Seaser2だろうがStrutsだろうがオープンソースというだけで
基本的に敬遠する企業担当者は少なくないこと。
(実際、やみくもに採用した青森の失敗事例 [srad.jp]がある)
UFJは、既に問題をねじ伏せて採用してきた実績があるって事を
前提知識にすると、オープンソースかどうかは重要でなく、
国産フレームワークの実績支援という視点が見えてくると思う。
関係ないけど、スラドで評価が高い三井住友銀行は富士通が構築 [fujitsu.com]してるのか。
証券システムトラブルで、矢面に立たされる事が多かった富士通が。
Re:補足 (スコア:2, 参考になる)
同業者の集まりで「現在銀行のシステムを担当していて、DBはOracleでクライアント部はJava使ってます」と言ったら「銀行でそんな普通のシステム使うの?」みたいなことを言われたことがあります……。
#そろそろIDで言うのもアレですがID
Re:補足 (スコア:2, 興味深い)
ちょっと調べれば分かることですが, 三井住友銀行のシステムはIBM, NEC, 富士通がやっています. 大きくはメインの勘定系はIBM, 営業店連携がNEC, 外部との接続が富士通という分担で, ハブシステム [nikkeibp.co.jp]を形成しています.
銀行のシステムは大きな所では基本的に銀行側のシステム部隊が構築を行いますので, メーカ側は運用などのテクニカル, 基盤技術等を除けば, 下請けと考えてもよいでしょう.
Re:補足 (スコア:2, 参考になる)
ここのところ、銀行によって実情はかなり違うようです。
銀行側のシステム部隊というのがきちんと機能していたのは、旧三菱、旧UFJで、ここでは「銀行システム部(設計)>システム子会社(構築)>大手ベンダ(運用)」の順に仕事が流れていたはずです。
一方、旧富士では、「銀行システム部(なにしてたんでしょう)>富士総研(設計・構築)>ベンダ(構築・運用)」、旧一勧は「銀行システム部>日立(設計・構築)>勧銀システム(構築・運用」になっていたと聞いたことがあります。
ちなみに、証券では、自社の部隊で構築ができる会社は皆無といっていいです。旧大手4社はシステム子会社が全部開発を行う体制だし、準大手以下は通常パッケージか共同利用型システムです。
Re:補足 (スコア:1, 興味深い)
某社で社内で作っている某フレームワークは今だにクラス名IDで、POJOでもないのでテストコードを書くのが大変だという理由で単体テストの自動化もほとんどの現場で実行されていません。
DAOの場合、ExcelにSQLを書いて大量のJavaソースコードを生産するという仕様で、Javaのコードを上書きしたらお終いですし、ソースのバージョン管理もできません。
S2StrutsやS2DAOと比べると明らかに成果物の品質は低いだろうなと感じます。
Re:補足 (スコア:1)
だと、山ほど事例があると思います。
ネットバンキング、オンライントレードの Apache(とか IBM HTTPD)
10年くらい前を思い出します (スコア:2, すばらしい洞察)
10年ほど前、まだインターネットの普及黎明期でしたが、どこかの企業や芸能人がホームページ(という表現が正確かどうかはともかく、俗称として)を立ち上げるたびニュースやプレスリリースが公開され話題となっていました。
10年前の「ホームページ」が今では「オープンソース」になっているのですね。
「あの三菱東京UFJがオープンソースを採用」ということがニュースになっていることから察するに、まだまだオープンソースが一般化しておらず消化されていないという証でもあったりします。
10年後、オープンソースが一般化するかどうかは私には解りませんが、それに向けてまだまだ努力せねば、と思うばかりでした。
Re:10年くらい前を思い出します (スコア:1, 興味深い)
「そういう時代じゃない」と部下の方と説得を試みるも、 WWWなんて使ったこともない方には理解いただけないようで。
その中身が初公開となる内容のものだったりして、 「○○(コンテンツ名)を公開」のほうが世間から注目されるのが明らかであっても、 「ホームページ」にこだわるんですねえ。
見える... (スコア:2, おもしろおかしい)