目次


極Blog的Rationalソリューション概要

RoseユーザのためのRSx一口講座

Comments

第1回 「はじめに」

本来の連載をさしおいて、またまた番外編です。極Blog的Rationalソリューション概要、RoseユーザーのためのRSx一口講座(・・・といいながら、連載)の開催です。

はじめに

少々口はばったい言い方ですが、Rational Rose(以下、Rose)は、UMLのモデリングツールの代表格として、マーケットで一定の評価をいただいてきました。 2005年以降、IBM Rationalでは、次世代のUMLモデリング環境として、Eclipseを基盤とした以下の製品をリリースしています。

  1. Rational Software Architect(以下、RSA)
  2. Rational Systems Developer(以下、RSD)
  3. Rational Software Modeler(以下、RSM)

(※本稿では、以降3製品をまとめて表現する場合には、"RSx"とする) しかし、既存のRoseユーザーが"Roseの延長線上の使い方"を試みると、機能面での違いにとまどいを感じる方も少なくありません。 近年の上流工程重視の流れやソフトウェアの規模・複雑さの拡大をにらみ、開発組織は従来の開発スタイル自体を再検討し、新しいスタイルに移行する必要がある・・・そのような危機感を感じており、その危機感をベースに開発スタイルのあるべき姿をいくつか想定しています。そして、RSxシリーズは多様な開発スタイルを支えるためのプラットフォームとして位置づけられています。 RSxシリーズをよりうまく使いこなし、「RSxを購入した」という“投資”を回収するためには、それが前提としている開発スタイルの変化を理解する必要があります。・・・これが本稿の狙いです。

個々の機能を詳細に説明した製品解説では、”木をみて森をみず”という結果になりがちです。 本稿では、

  • これまでRose/XDEをお使いいただいていたユーザーの皆さん
  • これからUMLを使おうと思っている皆さん
  • 組織的に上流工程の能力向上を狙っている皆さん

を対象に、「RSxによって実現しようとしている開発スタイル」という”森”をご理解いただければ・・・と思っております。

マーケットの変化と課題

“モデリング”に対する市場の期待

  • 品質問題
    • 設計(=モデリング)重視の機運再び
  • 品質と効率の両立
    • MDA(モデル駆動型開発)
    • プラットフォーム化+差分開発による、納期短期化へのチャレンジ
    • 再利用(自社フレームワーク、オープンソース etc…)
  • “上流工程成果物の再利用”というコンセプトの一般化
    • デザインパターン、アナリシスパターン

半完成品でなくても 〜部分的な設計のレベルでも、設計のポイントが明確になるという意味で〜 十分意味がある。

ソフトウェア開発の世界で、常に語られるキーワードの1つにQCD(※)があります。

※品質(Quality : Q)、コスト(Cost : C)、納期(Delivery : D) 開発組織はこの3つのファクターを向上させるために、日夜研鑽(とデスマーチ)を続けるわけですが、お客様との会話を通してみられるのが、次のような傾向です。

  • 上流工程に対する意識の高まり
    アジャイルは、単体テストの重要性やペアプログラミングに代表されるコミュニケーションによるスキルの伝達等価値あるスタイルの提示を行ってきました。が、その一方で、本来のアジャイルの趣旨を誤解した、“(設計やアーキテクチャー無き)コード偏重”的な風潮を産み出したという負の側面も持ち合わせます。今、改めて、“きちんと設計する”ということに対する関心が高まっています。
    また、昨今のSOAの議論に代表されるように、ビジネスのモデルといった、更に上流のモデル化への期待も年々大きくなっています。
  • 再利用の実践
    品質と効率を両立させるために「再利用しましょう!」というのは、昔からあるトークです。しかし昨今は、自社製やオープンソースのフレームワークを基盤に利用するというスタイルが一般化してきました。また、このような“実装の再利用”にとどまらず、デザインパターンに代表される“知識(=非実装)の再利用”も、その価値を認められています。
  • 組織的な取り組み
    上記のようなさまざまなフレームワーク、要素技術の変化に対応するために、組織的な取り組みを始めるところが増えています。特にシステムインテグレータでは、自分たちの開発能力のベンチマークとして“CMM/CMMi“が語られることが珍しくは無くなっています。
    また、日本版SOX法を契機にして、あらためて組織のガバナンスへの関心も高まっており、その流れは開発組織にも、“標準化”“プロセス化”という形で影響を及ぼしています。

Roseのビジネスから学習したこと

Rose ビジネスから学習したこと

  • UMLスキルの格差は大きい
    • 期待したほど広まってはいない。学習コストが安くはない。
    • “ある程度妥当なモデル”を組める人が少ない。
    • UMLの文法は習得しても、設計はできない。
      〜規模の拡大によりクリティカルな問題になりうる。対策必要。
  • UMLとコードとの格差
    • 設計と実装が分断されてしまう。
    • 設計と実装が混乱してしまう。

さて、“オブジェクト指向のモデリング業界”で、Roseを提供し、10年近くの月日が流れました。その経験をふまえ(そして自己反省も含め)次のことを学びました。

  • UMLを習得するのは、〜なんだかんだと〜“楽”じゃない
    UMLを使って上流工程を行うということは、UML自体の理解とともに、そもそもオブジェクト指向という考え方の理解が必要となります。「同じオブジェクト指向に基づくプログラミング言語(Java,C++ etc)は使っているのに、オブジェクト指向の設計はできない」というのは、単純におかしな話なのですが、でも、それが現実です。それに加えて、UMLの文法は習得しても、設計とはそれ自体難しい話です。結果として、Javaの普及ほどはUMLの普及は(関心が高くても)進んでいません。
    実装は普及しても、設計の道具が普及しない、というところが、上流工程重視の風潮を産み出しているという見方もできます。
    また、俗にオープン系といわれる分野でのアプリケーション開発が増えるに従って、開発に携わる人員も増えます。学習コストは無視できない額となるけれど、“学習“を軽視すれば、それこそ無視できないほどのスキル格差が現場に生まれます。
    今までありがちだった、「開発組織○○○人を2年でUML技術者に」のスローガンの元、粛々と○○○人が勉強する、というやり方そのものを再検討の俎上に載せる必要があります。
  • やっぱり、“UMLはコードじゃない”
    そう、やっぱりUMLは、コードじゃないのです(当たり前ですが)。Roseはモデリングツールであり、開発環境はユーザーの皆さんに別途用意してもらう必要がありました。開発環境によっては同じシェル環境の中で利用できたり、モデルとコードの同期がとられたりと、それなりに快適な使い勝手が実現されていました。が、やはり、埋めきれないギャップというものも、また、存在します。(このギャップについては、図3をご覧ください)。
図3:埋めきれないギャップ
図3:埋めきれないギャップ
図3:埋めきれないギャップ

“ここが変わった”:4つのポイント

RoseとRSxが前提としている開発スタイルの違い、少々乱暴ですが、4つのポイントにまとめることができます。

  1. 再利用を前提とした開発プロセス
  2. UML2.0 & MDD(モデル駆動型開発)
  3. モデリングツールではなく、統合環境
  4. “アーキテクチャーの裏付けのある品質”の実現

次回から、この4つのポイントを取り上げてみましょう。今回は文字ばかりでしたけど、次回は、絵もいっぱい入れましょう!

第2回 「UML2.0とモデル駆動型開発」


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=311670
ArticleTitle=極Blog的Rationalソリューション概要
publish-date=08112006