ObjectSquare [2005 年 10 月号]

[レポート]


SOA 時代のビジネスモデリング

〜 Modeling Forum 2005 参加レポート 〜

(株)オージス総研 オブジェクトの広場編集委員

Modeling Forum ロゴ

UMTP/Japan が主催する Modeling Forum 2005 が、2005 年 9 月 15, 16 日の 2 日間、大手町サンケイプラザ (東京/大手町) で開催されました。Modeling Forum は「モデリング技術」をキーワードに、最新技術や、製品、ビジネスプロセス、オフショア開発などの様々なテーマを扱うイベントです。今年で 2 回目となる当イベントは、SOA 時代のビジネスモデリングをテーマにコンファレンスとデモ展示が行われました。来場者数は 1000 名を越え、昨年の倍以上の規模のイベントとなったようです。

ここに、広場編集委員が聴講したセッションの内容やフォーラムの雰囲気を、所感を含めて記したいと思います。

もくじ

"リアルタイム"時代のデータ管理とは?
〜今、オブジェクト指向データベース復権へ

秦 信之氏/ソニック ソフトウェア株式会社 セールスエンジニアリング部 シニアセールスコンサルタント

SOAやUML、モデリングに関するセッションが多い中で、当セッションは唯一「データ管理」をテーマにしていました。 オブジェクト指向データベース(OODB:Object-Oriented DataBase)である「ObjectStore」の紹介セッションです。 私は、弊社が販売してる 「Objectivity/DB」サポート担当としてOODBに関わっています。 これまで、OODBというカテゴリでDB製品の情報を把握できる機会はそれほどありませんでしたので、 非常に貴重な機会であると思い参加しました。 このレポートでは、OODBに携わる者の視点で、Objectivity/DBとの比較も交えながら、セッションの内容と所感をお届けします。

受講者像は?

100人を超す満席のセッションで、講師の方が最初に「ObjectStoreをご存知の方は?」と尋ねられたところ、 15〜20人に1人の方しか挙手しませんでした。OODBへの関心はあるものの、具体的な製品イメージまでは・・という受講者が 占めていたようです。

オブジェクト指向データベースとは?

セッション内容の紹介に移る前に、まずは私の方から一般的なOODBの特徴を説明したいと思います。 OODBは、リレーショナルデータベース(RDB:Relational DataBase)と比較すると、 以下のような特徴を持ちます。

  OODB RDB
保存の仕方 ・オブジェクトを保存
・オブジェクト間の関連も保存
・2次元表で保存
・データ間の関係は検索時にSQLで指定
データ定義 クラスの定義情報よりデータスキーマ(定義)を取込み SQL(CREATE TABLE文)でデータを定義
データ操作 言語インタフェース(API)で操作 SQL(SELECT文など)で操作
イメージ

これらの特徴からOODBは、RDBを使ったオブジェクト指向アプリケーションが抱える次のような問題を克服します。

しかし、OODBに対して次のようなイメージを持たれる方も多いようです。
 ・・・「パフォーマンスが悪いんじゃないの?」
 ・・・「よくわからないけど難しいんじゃないの?」

オブジェクト永続化のアーキテクチャ

本セッションでは、ObjectStoreの機構や使用法について極力具体的に説明することを通して、 これらの誤解を解こうとしていたように思いました。セッションの流れとしては、 会社紹介、製品ラインアップ紹介と続き、中心となる製品であるObjectStoreの 説明をされました。そして、最後に軽く事例の紹介をされていました。

ObjectStoreの説明の中では、特に以下3点でObjectStoreを特徴づけされていました。 この3点について、Objectivity/DBとの比較を少し交えながら、以下に紹介します。

その一:「データ透過性」

ObjectStoreのデータ透過性とは、「一時オブジェクト」(アプリケーション上のオブジェクト)と 「永続オブジェクト」(DBに格納されたオブジェクト)を“同様に扱える”ことを 表している、とのことでした。この“同様に扱える”とは、“あるクラスの オブジェクトが永続化されるオブジェクトかどうかをアプリケーション側が意識することなく、 そのオブジェクトに対してメソッド呼び出しなどの通常の操作を行える”ことだと私は解釈しています。 本セッションでは、このデータ透過性を、具体的に次のように説明されていました。

さらに本セッションでは、オブジェクトの操作を行うための、Java APIを使用したコーディング例を紹介されていました。 例では、SQL等を埋め込まない純粋なJava言語で、少ないコーディング量でデータのトランザクション処理を記述できていました。 このあたりに「OODBは難しくないよ」というメッセージが込められていると感じます。

