コンポーネント部品の普及には再利用が利益を生むビジネスケースの確立が重要
	Grant Larsen 米ラショナルソフトウェア 再利用戦略担当ディレクター 2002/3/21

---

　米ラショナルソフトウェアは、オブジェクト指向技術やコンポーネントベースのソフトウェア開発における業界リーダー的な存在だ。同社で、再利用戦略担当ディレクターを務めるGrant Larsen氏が、「第3回 EJBフォーラム」（EJBコンポーネントに関するコンソーシアム主催）の開催に合わせて来日した。同氏は、UMLの仕様策定に初期から参画した経歴をもつ。現在はソフトウェア再利用のためのコンソーシアム「RAS（Reusable Asset Specification）」で多くの論文を発表し、J2EEや.NETプラットフォーム上におけるソフトウェア部品再利用に関する研究を行っている。今回は、来日中のタイトなスケジュールの合間に、貴重なインタビューの機会を得た。

（聞き手：Java Solution担当 宮下知起／構成：藤本京子）

――以前から業界内でソフトウェア再利用の試みはありましたが、あまりうまくいかなかった原因はどこにあるのでしょう？ 今回は成功するのでしょうか？

　多くの組織に受け入れられる、再利用に合った言語がこれまでなかったのその原因だという意見がありますが、それも事実でしょう。皆が独自の方法で再利用に取り組んできたので、組織間で共有できるものはなく、外部とのコミュニケーションが図れませんでしたから。

　RAS（Reusable Asset Specification）では、組織間で再利用可能な資産を共有できる言語を提供しているのが重要な点です。また、いまJ2EEと.NETという2つのメジャープラットフォームがあります。この両環境でベンダが力を結集して再利用がはかれるようなインフラ作りに取り組んでいることが、以前とは全く異なる状況だといえます。

　他の原因としては、再利用のためのビジネスケース、つまり採算の合う根拠が確立されていなかったこともあげられます。また、企業が再利用を管理するための成熟度がなかったことや、再利用される部品を扱うツールやインフラがそろっていなかったことも原因でしょう。

――ここでいうインフラというのは、J2EEや.NETなどのフレームワークを指しますか？

　 それも含まれますが、むしろここでいうインフラとは、社内の知的資産をどのように再利用可能なパッケージにしていくかという能力のことを指します。再利用可能な部品というものは、実際にそれを活用できる状況を明確にし、またどのように使い、そしてカスタマイズするのかというルールがともなったパッケージになって、はじめて効果を発揮するからです。

“コンポーネントの再利用を実現するためには、再利用が利益を生むというビジネスケースを確立することが重要”

――そういったツールやインフラ、再利用を可能にする組織を実現するためには、一企業だけでなく、多くの企業でそれが実践できるものでなければならないですよね。誰でも実践できるものにするためにはどういった要素が必要なのでしょうか？

　再利用が利益を生むというビジネスケースを確立することが最も大切です。そのためには、再利用可能なものを取り込む費用、パッケージ化する費用などを理解することが重要なのです。また、特定のプロジェクトへのフォーカスと製品全体のフォーカスとのバランスを取ることも大切です。つまり、各プロジェクトのニーズと、製品全体のニーズとを取り持つような、再利用に特化した舞台が必要だと思います。

――日本ではコンポーネントの社外流通の試みが活発になっています。しかし、今までソフトウェアは内部のロジックを隠すことで競争力を保っていたので、社内の部品を外に流通させると企業の価値が下がるという考えもあります。その結果、誰でも作れるような部品しか流通しないのではないかという意見もあります。

　その可能性はありますが、よいコンポーネントというものは、環境に合わせてカスタマイズや拡張ができるので、その拡張性で付加価値を見出せるのではないかと思います。また、再利用は幅が広く、一般市場でコンポーネントを流通させるということのみならず、企業内部で再利用を図るという場合や、特定のチーム間やプロジェクト間での再利用ということも考えられるのです。このような企業内における再利用の価値はかなり高いと思われます。

――日本ではRASはまだあまり聞きなれない言葉なので、詳しく伺いたいのですが。

　RAS(Reusable Asset Specification)とは、ソフトウェアを再利用可能資産として流通させるための枠組みを確立するための業界団体です。このコンソーシアムには4つのセクションがあり、それぞれのセクションでソフトウェア再利用のための議論が展開されています。セクションには「コンポーネントの利用プロセスを示すセクション」「コンポーネントの分類を行うセクション」「ソリューションセクション」「関連コンポーネントのセクション」があります。

　コンポーネントの利用プロセスを示すセクションでは、コンポーネントをどういう場面でどう適用していくかを議論しています。コンポーネントの分類を行うセクションでは、どのような状況でその部品が意味を持ち、再利用を図ることが可能かをまとめています。分類に関しては、金融向けか税務向けかといったビジネス的な分類もあれば、どういうハードウェアやOSを使うのか、どの程度の性能や信頼性が必要なのか、といった技術的な分類もあります。ここで分類されたそれぞれの環境化で、どの部品を適応させるのかを示すのが、先ほど紹介した利用プロセスを示すセクションで行っている議論というわけです。

