今回、定額給付アプリ市場に参戦して気付いたことの一つに、同業他社の製品はほぼ Access ベースで構築されていたということがあります。その理由を考えてみました。
- 業務アプリケーションと言えば C/S 型であるという意識が定着している。
- 業務アプリケーションは画面の高速描画、レスポンス性が重視されており、Web 向きではないと思われている。
- Access の開発者が多い。
- Web の開発者が少ない。（特に業務系）
- 今回のような短納期で Web 開発を行うノウハウがない。
しかし時代は着実に動いています。業務アプリケーションに Web は不向きという考え方はナンセンスです。
- 当社は今回の開発にあたって Wagby で項目を定義したあと、業務ロジックを MySQL のストアドプロシージャとして実装しました。短期開発とサーバ側でのレスポンス性の高さの両方を実現できる手法です。
- Access による開発では、端末数が増えた場合のレスポンスをどこまで吸収しているのか疑問です。mdb ファイルを、ファイルサーバで共有させればいいと簡単に考えている人が多すぎると懸念しています。
- Access で権限管理や内部統制をしっかり作り込んでいる例をあまりみたことがありません。技術的には不可能ではないですが、どうもそういう視点は納期に間に合わないという理由で押しやられている傾向にあります。また、残念ながらこの点を重要な評価項目とみなす人も多くありません。
最後に残るのは「そうはいっても Web は操作性が悪くて...」という指摘でしょうか。
しかしその点も変わろうとしています。Google Chrome を使って Wagby アプリケーションに接続してみると、あまりのレスポンスの良さに驚きます。大量の項目がレイアウトされた業務画面でも、わずか 1 〜 2 秒で描画してしまうため、下手な Access のアプリケーションよりも高速です。新しい Web アプリケーションの時代を感じさせます。
Web の技術が悪かったのではなく、IE 6/7 のレンダリングや JavaScript の処理がいかに遅かったか、これによって Web アプリケーションの地位が不当に下がっていたことを Google Chrome（や Safari, FireFox）は私達に教えてくれました。
この 20 日に、IE 8 正式版が登場しました。期待を込めて、複雑な業務画面（HTMLベース）の表示テストを行ってみました。
実機は Core 2 Duo 2.5GHz がのった Vista Home Basic で、メモリ 2GB です。
IE8 : 10 秒
FireFox：8 秒
Google Chrome：2 秒
という結果でした。
IE8 は正直、これ以上の高速化は難しいと思います。というのも内部で IE7 との互換モードを持たせているため、レンダリング処理については限界でしょう。一方で Google Chrome はさらに高速化すると言っており、FireFox も刺激を受けて高速化を表明しています。Safari は Chrome と同じレンダリングエンジンですから、パフォーマンスはほぼ同じと期待できます。
ということで、これからの Web アプリケーションは Google Chrome/Safari/Fire Fox の登場によって、本格的な業務システムへの採用をためらう理由がなくなってきます。JavaScript の多機能化によって、レスポンスだけでなく、操作性の面でもひけをとりません。ここまでくるのに時間はかかりましたが、Web 技術のさらなる進化は、私達にとって追い風です。