base_class

さて、2番目の「特別な基底クラスは必要ない」ことをやや強調されていた点が、私としては興味深かったです。 というのも、Objectivity/DBでは、永続化対象のクラスは特定の基底クラスを継承します (もしくはインタフェースを実装します)。 永続化を行うような特定のクラスを継承すると、“ドメイン領域に関するクラス”と “永続化という技術サービスを行うクラス”とを結合してしまう、という懸念点があります。 ObjectStoreはこの懸念点を解決し、永続化という関心事をアプリケーションから完全に 分割している、ということを強調されたかったのではと推測します。

一方で、“永続化を前提としてアプリケーションを構築する”という考え方を元に、 永続化に対する重要な機能を果たすクラスを基底クラスとして用意する、という 対応もできます。「データと振る舞いをカプセル化する」というオブジェクト指向の 考え方を、システムレベルに発展させているイメージです。 Objectivity/DBはこの立場で基底クラスを用意することで、 オブジェクトの永続化に関する操作をより直感的に行えるよう工夫をしているように思います。

とにもかくにも、オブジェクトの永続化のために基底クラスを用いるかどうかは、 そのOODB製品を特徴づける1つのポイントのようです。

その二:「仮想記憶マッピングアーキテクチャ」

OODBの重要なアーキテクチャとして、アプリケーション上のオブジェクトと、DB上の オブジェクトのマッピングがあります。 ObjectStoreでは、後述の“キャッシュフォワードアーキテクチャ”を使用して、 アプリケーション側にオブジェクトをキャッシュするとのことです。 この際、このキャッシングに「OSの仮想記憶領域を使用する」ところがポイントで、 OSのアドレッシング機構を使用して通常のメモリアクセスと同等の速度を 確保できるということでした。高速性を非常に重視したアーキテクチャになっています。

Objectivity/DBでも、同じくキャッシュ領域をアプリケーション側に確保します。 しかし、 OSとは別に独自にキャッシュ領域を持つという点に違いがあります。 OSに依存せず、「独自にオブジェクトを管理する」ことを主眼としたアーキテクチャに なっていると言えます。例えば、C++ API では必要なオブジェクトを意図的にキャッシュに “留めておく”ことができます。言い換えれば、キャッシュがいっぱいになったときにも、 必要なオブジェクトのOSによるスワップアウトを防げます。 したがって、大量のデータを取り扱う時にも、より安定したパフォーマンスを保ちやすく なっています。

Objectivity/DBのキャッシュ

これらは細かい違いのように見えますが、アプリケーション側でデータ操作を行う OODBでは、キャッシングは重要な要素であると感じています。 どのようにキャッシングを行うかも、OODB製品を特徴づける1つのポイントのようです。

その三:「キャッシュフォワードアーキテクチャ」

OODBやRDBなどの種類を問わず、一般的にデータベース管理システム(DBMS)は、 ディスクへのI/Oを高速化するためのキャッシュ(メモリ領域)を使用します。 本セッションでも説明がありましたが、 典型的なクライアントサーバ型RDBでは、DBサーバ側で統合的にキャッシュを使用しています。 この場合、アプリケーションが必要とする毎にDBサーバへのデータの問合せが行われるため、 システムの規模が大きくなるほどサーバへの負荷が高くなります。

これに対して、ObjectStoreでは、各アプリケーションプロセス側でそれぞれが必要なデータを キャッシュするということでした。これにより、データへのディスクI/Oと、アプリケーションとDBサーバ間 で生じるネットワークのトラフィックを軽減していると説明されていました。 このあたりに「パフォーマンスはむしろいいんだよ」というメッセージが込められていると感じます。

本セッションでは特に、ObjectStoreを使用したシステム内の、 「1.アプリケーションプログラムのメモリ領域」,「2.キャッシュ領域」, 「3.DBのデータ領域」のそれぞれでデータが発生し消滅するタイミングについて、 何枚ものスライドを用いて順を追って説明されていました。 トランザクションのコミット後もキャッシュ領域にオブジェクトが保持し続けられ、 次にアクセスされたときに再利用される様子がよく伝わってきました。 また、複数のクライアントプロセスが存在する場合に、トランザクションの一貫性を 保つ仕組みもここで紹介されていました。

