InfoPathはなぜ苦戦したのか？――新バージョンが目指すもの（1/3 ページ）

InfoPath 2007ではSharePointとの連携の強化やVisual Studioとの統合の改善が図られ、企業内開発者にとって同製品はこれまでよりも魅力的な製品となりそうだ。だが、同製品は今後も、フォームベースのアプリケーションを開発するための多数の選択肢の1つに留まるだろう。

[Greg DeMichillie，Directions on Microsoft]

　Microsoftのフォーム作成ソフトウェアの新版「InfoPath 2007」では、Visual StudioやSharePointとの連携が強化され、ブラウザベースのフォームもサポートされるため、企業内開発者にとっては、これまでよりも魅力的な製品となりそうだ。

　これまで、InfoPathがXMLやそのほかの関連文書フォーマットをサポートする点に魅力を感じながらも、Visual Studioなど、Microsoftの主要な開発者向け技術のサポートが不十分であることから、InfoPathに手を出さずにきた開発者も、新版には心を惹かれるだろう。たが、InfoPathは今後も、フォームベースのアプリケーションを開発するための多数の選択肢の1つに留まるだろう。

バージョン2003は目標に達せず

　InfoPathは、フォームとその付随データを記述するための主要な方法としてXMLを用いた電子フォームを設計／入力するためのツールだ。同製品は使い慣れたOfficeライクなインタフェースを提供し、オフラインでのデータ入力をサポートする。オフラインでのデータ入力は、Webベースのフォームでは不可能だ。フォーム設計者はInfoPathを使えば、コードやスクリプトを書かずとも、ユーザーの入力内容の検証など、さまざまなカスタマイズタスクを実行できる。

　ただし、InfoPathはOffice 2003のコンポーネントとして大々的に発表されたにもかかわらず、Microsoftが望んだほどの人気を博するには至っていない。その理由としては、以下のような点が考えられる。

開発者ではなく、インフォメーションワーカーにフォーカスが置かれている
　MicrosoftはInfoPathを「オフィスワーカーが自分のフォームを設計するために用いるツール」と位置付けた。ほとんどすべてのインフォメーションワーカーはフォーム（電子フォームであれ、紙のフォームであれ）を使い慣れているが、電子フォームの設計はどちらかと言えばプログラミングのような作業だ。なぜなら、設計者は「データがバックエンドシステムでどのように表示されるか」といった問題を考慮しなければならないからだ。

　またInfoPathは、かなり使い勝手の良いフォームデザイナーになってはいるものの、XMLの土台となるコードは表示されたままだ。大半のインフォメーションワーカーは、XMLについて少しは知識を持っているにしても、それほど詳しい知識は持ち合わせていないはずだ。

開発者プラットフォームと調和していない
　InfoPathは当初、インフォメーションワーカーをターゲットに据えていたが、XMLを強力にサポートする点が、一部のIT開発者の注目も集めた。だが、そうした開発者は、同製品がVisual Studioや.NET FrameworkといったMicrosoftの主要な開発者向け製品をサポートしていないことを知り、落胆した。

　例えば、多くのInfoPathフォームは開発者がフォーム固有のコードを記述しなくてもカスタマイズできるが、カスタムコードが必要とされる場合、開発者は当初、JScriptやVBScriptなどのスクリプティング言語やCOMをベースとする旧式のプログラミング技術を使わなければならなかった。

　一方で、Microsoftの開発者部門は開発者に対し、.NET Frameworkのほか、C#やVB.NETなどの言語への移行を強く奨励していた。.NET Frameworkと対応言語のサポートは、2004年にInfoPath 2003 SP1がリリースされるまでは提供されなかった。

フォームの設計と使用にはInfoPathが必要
　おそらくInfoPathにとって最も大きな制限事項は、ユーザーがフォームに入力するためには自分のシステムにInfoPathをインストールしておく必要があった点だ。