ソフトウェアの標準と部品化 7 /遺産と再生産

前回までは開発手法の話題に回り道をしていた感じでもありますが、部品化や再利用などを検討する時、現在のようにプラットフォームの変化が大きいときに問題となるのは、開発方法と実現手段(コードや言語、プラットフォームやライブラリの選択)です。

プラットフォームは、過去に比較すると集約的になってきているといえるのではないかと思います。

メインフレーム、オフコンやＰＣ、組込みまで視野に入れたとしても、かつてハードウェアメーカーがそれぞれのハード使用、CPU、開発言語を擁するというようなことは無くなり、ローカルな環境はレガシーと呼ばれるほど、種類は収束しているとも言えるのかもしれません……

　　▼レガシーシステム　【legacy system】
　　　　e-words IT用語辞典
http://e-words.jp/w/
E383ACE382ACE382B7E383BCE382B7E382B9E38386E383A0.html

比重の変化

楽器の演奏情報の通信規格にMIDI(Musical Instruments Digital Interface)規格というものがあります。

MIDI規格はコンシューマー分野でのデジタル通信規格としてはメーカー間のコンパチビリティが高く、各種のデジタル通信規格の中でも大成功を収めた規格です。

電子楽器やMIDI関連機器は通信規格に対応し機器パネル面での操作などとは別に送受信による通信制御にも似た機能を実現する必要があります。

CPUを搭載してソフトウェアによって動作する製品が主であるとは言え、製品によっては、パネル面での操作以上データ通信を行うものもあり(単体機能はなくてもMIDIでは制御可能など)、かつての電子楽器のMIDI機能の全体に占める比重が大きい場合もあり、その開発コストは問題にもなっていました。

ところが、製品本体の機能が強化された結果、MIDI部分の全体に占める割合は低下していったため、基本的には変化した部分が無いにも関わらず、あまり重視られなくなりました(経験が生かされたり、開発方法の変化などの要因が大きいですが)。

このような相対的な比重の変化によって、問題が小さくなったかのようにみなされる現象は、ＰＣアプリケーションや他のシステムでも同様です（同じようなコードを何回も書いている人は結構いるのではないかと思います）。

この比重の変化は、ライブラリ化などの検討を行う上でも多少影響を与えます。

かつてと全く同程度の開発コストは掛かっていても、全体から見ると、もはや、比重が小さいことや、参考にできる既存のものや経験があるため再実装してもかまわないという判断が働くことがあります。

プラットフォームが遺産(レガシー)に……

まして、プラットフォームや標準技術が流動的で見極めが難しい場合には、まさに、前提条件が変化している中でのポータビリティを保つという課題をクリアする必要があり、しかも、デファクトスタンダードとなるまでは多分に投機的ですから、ライブラリ化と合わせて２重の投機を行うことになります。

そのリスクを考えると、開発難易度が軽いものは必要に応じて対策した方が良いという考えは間違いではないかもしれません。

レガシー・マイグレーションは、エンタープライズ分野での課題の１つですが、レガシーシステム用のライブラリが生かされることは考えにくいでしょう。

標準的なプラットフォームと考えられていたものが、「遺産」と認識されるようになる前にポーティングするというのが前提だとは思いますが、簡単でローコストに行うことができるのであれば、問題にはしないですね。