一方、Objectivity/DBのキャッシュ分散の仕組みも、本セッションから得られる内容においては 類似しているように思いました。Objectivity/DBでもアプリケーション側でオブジェクトをキャッシュし、 トランザクションのコミット後もキャッシュ内でデータを確保します。 また、「ロックサーバ」というサーバがアプリケーションからオブジェクトへの問合せを 一元的に管理します。このサーバがアプリケーションとプロセス間通信を行いながら オブジェクトへのロックや更新状態を管理しています。この仕組みによって、 トランザクションの一貫性や、DBサーバからの適切なタイミングでのデータ取得に対応しています。

ObjectStoreとObjectivity/DBの明確な比較点は得られなかったものの、 アプリケーション側でデータ操作を行うOODBでは、分散アーキテクチャの実現方法も、 やはりそのOODB製品を特徴づける重要なポイントであると思います。

所感

全体を通して、ObjectStoreの使いやすさとパフォーマンス面の説明に、特に重点を置かれていました。 細かなアーキテクチャやコーディング例などをあえて紹介することで、 これまで全くOODBを使用したことがない人にも、そのメリットが伝わるセッションだったように思います。

本セッションの枠内に限定すると、「モデリングフォーラムでなぜ『データ管理』?」という疑問が残りました。 しかし、より広い文脈で考えると、「一貫したオブジェクト指向によるシステム開発と運用」 という観点でOODBのメリットを捉えることができると思いました。 システムの開発スピードや生産性の向上、そして稼動後の運用コストの削減を求める声はますます高まっています。 このフォーラムのようにSOAやモデリングが注目される1つの理由は、このような声に応えるために、 システムのライフサイクルを通じて一貫した方法論を用いる必要性があるからだと考えます。 そして、どのようなシステムでも、データ管理の問題は避けては通れません。 データ管理を含めた一貫性を考えた時に、OODBを採用するという手段もまた有効である・・・ということを、 多少ひいき目ながら感じました。

最後に、このレポートでは、OODBを既に知っている者として単なるセッション紹介だけではなく、 少し踏み込んでObjectivity/DBとの比較点も紹介させていただきました。 「OODBはよくわからない」という方に、OODBの製品の違いを通して少しでも具体的なイメージを持っていただければ幸いです。
Objectivity/DB については、弊社オージス総研の紹介ページを参照してください。

( 井藤晶子 )

エージェント指向モデリング法を題材とした利用者主導の初期要求分析の味見

羽田 昭裕氏/日本ユニシス株式会社 ビジネスイノベーションオフィス 統括パートナー

この講演では、SOA 時代が進んだ「ちょっと未来」の予想をし、その時代において技術者がすべき仕事を考えました。そして、その解として、i* (アイスター) という要求分析モデリング法を紹介して頂きました。講演では、i* の表記の説明や、事例とその分析例の紹介もありましたが、i* の詳細はウェブサイトや文献等にゆずります。このレポートでは、i* の簡単な紹介とともに、SOA 時代に i* のような方法がどうして有用であるのかという点にしぼって報告したいと思います。

SOA 時代が進み、ソフトウェアがビジネスにすぐに対応できるようになったら…

「SOA 時代が進み、ソフトウェアがビジネスにすぐに対応できるようになる。」---それはどんな時代でしょうか。羽田氏は、そういった時代に、どのような仕事が技術者に求められるようになるのかを問題提起し、そこから初期要求分析とエージェントの必要性を説明されました。

要求水準の変化への対応は現場力の強化が必要

要求水準の変化への対応が最重要に --- 現場力の強化が必要

SOA 時代が進んだ結果、ビジネスプロセスが最適化され、さらにソフトウェアがビジネスにすぐに対応できるようになったら、残る重要課題は何でしょうか。それは市場・顧客等の要求の変化への対応だというのが羽田氏の主張です。要求水準の変化以外にも変化には様々なものがありますが、その他の変化には組織構造改善やプロセス改善で対応できます。

難しいのが要求水準の変化への対応です。そして、この変化に対応するには現場の気づき・仮説検証が必要です。羽田氏はそれを「現場力」と表現されていました。つまり、SOA 時代の変化への対応は、現場力がより重要になってきます。(右図参照)

情報を必要とする人が情報を取れるような手段の提供 --- エージェントが活躍

「情報を提供できる人と、それを必要とする人は違い」ます。その情報ケイパビリティ(*1)ギャップを埋めるため、これまではシステムを拡張して対応してきました。しかし、現場に適切な情報を提供するためには、情報を必要とする人自身に情報ケイパビリティを持たせることが必要です。上述したように「現場力」が重要になってくると、現場を支える情報の提供手段が望まれるからです。そして、「我々技術者がユーザに提供できる解が、エージェント(*2)なのでは?」と、羽田氏は述べられました。

