事例研究 Javaシステムで.NETテクノロジを採用する理由とは？ 山田 祥寛 2005/03/05
Page1 Page2

.NET Framework採用のポイントは「Officeとの親和性」

　さて、以上のシステム構成をご覧になって、疑問に思われた方もいるかもしれない。

　これだけの規模のJava資産を持てば、当然、追加機能についてもJavaベースで開発したいと考えるのが当然だ。にもかかわらず、あえて今回のアドオンについて、.NET Frameworkを採用した理由とはどのような点にあったのだろう。.NET FrameworkとJavaとの混在には、何かしらの狙いがあったのか。

　「いいえ、実は今回インタビューの打診をいただくまで、『異なるプラットフォームの混在』という感覚はなかった、というのが正直なところです。使いたい機能があって、使えるものを選定していった結果が『混在』という形になったわけで、まずプラットフォーム選択ありきだったわけではありません」と渡辺氏。

　渡辺氏は「プロジェクト評価レビューシート」で.NET Frameworkを採用した理由として「Officeとの親和性」を挙げた。

　「以前、図表を出力するためにJavaアプレットを利用したこともありました。しかし、Javaアプレットには2つの問題がありました。ひとつに、パフォーマンスを十分に発揮できなかった点、もうひとつに意図した印刷レイアウトを実現するのが難しかったという点です。それに比べて、Microsoft Excelならばデータを流し込むだけで図表の作成は特別なコーディングなしでも実現できますし、印刷レイアウトの定義も容易です。クライアントがExcelである場合には、接続性という観点からも、サーバ側にJavaテクノロジを積極的に採用するという選択肢はありえません。クライアントがExcelに決まった時点で、サーバ側は.NET Frameworkに決まったわけです」（渡辺氏）。

　Excelを業務アプリケーションのフロントエンドとして利用する場合、実装には以下の選択肢が考えられる。

• Visual Basic for Applications（以降、VBA）
• Office COMアドイン
• Visual Studio Tools for Office（以降、VSTO）

　VBAは最も簡単な実装手段であるが、ロジック部分をクライアント・サイドに実装しなければならないことから、プログラム改訂時の再配布を考慮すると、今回のように不特定多数のユーザーの利用には適さない。また、Office COMアドインは、Office機能のカスタマイズのために提供されている旧来からの伝統的な手段ではあるが、COMの将来性を考えれば、新規のアプリケーションに採用するメリットは感じられない。

VSTOに関する詳細については、以下の記事を参照いただきたい。 技術解説：Office 2003で変わる業務アプリケーション - .NET Frameworkテクノロジを使ったスマートな展開 - 特集：.NET言語による次世代Officeソリューションの開発　- Visual Studio Tools for Office 概要 -

　以上の理由から最終的に残った選択肢が、VSTOであったわけだ。

　VSTOは.NET Frameworkベースのアーキテクチャであるから、今後の発展性も望めるし、アセンブリ（ライブラリ）自体はサーバ側で管理しているので、再配布の問題も少ない。

Visual Studio Tools for Office採用の課題

　もちろん、VSTOを採用したことで苦労した点も少なくはなかった。

　「最も困ったのが、VSTO関連の資料が少ない点でした。そのため、VBAのリファレンスを参考に『.NET Frameworkではたぶん…』という試行錯誤の繰り返しで、実装を行わなければなりませんでした」と安西氏は語った。

　コード・アクセス・セキュリティ（CAS）設定を配布する方法でも試行錯誤があったという。というのも、NEC社内で展開しているActive Directory構成環境では、グループ・ポリシーによる配布が許可されていなかったためだ。結局は、CASを設定するためのインストーラ（「.msi」ファイル）を配布することで対処したが、現在のバージョンではインストーラ作成時のオプションが乏しく、常に設定が上書きされてしまう。そのため、すでに何かしらの別の設定がされているクライアントにおいては、「.msi」ファイルの実行によって既存の設定が初期化されてしまうという懸念があった。

　「代替策として、コマンドライン・ツールである「caspol.exe」を利用したバッチ・ファイルの作成も検討しましたが、caspol.exeの動作検証に時間を確保するのが難しかったこと、また、いまのところCASの設定を行っているユーザーがほとんどいなかったことから、今回は暫定的に「.msi」配布の形態を採用しました。配布に限らず、CASについては、現時点でリファレンスなどのドキュメントも少ないようです。意図したとおりに機能してくれるかは、とにかく試行錯誤の連続でした」と安西氏。

　またVSTOに限らず、現時点でリッチ・クライアント技術を利用する場合に一般的にいえることだが、利用に際しては、クライアントにあらかじめ必要なソフトウェアをインストールしておかなければならない。例えばVSTOを利用する場合に必要となるのは、Excel 2003や.NET Framework再頒布可能パッケージだ。セットアップ・マニュアルは事前に配布していたものの、Excel 2003のインストール・オプション設定回りの解説や.NET Framework再頒布可能パッケージのセットアップ・プログラムの配布には苦慮したという。

　リッチ・クライアントは、いわゆる「ファット・クライアント」とは異なり、アプリケーション個々の配布こそ不要である。しかしWebブラウザ（シン・クライアント）との相違点は、リッチ・クライアントを利用するための基本ソフトウェアの導入が不可欠という点だ。今後、新たなクライアント環境の選択肢として「リッチ・クライアント」の存在感が増してくることは予想されるが、導入／運用に当たって、このような問題点を認識しておくことは重要だろう。

今後の.NETに対する取り組み

　Pegasus開発チームにとって、今回の.NET Frameworkへの取り組みは大きな試みでもあった。細かな機能面の改善もさることながら、開発チームでは「今回の構築で得た.NETについての技術知識を、部内のほかのメンバーにいかに浸透させる環境を作っていくかが大きな課題」（安西氏）だという。今後、「Pegasusのほかの機能へ.NET開発案件を水平展開させることも検討中」（渡辺氏）とのことで、これまでJava中心の開発を行ってきた開発チームにとっては、ユーザー・ニーズに応えうる要員リソースの確保および教育が最重要の課題のようだ。

　最後に、筆者が今回のインタビューを終えて印象に残ったのは、安西氏の以下の言葉だった。

「これまでのシステム開発では、Javaや.NETといった特定の技術そのものに縛られがちでした。それに対し、今回の機能開発では、『何も意識しないで開発した結果、Javaと.NETが混在した』という点に大きな意味があるように感じます」

　Javaや.NETを対極的なものとして捉えてしまうと、時として、Javaか.NETかという二者択一の議論に陥りがちである。しかし、われわれが置かれている環境は、それほど単純ではない。利用者の目的や置かれた環境、制約条件などに基づいて、そのときどきの適材を選択していく視点が重要なのである。そんな当たり前の事実を、いまさらながらに感じさせられる今回のインタビューであった。

INDEX
	［事例研究］Javaシステムで.NETテクノロジを採用する理由とは？
	1．Javaベースの資材調達システム「Pegasus」
	2．.NET Framework採用のポイントは「Officeとの親和性」

　

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