Webサイトの商品購入画面や,インターネット・バンキングの振り込みや残高照会画面にFlashを利用する――。このように,バックエンドのデータベースなどと連携する,Webアプリケーションのフロント・エンドとしてFlashを採用するユーザー企業が増えている。ユーザーの操作性を高めるなどの理由からである。半面,開発に際して注意すべき点も多い。

(吉田 晃=akyoshid@nikkeibp.co.jp)

表1●FlashをWebアプリケーションのフロント・エンドに利用している主なユーザー企業
 Flashといえば,アニメーションを表示するためのツールという色合いが濃かった。それが最近,DBMSなどバックエンドと連動したWebアプリケーションのフロント・エンドとして利用するユーザーが増えている(表1[拡大表示])。「Flashをフロント・エンドに使ったことで顧客から良い評価を得ている」(トレイダーズ証券 執行役員 IT戦略部・マーケティング室 担当 奥山 泰全氏)とFlash導入の効果が出ている。

 Flashを使ったフロント・エンドは,端的にいうと,クライアント/サーバー・システムのクライアント・アプリケーションのような操作性を実現できることに特徴がある。実際,Flashの導入目的として,サイトの使い勝手を向上する,つまりユーザビリティを挙げるユーザー企業が多い。また,デザインやある程度の処理をクライアント側のFlashに任せられるため,サーバーの負荷ややりとりするデータ量を抑えられる点を評価している。それに,プラットフォームに依存しない。

 半面,Flashをフロント・エンドとして利用する上で注意すべき点もある。例えば,チェック・ボックスやスクロール・バーなどのGUI部品を自前で作り込まなければならない,デバッグ環境が貧弱,といった点にユーザー企業は苦労している。

ユーザビリティを高める

 Flashの利用ではまず,“ユーザビリティを高める”という目的がある。

 Flashを使ったデザインやシステム開発などを手がけるセカンドファクトリーは,同社と取引のある企業のユーザー・インタフェースを分析した結果,Webシステムがあまり活用されていなかったという。「データ入力が手間で,入力しない人が多い」(セカンドファクトリー 代表取締役 大関 興治氏)のが理由だった。Webシステムの操作性を高めることが重要というわけだ。