*1 情報ケイパビリティ: 情報を活用できる能力。

*2 エージェント: ここでは、自らその目的に向って動くものとしています。エージェント指向については、オブジェクトの広場: エージェント指向が目指すものを参照して下さい。

現場主導で適切な判断ができる手段の提供 --- 意図を導く思考法

情報を提供する手段があるとき、適切な方向に導く方法と、それが適切かを判断する手段や基準がないと現場は意思決定ができません。そこで、その解として、i* を紹介されました。i* を選択した理由は 3 つあり、1) ビジネスの現場で使われることが多い KJ 法に似ている(*3)こと、2) ゴール指向なので意図が表現できること、3) エージェントと親和性の高いことを挙げられていました。

*3 筆者注: 筆者には KJ 法にも、i* にも明かるくないので、どのあたりが似ているのかは理解できませんでした。

i*とは...

i* は、エージェント指向なアプローチをとって要求分析を行うモデリングフレームワークです。トロント大学で開発されました。これを使って、モデルを作り初期要求分析を行うことができます。i* はゴール指向要求分析法の 1 つなので、分析領域をゴール・アクター・タスク等とその関係でモデリングしてゆきます。

そのときモデリングするのは、改善された状況(To-be モデル)です。i* 自身は現状の問題もイシューも導きません。現状の各利害関係者の「意図」を抽出しておき、そこから導いたゴールを元にモデルを起してゆくのが、i* での分析の流れです。よって、始める前に現状を確認しておく必要があります。

i* の進めかた

では非常に簡単にですが、i* での分析の例を紹介します。

ただし、以下に挙げた例は、i* の説明のため非常に単純化したもので、筆者が考えたものです。講演では、「顧客に配送する商品に不良品があり返品が多い」という事例を分析されていましたが、紙面の都合上、例を変更しました。講演のレポートとしては、例を変えることは適切でないかもしれませんが、ご了承ください。

事前準備: 現状を描く

分析を行う事前準備として、現状をストーリーボードのような形式で、描いておきます。

現状

意図からゴールを導く

状況が描けたら、各利害関係者の「意図」を抽出します。そして、それからゴールを導いてゆきます。例えば、開発部隊がテストチームに「バグ情報は早く知らせて欲しい」と言っている状況から、「バグの情報の早期化」というゴールを導くという具合です。

現状からゴールを導出

ゴール指向で状況を整理する

ゴールが導けたら、状況を整理しモデリングしてゆきます。上の例でいうと下図のようになります。下の例では、「バグの情報を知る」という既存のゴールと今回の分析で発見した「バグの情報の早期化」というゴールの 2 つを書いています。後者のゴールは、ゴールに到達したかどうかを「はっきり」と判断できないのでソフトゴールというものになります。(記法に関しては、GRL のウェブサイトを参照して下さい。)

状況のモデリング結果

ゴールの依存関係から、達成すると効果のあるゴールの仮説を立てる

実際の業務を分析すると、ゴールがたくさん出てきます。それらのゴールには依存関係が当然あります。そのゴールの中から達成すると効果のあるゴールを見つけます。できるだけ、そのアクターだけで解決できるゴールを選ぶのが良いそうです。他のアクターとの依存がある場合でもそれが「情報」であれば、エージェント化できると仮定して、ゴールを選びます。

エージェントを使うことを検討する

最後に、エージェントを使ってゴールを達成できないかを検討します。ゴール指向要求工学では、エージェントはソフトウェアや人などを抽象化した概念だそうです。つまり、達成したいゴールがあり、エージェントを使うことで「情報」が流れ、達成できることをモデルで検証する訳です。

エージェントの適用結果

初期要求分析に i* を使うと...

結局、i* を使うと何がうれしいのでしょうか。まとめてみます。

所感

講演時間の制限(45分)から i* の説明に割かれた時間も多くなかったため、i* の理解を深めることは残念ながらできませんでしたが、要求分析法等の現場力を支える手法の必要性は感じました。i* は KJ 法に近い分析方法で、流動的なものを扱うことができるのだそうです。ここが安定的な振る舞いを記述するのに適しているユースケース法と大きく異なります。また、ポストイットで情報を整理してゆくような感覚で利用できるのが、現場の人向きという感じがしました。