　ソリューションセクションでは、コンポーネントの具体的な要求条件やコード、テストケースといったものを用意しています。最後に、関連コンポーネントのセクションでは、部品同士の関連性を、共通性や依存性などを元に4種類に分類しています。

　将来的には他のセクションができる可能性もありますが、現段階ではこの4つが大きなセクションとして成り立っています。将来的に考えなくてはいけないのが、再利用の可能性に関する部分でしょう。現在RASのスペックで、成果物としての要件やコード、ドキュメント、テストなど、ある程度の規定はありますが、詳しくは定めていないので、今後そういった規定の必要性も出てくると思います。具体的なコンポーネントのフレームワーク、パターン、Webサービスの概略を作る中で詳細規定が決まってくるでしょう。

　RASの現況は、FedExの問題を解決するのに似ています。FedExは荷物の大きさに規格があり、ラベルを貼る位置も一定で、その中でどれくらいの長さのコンベアベルトが必要なのか、トラックに何個積めて、飛行機に何個積めるのかが簡単に計算できます。FedExのラベルを見れば、それが書類であるか、それ以外のものであるかがある程度分かりますが、詳しくは記述されていません。RASの現状もそれに似ています。中身はまだ詳しくは見えません。

　ある程度中身についてコメントはしていますが、例えば成果物としては要件やコード、ドキュメントやテストを揃えるべきたどというある程度の規定はありますが、それ以上のことはまだ定めていません。しかし今後は、具体的なコンポーネントのフレームワーク、パターン、Webサービスのプロファイルを作る中でそういう詳細規定が決まってくると思います。

――RASで語られているコンポーネントの粒度はどれくらいのものなのでしょうか？

　これは当社の課題でもあります。細かいものから大規模なものまで、広い範囲の粒度のものを扱わなくてはいけないということがわかってきました。会社の投資内容や知的資産というものは、ソフトウェア本体のみならず、ドキュメントやデザインという成果物にも象徴されます。ですので、いろんな種類の成果物を再利用できるようなスペックが必要なのです。再利用可能な成果物としては、例えば要求条件のドキュメントや、デザインモデルなどです。それとは逆に、リファレンスとなるアプリケーションやフレームワークのような大規模なものも再利用できるようにしています。規模の大小に関わらず、どんな場合もまずコンポーネントをよく観察してどういう機能をもつかを理解し、それがどういう状況下で意味をもつかを把握する必要があります。

“再利用技術の標準化と、ツールの成熟のあとに、コンポーネント再利用の普及期がやってくる”

――RASで目指していることが、米国の多くの企業で行われるようになるのは、いつのことになると思われますか？

　なかなかよい質問ですね（笑）。新しい技術が認められて採用されていくパターンというのは、実はある程度決まっています。多くの企業は標準化されない限り、なかなか採用しないと思います。また、その標準を実装しサポートするツールがそろわないと採用したがらない会社も多い。それ以前に、その技術の意味について企業を教育する必要もあります。スペックを策定し、標準化し、それに沿ったツールを作り、その内容を周知させるのには時間がかかるでしょう。UMLも標準として受け入れられ、広く採用されるまでには時間がかかりました。RASに関しても同じことがいえると思います。

――日本はアメリカと違い、企業のシステムはSIベンダが作ることが多く、そのSIベンダに下請け、孫請けがあるという構造をもっています。このようにアメリカとは違った産業構造的な問題があるところに、ソフトウェア再利用という新しいモデルを組み入れるのは難しいのではないでしょうか。

　かえってそういう仕組みのほうが再利用はしやすいのではないでしょうか。トップベンダで全体の枠組みや構造を決めて、各サブベンダが何をするか、上から指示を出すわけですから。むしろSIベンダにとって一番大きな問題は、知的所有権の問題だと思います。例えばSIベンダがある顧客のためにシステムを構築した場合、そこで得た知識やノウハウを次のプロジェクトにも活用できればいいのですが、顧客の知的所有権を活用することができないという倫理的問題が発生します。ある程度の利用は可能と思われますが、その顧客との関係上、一定以上の再利用はできないでしょう。このような課題はありますが、全体的な構造が再利用を阻むものではないと思います。

――日本のエンジニアは昨年あたりからUMLやRUPなどに積極的に取り組み始めた ばかりなのですが、どういう順で習得していけばいいでしょう？

　 開発者なら、まず、ユースケースからアプローチするのがよいでしょう。構造化プログラミングの経験がある開発者なら、要件を決め、分析をし、デザインを決めるといった段階はわかっているので、その知識をオブジェクト指向的な観点から見て学んでみることです。例えば今まで使ってきた要求条件の整理をオブジェクト指向やUMLを使ってどうするのか、解析や設計も今までの方法からUMLやオブジェクト指向を使った方法に変えてみるなどして、既存の知識をオブジェクト指向的な観点から捉え直すといいと思います。オブジェクト指向もソフトウェア工学の基本原則をベースとしていることに変わりはないので、それをデザインや開発に活かし、いかに既存の知識に肉付けしていくかということです。ラショナルソフトウェアのセミナーを受けるというのもいいと思いますよ（笑）。

[関連リンク]
米国ラショナルソフトウェア
Reusable Asset Specification