ObjectSquare [2001 年 10 月号]

[レポート] オブジェクト指向2001シンポジウムレポート


オブジェクト指向2001シンポジウムレポート

(株) オージス総研
eソリューション事業部
オブジェクトテクノロジーソリューション部
山内亨和

はじめに

去る8月22日から24日に渡ってオブジェクト指向2001シンポジウムが開催されました。
こちらは情報処理学会 ソフトウェア工学研究会が主催し、産業界と学会の共同で運営、開催されるオブジェクト指向に関する日本最大のシンポジウムです。これまで、過去6年間に渡ってオブジェクト指向技術に関する様々な議論を行なわれてきて、今年で7年目になります。

今年のオブジェクト指向シンポジウムも、その話題は多岐に渡りました。その中で2日目の講演から、私が聴講した『RUP & XP: オブジェクト指向開発の進行図』と私自身も発表者の一人として参加した『モデリングワークショップ 再利用への新たな視点と実際』について、思うところを述べさせていただきます。

RUP & XP: オブジェクト指向開発の進行図

去年に行われた「RUP vs XP」に引き続いて今年も「RUP & XP」セッションが行われました。今年の講演名はvsではなく&となっています。これは対決色を弱める意図もあったようです。2つのプロセスが成熟してきたことを暗に示しているのかも知れません。

今年はRUP支持者として平澤さん(ウルシステムズ)が、XP支持者として平鍋さん(永和システムマネジメント)が発表をしていました。この講演の発表資料は平鍋さんのXPのホームページに公開されています。実はこの講演は思いがけず、RUP支持者、XP支持者の本音を聞くことができた、お得な講演でした。その本音の一部をお伝えします。

アーキテクチャと変更への姿勢

RUPではアーキテクチャを推敲フェイズで集中的に構築します。推敲フェイズ終了後にアーキテクチャを変更することはありません。
対して、XPではアーキテクチャを最初のイテレーションで創発します。ただし、その後でアーキテクチャが変更されることはあるようです。
Ron Jeffriesという方の言うには、「RUPは常にアーキテクチャから始める。それはXPも同じだ。ただ、私たち(XP)にとってアーキテクチャはsmall sideである。RUPは変更を許容する。それはXPも同じだ。私たちにとって変更はlarge sideである。」といっているそうです。

予算と要員の見積もり

RUPは方向付けフェイズで初期の計画案を作成し、この計画案を元にそのプロジェクトの予算をコミットすることを推奨しています。要員計画については推敲フェイズの終わりに立てるそうです。しかし、実際のビジネスでは、推敲フェイズでの要員見積もりでは遅いこともあるそうです。それは、推敲フェイズで要求をまとめあげ、アーキテクチャベースラインを構築した結果、方向付けフェイズで見積もった予算とかけ離れた、本当の予算がわかることがあるからです。

XPの場合は、予算と要員を見積もる方法が提示されていません。実際に、XPでプロジェクトを受ける場合には「5人で6ヶ月、ベストを尽くしますので、30人月です」といった"決め"で見積もるしかないといっていました。代わりにRUPの方向付けフェイズをプロジェクトの始めにとって、そこで予算をコミットするのが現実的という話がありました。

感想

上でも書いたように、それぞれのプロセスの足りない点について支持者がどのように考え、その点をどうやって解決しているかといった話が聞ける、非常に面白い講演になりました。講演者のお二方ともさすがに手馴れたもので、テンポよい掛け合いが講演をより魅力的なものにしていました。その意味でも学ぶべきことが多い講演でした。

最近、JavaWorldでXPの記事が掲載されたり、XPの翻訳本が出たりとXPのニュースが満載していて、なぜこんなにXPが人気あるのかと疑問に思っていましたが、今回の講演中にその答えがわかったような気がします。
XPは14のプラクティスの一部(テスティングやリファクタリング)を限定的に導入することが可能です。そのため上司やクライアントに大々的に「開発プロセスのXPを導入します」と言わずにすむため、実作業に取り込みやすいのだろうと、認識しました。対してRUPなどはプロセス色が強いため、上司やクライアントの協力を得ないと導入が難しいのではないでしょうか。
しかし、XPで一部のプラクティスのみを導入した場合でも、それをプロセスと呼べるのか少し疑問は残りますが。

モデリングワークショップ 再利用への新たな視点と実際

モデリングワークショップとは

モデリングワークショップとは、あるモデリングの題材について、チームでモデリングを行い、その成果物をもとに発表するワークショップです。このワークショップは96年の『良いオブジェクト指向設計とは−共通問題による設計コンテスト』から始まり、98年からは現在使用しているパソコン販売管理システム問題をモデリングする今の形式になりました。

これまでの3年間のワークショップで重点を置かれていた点とは、

と、通常のシステム開発のアクティビティの中で行われるモデリングについて焦点を当てていました。今回のテーマはこれらとは一味も二味も違います。

今回のモデリングワークショップでは、オブジェクト指向の醍醐味とも言える「再利用性」を考慮するとモデリングはどう変わるかという観点から、「フレームワークの視点から」のモデリングと、「ビジネスモデリングの視点から」のモデリングを提示しました。また、今回提供された問題では今回導入する(と仮定された)パソコン販売管理システムをWebベースのシステムであると限定しました。
それぞれのモデリングを行ったのは以下の方々です。

フレームワークの視点から

「フレームワークの視点から」は豆蔵有志チームが担当していました。この発表の詳細な資料は豆蔵のHPから参照することができます。発表内容はこの資料を参考にしていただければわかりますので、今回は発表の感想だけにさせていただきます。

