Ajaxの開発を経験した多くのITエンジニアは,「ちょっとだけ気が利いているというレベルのものにAjaxを使うとよい」とアドバイスする。

 SIベンダーであるオープンストリームの川道司氏(ソフトウェアエンジニアリンググループ システムズアーキテクト)は,処理経過を表す「プログレス・バー」をAjaxで顧客のシステムに実装した(図1)。このシステムでは,WebブラウザからWebサーバーにHTTPでアップロードしたファイルを,Webサーバーがさらに他社のFTP(File Transfer Protocol)サーバーに転送する。以前は,ファイル転送の途中経過が利用者に分からなかった。例えば,ファイル容量が大きくFTPで転送しているうちにHTTPがタイムアウトになっても気付けなかった。

図1●Ajaxを適用することで実現した処理の例
図1●Ajaxを適用することで実現した処理の例
オープンストリームの川道氏は,Webサーバーにアップロードされたファイルを他社のFTPサーバーに転送するシステムの使い勝手を改善するため,処理経過を示す「プログレス・バー」をAjaxで実装した

 そこで,Ajaxを使いファイルの送信状況を200ミリ秒周期で取得した。バーの延びで進捗を表現する小ウインドウをDHTMLで描画し,送信をキャンセルするボタンも設けた。「複雑な処理ではないが,想像した以上に利用者には好評だった」(川道氏)。

 逆にAjaxが向かないのは,「オフライン環境で使いたい場合」(Ajax開発支援ツールのメーカーであるHOWS 技術部 研究員 山本修平氏)や,「豊かな表現や演出を求められている場合」(ゼロベース インタラクション・デザイナー/エンジニア 田中孝太郎氏)だ。こうした要求があるなら,同じリッチクライアント技術でもクライアントにランタイム・ソフトを導入するタイプが向いている。Ajax技術に詳しい日本IBMの米持幸寿氏(コンサルティング・テクノロジー・エバンジェリスト)は,「業務システム開発ではAjaxは最後の手段。ランタイム・ソフトを使用するリッチクライアントでも,ファットクライアントでも,要求を満たせないときに限定して使うべき」という。

 Ajaxはオフライン環境には向かないし,システムの全画面の表現力を高めようとすると,設計・開発・テスト・保守の手間が無視できないほど増大する。日本IBMの米持氏によれば,「工数は(従来のWebシステムと比べて)少なくとも2~3割増しになる」。これはライブラリを利用した場合であり,一から作り込む場合はさらに工数が膨らむだろう。

 工数が増大する理由の一つは,JavaScriptの言語特性にある。スクリプト言語なので,構文エラー,クラス名の書き間違え,ロジックの間違いなど,すべてのエラーが実行時になって表面化する。コンパイル言語より原因の切り分けが面倒になりがちだ。

 Ajaxを利用することで工数が増えることを,システムの利用者や所有者にはなかなか理解してもらえない。「操作性を向上させるためにAjaxの利用を提案しても,コスト増について理解を得られないケースが多い。SI案件でどの程度利用すべきかの判断は難しい」(オープンストリーム 主管システムズアーキテクト 高安厚思氏)という声が多い。システム間連携ツールの「ASTERIA WARP」の管理ツールをAjaxベースで開発したインフォテリアの照沼領氏(第1研究開発部エンジニア)も,ほぼ同意見だ。「数十万人規模の利用者に使ってもらえるサービスか,数百本単位で売るパッケージ・ソフトでなければ,開発にかけたコストを回収できないのではないか」と指摘する。

 では,Ajaxを業務システムに適用することは非現実的かというと,そうとも限らない。JavaScriptを自動生成する「マスカット」や「Eclipse AJAX Tools Framework」などのフレームワークを使うことで活路が生まれる。「できる限りJavaScriptのコードを書かないことが,品質と保守性の底上げにつながる」(日本IBM 米持氏)。この場合は,「HTMLだけのWebシステムと遜色ない工数でAjaxのシステムを構築できるだろう」(マスカットを開発したNTTデータ 木村氏)。