ソフトウエアの部品化(コンポーネントの再利用)の流れとオブジェクト指向開発方法論の関係

 ここからはかなり専門的で,しかも最新のトピックの解説に入りますが,本連載で設定している“オブジェクト指向開発方法論がもたらす普通の人々へのメリット”という視点を忘れないにしています。また,これからオブジェクト指向開発方法論を本格的に学習したいと考えている人は,学習教材選択時などの視点設定の参考になると思います。

 なお,コンポーネントに関しては次回以降から,普通の人々の視点で具体的に取り上げます。ここでは,オブジェクト指向開発方法論の変化の中で,コンポーネントが無視できなくなってきている事情を理解してください。

 私はこれまでMicrosoftのCOM/COM+という技術を中心に研究活動し,プログラムを作成したり,開発現場にアドバイスを与えたり,あるいは各方面に記事を書いたりしてきました。このため,かなり頻繁にMicrosoftのWebサイトにアクセスし,同社が開くセミナーにも参加してきました。その過程で気づいたことが1つあります。それは,Windows 2000サービス・パック1を公開した2000年7月前後から,同社はサイトの一部公開情報をこれまでとは異なる方向で更新してきたということです。

 一部の方はご存知でしょうが,MicrosoftはこれまでWindows DNAというマーケティング用語を前面に押し出し,営業活動を展開してきました。しかし,今その用語は過去のものとなっています。現在は,Windows DNAではなく,Microsoft Web Solution Platform(以後MWSPと略記)に名称変更されています(詳細はこちらを参照)。この名称変更を知ったとき,私は次のような疑問を即座にもちました。

“この名称変更は,業界標準オブジェクト指向統合モデリング言語であるUMLの発案企業であるRationalにもなんらかの影響を与えるのではないか?”

図1
 この疑問への回答は図1[拡大表示](詳細はこちら参照)が用意してくれています。

 ご承知のように,MicrosoftとRationalはビジネス・パートナの関係にあります。先に紹介したRumbaugh氏は,次期UMLバージョン2.0の標準化が進行中であることを表明し,次のような文章をWeb公開しています。