ただ、このような分析手法と、UML やユースケースとはどのようにリンクされてゆくのでしょうか。その点が気になりました。適材適所で良い手法を使うことは、私は賛成の立場です。ただ、この場合は A 手法、あの場合は B 手法を使うという状況は、結局は利用者にとって不便でわかりにくい状態だと感じます。どんな問題にも対処できる巨大な手法は敬遠したいですが、「上流の分析のアウトプットがスムーズに下流の分析のインプットにできる」...そんな状況を期待します。それがあって初めて、SOA 時代の幕開けという気がします。

( 水野正隆 )

参考

企業 IT 部門にとっての UML と反復型プロセスの価値

藤井 智弘氏/日本アイ・ビー・エム株式会社 SDP テクノロジー・エバンジェリスト

タイトルどおり、企業の IT 部門から見た場合の UML と反復型プロセスの価値を考えるセッションでした。しかし、面白いことにユーザ企業の IT 部門からの出席者は少なかったようです。その理由が、このフォーラムの出席者層によるものなのか、ユーザ IT 部門の視点を知りたいエンジニアが多数出席したのかはわかりませんが...私自身は後者です(笑)。

ところで藤井氏は、同様の内容を 3 回程講演で話されているそうです。もともと同じ内容の講演はしないという考えを持っていた藤井氏ですが、UML や反復型プロセスへの誤解が未だ多くあることから、啓蒙活動の必要性を感じ、本内容の講演を続けているそうです。

UML を使わない理由はない --- 時代の要請

藤井氏は、UML を使わない理由はないというスタンスです。それを、UML をとりまく現状を整理することで説明されていました。1 つは、UML がオブジェクト指向に基づく設計表記法として事実上の標準となっていること。もう 1 つは、IT 部門が行う活動に UML が関係するようになったことです。UML の適用分野が拡大した(している)ことで、IT 部門の活動に入り込んできているのです。MDA の登場や UML を使ったビジネスモデリングの関心の高まりが、UML の適用分野拡大の理由です。

UML をとりまく現状
UML をとりまく現状

ビジネスモデリング分野へは、2005 年 6 月の BPMI (*1) と OMG の合併で、より広がってゆくと発表されておられました。

*1 BPMI: Business Process Management Initiative. ビジネスプロセスマネジメントに関する技術の標準化を進めている非営利団体。BPML (Business Process Modeling Language) というビジネスプロセスモデリング言語を発表している。

つまり UML が、1) 事実上の標準なのでオフショア開発をする際には欠かせない存在となっていること、2) ビジネスプロセスモデリング等のエンドユーザも関係する活動に使用されつつあることから、もはや UML を使わない理由はないと結論づけられていました。

反復型プロセスは、ユーザにも価値あり --- それはリスク回収型アプローチ

反復型プロセスは、事前に反復の計画を立て、反復毎にアーキテクチャのリスクを減らすリスク回収型のプロセスです。しかし世間には、「ちょっと作っては見てもらう、またちょっと作っては見てもらう」やりかたを反復型プロセスだとする誤解が広まっていると、藤井氏は主張されていました。ありがちな誤解に下記の 4 つを挙げられていましたが、納得です。

そして、汎用性・拡張性のキモはアーキテクチャにあるとし、アーキテクチャのリスクを減らしてゆく反復型プロセスの有用性を説いておられました。

汎用性・拡張性のキモがアーキテクチャにあることは、ステレオ機器を例にわかりやすく説明されました。ステレオ機器は、音源・アンプ・スピーカ等の様々なコンポーネントの組合せで出来ています。でも、コンポーネントのインターフェースと相互作用(動作)が抽象化されているので、音源が CD であっても DVD であっても、問題なく音源として他の機器に接続できます。そして、インターフェースと相互作用を決定することがアーキテクチャを構築することだと説明されました。我々がステレオ機器を拡張できるのは、しっかりしたアーキテクチャの恩恵だという訳です。

しかし、拡張性のあるアーキテクチャには、インターフェース、構造、相互作用も決定する必要があり、それには様々なリスクがあります。反復は、そのリスクを回収するための良いアプローチなのだということです。

SOA 時代における UML・反復の重要性の高まり

MDA/UML による Business から IT への変換SOA 時代になり、ユーザ IT 部門の UML・反復型プロセスの重要性が高まってきていると話されていました。

UML: "Business to IT" の実現のため

"Business to IT" の実現のためビジネスモデリングの重要性が高まってきているが、ビジネスモデリングはユーザ主導で行わなければなりません。そして、そのモデルは MDA/UML という技術で IT へと変換されます。モデリングの質が IT の差になって現われるのです。

