VB研公開ゼミ議事録 VB 6業務アプリはいつまで使えるの？ Vistaでは？ デジタルアドバンテージ　遠藤 孝信 2006/08/30
Page1 Page2 Page3

.NETへ移行するメリットは？ これからのWindows業務アプリケーションのあるべき姿とは？

− ClickOnceによるアプリケーションの配布 −

【小川】　では、2番目の議題に移りたいと思います。大野さんもおっしゃるとおり、.NETに価値がなければ移行する必要はありません。では、移行すると、具体的にどういうメリットがあるのでしょうか？

　例えば、Visual Studio 2005の目玉機能の1つとして、「ClickOnce」があります。これは、オンデマンドでサーバ側からアプリケーションを配布することで、クライアント・アプリケーションのバージョン管理を半自動化するものです。これと似たような目的の機能として、前版のVisual Studio.NET 2003のときには、「ノータッチ・デプロイメント」という機能がありましたが、現実的にはこれは全然「ノータッチ」ではなく、環境設定が煩雑であまり普及しませんでした。新しいClickOnceはどうでしょうか？

【大野】　1回のクリックでアプリケーションを実行できるようになりますので、その意味では本当に「クリック・ワンス」ですね。

【小川】　VB 6では一般的なクライアント／サーバ型のアプリケーションでは、アプリケーションのバージョンアップに伴う配布が大きな問題になることがあります。アプリケーションのバージョンを新しくしたときには、クライアント側のアプリケーションを更新するために配布する必要があるわけですが、特に大規模に展開されたシステムでは、配布に莫大なコストがかかります。

　このため、VB 6ベースの業務アプリケーションを、配布問題を回避できるブラウザ・ベースのWebアプリケーションに移行する動きが一時期、非常に活発化しました。この流れは、VB 6プログラマにとっては、大きな逆風になっていると思います。

　しかし今回のClickOnceの登場により、VB 6プログラマが以前から培ってきたスキルを生かしながら、配布問題を回避し、Windowsアプリケーションならではのリッチなユーザー・インターフェイスを備えた、最新のビジネス・アプリケーションを開発できるようになるのではないかと期待しています。

【鎌田】　そうですね。最新の.NET環境に移行すれば、ClickOnceで配布が容易になるというのは大きなメリットです。しかしこれは、アプリケーションの配布だけではなく、配布後のアプリケーションの稼働についても利点をもたらします。

　これまでのCOMコンポーネントの場合、安定していた環境に別のアプリケーションやコンポーネントをインストールすると、それまで問題なく動いていたアプリケーションが突然動かなくなる場合がありました。これは、追加インストールによって、いままでとは異なるバージョンの共通DLLファイルがコンピュータに上書きインストールされてしまうという、いわゆる“DLL Hell”と呼ばれる問題です。

　しかし、.NETではこれが起こりません。実際グレープシティのサポートの現場でも、.NETが広く使われるようになったころから、アプリケーションが突然動かなくなったとか、配布時にレジストリ登録がうまくいかないといった問い合わせが激減しました。これは.NETの大きなメリットだと感じています。

【大野】　配布問題の回避は、.NETの大きな魅力の1つですね。ClickOnceによって、アプリケーションの配布が容易になることは間違いのない事実です。

　ただし1点注意してほしいのは、ClickOnceはサーバからアプリケーションをダウンロードして実行するので、多数のクライアントが一斉にそれを行うような場合には、ネットワークの帯域やサーバの負荷を考慮する必要があるということです。具体的には、配布専用のサーバを用意する、配布用サーバを増やして負荷分散を行うといった工夫が必要になります。

【小川】　なるほど、アクセス集中に関してはWebアプリケーションの場合と同様の配慮が必要ですね。

− WPFによるリッチなユーザー・インターフェイス −

【小川】　違いがひと目で分かるという分かりやすさも手伝って、Vistaの目玉機能として、ユーザー・インターフェイスの一新が挙げられることが多いようです。皆さんもWebの記事などで、3Dグラフィックスを多用したVistaの画面などをご覧になっているでしょう。

　.NETアプリケーションはWPF（Windows Presentation Foundation）と呼ばれる新しいVistaのアプリケーション・インターフェイスを通して、Vistaの強力なグラフィックス機能を活用できるというメリットがあります。これについてマイクロソフトは、「Vista時代には、業務アプリケーションのユーザー・インターフェイスもガラッと変わり、使い勝手と生産性が大きく向上する」というような主張をしているようです。

　しかし正直なところ、業務アプリケーションで、最新の3Dグラフィックスが本当に必要なのかどうか、質素なGUIでも十分なのではないかと思います。よりリッチなユーザー・インターフェイスが利用可能になるのは歓迎するとしても、本当にそれが業務アプリケーションに直結するメリットとなるのかという点について、懐疑的なプログラマは多いのではないでしょうか。

【鎌田】　業務の種類によって、ケースバイケースだろうと思います。グラフなどを多用して、データをビジュアルに表示するようなものならWPFの表現力は有効でしょう。しかし単純な文字データの表示や、もっぱらフォーム入力を行うといったアプリケーションでは、Vista時代になってもあまり劇的な変化はないだろうと思います。

【小川】　グレープシティでは、Vistaの新機能であるWPFを積極的に使った、新しいインターフェイスのコンポーネントを作成するプランはないのですか？