The work(UMLバージョン2.0の策定作業) will proceed in two stages with intermediate feedback,with a target completion date of January 2002. I fully expect UML 2.0 to slip to the end of the year. (No,I'm not afraid to make predictions in print. Check back in two years to see if I was correct.)
(私の解釈:UMLバージョン2.0の策定作業は,参加メンバーからのフィードバックを受けながら進行中である。作業完了は2002年1月を予定している。しかしイライラすることに,この作業は2002年の12月までずれ込むことは間違いないだろう。真偽の程は2年後にはっきりするはずである。2年後に私のこの予測が正しいことは証明されるはずである。ムシャクシャするからこの文章を世界に向かって公開する)

 すでに述べたように,UMLは標準化団体であるOMGの場でバージョンアップ作業が行われますから,多くの企業が新バージョン策定作業に参加してきます。この文章は作業の困難さを見事に表現しているのではないかと思います。読み方によっては,かなり感情的であり,イライラが募っている印象を受けます。同氏は,開発プロセス論(オブジェクト指向開発方法論といってもよいでしょう)にも言及し,次のような文章も用意しています。

Another initiative deals with a framework for specifying software development processes. This would provide a standard way to specify a process,such as RUP (Rational Unified Process).
The proponents claim that this would allow organizations using multiple processes to compare them easily. I am skeptical of the value of this -- I think that an organization should pick one process and stick with it -- but,in any case,it is important that RUP be expressible in such a framework,so Rational is participating in this initiative. Philippe Kruchten is the Rational lead on this work.

(私の解釈:ソフトウエア開発プロセスの仕様も策定中である。RUPなどの開発プロセスを作成するための標準指針が準備されることになるだろう。いろいろな提案が行われている。人々は,標準指針があれば複数の開発プロセスを簡単に比較できるから便利だといっている。私はそのような意見に同調したくない。各社は1つの開発プロセスを採用し,それを最後まで利用すべきである。そうはいってもいろいろな考え方があり,私の考えを押し付けることなどできない。ただRUPなどもそうなのだが,開発プロセスはそれぞれの現場で必要に応じて拡張可能なフレームワークにすぎない点だけは忘れないでほしい。当社ではPhilippe Kruchtenが中心となり,この作業に参加している)

 この文章もかなり感情的といえるでしょう。複数のオブジェクト指向開発方法論を比較することには価値がなく,1つの方法論を採用し,自分の開発現場の応じて拡張することが望ましい,と述べています。より具体的にいえば,Rationalが考えているRational Unified Process(RUP)をまず標準として採用し,各社が直面している問題に応じて,柔軟に拡張してほしいと述べています(少なくともこのように解釈可能)。しかし,この主張は以下のような事情により複雑化しています(詳細はこちら参照)。

図2
 図2[拡大表示]では,RationalのRational Unified Process(RUP)とMicrosoftのMicrosoft Solutions Framework(MSF:詳細はこちら参照)を統合すると述べ,その統合のメリットを謳いながら,RUPの特徴として次のような項目を挙げています。なお,この記事はPhilippe Kruchten氏が起草しています。

・Develop software iteratively(反復型開発)
反復型は逆戻りを許さない滝(ウォータフォール)型開発作業ではなく,必要に応じて柔軟に逆戻りを可能とする開発プロセス・モデルと考えるとよいでしょう。発注者の視点に立てば,要求追加や要求変更がかなり受け付けられると一般的には考えてよいでしょう。

・Manage requirements(要求管理)
システムが複雑化すればするほど,要求変更管理が必然的に重要になります。

・Use component-based architectures(コンポーネント・アーキテクチャの採用)
これは開発者側の技術力に依存する部分が相当あるのではないかと思います。システムの具体的な組み立てになりますから,普通の人々の視点からは,どのようなコンポーネントが実際に使われるのか見えないことになるでしょう。コンポーネントに関しては,次回以降の連載の中で,普通の人々の視点から,コンポーネントがもたらすメリットを具体的に取り上げます。

・Visually model software(ビジュアル・モデル)
“あいまいな要求”を形あるものにするソフトウエア・ツールを使用することを推奨していると考えるとよいでしょう。

・Continuously verify software quality(品質保証)
完成したシステム製品を納品する直前で品質のテストをするのではなく,必要に応じて開発作業中にテストすることを推奨している,と考えるとよいでしょう。

・Control changes to software(要求変更管理)
インターネットとデータベースという一般的なWebアプリケーションを作成する場合,将来のアクセス件数をある程度予測しておく必要があります。この予測の範囲内でいくつかの変更を行った場合,変更履歴を記録管理しておき,必要に応じてシステムのアップグレードを提案することを述べていると思います。つまり,発注者が納得できる説明を行うためのデータを常に収集するとともに,その過程で自分たちなりのパターンなどを見つけることを唱えているものと思います。

 次に,RUPに統合される側であるMicrosoftの開発プロセスを見てみましょう。先ほどMicrosoftのWindows DNAに代わる新しい用語であるMicrosoft Web Solutions Platform(MWSP)を紹介しましたが,このMWSPはMSFをベースに作成されていると考えられます。MicrosoftのMSF紹介ページには,MSFは1994年から起草開始されたフレームワークであると明示され,このフレームワークが持つプロセス・モデルの内容を一般公開しています。基本的にRUPとそれほど大きく変わるところはないと思われますが,私は次のような文章にちょっとした驚きを禁じ得ませんでした。

・MSFプロセス・モデルは,これまでのプロセス・モデルであるウォータフォール・モデルと最近のプロセス・モデルであるスパイラル・プロセス・モデルを折衷したモデルである。

 現在公開されている多くの開発プロセス論は,基本的にウォータフォール・モデルを後戻りできないモデルとして過小評価している印象を私はもっていましたが,Microsoftはどちらかといえば,ウォータフォール・モデルの利点を積極的に評価しようとしているのです。また,同社はMSFを単なる方法論(メソドロジ)ではないと主張するとともに,現在採用されているメソドロジのいくつかはメインフレーム時代に唱えられたものであり,インターネット時代の現状には柔軟性にかけ有効ではないと主張しています。

今回のまとめ

 今回は,オブジェクト指向開発方法論の現状を,RationalとRumbaugh氏の動きを中心に紹介いたしました。現役開発者の方は,今回紹介した情報を,通常はプログラミング作業に従事しない“普通の人々”の視点から眺てください。発注者の中にはプログラミング言語などを知らない“普通の人々”がいるのが現実です。しかし,RationalとMicrosoftの提唱している開発プセス論では,エンドユーザーのためのソフトウエア開発論が繰り返し主張されています。私は,オブジェクト指向開発方法論のメリットをエンドユーザーに実感してもらうことがその普及の第一歩ではないか,と考えています。

 アラン・クーパーは,その著「コンピュータはむずかしすぎて使えない」(翔泳社)の中で,“ユーザのためのUI(ユーザー・インタフェース)”の必要性を説いています。プログラミング言語を知らない“普通の人々”は,インターネット上でメール交換を行い,ショッピングを楽しみます。これらの“普通の人々”の視点を重視するのがオブジェクト指向開発方法論の原点ではないかと思います。

 次回は,オブジェクト指向開発方法論に必ず登場する“クラス”を,“普通の人々”の視点から取り上げたいと思います。明日またお会いしましょう。