反復型プロセス: 「つなげてみて、つながらないリスク」を減らす

SOA では、コンポーネント同士をネットワークで接続することになりますが、そのリスクの1つとして、ネットワークという遅い通信線の影響が最後のシステム接続時に判明することになります。「つなげてみて、つながらないリスク」を減らすには、しっかりとしたアーキテクチャが必要であり、リスク回収型の反復型プロセスが必要だとのことです。

所感

「もはや、UML や反復型プロセスが良い・悪いを問う時代ではない」というのは、私も同意見です。また、そもそも論として、個別の価値を議論するよりも「その技術で何ができるかを考えなくてはならない」という意見もあるでしょう。しかし、我々ベンダ側が個々のユーザ企業に UML や反復価値の判断材料を十分提供できていたかを考えるとき、現状を見る限りでは、反省の気持ちを感じずにはいられません。OO/UML 等の啓蒙活動など、まだまだ、オブジェクトの広場がしなくてはならないことはあるように感じました。

( 水野正隆 )

参考

ユーザ中心の設計

比嘉 康雄氏/(株)電通国際情報サービス

ユーザから真の要求を引き出す。 多くの開発者の方が苦労されていることではないでしょうか。

このセッションでは、Seasar でおなじみの比嘉さんが、 ユーザから真の要求を引き出すことを目的とした設計手法である User Centered Design(UCD)、日本語では「ユーザ中心の設計」を テーマにした講演をされました。

なぜ仕様変更は発生するかという話(UCD が必要となる背景)から始まり、 UCD とはどんなものか、そして、UCD を実現するためにはどうすればよいか という流れで行われました。

仕様変更が起きるわけ

まず、UCD が必要となる背景として、仕様変更が起きる理由についての話がなされました。

結論を先に書きますが、仕様変更が発生する根本的な原因は、 要求が「見える化」されていない ことです。

要求が「見える化」されることによって、ユーザは要求についてイメージしたり、 理解したりします。こういったイメージや理解が、真の要求に気付くきっかけになります。 しかし、要求が「見える化」されていないと、真の要求に気付くことができず、 その結果、要求についてレビューすることができません。 例えば、単に要求を箇条書きにしたものを提示しても、要求について具体的な イメージができなければ、 その要求が本当に求めているものなのかどうか判断することはできません。 補足としてイメージを書いてみました。


図1 要求が「見える化」されておらず、真の要求がイメージできていない状態

ユーザによるレビューができていないため、要求があいまいな状態のままになってしまい、 システムが稼動する直前になって、仕様変更が発生してしまいます。

UCDとは

ここまでの話で、私は仕様変更が発生する原因と要求の「見える化」が重要であることを 理解することができました。 では、要求の「見える化」のために具体的にどういったことを行えばよいのでしょうか?

冒頭でも記述しましたが、UCD はユーザから真の要求を引き出すことを目的とした設計手法です。 その UCD を実現するために作成するものとして具体的に3つ提示されました。

表1 UCDを実現する三種の神器
名前 概要 見える化の対象
UIモックアップ 本物を創造するのに十分な情報を提供する紙芝居(HTMLやFlashなど) 出来上がったイメージ
操作マニュアル UIをどのように利用するのかをユーザに確認するためのドキュメント(UIモックアップのスクリーンショットに説明を加える) 実際に操作するイメージ
作業手順書 業務の仕様をユーザに確認するためのドキュメント(基本は箇条書き) ユーザの視点での業務の仕様

これらをUCDを実現する三種の神器と呼びます。 三種の神器はすべて「見える化」することを目的にしています。 それぞれ何を「見える化」するかは、「表1 UCDを実現する三種の神器」を参照してください。

三種の神器を作成する目的は、ユーザと開発者が実際に稼働しているところ(ゴール)を具体的に イメージできるようにすることです。補足としてイメージを書いてみました。


図2 要求が「見える化」され、ゴールを具体的にイメージできている状態

三種の神器のポイントと効果

UIモックアップ

UIモックアップ作成のポイントは

です。UIモックアップ作成の目的はユーザの要求を引き出すことなので、 コストをかけず、シンプルに作ることが大切です。 このようにUIモックアップをシンプルにしておくことで、使い捨てではなく、 実際のデザインのスタートポイントとすることにも使用できるとのことです。 例としてWebデザイナに絵コンテとして渡すことなどの使い方が挙げられました。

操作マニュアル

操作マニュアルは、

