[MSDN Mag]
2002年には、業界の大きな流れに関連して「Microsoft.NET」「.NET Web Services」「XML Web Services」といったキーワードが挙げられると思います。また、Visual Studio.NETの最新版のリリースも目前です。そこで、グレープシティ株式会社の新製品のリリーススケジュールやロードマップをお聞きかせいただきたいのですが。
[ファンガー氏]
やはり2002年の当社にとっての一番の大きな課題は、Microsoft.NETとVisual Studio.NETへの各製品の対応です。我々は、.NETに賭けているところが大きく、2002年の製品は.NET一色になるでしょう。とにかくVisual Studio.NET発売と同時にスタートし、2003年にかけて約20製品を順次発売する計画です。ただMicrosoftだからというわけではなくて、.NETは非常に技術的に優れているプラットフォームだと思います。
実際には相当早い時期から、たとえば中国では、企業向けの会計ソフトを出しているのですが、会計ソフトをネットワーク対応で作った場合にはどうなるかといったことを実際にやらせてみて、たくさんの研究を行なってきていました。しかし、今回はMicrosoftもすごいことやったなと考えました。これは今までのVisual Studioや、Visual Basicの16ビットから32ビットの移行といったものとは比べ物にならないくらい凄いことだと思います。それは、パワフルであると同時にシステムの構築がスピーディに行なえるということです。我社も、今までのActive Xなどのコンポーネントでは、業界トップだと自負してますが、.NETでも絶対に乗り遅れないという意気込みで取り組んでいます。現在「InputMan」の.NET対応版の開発が急ピッチで進められています。Visual Studio.NETのリリースと同時期に出そうと考えています。
実際には相当早い時期から、たとえば中国では、企業向けの会計ソフトを出しているのですが、会計ソフトをネットワーク対応で作った場合にはどうなるかといったことを実際にやらせてみて、たくさんの研究を行なってきていました。しかし、今回はMicrosoftもすごいことやったなと考えました。これは今までのVisual Studioや、Visual Basicの16ビットから32ビットの移行といったものとは比べ物にならないくらい凄いことだと思います。それは、パワフルであると同時にシステムの構築がスピーディに行なえるということです。我社も、今までのActive Xなどのコンポーネントでは、業界トップだと自負してますが、.NETでも絶対に乗り遅れないという意気込みで取り組んでいます。現在「InputMan」の.NET対応版の開発が急ピッチで進められています。Visual Studio.NETのリリースと同時期に出そうと考えています。
[MSDN Mag]
しかし、.NETのほかにJavaというものがあります。コンポーネントベンダーとしては、Javaにも力を入れているわけですか?
[ファンガー氏]
Javaは3年ぐらい前から少しずつ取り組んできました。.NETというものがまだ見えてこない頃からです。リスクを軽減するために、少しJavaもやっておいたほうがいいのではないかということで取り組みを始めたわけです。
当初はクライアントサイドのJava Beansコンポーネントだったのですが、やはりなかなか伸びなかった。そして現在、Java事業部という部署で扱っているもののなかで売れている製品は、デバッグ、チューニング、プロファイリングなどのツールなのです。製品ではやはりサーバサイドのものが中心になるでしょう。Javaもここまで実績が出てきましたし、なくなることはないと考えています。もっと伸びるかもしれない。ですから、Javaも一部は続けていく方針です。しかし、我々にとって今最も大きいのは、売り上げでも事業部の人数でも、WindowsプラットフォームベースのActiveXコンポーネントの部隊なのです。そして引き続き、.NETでもそうなるのではないかと考えています。
当初はクライアントサイドのJava Beansコンポーネントだったのですが、やはりなかなか伸びなかった。そして現在、Java事業部という部署で扱っているもののなかで売れている製品は、デバッグ、チューニング、プロファイリングなどのツールなのです。製品ではやはりサーバサイドのものが中心になるでしょう。Javaもここまで実績が出てきましたし、なくなることはないと考えています。もっと伸びるかもしれない。ですから、Javaも一部は続けていく方針です。しかし、我々にとって今最も大きいのは、売り上げでも事業部の人数でも、WindowsプラットフォームベースのActiveXコンポーネントの部隊なのです。そして引き続き、.NETでもそうなるのではないかと考えています。
[MSDN Mag]
業界の動きを見て、話を伺ったりすると、システムを一括で請け負った場合などの特徴として、納期が相当短くなっていると聞きます。納期が短くなるということは、コンポーネントが今後もっと使われるようになるのではないかと思います。これまで打ち合わせを行ない仕様書を書いていたくらいの時間で、開発を終わらせて納めなければならない。社内で作れる人間はいるけれど時間はかかる。そこでコンポーネントビルダーから仕入れて、それを使って構築したシステムを納めるというのが効率のいいやり方だと聞きました。不景気になって、コンポーネントを使ったプログラミングスタイルが、流行るという言い方は皮肉ですが、スタイルを移行しなければならなくなったというのが、逆にグレープシティにとってはラッキーだったと、私はちょっと考えたのですが。
[ファンガー氏]
そのとおりだと思います。納期までのサイクルが、本当に短く早くなって来ています。そしてそのなかで、コンポーネントを利用して開発することのメリットは、ますます大きくなるでしょう。しかし、特に会社によってはソースコードを自分の所で持っていないと安心できないとか、納めたあとにでも、メンテナンスを行なう必要もあります。こういった部分で、どうもサードパーティの製品には不安があると言われるのも事実です。
このようなケースには、今後いろいろな対応をしていかなければなりません。ソースコードを出せる状態に持っていける場合は持っていくとか、最近米国で試みられているように、直接ソースコードを渡すのではなく、第三者がそのソースコードを持っていて、ベンダーが何かの理由で対応できなくなった場合に、第三者のほうからソースコードが入手できて、メンテナンスが可能になるといった方法です。問題は残されてはいるのですが、それを探りながら順番に解決していって、大手のシステムインテグレータやメーカー系の人達などが開発している巨大なシステムや、ミッションクリティカルなシステムなどにも、コンポーネント使っていただきたいと思っています。とにかく短期間で、そしてコストを抑えて納める必要性がますます高くなってきています。それは我々のような、コンポーネントビジネスをやっている会社にとっては非常にいい話です。
このようなケースには、今後いろいろな対応をしていかなければなりません。ソースコードを出せる状態に持っていける場合は持っていくとか、最近米国で試みられているように、直接ソースコードを渡すのではなく、第三者がそのソースコードを持っていて、ベンダーが何かの理由で対応できなくなった場合に、第三者のほうからソースコードが入手できて、メンテナンスが可能になるといった方法です。問題は残されてはいるのですが、それを探りながら順番に解決していって、大手のシステムインテグレータやメーカー系の人達などが開発している巨大なシステムや、ミッションクリティカルなシステムなどにも、コンポーネント使っていただきたいと思っています。とにかく短期間で、そしてコストを抑えて納める必要性がますます高くなってきています。それは我々のような、コンポーネントビジネスをやっている会社にとっては非常にいい話です。
