リッチ・クライアントの思わぬ落とし穴

Webアプリケーションの普及と限界

ここ10年ほどで、企業システムの多くがWebアプリケーションに移行してきています。それ以前の主流といえば、Visual Basicで開発されたクライアント・アプリケーションをRDBMSに接続するクライアント・サーバー型か、もう少しさかのぼればホスト・コンピュータと端末でした。

Webアプリケーションが主流になってきた理由は、クライアント・サーバー型でネックとなっていた「アプリケーション配布問題」を解決する策として期待されたこと、また、アプリケーション・サーバーの機能／性能／信頼性が、企業の基幹システムを担うに値するほどに向上してきたことがあります。

しかし、これらの理由は、システムを提供する側の理屈に過ぎません。アプリケーションを実際に使う利用者の視点に立てば、Webアプリケーションへの評価は「前のシステムより使いづらい」という悪評がもっぱらでした。

その大きな理由は、Webアプリケーションのユーザー・インタフェースにおいて、HTMLによる表現が前提となってしまっていることです。HTMLは、元来は文書の表現に用いられることを意図した技術であり、インタラクティブなマン・マシン・インタフェースとして用いることには、そもそも無理があったのです。

クライアント・サーバーやホストと端末でできていたこと、例えばフォーカスの遷移と同期した入力チェックや入力補完、修飾キー（CtrlやAlt、Shiftなど）やファンクション・キーの活用、編集可能な表、タブによる1画面内の表示切り替え、周辺機器との連動、といった事柄の多くは、通常のWebアプリケーションでは実現できません。こうした制約があるWebアプリケーションは、業務効率を悪化させたり、使用時にストレスを感じさせたりと、利用者をいらつかせることになっていたのです。

限界を取り払う期待の星「RIA」

今回の事例では、日ごろから利用部門の苦情を聞かされていた情報システム部員のAさんが、その原因であるWebアプリケーションの制約を取り払おうと考えたところから話が始まります。Aさんは、現行システムの保守のために常駐してもらっている、システム会社のBさんに声をかけました。

Aさん「Bさん、最近リッチ・クライアントとかってよく聞くじゃないですか？」

Bさん「あぁ、AjaxとかFlexとか。Google Mapとか、それで作ってるんですよね」

Aさん「そう、それ。今度のプロジェクトではそんな風にやってみたいんですよ。やっぱり今のシステム、使いづらいし」

Bさん「いいですね、私としては個人的に調べてみたことがあるくらいの知識ですが、お手伝いさせてもらえますか？」

Aさん「Bさんに見てもらってる営業管理システムの、商談管理画面でやってみようと思うんですよ。改修依頼もたまってきてるし」

社内で一番立場の強い営業部から毎週のように使い勝手への不満を聞かされているAさんと、新技術に挑戦できるチャンスをもらったBさんの利害関係が一致して、Flexを用いて画面を改修することで話はとんとん拍子に進みました。

現在Webアプリケーションで提供されている商談管理画面を土台に、これまで別画面だった商談履歴を集約して一画面の中で見られるようにするといった改修を加えることを営業部に提案し、プロジェクトがスタートしたのです。

Bさんも、初めて挑戦するFlexアプリケーションでしたが、個人的に調べてみたことがあるというのはだてではなく、手早くプロトタイプを作り、設計／実装を進めていきました。

このプロジェクトのその後は、次ページに続きます。