「接続」か、「移植」か

　ガートナーによれば、Visual Basicで作成したプログラムを.NETフレームワークへ移植するには、新規に作成する場合の40－60％のコストがかかるそうだ。トレーニングなどの費用も含んだ数字とはいえ、ひどい話だ。

　具体的なシナリオを考えてみよう。開発に1億円かけたVisual Basicのアプリケーションがあるとする。これからの標準は.NETフレームワークなので、4000万円かけて.NETフレームワークに移植した。トータルでの開発費は1億4000万円となり、4000万円の赤字が発生してしまった。

　どこに問題があって、このような結果になったのだろうか？.NETフレームワークに問題があるのだろうか？

　違う。.NETフレームワークに問題はない。問題は「移植」というアプローチの採用にある。.NETの基本思想は「接続」である。基本思想とは異なる「移植」アプローチを採用したために、コストが増大してしまったのである。

　既存のVisual Basicプログラムを、わざわざ.NETフレームワークに「移植」する必要はない。.NETフレームワークはCOMと接続できる。COMはマイクロソフトのコンポーネント規格で、Visual Basicプログラミングの根幹である。よって、「移植」せずに、新規の.NETフレームワークプログラムと既存のVisual Basicプログラムを「接続」すれば良かったのである。

　先ほどのシナリオを「接続」で作り直してみよう。開発に1億円かけたVisual Basicのアプリケーションがあるとする。このアプリケーションを機能追加するとする。.NETフレームワークとVisual Basicは「接続」できるので、新規部分の開発は.NETフレームワークを使用できる。

　.NETフレームワークによる生産性向上により、従来なら4000万円だった開発費が3000万円となった。「接続」アプローチを採用すれば、結果は1000万円の黒字になるのである。

　もう少し考えてみよう。UNIXで動いている既存資産があるとする。会社の方針で、これからはインフラとしてウィンドウズを使うことが決定したとする。移植の場合は「UNIXからウィンドウズに移植しよう。Javaならウィンドウズでもそのまま動くから良かった」である。

　接続の場合は「新しいプログラムはウィンドウズで作ろう。UNIXで動いている既存アプリケーションの機能が必要になったら、ウィンドウズのプログラムからUNIXのプログラムを呼び出せば良い。.NETならUNIXでも簡単に呼び出せるから良かった」である。

　さて、あなたはどちらのアプローチがより現実的だと考えますか？