フレームワークチームはパソコン販売管理システムのフレームワークをモデリング、開発するために以下の3つのチーム分けを行っていました。

ドメインチームは販売管理ドメインモデルのフレームワークを、アーキテクチャチームはWebの画面遷移のフレームワークとしてユースケースエンジンなるものを構築していました。最終的にこの2つのフレームワークを拡張し、統合することで今回のパソコン販売管理システムを構築するそうです。

今回、フレームワークチームの販売ドメインモデルのフレームワークを見ていて面白いと感じたことがいくつかありましたので上げます。

バリエーション

ドメインモデルをフレームワーク化するために、そのドメインのバリエーションを探す方法をとっていました。同業種では基本的な業務の仕組みは同じですが、細部は異なります。この細部のことをバリエーションと呼んでいると思われます。
同業種に存在するバリエーションを調査して、その共通点と違いを見つけることでドメインモデルのフレームワークを構築するようです。
フレームワークチームの発表の中で、ドメインモデルのフレームワークを構築するためには、ドメインエキスパートの参画が不可欠で、実際に今回もドメインエキスパートに参加してもらった結果、その前までのモデルがより現実に即したものになったと言っていました。

交換可能な(pluggable)アクティビティ

このドメインモデルのフレームワークで業務の流れを表現するためにアクティビティ図が用いられていました。このアクティビティ図で面白かったのは、アクティビティが交換可能なのものとされていたことです。以下の図参照

このようにアクティビティ図においてもドメインモデルのバリエーションを表現することが可能のようです。

ビジネスモデリングの視点から

「ビジネスモデリングの視点から」は事業模型倶楽部チームが担当していました。この発表の詳細な資料についても事業模型倶楽部のHPから参照することができます。

ビジネスモデリングチームはこのモデリングのために、仮想的にパソコン販売管理システムのオーナーであるパソコン販売会社になり、パソコン販売会社の経営戦略の立案と実業務の詳細な定義を行いました。UMLを用いてビジネスモデリングを行うことの効果について検証するために今回、経営戦略を立てる経営チームと、立てられた経営戦略をUMLのモデルに落とし込むシステムチームに分けて、この2つのチームが協調して作業しました。

ちなみに、今回ビジネスモデリングを行うために使用したビジネスモデリング手法はEriksson/Penker によって書かれた「Business Modeling with UML」です。ビジネスモデルからシステム要件に落とし込む方法が明記されていたため採用しました。

今回の作業、また発表で気づいたことを以下にあげます。

UML単体で行うビジネスモデリングの限界

今回採用したBusiness Modeling with UMLで用意されているダイアグラムの一つにプロセスダイアグラムというものがあります。これはステレオタイプの機構を用いてアクティビティ図を拡張したダイアグラムで、「プロセス」と、「プロセスが生み出し、使用するリソース」の関係を記述できます。もちろん、プロセス内の作業順序も表現できます。プロセスダイアグラムはUMLのアクティビティ図よりも表現力があり、ビジネスプロセスをモデリングするのに適しています。UMLが元から用意しているダイアグラムはビジネスをモデリングするには表現力が不足しています。ビジネスモデリングのためにUMLを拡張する必要があります。

また、UMLではまったく書けないもの、もし書けたとしても嬉しくないものも存在します。Business Modeling with UMLではSWOTダイアグラムを用いてビジネスの戦略を検討します。これはUMLではありまん。自社の強みと弱み、社外に存在する機会と脅威の記述とこれらに対する戦略をまとめたマトリクスです。もし、これをUMLで表現したとして、誰が喜ぶでしょうか? UML以外のモデルで記述したほうがよいものは、無理にUMLを使う必要はありません。ただし、その時に気をつけておきたいことは、UMLのモデルとUML以外のモデルの相関関係を意識することです。UML以外のモデルとUMLのモデルは互いに独立したものではなく、相互に依存しあっています。ある一つのビジネスの別の側面をモデル化しただけだからです。これらのモデル間に存在している関係がどのような関係かを知っておくことで、一方のモデルが進化すれば他方のモデルも進化するでしょう。

経営の視点から記述した概念モデル

通常、概念モデルというと、システム開発の対象となっている実業務中の概念のモデルですが、今回は経営戦略の視点から概念モデルを記述しました。経営戦略の視点から概念モデルを書く過程で、戦略の複数候補や、将来の戦略などについて考慮することになります。この活動によって、ビジネス界の環境変化に対応できる概念モデルを構築でき、その構築された概念モデルによって仕様の変更に強いシステムが作られるでしょう。

感想

当初、事業模型倶楽部がモデリングワークショップの参加依頼を受けたときは、発表日まで1ヶ月しかなかったこともあり、「果たして間に合うのだろうか...」という心配をしていましたので、無事発表を終えたときは達成感で一杯でした。

今回発表して意外だったことは、「これからはビジネスモデリングが重要」と考えて、活動をはじめようとしている方々が多く見受けられたことです。これまでソフトウェア工学はソフトウェアシステムに焦点を当ててきましたが、これからはビジネスシステムについての研究も増えていくことでしょう。楽しみです。

最後に

今年のオブジェクト指向シンポジウムは今回紹介した講演の他にもLinda Rising氏による「Introducing Patterns(or any new technolozy) into the Workplace」や、「ソフトウェア工学の近未来チャレンジ」など多くの興味深い講演がたくさんありました。ぜひ来年は(業務の都合がつけば)3日間参加したいものです。

最後ではありますが、面白い3日間を企画、運営してくださったシンポジウム実行委員会の方々に感謝します。

関連リンク、書籍




記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。
  



© 2001 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP