![]() |
![]() |
|
Loading
|
@IT > @IT リッチクライアントソリューション カンファレンス II セミナーレポート |
![]() |
|
![]() ![]()
ユーザーニーズはどこにあるのか? という問いに対して、細川氏は「ダム端末に慣れたユーザーにどうやってリッチクライアントを提供するかがポイント」と指摘。コールセンターなど“短時間に大量入力が必要な環境”ではそれに合った操作性が最重要であり、既製品ではまだ要件を満たしていないと分析。今後、このような厳しい条件を満たすことがリッチクライアントに求められると解説し、さらに「カルチャーギャップを理解してもらい、付加価値を認めてもらわなければ現場は納得しない」と語っている。 リッチクライアント導入時のポイントでは、長谷部氏は心理的バリアとして「多人数で利用する場合にクライアント単位の課金はつらい」「C/S→標準HTML→リッチクライアントという流れは“やり直し”と感じてしまい、後ろ向きの開発に見られる」の2点が存在すると指摘。細川氏は「とにかくセキュリティに尽きる」と語った。
ワトコット氏は、欧米で業務に即した形で使われている例を示し、RIAの効果をアピールした。米国のディスカウントストアが、Flexを使ってオンライン販売のWebサイトをRIA化した事例では、チェックアウトのプロセスを簡単にし、操作や入力でヘルプやナビゲート機能を強化したガイデットセリング(ガイド付き販売)を実現した結果、コンバージョンレート(購買率)が50%向上したという。 また、あるコールセンターでは複数システムを1つのインターフェイスからアクセスできる仕組みを作ったが、それ以前に同様の目的で行われたJSPベースのシステムよりもコード行数が30%少なかったという。 ワトコット氏は、「Webはもっと進化する。Web 2.0は、RIAとして現われてくると思っている」と締めくくった。
山形氏の「Biz/Browserを導入する目的は?」という問いに対し、田中氏は「リッチクライアントの導入目的は、操作性をいかによくするかという点に集約される」とした上で、海外ではHTMLで十分という声も多いが、日本ではHTMLは効率が落ちるという声が強く、HTMLシステム普及の障害になっていたと指摘。その上で「Biz/Browserは運用コスト低減し、エンドユーザーの操作性向上を実現する」とした。また田中氏はリッチクライアントの落とし穴として、「凝ったものが作れるために際限なく作リ込んでしまい、コストがかかり過ぎること」を挙げた。 今後の製品の方向性は?という問いに対して、田中氏は「あらためてBiz/Browserの導入の目的はどこにあるのかを考える必要がある」とした。そしてこれまでのソフトウェア開発が機能デザインばかりを考えてきたが、今後は役務に応じてどういうUIが必要となるのかについて考えていくことの必要性を訴えた。
続けて同社ユビキタスプラットフォームグループ ソリューション統括本部 荒井達郎担当部長が登壇、同社のPDAベースのリッチクライアント・ソリューションを紹介した。荒井氏は企業向けPDAの現状について、「携帯電話に比べて入力作業を効率的にできる。さらにPCよりも高セキュリティを実現できるうえ、カスタマイズと携帯性の両立ができる」と優位性を強調する。モバイル業務では、立って快適に入力できること、思考を妨げない応答性能があることなどの条件を挙げ、適したリッチクライアントを選択することで、端末性能を最大限に生かす性能設計が実現できるとした。
伊藤氏は、「従来より企業システムのアーキテクチャについて集中処理か、分散処理か、という議論があった。管理という面では集中型が楽。使い勝手と管理コスト削減を両立させる手軽なリッチクライアント製品として開発した」とFacerLiteを紹介した。 デモを交えて、キーボードオペレーション型システムや紙の帳票デザインをそのまま画面再現できる機能、EclipseプラグインであるFacerLiteDesignerを用いる開発生産性とともに、運用コストの低さやサーバライセンスなど、価格的なアドバンテージをアピールしていた。
Adobe Readerは、サーバ製品群「Adobe LiveCycle」と連携することでアクセスコントロール機能や、暗号化機能、電子署名付与など、さまざまな機能を追加することができる。入力データをリアルタイムで2次元バーコードに反映させることにより、紙資源をデジタル化することも可能。 この機能は好評を得ており、銀行の申し込み用紙や埼玉県庁の申請書などに採用されている。このようにPDFは、「紙と電子プロセスの融合」に強いリッチクライアントであると小島氏は訴えている。
J-Frame Serverは標準Java仕様に準拠して作成おり、サーバサイドで動作する。Java標準のGUI APIである(AWTやSWING)をサーバ側のGUIアプリケーションで動作させることで、HTMLだけでは実現できなかったきめ細やかな操作性を実現している点が特徴だ。舟城氏は「エンタープライズ用途におけるリッチクライアント環境では、J-Frame Serverが最も柔軟性がある」と自信を見せた。
米持氏は、そのほかにもJ2EEと連携できるリッチクライアントは多数あると指摘。それぞれに得意分野/不得意分野があるため、必要に応じて組み合わせれば良いと説明しつつ、「社内向けの多機能なものと、社外向けの軽いものの2つが最低限必要になってくるだろう」と語り講演を締めくくった。
設計での失敗では、アドビの「プロトタイプを作るとユーザーのイメージ以上のものができあがるため、より多くを求められて開発側に高いデザイン力が必要になる」といった例や、マクロメディアの「クライアント側にデータを送り過ぎて処理が遅くなる」などの事例が挙げられた。 レスポンスに関する問題では、アクシスソフトは「サーバとの通信のバランスが必要。常にサーバと通信すると遅くなるが、クライアントに持ちすぎても遅くなる。両者のバランスが取れるように開発するのがポイントだ」と指摘。東芝ソリューションは「キー入力をすべてサーバに送信するので、クライアント-サーバ間の回線が極端に遅い場合には向かない。逆にDBサーバへのアクセスがひんぱんな場合などにはレスポンス向上につながる」といい、ブレインセラーズは「設計次第で解決可能」といった意見が出され、状況に合った製品選び、開発手段の選択の必要性を訴えた。
主催:アイティメディア株式会社
協賛各社(順不同):マクロメディア株式会社、 アクシスソフト株式会社、株式会社日立製作所、 ブレインセラーズ・ドットコム株式会社、 アドビ システムズ株式会社、東芝ソリューション株式会社 日本アイ・ビー・エム株式会社 掲載内容有効期限:2005年3月10日 |
|