“コンテキスト(文脈)”という言葉は、一般用語としてもいろいろな意味合いを含んでいてイメージしづらいところがあります。アセットベースド開発におけるコンテキストとは、アセットに関する次のような関連情報を伝えるために設定されます。
コンテキストの違いを明示するのは、それがアセットの性格に対して暗黙の情報を提供するからでもあります。表面的に同種の機能――例えばユーザー認証ー――を提供するモジュールがあったと仮定して、それが「防衛関連のシステム向け」と「一般企業のイントラネット向け」の2つだとしたとき、読者の皆さんは前者の方がよりセキュリティに関して厳しい条件が課せられていると想像されるのではないでしょうか? また、皆さんが金融業界向けのソフトを開発されていると仮定しましょう。利用可能なソフトウェア部品群があって、いま必要としている機能を探そうという場合、同じ金融業界向けのシステムで実績のあるもの(アセット)からまず当たってみるのではないでしょうか?
「必要な機能を持ったアセットを探すためなら、機能の詳細な仕様(APIの説明や外部仕様書など)があればいいじゃないか?」と思われるかもしれません。APIの説明の類は個々のアセットについて確実にその機能性を(限界も含め)表現してくれます。いい換えれば、「APIの説明を参照して必要なアセットとして判断できる」くらい、あらかじめ求められる要件が詳細に理解されている必要があります。開発スケジュールからすると、設計がかなり進んだ時点といえるでしょう。
それに対してアセットベース開発は、スケジュールの早い段階――すなわち、開発するシステムの詳細までは決まっていない段階から“利用できそうなアセット”をリストアップし、それらを再利用するという前提で作業を進め、必要が生じたときにカスタマイズを決断する、という流れになります。コンテキストの使い方の1つに、この最初の候補出しの段階での絞り込みがあります。
これまでのソフトウェア開発を“オーダーメイドの仕立て屋さん”にたとえるとすると、アセットベース開発は「紳士服の○○」のような“吊しの服屋さん”に見立てることができます(図2)。ゼロから寸法をとってデザインを決めるフルオーダーメイドに対して、典型的なスタイル・体型に合わせた“ほぼ完成品”(←これがアセットですね)が用意してあって、その中からあれこれ比較しながら適当なものを選び、最終的には自分に合うよう袖丈を調整する、セミオーダーメイド/レディメイドがアセットベース開発ということになります。
さて、次回は「アセットの付帯情報」の残り2つと、これらのコンセプトの標準規格「Reusable Asset Specification」の概要についてご紹介します。
藤井 智弘(ふじい ともひろ)
日本アイ・ビー・エム株式会社 ソフトウェア事業Rationalテクニカルセールス
ソフト開発ってホントはもっとおもしろかったはず! という思いの下で、“管理管理!”でも“開発者の(行き過ぎた)自由!”でもなく、その程よいバランスこそが解と、啓蒙活動にいそしむ日々。もっとチャレンジしましょうよ!
Copyright © ITmedia, Inc. All Rights Reserved.