といった形式でモックアップのスナップショットに対し記述します。 ユーザの視点で作成するため、開発者がユーザの立場で仕様を考えることが できるようになるという効果があるようです。

作業手順書

以下の2つの問いかけを開発者が自分に問いかけながら作成することが ポイントとしてあがっていました。

私の考えになりますが、これらの問いかけを行う目的は、 1点目については、開発者が業務についてユーザの立場で仕様を考えることが できる効果があると思います。 2点目はゴールを先に考える、つまり逆向きに考えるということですが、 何のための手順であるかを先に明確にすることで、手順に矛盾や無駄が入らないようにする 効果があると思います。

所感

事前登録の早い段階から満席になっていた人気のセッションだけあって、 100人程度収容可能な会場は満員でした。 また、他のセッションと比べて、質疑応答の時間を多くもうけていた(15分から20分ぐらい あったかと思います)のが印象的でした。

セッションの参加前は、UCDというと扱う範囲が幅広く、漠然とした内容になってしまうと 思っていました。しかし、UCDを実現する三種の神器など、 比嘉さんの体験に基づく具体的な方法が示されたことで、 「実際の作業にすぐにでも適用できるのではないか」と思える内容でした。

要求をどのように明確にして、実現するかということに関して私もよく悩みます。 特にユーザビリティなどの非機能要求は、要求があいまいになりがちです。 ユーザの望んでいない、使い勝手の良くないユーザインタフェースが出来てしまうのは、 要求のあいまいさが原因の一つとして挙げられると思います。 ソフトウェア完成後に使い勝手の良くないユーザインタフェースであることがわかると、 極端な話、せっかく作成したソフトウェア自体をユーザに使ってもらえない ということもあるかと思います。 ユーザが本当に望んでいるものを早い段階で明確にすることができれば、このような 問題に対応できると思います。

ゴールのイメージを「見える化」し、ユーザと開発者でゴールのイメージを 共有することが大切だと思いました。

今回「見える化」というキーワードが出てきました。 このトヨタ生産方式の用語が最近ソフトウェア開発に関する記事の中で よく出てきています。その背景には、ソフトウェア開発は要求をはじめとして、 QCD(品質・コスト・納期)やセキュリティの問題など、「見えない」ことが 原因で発生している問題が多いということがあるのだと思います。 「見える化」について考えているときに、画家のパウル・クレーの言葉を思い出しました。 「芸術は、目に見えるものを模写するのではなく、目に見えない人間の内的な世界を見えるようにするものだ」。 本当に大切なことがいつも見えているとは限りません。むしろ見えないことの方が多いのかもしれません。 それをどのように「見える化」するか、これからのソフトウェア開発の課題だと思っています。 「見える化」についてはオブジェクトの広場でも、 「見える化」でソフトウェア開発! というレポートが掲載されていますので、興味ある方は参照してみてください。

( 森稔貴 )

中国におけるオフショア開発の現状と成功のポイントとモデリングの活用

齊藤 肇/日本海隆株式会社 取締役社長

今まさにブームとなりつつあるオフショア開発におけるUML活用の意義と、その際の留意点について、上海交大ハイロン社の経験を基に報告が行われました。

中国におけるオフショア開発のメリットと問題点

中国でのソフトウェアビジネスがなぜ注目されるのか、その理由として以下の3点が挙げられました。

(1)低コストである。

日本向けで、20万/人月〜30万/人月だそうです。

(2)人的資源が豊富で、平均的に技術力が高い。

2004年の大学新入生400万人中、コンピュータ専攻者は6万人、関連専攻者は  15万人に及び、IT専門学校では、毎年10〜20万人の学生がいるそうです。

(3)日本にとっては、中国人のもつ漢字力が強みとなる。

例えば、中国人は6ヶ月のトレーニング、又は実践を通して、日本文部科学省能力検定2級以上の能力を身につけることができるそうです。更に、日本での研修を一年間行えば、打ち合わせができる程の能力を有することが可能だそうです。

以上のようなビジネスの優位性がある一方で、問題点もあります。それは、文化的な差異や語学力の弱さだそうです。これは、開発を進めていく中でのコミュニケーションや仕様の理解、打ち合わせといった場面で大きな障害になるとおっしゃっておられました。

オフショア開発におけるUML活用の意義

前述した問題点を打破する上で、ハイロン社ではUMLの導入を行っています。その狙いとして、下記の三つを挙げられました。

(1)UMLを使用することでコミュニケーションの円滑化を図る。

