PR

 「特定のベンダーに強く依存したシステムを構築するのはリスクが大きい」。---少なくとも頭では誰でも理解していることだろう。だが実際は,「○○社のツールは開発生産性が高い」「連携が楽」「大企業だから安心」といった理由でこのリスクが無視され,ベンダー依存のシステムを構築してしまうケースが後を絶たない。

 開発ツールに関する依存性を例にとれば,かつてVisual Basic 6.0やDelphiといったRADツールで開発したシステムのほとんどがこれに相当する。

 米Borland SoftwareがIDE(統合開発環境)部門の売却先を探しているという2006年2月の発表は,このリスクを再認識させてくれた(関連記事)。売却先の企業がDelphiのバージョンアップやサポートを中止したらどうなるのか,と考えたのである。

 実際には,3月に開催されたBorland Developer Conference Tokyo 2006で,Borland SoftwareのDavid Intersimone副社長が「IDE部門の新会社を設立する」と述べたことから,最終的にユーザーが不利益を被らない形で決着する可能性が高い。ただ,2月の発表の時点では,Delphiで組まれたシステムの将来に不安を感じたユーザー企業やDelphi開発者はかなり多かったのではと思う。

 ちなみに,Borland Softwareの名誉のために言うと,DelphiのライバルであったVisual Basic 6.0は,既に2005年3月の時点で通常サポート・フェーズを終了している。Visual Basic .NETに対する互換性も高いとは言えない。これまでのDelphiの状況は,Visual Basicと比べればまだ良かったと言える。

ベンダー独自の言語には不安がある

 構築したシステムが特定ベンダーに依存するといっても,依存の仕方は様々だ。開発ツールに関連する部分では,システム開発に使用したプログラミング言語自体がベンダー独自のものである場合もあれば,ライブラリが独自のものである場合もある。Javaや.NETのような中間言語形式の場合には,仮想マシンやCLR(Common Language Runtime)も含めるべきかもしれない。開発ツール以外も考えるなら,データベース管理システム,ミドルウエア,Webアプリケーション・サーバー,OSと,数え上げればきりがないほどである。

 言語やライブラリがベンダー独自のものである場合,単にIDEの販売やサポートが終了した,というだけでは済まない。IDEのサポートが終了しただけなら,別のIDEに乗り換えれば済む。これに対して,言語やライブラリのサポートが終了した場合には,既存のコードのすべて,もしくはかなりの部分が“不良資産”となることを覚悟しなければならない。メンテナンスのたびに通常よりもはるかにコストがかかるうえ,だましだまし使ってもいつかは一からコードを書き直す必要が生じる。その際のコストは,IDEの使い方を開発者に教育するのとは比較にならないほど大きなものになるはずだ。

 かつてライバル同士とされていたVisual BasicとDelphiは,いずれもプログラミング言語自体が特定ベンダーに依存している開発環境である。Visual BasicはBASIC,DelphiはPASCALをそれぞれ基にしているものの,大掛かりな独自拡張を施した結果,ANSIやISO/IECが策定した標準とはまるで異なる言語になっている。互換性を持つコンパイラをほかのベンダーが出荷していない以上,ベンダーがサポートを中止した時点で既存のコードが不良資産化するのは避けられない。この点は,数多くのベンダー/組織がコンパイラを出しているC/C++などの言語と大きく異なる点である。

 加えて,標準が形骸化すると,バージョンアップの際の拡張や仕様変更に歯止めがなくなるのも問題だ。仕様変更の結果,前バージョン用のコードをコンパイルできない,などということも起こりうる。コンパイル・オプションを指定することで,20年近く前のK&R C(ANSIが標準化する以前のC)時代のコードでもコンパイルできることが多いC/C++コンパイラでは考えられないことである。もちろんC/C++コンパイラにもバージョンごとの非互換性はあるが,Visual Basicなどと比べればその差は非常に小さい。

 ライブラリについてはどうだろうか。VBやDelphiの場合はもちろん,C++の場合でもBorlandのVCL(Visual Component Library)やMicrosoftのMFC(Microsoft Foundation Classes)といったベンダー固有のライブラリを利用していては,ライブラリのサポート中止とともに該当する部分のコードが不良資産となる。サードパーティが販売するActiveXコントロールなどのGUI部品を利用している場合も同様だ。GUI部分は仕方がないにしても,純粋なロジックの記述などでC++の開発者の多くが,できる限りSTL(Standard Template Library)のような標準ライブラリを使おうとすることにはこうした理由がある。もっとも,VCL,MFCはいずれもソースコードが付属しているので,仮にサポートが中止されてもバグ修正くらいなら自分でできる。

システムの寿命を見極めて開発環境を選択する

 では,ベンダー独自のプログラミング言語を採用した開発ツールは使うべきではないのだろうか。記者は,そこまで言うつもりはないし,現実問題としてそれでは言語の選択肢が狭くなりすぎる。

 ここで記者が主張したいのは,こうしたツールを採用する際のリスクを承知したうえで,メリット/デメリットをきちんと判断して開発環境を選択すべきだということである。数年後に一から作り直すことが前提なら,こうしたリスクよりも生産性の高さを重視して開発環境を選ぶ,というのもうなずける。Webアプリケーションの画面周りなどはこれが当てはまる可能性が高い。GUI部分とビジネス・ロジック部分など,システムを分割して考えるのも一つの手である。

 ただ,開発したシステムが当初の計画よりもはるかに長い間使われることは意外に多い。さもなければ,2000年問題などは発生しなかったはずである。開発費が安いといった目先の利益にとらわれて開発環境を選択すると,後で痛い目にあう可能性がある。

 もう1点,オープンな標準さえあれば,ベンダーへの依存性がなくなるわけではないことにも注意が必要だ。たとえ標準化されていても,そのベンダーがサポートを中止したときに,代わりとなるツール/環境がなければ意味がない。この点で,ECMAに始まってISO/IEC,JISまで標準化がなされたとはいえ,本家Microsoft以外のコンパイラが弱いC#には現時点では不安がある。Borland SoftwareのC#統合開発環境も,コンパイラ自体はMicrosoft製だ。

 さらに,標準があってもベンダーがないがしろにするようでは役に立たない。これを防ぐには,ベンダーが標準を遵守するようにユーザーが誘導していくことが大切だ。具体的には,「ベンダーが独自に拡張した機能は,たとえ便利であってもできるだけ使わない」という姿勢を守る必要がある。実際,市販のC/C++コンパイラが生産性向上のために独自の拡張機能を搭載する一方で,ANSIとISO/IECの標準仕様を高いレベルでサポートしているのは,C/C++プログラマの多くがこうした姿勢をとってきたことが大きい。便利な機能をわざわざ使わないなんて,と感じる方がいらっしゃるかもしれないが,長い目で見ればコードのポータビリティのほうが重要なのである。

 このほか,ベンダーが開発環境をサポートし続けるかどうかは,ベンダー自身のポリシーも大きいように思える。ユーザー(開発者)は,ベンダーが将来にわたってサポートし続けるかどうかを推測しつつ開発環境を選択する必要があるだろう。その一方で,ベンダー側も,ユーザーが常にそうした眼で眺めていることを肝に銘じてサポートを実施していただきたいものである。