IBM、ラショナルを買収 45
ストーリー by kazekiri
ビッグブルー傘下に入るUML 部門より
ビッグブルー傘下に入るUML 部門より
ロイターが伝えるところによると、
IBMが
ラショナル・ソフトウェアを21億ドルで買収することになった
ようだ。ラショナルのプレスリリースは
ここ。ラショナルが買収のターゲットになっているという話は
最近広まっていたが、やはりIBMが落としたかということか。
ラショナルの高度なソフトウェア開発ツールを手に入れることは、
IBMがソフトウエア開発環境の市場においてトップベンダーの位置を
固めることに役立つだろう。
$15 billion market? (スコア:3, 興味深い)
それによると、現在 $9 billion 規模のソフトウェア業界は四年後には、
$15 billion 規模になる見通しだから、
開発環境で押している MS を相手にするにも、$2.1 billion の今回の買い物は
良い買い物だった、ということみたいです。
アメリカは景気がどんどん下向きになってきてるので、どうだかなぁという感じですね＜ $15 billion market
景気が悪いからこそ多角化して景気との連動を避けるとか、
Rational を伸ばしていける未来があるとか、色々見方はあるんでしょうけど、
識者の意見求む。
最近ますますカッコイイ big blue ですが、寒い業界を盛り上げてもらいたいですね。
バラの花は・・・ (スコア:2)
今、UML流行ってますか？認知度は確実に上がっただろうけど・・・。再就職の時には認めてもらえる技術であって欲しい（笑）。
Re:バラの花は・・・ (スコア:2, すばらしい洞察)
ウチの会社では全員必須で教育受けさせられますよ。
ユーザーも次のプロジェクトから使うとおっしゃってます。
問題は、UMLに限らずドキュメントの保守ですね。
いつも結局「ソースコード見るのが一番早くて正確」になってしまう。
いや、もちろん悪いのは私なんですが…
Re:バラの花は・・・ (スコア:2, 参考になる)
いまの職場でもUMLを用いた分析設計開発は必須ですし。
でも、全体に浸透するのは当分先でしょうけどね。
ステートチャート図を見せても、これ何の図ですか？って言われるぐらいですから。
＃個人的には、現状を把握するのにクラス図書いて、リファクタリングするから必須だったり
Re:バラの花は・・・ (スコア:1)
アメリカ相手にやってた仕事だと仕様書からユースケースやパッケージ図で来てました。
個人的に一番使うのはクラス図かな。デザインパターンを使って設計・実装をしようとすると UML で絵を残しておかないとわけ分からないことになっちゃうんで。
道具で設計はできない (スコア:1, 興味深い)
UMLどころか構造化ダイアグラムも知らない相手には, 未だにフローチャートです. DBの設計や画面展開図で書かれた要求仕様を見ると, どうやらデータ中心設計も正規化も知らないらしい...
ですからUMLはもっぱら内部向け, というより個人で作れる範囲での設計用ですね. プログラムを作る人間の8割がたはカプセル化, 継承, ポリモーフといった基礎的な概念が分からないので, UMLに沿った形での製造は不可能です.
さらにUMLやオブジェクト指向についての知識が有っても, それを活かした設計ができるかどうかはまた別の話で, UMLで記述されてはいても実態は従来の構造化設計の枠組みを一歩も出ていないことがほとんどです. ですから設計でUMLを使うという開発プロジェクトが有ったとしても, ごく一部のオブジェクト指向設計に経験のある人以外の設計は役に立たない, というかUMLで記述された設計書は無くてもいいです.
私が経験したほとんど唯一の成功例では, 準備期間がかなり有ったことも手伝って, システム分析段階でオブジェクト指向に精通したメンバーを数名投入し, 数ヶ月に渡って設計を行うメンバー全員にオブジェクト指向をレクチャーしつつシステム分析を進め, 最終的なまとめからドキュメント化をUMLで行うという方法を取りました.
これは5年ほど前の話ですが, その後流行りに乗ってUMLを使ったプロジェクトで成果が上がったという話は聞いたことが有りません. やはり問題になるのはUMLという道具ではなく, それを使いこなすための設計技術をプロジェクト全体としてどの程度保持しているかということに有るみたいです.
不十分な道具では尚更設計できない (スコア:3, 興味深い)
それとあと、UML自体の意味というか書式を理解してない(誤解した)まま
突っ走っちゃったプロジェクトってのも、痛いものが有りますね。
UMLの各記号の意味を「社内独自解釈」しちゃうんだったら、わざわざ「U」MLを使う必要は無いわけで。
#百歩譲って単なる非UML絵を描くツールとして使うっていうなら、せめてRoseみたいな高価なものは選ばないほうが…(^^;
ただ、気持ちは半分わかるんですよね。
そういう場面で UML専用ツールを使うのはどうよ?と疑問に思いますが、
それ以前に、そもそもそういう場面が有る、という点が重要なんだと思います。
つまり、UML自体の記述能力って、あんまり高くないですよね。
だからUMLを逸脱した記述をしたくなってしまう。ここが本質的問題だと思う。
#ついでにいえば、その低い表現力の中でも更にサブセットしか実装できていない、実在の各種UML製品…(T_T)
##そういう意味では、特にRoseは高すぎ!!
分析にせよ設計にせよ実装にせよ、やりたいことをUMLで「必ず」素直に描けるかというと
とてもじゃないがNOなわけで、そうするとUMLを(メインの)Documentとして採用した場合に
UML自体がプロジェクトの足を引っ張り兼ねなくなっちまう…
たとえば卑近な所で。実装についてですが、UMLの「関連」って、
一般的なプログラム言語で一般的な表現(^^;によって表現される「関連」と
結構ちがうものをしか表現できないんですよね。
あの表現は意味的にはむしろRDBの関連のほうに近くて、
OOP言語のポインタだか参照だかを使う関連とは、かなりノリが違う。
いや、それ自体単独ではそれでいいんですが、OOPはそもそも上流から下流まで
意味のインピーダンスミスマッチを少なく出来ますよってのが売りな筈なのに、
よりによってOOP設計のためのカナメのVisual言語(Document)に、
こんなインピーダンスミスマッチが新規に導入されてしまったんでは
OOPにとって「迷惑」だな、という思いが有りまして。
我々が大抵最初に思考の道具として使う自然言語は、(厳密さはかけるものの)かなり表現力があります。
計算機プログラム言語も、自然言語ほどじゃないけど表現力が結構あります。
なのに間に挟まるUMLの表現力がそのどちらよりも少なくて「ボトルネック」になってしまうのならば、
一体なん役に立つんだ？と心配になってしまいます。
部分導入、つまりUMLが得意とする表現「だけ」に使うならば、それでもOKですけど、
少なくとも今のUMLは、Documentの全てとか中心とかを任せるのは、きついと思います。
で、ということは、UMLのどの機能をイツどこで使うのが適切か？ってのを
見抜く確かな目がないと導入は逆効果になりかねないってことであって、
そういう意味ではUMLの導入ってのはそれ自体かなり難しいものがありますね…
Re:不十分な道具では尚更設計できない (スコア:1)
＞計算機プログラム言語も、自然言語ほどじゃないけど表現力が結構あります。
＞なのに間に挟まるUMLの表現力がそのどちらよりも少なくて「ボトルネック」になってしまうのならば、
＞一体なん役に立つんだ？と心配になってしまいます。
表現力に富む＝具体的
表現力が少ない＝抽象的
ということなので、別によいのでは？
UMLは抽象的なレベルで他の人とコミュニケーションするための道具と考えてみては？
具体的なレベルでコミュニケーションしたい場合は、コードを見せると。
Re:不十分な道具では尚更設計できない (スコア:1)
>表現力が少ない＝抽象的
>ということなので、別によいのでは？
抽象とか表現力少ないとか考えるためには、まず「どの表現を」削除してるか？を考えないとしょーがないですね。
そういう意味でUMLは、何か重要な情報の幾つかを誤って捨象しちゃってるんじゃないか、
という不安があります。
>UMLは抽象的なレベルで他の人とコミュニケーションするための道具と考えてみては？
人間相手にしか使えないというのがもし真ならば、
UMLとコードの間の自動変換機能って奴は、どれもこれも全て必ず原理的に、駄目なものでしか有りえない、
ということになりますが、それでいいんでしょうかね？
UMLってそこまで「使えない」ものでオワリだということなんでしょうかね？
Re:不十分な道具では尚更設計できない (スコア:1)
ならばAgreeです。
Re:不十分な道具では尚更設計できない (スコア:1)
どこまで有効か？という問題はありますね。
UMLと丁度同じくらいの自由度(っていうのかな)が、人間のコミュニケーションとして妥当な自由度なのかというと、
そんなの状況次第なわけで、「有効か」と問われれば答えは「何をコミュニケートしたいかに拠る」としか言えない。
そのUMLの有効範囲を過小評価しても過大評価しても、まずいことになるでしょうね。
で、今世間で言われてる程度(笑)よりは、UMLの表現力は、もう少しばかり小さい、んじゃないかと思います。
結局問題は、UMLの能力範囲を、世間が(普及とはそういうことですから)どれだけ誤解してないか？に尽きるんで
ちょっとのズレはそれなりに不安のモトとなります。
コミュニケーションのツールとして (スコア:0)
システム開発なんて全然知らないお客様と
要件を詰めていく時に使うのは難しいように
思っています。
# 今使おうとしているのでAC
Re:不十分な道具では尚更設計できない (スコア:1)
>表現力が少ない＝抽象的
そうですか？
抽象度の高さというのは、(非可逆の)圧縮率の高さみたいなもんだと思います。
元の事象(？)をどの圧縮法で圧縮したかによって現れたサイズの差と。
表現力というのはその圧縮画像を見せてどれだけ雰囲気を伝えられるかということだと思いますし、
良い(その事象に適した)圧縮法を使用することにより、同じサイズでも伝わり方が違うのは周知の通りですので、
UMLの表現力がイマイチなのであれば、それは困ったことだと思います。
Re:不十分な道具では尚更設計できない (スコア:1)
hienさんは、UMLを使用して抽象的なレベルでコミュニケーションするにあたり、具体的にどこらへんで困りました？
Re:バラの花は・・・ (スコア:1)
こう書かれると分野の違う人にはUML＝技術のように見えるかもしれません。
# 書いているご本人は承知のはずで、UMLは書き方ですね。
私は、３年前に仕様書を書くためにシーケンス図を、
実装のためにクラス図とパッケージ図を使ったくらいでした。
# 実装方面はやはり、Rose
最初にマトモに手にした情報が「UMLモデリングのエッセンス」。つまり、
Martin FowlerのUML DISTILLED（原書名がかっこいいと思う）です。
なので、遅めのほうかと。
今の職場の先輩などは、OMTとかから始めている10年選手なので。
現在は、要件定義的な部分で、ユースケース図・配置図・
アクティビティ図・パッケージ図・クラス図・シーケンス図
を使ってますが、真似事レベルな部分が多いです。
それもあって、オージス総研のはブロンズしか取っていないです。
最近は自分の身の回りでモデリング練習をしているのですが、
K-1とPRIDEでやってみたら結局、UMLは使うけど図解に成ってしまいました。
だから、こういうのもレビューする機会がほしかったりします。
ちょっと宣伝 (スコア:1)
僕が直接関係しているわけではないのですが， おなじグループの人がやってるので宣伝．
MAGE (MicroArray and Gene Expression) [mged.org]のオブジェクトモデリング (OM) には，UML を使っています．関係者が世界に散らばっているので 統一的な表記法を採る必要があったのだと思います． 逆に言えば，開発者グループが顔をつき合わせられるような 場ではさほど有効ではないのかもしれないですね
# 宣伝なので ID
Koichi
IBMが買っちゃうと。 (スコア:1)
「UML for SoC」を標準化する「UML for SoCフォーラム」を設立 [zipc.com]
Re:IBMが買っちゃうと。 (スコア:1)
それらの連携関係は今後どうなるのかな…
設計ツールの会社は、設計ツールを消費(笑)する会社に買収されちゃうと、
ちょっときついものが有るなあ。特に有名メジャーどころだと尚更。
#以前マイナーさが話題になった音楽製作ソフトの類とUMLツールとで、どっちがマイナーなのか？と心配になったんでG7
下請け会社に買わせる (スコア:1)
> 買収されちゃうと、ちょっときついものが有るなあ。
> 特に有名メジャーどころだと尚更。
この手の設計ツールって、一緒に仕事をする複数の会社で同じものを使わなければいけませんよね。たとえば、マイクロソフトのオフィス製品なんて、事実上の標準なので、これらのフォーマットでドキュメントを書いてくれって言われたりしますよね。ですから、ラショナルの製品で UML を書かなきゃ仕事は投げないよ、と IBM が下請け会社に言っちゃって大量にさばくなんてのはありうるのではないでしょうか。
開発をやる下請け会社からすれば、いまのところ UML なんて迷惑以外のなにものでもありませんねえ。設計図の書き方を統一して得をするのは発注元であって、一本百万もするソフトを買わないと仕事にならないのでは困ります。この手のツールってのは、上から下に伝わってくるもので、上はこれ使うと便利だ時代に乗り遅れるって洗脳されちゃって、下の方ではヒーヒー言うっていう感じじゃないですか。
Re:IBMが買っちゃうと。 (スコア:0)
trueOne
Re:IBMが買っちゃうと。 (スコア:1)
最近のIBM は Eclipse <-> WebSphere 開発環境 とか、ある程度うまく OpenSource <-> Business のバランスをとってると思います。 Rose を WS Family に持ってくるとしたら、Enterprise or TeamDevelopment 環境を外した personal 版を公開してくれる可能性があるかも。
妄想かもしれないけど。。 でも買ったのが IBM で良かったと思ってマス。
開発環境だけでなく (スコア:0)
対して、日本のビッグネーム各社はどうやって強化しているんでしょうか?
# ACにするする(これ、一度やってみたかった)
…松下かと思った (スコア:0)
Re:…松下かと思った (スコア:2, おもしろおかしい)
受付「いま受付にナショナルの方がみえられています」
担当「わかりました（『ラショナル』だっちゅーに）」
実話です。一般的にありがちではないかと。
当面の興味は、、 (スコア:0)
Rose高くて使えなかったところは多いと思われ。
# 価格下がったら、他社製品も対抗して下げざるを得ない。
# もろ、利害関係者なのでAC
UML 用ツール (スコア:1)
私は MagicDraw とか Dia を使ってますが。
Re:UML 用ツール (スコア:2, 参考になる)
まぁ機能足りなさすぎて困ってしまうことが多いですが。
ただ、じゃあ高いRoseならバラ色なのか？と問われると、答えはNoですね。
高いくせに「こんな機能も無いのか？」と新鮮な驚き(笑)に見舞われることが多いです。
というかそれ以前の問題として、UMLも含めた「図」を描くツールには
どんな機能が有るor無いと快適なのか(あるいは逆に不快(!)なのか)ってのを
ほんとに考えて作っているのか？と、小一時間くらい問いたくなることが多いです。
計算機の画面で図を描くってことが一般的にどういうストレスの有りがちなことであり、
それを緩和するには何をすればいいか…といった事柄を、もっと考慮して欲しい。
困ったことに、この問いたい相手は、FREEのIIOSSも高価なRoseもどっちも含まれてるんです。
ほかにVisioやDiaや…も少し触ったけど、大同小異。
こうして見ると、俺が触ったことが無いソフトの中に素晴らしいものがあることを祈らずにはいられません。
さもないと、UML全体が地盤沈下しちまわねーか？という心配がまず沸いてくるんで。
UML自体が(これまた)バラ色だとは決して言いませんが、無いよりはマシなことも結構あるんで、
消えて欲しいとは思わないんですよね。そういう意味では、
UMLのキラー(=みんなが「なるほど便利だ！」と思ってくれるような)ツールが欲しい所です。
で、どれが良さそうでしょうか？(^^; #できればOpenSourceで…
Re:UML 用ツール (スコア:1)
# 「金ないのにProfessionalかよ!」というツッコミはなしで(笑)。
Re:UML 用ツール (スコア:1)
でも、Visioって重たくて使いにくいのよね。
Re:UML 用ツール (スコア:1)
Enterprise Architect [sparxsystems.com.au]使ってます。
最近、日本語版リリースのアナウンス [sparxsystems.jp]がされたようです。
このツールを使用する前は、VisioのUMLアドインを使ってUMLモデリングをしていました。が、あまりの重さ＆不安定さに閉口して、こちらのツールに乗り換えました。 :-)
動作プラットフォームはWindowsに限定されますが、その代わりに、Pure Javaのツールに比べてカナリ軽快に動作してくれます。
自分は、分析・設計フェーズにおけるクラス図、シーケンス図、コンポーネント図、パッケージ図(UML?)の記述に使用しています。
価格が良心的なのもポイント高いです。($100～200程度)
＃ Rose, Togetherもいいけど、100万円は出せません・・・。
Re:UML 用ツール (スコア:0)
Re:UML 用ツール (スコア:1)
したJPEGを使ってます。
いや、使ったツールの中では、出力したダイアグラムが一番
まともだったから。
でも、モデリングツールとしては、使えないかな...
＃1.0だと各図の間で連携できないから、手間かかりすぎ
Re:当面の興味は、、 (スコア:1)
たかいっす。
買えない…
なもんでIIOSS使っていたりしますが。
でも、最初の設計はやっぱり紙と鉛筆だ(爆)
誰かに試行錯誤する段階になってから清書だ(汗)
kusanagi shin
Re:当面の興味は、、 (スコア:1)
確かに高いので, 私はuml [sourceforge.net](最近Umbrelloって名前に変わったみたい)を使っています. どうせ客先に提出するドキュメントを作るわけじゃない(出したって分かりゃしない)ので, 自分で設計をまとめられれば十分という用途になら, かなり使えます.
WSADに・・？ (スコア:0)
金が無くてEclipseしか使えないのでAC。
Re:WSADに・・？ (スコア:1)
OOPSLA2002の 最大スポンサーがIBMとMicrisoftだった [atmarkit.co.jp]りするような図式から妄想すると、 エンタープライズなドメインにおけるオブジェクト指向 + Webサービス(んで今後は Aspect指向も取り入れる?)なシステム構築の土俵では:
……といった布陣で戦っていくのかな？(Sunは? Sun One Server??)。 OS、言語はいずれもMSに伍していけるけれども、現状のWSADはVisualStudio並とは言い難 いなかで、 XDEを擁するRationalを傘下に収めるのは興味深いと思います。
個人的にはこの動きがEclipseのEMFやGEF、Eclipse本体とどう関連していってくれるのか が気になります。
Re:当面の興味は、、 (スコア:0)
たんなるお絵かきツールとは一線を画しているよね．
てなわけで，もしほんとうにROSEが値下げしたら
よそはかなーり困るのでは．
とゆうか，値下げしてくれ．全社的に使い倒したいんだ．
UMLって本当に使えるもん？ (スコア:0)
買った入門書には企業体/企業活動をまるごどUMLで記述出来るって書いてあるんです。非ルーチンワーク/エクセプションのハンドリングも含めての企業体/企業活動ですけど、そういうのもUMLで記述可能？
Re:UMLって本当に使えるもん？ (スコア:0)
まともなセミナにいってきちんと洗脳されてきてください。
すくなくとも既存の表現形式よりずいぶんましなところが
理解できるでしょう。
ただし万人がつかえるのか，という点についてはノーコメント。
Re:UMLって本当に使えるもん？ (スコア:0)
また実際になされています。
UMLの拡張に関して勉強してみてください。
Re:UMLって本当に使えるもん？ (スコア:0)
>また実際になされています。
へー、凄いですねえ。で、もうちょっと教えてください。事前予測不可能な原因による突発的な事態。一般社員で対処可能なのか、役職者でOKなのか、役員の出馬が必要なのかはその時になってみないと分かりません。対処方法も場当たり的に決めて行きます。こういうマニュアル化できない事象は、実際の企業では起こる事ですね。
こういう事前に策定不可能な事象をどの様にUMLを使って図式化等を行っていくのでしょう？それともUMLで可能なのは、そういう例外的な事象は別扱いに
Re:UMLって本当に使えるもん？ (スコア:1)
場当たり的とはいえ、ケースとルールと照らし合わせての判断ですから。最終的には文書化できますよ。これはUML以前の問題ですね。作れるかどうかは単に時間とパワーとスキルの問題です。ディズニーランドの服装規定のあやふやなところは、「○○担当（一人か二人しかいない）が判断する」ということを明記します。担当者を一つのブラックBOXとしてルール記述をするということも可能なんです。
またココ最近流行の「危機管理」に関しても、「誰が記者会見で答えるか」などのルールは決めていこうというムードが高まっていますね。ちなみに「社長は出すな」というルールを見たことがあります。現場を知らない偉い人が、ペーペーの記者相手に逆切れすることを嫌ってのルールだと思います。
突発的な事故で金銭的な被害が出るケースに関しては顧客との契約書にもつらつらと書かれますよね。んでもめたときには「裁判所」というクラスが登場します。
Re:UMLって本当に使えるもん？ (スコア:0)
> ですから。最終的には文書化できますよ。
ふむふむ。「担当者が適宜対処する」とかの指針は、行動指針マニュアルに記す事はできますね。実際に何をするのか、何ができるのかがまったく予測不可能だとしても。
なるほど、企業体/企業活動のUMLによる記述とは、そういう話ですね。そうか、「企業体/企業活動」というあまり適切でない単語を使うから誤解が生じるのであって
Re:UMLって本当に使えるもん？ (スコア:1)
「組織」と言った方がよいかもしれませんね。体制図ってクラス図そのものでしょう。
「担当者」を決める際には、クラス図を作成するのと同じ手順で決定できます。
・彼に何をして欲しいか？
・彼は何ができるか？
・彼は何を知っているか？
の整合性を取っていくことでメソッドとフィールドが決めれます。
逆に組織はオブジェクト指向でないと設計しにくいです。
Re:UMLって本当に使えるもん？ (スコア:0)