UMLでシステムの視覚化を行い、それによってコミュニケーションミスを防ぐことを意味します。

(2)オブジェクト指向開発を習得する。

オブジェクト指向言語(Java、C++等)が主流を成す現在において、オブジェクト指向開発は必須であるとの認識によるものです。

(3)コンポーネント開発による開発資産の再利用を促進し、生産性を向上させる。

実際、UMLを使用した同社のソフトウェア技術者の感想の中でも、UMLの活用は

といった点が、UMLを使用する際のメリットとして挙げられていたそうです。

UML開発の課題

しかし、オフショア開発へのUMLの導入は下記のようなデメリット及び課題を抱えているのが現状のようです。

(1)初期投入が高い。

ライセンス購入費用や、UML及び繰り返し開発の教育費用とその時間の捻出が必要であることを意味します。実際、技術者の感想の中で、UMLおよびツールの習得に時間がかかる点がデメリットとして挙げられていました。

(2)日本側の開発手法が統一されていない。

開発プロセスがお客様毎に異なるため、スキル習得の統一化が困難な状況だそうです。

(3)中国オフショア案件におけるUML開発の占める割合が圧倒的に少ない。

それ故、発展途中である中国オフショア企業としてどこまでUMLに投資すればよいかの判断が難しいそうです。また、UMLを習得している熟練技術者は少なく、分析・設計レベルにはまだ達していないのが現状のようです。

(4)繰り返し開発にてオフショア開発を行うUML使用顧客はほとんどいない。

オフショア開発で採用される主なライフサイクルはウォーターフォールで、開発担当分野も下流工程が中心なため、中国側には繰り返し開発の実績がないのが実情のようです。従って、繰り返し開発を採用する場合は、日本側がきちんとプロジェクトの進行管理を行わなければ、開発の効率性が大きく損なわれる場合があると指摘されていました。

オフショア開発にUMLを活用する際の留意点

前述のような課題を踏まえたうえで、今後オフショア開発にUMLを活用し、プロジェクトを成功させる際に留意すべき点について、以下のような提案をされていました。

(1)中国には、分析・設計についての熟練技術者はいない。
(2)繰り返し開発の実績がないので、ウォーターフォールでUMLを使うところからスタートさせる方が良い。
(3)UMLの技術者が本当にいるかどうかは、面接で確認する必要がある。
(4)日本側に自社としてのUMLを活用した開発方法が確立していることが重要である。もし確立されていないのであれば、UMLの活用はしない方が良い。

所感

以前アサインされていたプロジェクトが中国でのオフショア開発を行っており、その際に言葉の壁による仕様伝達の難しさを目の当たりにしました。しかし、お互いの力量をきちんと把握した上で、開発手法やUMLの活用方法に気をつければ、UMLが互いの橋渡しになることが可能であることがわかり、UMLの持つ可能性の大きさを感じました。

( 龍野美羽 )

全体を通じて

冒頭でも書きましたが、このフォーラムは「SOA 時代のビジネスモデリング」がテーマになっていました。やはり、かなりのセッションが「SOA」をキーワードに発表されていました。多くのソフトウェアベンダも自社製品が SOA に対応していることをアピールされていました。SOA がソフトウェア開発のキーになりつつある状況が良くわかりました。

今後 SOA が進むと、ビジネスの分野に IT 分野のモデリング技術がますます浸透するでしょう。そういった状況では、我々が行ってきたソフトウェアのモデリングという行為はユーザ主体になると思います。ただ、そうなるには技術の進展だけでは難しく、啓蒙活動や IT 技術のビジネス分野への歩み寄りも重要です。「良い」と主張するだけでは、相手からみると押し付けと変わらず、理解してもらえません。

例えば、ユーザからみて UML によるモデリングという技術は正しく理解してもらえているのでしょうか。私はまだまだ理解不足の部分があると思っています。また、UML によるビジネスモデリングは現状のビジネスモデリングを置き変えられるものではないと思います。お互いの技術の取り込みや住み分け (=IT 技術のビジネス分野への歩み寄り) も必要でしょう。

SOA 時代が幕開けし、UML や MDA 等の IT 技術を、押し付けるだけにならないような取り組みの必要性が高まるのではないかと感じ、会場を後にしました。

(水野正隆, 2005.10.6)

参考・関連記事

オージス総研がお手伝いできること

当社では「オープンソースのESB、Mule ESBを活用した連携ソリューション」を提供しています。

もしクラウド連携や企業システム連携でお困りの方は当社までご相談下さい。



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

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