【鎌田】　ええ。具体的な製品のリリースのプランはまだありませんね。しかしWPFの技術を使って、入力インターフェイスをどのように変えられるか、という研究は始まっています。

　実際、現在のWindowsフォームでは不可能だけれど、WPFなら簡単に実現できるということもあります。例えば、日付の入力フィールドで「16」と入力すると「平成16年」と入力値を補完して表示するようなケースで、「16」の部分の文字の大きさを変えたり、太字にしたり、色を変えたりして目立たせたいときがあります。しかし現状では、基本的にコントロール単位でしかフォントを指定できません。実現方法はありますが、こういったきめ細かな制御は非常に面倒です。

　ところがWPFを用いると、比較的容易にフィールド単位で文字の大きさを変えたり、色を変えたりできます。この例のように、単純な入力アプリケーションでも、WPFのメリットが生きるケースはあると思います。

【小川】　なるほど、そういうことをいまグレープシティでは研究されているんですね。

【鎌田】　はい。実際プロトタイプも作成しており、いままでは実現困難だったことが簡単にできるようになって、面白いと思っています。ただし、WPFを用いたアプリケーションのGUI作成では、基本的にXAML（ザムル）というマークアップ言語を用いることになります。Windowsフォームとはデザイン方法がガラリと変わってしまうため、最初は苦労するかもしれません。

【大野】　XAMLとは、Windowsアプリケーションで、WPFを活用したGUIを記述するためのXMLフォーマットの言語ですね。現状はまだ開発環境がXAMLをサポートしていないので、XAMLのコードを直接手で記述する必要があるのですが、Visual Studioの将来のバージョンでは、XAMLをIDEがサポートし、ビジュアルな開発ができるようになります。またプログラマだけでなく、XAMLベースのGUIをデザイナーが設計できるようにするツールとして、Microsoft Expressionを提供する予定もあります。これらにより、XAMLの取り扱いは現在より大幅に簡単になると思います。

　Vistaでは、現在.NETで使われているWindowsフォームに加えて、WPFを使ったフォームという選択肢が増えると考えていただければよいと思います。Windowsフォームが使えなくなるからWPFに移行する、ということではありません。

　鎌田さんがおっしゃるとおり、従来どおりの簡単なユーザー・インターフェイスで問題ないアプリケーションは当然あると思います。これらを何が何でも、WPFで3D表示にすればよいということではありません。

　しかし例えば、不特定多数の顧客に使っていただくものや、商用アプリケーションなど、使い勝手がほかの商品との差別化につながるような場合には、いままでのWindowsフォームを使って構築するよりも、WPFを使って、より使いやすく、直感的な操作が可能なGUIを開発する価値があるでしょう。

　つまりVistaでは、使いやすいアプリケーションを実装するための選択肢が増えたということです。いままでのWindowsフォームやWebフォームに加えて、従来はゲームなどでしか使われなかった、DirectXによる3D機能を、必要なら業務アプリケーションでも利用可能になったと受け取っていただければよいでしょう。

− .NETアプリケーションのパフォーマンス −

【小川】　一般的な先入観として、フレームワークが高機能な分、.NET対応アプリケーションのパフォーマンスは、以前のものよりも低いのではないか、と考えるプログラマが多いと思います。

【鎌田】　しくみ上、最初の起動には多少のオーバーヘッドがありますが*、それ以降の個別処理に注目すれば、必ずしも.NETアプリケーションが遅いとは思いません。遅い.NETアプリケーションは存在しますが、よく調べると.NET自体が問題なのではなく、単純にアプリケーションの作りが適切でないということも多いようです。一概に.NETが遅い、とはいえないと思います。

* .NETの実行ファイルは、中間言語（IL：Intermediate Language）形式でファイルに保存されており、これが実行時にネイティブ・コードに変換されてアプリケーションが起動することになる。このためアプリケーションの初回起動時には、Windowsフォームが表示されるまでに時間がかかることがある。なお、Ngen.exeコマンドを利用すれば、事前にネイティブ・コードに変換しておくことが可能で、これによりアプリケーションの起動時間を短縮することは可能である。

【小川】　お客さまの声としてはどうですか。

【鎌田】　サポート部門では、特にWebアプリケーションでパフォーマンスの相談を受けることが多いのですが、よく聞いてみると、ほとんどは実装や仕様に原因があります。

【大野】　中間言語（IL）ですので、最初にJITコンパイルで時間がかかるのはある程度仕方ないですね。ただ、起動しただけで、すぐに終了するというアプリケーションはあまりないですよね。通常は、いったん起動したら、しばらくはプログラムの実行を継続するでしょう。

　従って全体的に見れば、起動時の負担が全体に及ぼす影響はわずかだと思います。特に心配なのは、.NETのパフォーマンスを確かめるために、サンプルを作って実行してみるような場合です。この場合には、起動と終了を短時間で繰り返すでしょうから、起動時の負担が過大に見えてしまいます。

INDEX
	VB研公開ゼミ議事録
	VB 6業務アプリはいつまで使えるの？ Vistaでは？
	1．VB 6を使い続けること、.NETに行かないことの何が問題なのか？
	2．.NETへ移行するメリットは？ これからのWindows業務アプリのあるべき姿とは？
	3．新環境のメリットを生かすため、アプリのあるべき姿に向けてどうすればよいのか？

　

「VB研公開ゼミ議事録」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）