図1●Beauty-Moreの商品購入画面
まず商品カテゴリを選択すると,商品名,概要,価格などを表示する。次に,商品アイコンを画面左のショッピングカートにドラッグ・アンド・ドロップし,購入数量を指定すると,合計金額を計算,画面左に表示する。商品カテゴリを変更しても,画面の再読み込みはしない。

 そこで,同社が手がけたビューティモアのサイト(http://www.beauty-more.com/)の商品購入画面(図1[拡大表示])は,このような点を踏まえて操作性が高まるようにユーザー・インタフェースを設計した。商品を購入したい場合,希望商品のアイコンを画面左上の「ショッピングカート」にドラッグ・アンド・ドロップし,数量を入力するだけでよい。合計金額は自動的に計算され,画面左に表示される。この間,画面の再読み込みは発生しないため,ユーザーはスムーズに商品を選択可能だ。

 HTMLをユーザー・インタフェースに使う場合,例えばECサイトでは,商品選択,購入商品の選択など,ユーザーがあるアクションを起こすと,その都度サーバーから次の画面を送ってもらうことが多い。ソニー銀行は,この画面遷移の際に「ユーザーの思考が止まってしまう」(ソニー銀行 営業企画部 コンテンツ制作Gp サイトディレクター 井出 浩子氏)ことを防ぎたいためFlashを導入した。

 もちろん,Flashが得意とするアニメーションなどの動きのある画面を作れるのも利点の1つだ。ネットイヤーグループは,ソニー銀行の資産運用シミュレーションを実行する「アドバイスエンジン」を開発するうえで,他社のアンケート入力画面を分析した。その結果,「入力に1時間も要する画面があった。最後まで入力してもらうためには楽しさも必要」(ネットイヤーグループ 執行役員 バイスプレジデント 高 京樹氏)だと感じたという。

プラットフォームに依存しない

 技術面で見ると,Flashを導入したポイントは各社とも「プラットフォームに依存しない点」と口をそろえる。

 「Flashはデファクト・スタンダード」(エイベックス ネットワーク 執行役員 eCRM プロジェクト 兼 危機管理担当 松田 徹氏)と言い切るユーザー企業もいる。マクロメディアによると,「98%以上のパソコンおよびMacintoshにFlashのプラグインが導入済み」(マクロメディア 取締役CTO 田中 章雄氏)という。

 HTMLをユーザー・インタフェースにすると,例えばWindowsとMacintosh,NetscapeとInternet Explorerという組み合わせだけでも4通り動作確認が必要になってしまう。エイベックスは「JavaScriptを使ったページを作った場合,ページ作成と同程度の工数が動作確認に必要になる」(松田氏)点を問題視した。

 一方で,プラットフォーム非依存という観点では,選択肢としてJavaアプレットもある。ネットイヤーグループでは,ソニー銀行のアドバイスエンジンの開発時に,FlashのほかにJavaアプレットもプロトタイプを作成,検討した。ただし,Javaアプレットを使い,画面上のアイコンをスムーズにドラッグ・アンド・ドロップするためには「チューニングが必要」(ネットイヤーグループ SIPS事業部 テクニカルストラテジー プリンシパル 西川 忍氏)と考え,Flashを利用している。

 また,Java VMをすべてのOSが標準で搭載していない点を考慮したのがトレイダーズ証券である。「Windows XPにはJava VMが標準搭載されていない。XPの発売後,半年程度でOSの主流になると考え,Javaアプレットの採用は見合わせた」(トレイダーズ証券のシステム構築を担当したイ・システム 開発担当執行役員 藤原 正之氏)。

デザインをFlashに任せ,サーバーとの通信量を減らす

 さらに,従来のクライアント/サーバー・システムと同様に,Flashにデザインを任せ,サーバーとのやり取りはデータのみにする,という実装ができるのも利点だ。ユーザー・インタフェースのHTMLを出力するWebアプリケーションでは,どうしてもサーバー側にクライアントのデザイン部分のロジックを持つ必要がある。そのうえ,データを含むHTMLをクライアントに送信しなければならない。

図2●Flashで開発する上での注意点
主な注意点は(1)GUI部品を自前で作らなければならないほか,デバッガが貧弱,(2)プログラムの管理が煩雑になりがち,(3)Flashのファイル・サイズに注意しないと,ダウンロードに時間がかかってしまう――点である。ただし,最新版Flash MXでは(1)を改善している。

 トレイダーズ証券では,Flashで作成した外国為替取引システム「セービングフォレックス」で,時々刻々と変化する為替相場データをプッシュでユーザーに配信している。Javaサーブレットを使った同社の別システムでは,10秒ごとにリロードする方式を採用している。ただし,その都度,為替相場データ以外に,デザイン・データ(HTML)を読み込む必要があり,通信量が増えるという問題がある。これを防ぐのが目的である。

 同時に,サーバーの処理負荷も減らすことができる。フロント・エンドにHTMLを使う場合,サーバー上の画面遷移プログラムやHTML出力プログラムが実行されるため,サーバーの負荷がどうしてもかかる。こういった画面遷移などの処理をFlashで作ったフロント・エンドに持たせることで,サーバーの負荷を減らすことが可能だ。

開発には注意が必要

 しかし,FlashをWebアプリケーションのフロント・エンドを開発するツールとして見た場合,“弱さ”もある。ユーザー企業は,(1)GUI部品を自前で開発しなければならないなど開発環境が貧弱,(2)ActionScriptで記述したプログラムの管理――といった点に苦労している(図2[拡大表示])。(1)については最新版のFlash MXで改善されているが,Flashで開発するうえではこういった点に注意したい。