これまで，「ソフトウエアの再利用」は期待に反してあまり進まなかった。だがOMGが再利用の標準規格として承認した「RAS」は，この状況を変える可能性を秘めている。ソフトウエア資産の情報をどのような形式で記述し，どのような仕組みで再利用するのかを具体的に解説する。
過去40年におよぶソフトウエア・エンジニアリングの歴史において，ソフトウエアの再利用については数多くの検討・提案がなされてきた。サブルーチンやデータ構造宣言の再利用，コンポーネントやソフトウエア・パターン（以下，パターン），フレームワーク，ドキュメントの再利用など，枚挙に暇がないほどである。
こうした様々なソフトウエア資産を効果的に再利用して進める「アセット・ベースの開発（Asset Based Development）」は，今後ますます重要になる。拡大し続けるソフトウエアの規模に対応するには，もはや必要な工数に応じて労働力を投入する「レイバー・ベースの開発（Labor Based Development）」では限界があるからだ。特に爆発的な勢いで規模が拡大している携帯電話やデジタル家電の組み込みソフトウエアの開発では，レイバー・ベースからアセット・ベースへの移行が不可欠であり，現在はその過渡期にあると言ってよい。
そこで本稿では，再利用の観点からソフトウエア資産の種類や内容，適用分野といった“仕様”を記述するための標準規格「RAS（Reusable Asset Specification)」を解説する。もちろん，RASの登場で即座に広範な再利用が実現する，というわけではないが，有力ベンダーによる支持や，ツールでの操作が容易，といった点から見て，RASは再利用を促進する大きな可能性を秘めている。ソフトウエア開発に携わるITエンジニアはもちろん，多くの読者にとって知る価値があるだろう。
一筋縄にはいかない再利用
まずRASの意義を明確にするために，これまで再利用がなかなか進まなかった要因や，それとRASとの関係を整理しよう。なお以下ではRASでの呼称に従って，コンポーネントやパターン，ドキュメントなど，互いに関連する様々なソフトウエア資産をひとまとめにパッケージ化したものを「アセット」，アセットに含まれる個々のソフトウエア資産を「成果物」と呼ぶことにする。
読者の中には，「アセットの広範な再利用なんて幻想だ」，「再利用しようとしても，技術的にすぐに陳腐化してしまう」などと否定的な意見を持つ方もいるだろう。こうした意見はある面で的を射ているし，筆者も否定するつもりはない。ソフトウエア・エンジニアリングのプラクティスを体系化した書籍として有名な「実践ソフトウェアエンジニアリング」においても，著者のロジャー・S・プレスマン氏は「ソフトウエア産業の潮流はコンポーネント（部品）の組み合わせによる開発に動いているにもかかわらず，ほとんどのソフトウェアはいまだ特注品である」と指摘している。
では，これまで広範な再利用が進まなかったのはなぜか。その要因は大きく分けて4つある（図1）。
|
|
|
図1●ソフトウエアの再利用を促進するRAS RAS（Reusable Asset Specification）は，これまでソフトウエアの再利用を阻害していた要因の多くを解決できると期待されている [画像のクリックで拡大表示] |
まず，アセットの再利用に取り組む「インセンティブ（動機付け）」の欠如である。一般的なシステム開発プロジェクトでは，開発者は納品物の作成に手一杯で，再利用可能なアセットを作成する余裕がない。
第2の要因は，再利用可能なアセットを作成するための「技術」が確立していないことだ。なかでも，広範な再利用を可能にする，的確な「抽象化」の技術が欠かせない。
第3は，アセットに対する信頼感の欠如である。特にアセットそのものに関する情報が乏しい場合は，開発者は安心して再利用することができない。
最後の要因は，アセットを再利用しやすくするための考え方・手順や，再利用可能なアセットの仕様を記述するための「標準規格」がこれまで存在しなかったことだ。標準がなければ，各企業やプロジェクトで再利用可能なアセットの仕様を一から記述しなければならず，膨大な手間とコストがかかる。
こうしたアセット・ベースの開発を阻害する要因を除くためには，様々な取り組みが必要となる。例えば，再利用のための体制作りやプロセス（手順）の策定，仕組み作り（ナレッジマネジメントなど），そして再利用を円滑かつ低コストで実施するための標準の確立だ。これらのうち，最も軽視されがちなのが，最後に挙げた標準への取り組みである。だがRASが登場したことで，再利用可能なアセットの仕様を記述する手間とコストを削減できる可能性が高まり，標準への取り組みにも弾みがつきそうだ。また，RASの規格に従ってアセットの詳細な情報を体系的に管理すれば，信頼感の問題も軽減されるだろう。
もちろん，再利用に対するモチベーションや，的確な抽象化の技術については，RASが登場したからと言って問題が解決するわけではない。ただし，RASの規格に対応したツールが普及して，再利用可能なアセットを作成・管理しやすい環境が整えば，例えばアセットの抽象化レベルの検証や改良を進めるうえで役立つはずだ。
アセットの仕様をXMLで管理
RASはアセットの流通を推進することを目的とする団体「RASコンソーシアム」が策定した。RASコンソーシアムは，米ラショナルソフトウェア（現IBM）が中心となり，米IBM，米マイクロソフト，米コンポーネントソースなどと共同で2000年に設立。2003年10月に，最新の「RAS 2.1版」を標準規格案として標準化団体「OMG」に提出し，2004年5月に承認された（図2）。2.1版の策定は米IBMなど6社が中心になり，米ボーランドや富士通など約20社が支持を表明している。
|
|
|
図2●「RAS 2.1版」の仕様をまとめたドキュメント ソフトウエア再利用の推進を目的とするRASコンソーシアムが規定し，2004年5月にOMGで承認された |
RASは，様々なソフトウエア資産をどのように「アセット」としてパッケージ化するのか，またアセットに関する様々な属性情報をどのように記述するのか，といったことを定めている。アセットの属性情報は最終的に，XMLドキュメントとして管理する。RASの実体は，このXMLドキュメントの構造（タグの名称や属性，タグ同士の親子関係など）を定義した「XMLスキーマ」，およびXMLスキーマをUMLで表記したモデルである。これにより，モデリング機能を備えた開発支援ツールなどを使って，アセットの属性情報を記述したり再利用したりすることはもちろん，アセットの構造そのものを修正して定義することも容易にできるようになる。
具体的なイメージをつかんでいただくため，RASに従って再利用可能なアセットを作成する手順を図3に示した。例えばソースコード，UMLモデル，テストケース，ドキュメントなどの成果物をパッケージ化し，アセットとして再利用できるようにしたいとする。通常は，RASの規格に対応した開発支援ツールなどを使い，作成したいアセットや個々の成果物の属性情報（詳細は後述）を登録して保存する。すると，そのアセットの属性情報を記述したXMLファイル（「マニフェスト・ファイル」と呼ぶ）と，その構造を定義した「XMLスキーマ」が作成される。
|
|
|
図3●RASによる再利用可能なアセットの作成手順 RAS対応の開発支援ツールなどを使って，アセットの属性情報を登録・保存すると，マニフェスト・ファイルが作成される。これと，マニフェスト・ファイルの構造を定義したファイル，および再利用の対象となる成果物（実体はファイル群）をまとめてZIP形式で圧縮する（拡張子は「.ras」となる） [画像のクリックで拡大表示] |
次に，これら2つのファイルと，ソースコードやUMLモデル，テストケースといった個々の成果物のファイルをまとめて，「ZIP形式」で圧縮する。その結果，「.ras」という拡張子を持つ圧縮ファイル（「RASファイル」と呼ぶ）が作成される。このRASファイルが，再利用の対象となるアセットの実体である。
テキスト・エディタなどを使って，マニフェスト・ファイルを手作業で作成することもできる。ただし，ファイル・サイズが大きい場合は，XMLスキーマによる定義とマニフェスト・ファイルのタグセットとの整合性を保つのが困難になる。
作成したRASファイルを再利用する場合も，通常はRASに対応した開発支援ツールを使う。ツールでRASファイルを呼び出し，圧縮ファイルを展開すれば，再利用が可能になる。ツールは，XMLスキーマに従ってマニフェスト・ファイルの内容を自動的に解釈できるので，アセットや個々の成果物に関する属性情報を表示することが可能だ。なお，RASファイルは解凍しなくても，WinZipやPKZipなどの圧縮・解凍ソフトを使えば，アセットの構造（ファイル，ディレクトリ，サブディレクトリ）を見ることができる。
|
