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

トラブルへの対処「通信頻度を削減せよ」

“重い”原因として「通信頻度が多すぎる」「遅いWebサービスを使っている」いう状況が、おおかた明らかになりました。また、開発用のクライアント・マシンであらためて確認してみたところ、表示が早かった場合であっても、CPUを100％近く使い切ってしまっていました。通信そのものや、レスポンスとして返されたメッセージの処理（得てして処理の重いXMLであったりする）、コンポーネントの表示など、考えてみれば大変な負荷がクライアントにもかかっていたのです。

原因が明らかになってみれば、対処方法も明らかです。まずは通信頻度を減らすことです。遅いWebサービスを使っている機能は、そもそもユーザーからの要求によるものではなく、AさんとBさんが提案して追加した“おまけ”も多かったので、そうした機能については割愛したり、割愛できないものはWebサービスの利用から自前のプログラムに切り替えることにしました。

通信頻度を減らすため、まずは大きく2つの方策を取ることにしました。第1に、1画面に詰め込みすぎた構成要素を削減することです。「1画面であれもこれも同時に見たい」というのは利用者からのよくある要望ですが、実際の使われ方を調べると、たくさんの情報を出していたとしても、すべてを活用している利用者などほとんどいないものです。あらためて表示項目を精査／取捨選択して、優先順位の低いものは別ダイアログに移すなどの改修を行うことにしました。

それでも削れない表示項目は、初期表示時点では表示されていないタブの中身（プルダウンに含まれるマスタ・データなど）を、タブが選択されたタイミングなどで読み込むよう通信のタイミングを遅延させることで、初期表示時の通信頻度を削減します（初期状態で非表示のタブに含まれる入力必須項目に、旧版では入っていたはずのデフォルト値が入らないといったバグに悩まされましたが、最終的には動作させることができました）。

また、最終的にそれでも減らせない通信については、何回かのリクエストに分けて取得していたデータをまとめて取得するFacade（手続きを集約するデザイン・パターン）をサーバー側に設けることで、20リクエストを要していた初期表示が5リクエストで処理できるようになりました。

慎重さとともに、新技術に果敢に挑戦していこう

Bさんは、その後しばらく新技術の採用にこりごりだったようで、一度は挑戦したFlexやAjaxにもあまり触りたがりませんでした。しかし、最終的にリリースし直したアプリケーションはやはり営業部の利用者に大好評で、AさんはBさんにそのことを伝えながら、こんな話をしました。

Aさん「今回は、いろいろと勉強になりましたね。私もちょっと調子に乗っていろいろ詰め込みすぎたけど、もう少しだけ慎重になればよかったね」

Bさん「いやぁ、やっぱり枯れてないものは怖いですよ」

Aさん「そうですねぇ。でも今回のことは、技術が枯れてないというより、我々にノウハウがなかったのと、リリース前のテストを慎重にやらなかったせいじゃないかな。いま振り返って考えれば分かるけど、ああいう作り方をしたらどんどん通信するようになっちゃう、そのことを知ってればそれなりの画面設計をしたよね。便利なWebサービスがいろいろあるから、またそれをBさんが簡単に使いこなしてくれるから、それが楽しくってあんな画面にしちゃったけど、次は、同じことはしないですよね。それに、新しい要素技術を入れれば、当然非機能要件にも影響を与えるんだから、影響範囲のシステム・テストもしなくちゃいけない、ここはうちの部長にも怒られたんですよ」

Bさん「え、C部長に？うわぁごめんなさい、大丈夫かなぁ」

Aさん「いやいや、Bさんが悪いってことじゃなくて、システム・テストはうちの仕事だろう、お前が付いていながらなにやってる、って。新しい技術を採用するなんてことは、うちの会社でもよくあることだ、協力会社さん任せじゃなくて、うちも責任もってやらなきゃいけない、と」

Bさん「・・・・・・」

Aさん「でもね、最後は褒められちゃいましたよ。今回のように、新しい技術を使ってまで利用部門を喜ばせる提案を、システム側からやっていくってのはいいことだ、それがこの仕事の醍醐味（だいごみ）だろう、いい勉強したな、って」

若いBさんは、感動したのか少し涙目になって、その後はまた前向きに、でも慎重に、新技術に取り組むようになったそうです。

本記事のまとめとして伝えたかったことは、AさんとC部長が全部言ってくれました。現在では、新しい要素技術やWebサービスが多く出現しており、すごいことが簡単にできるようになってきています。そうした技術を活用しないのはもったいない、ですが、そこには慎重さも必要です。

本連載はこれで終了です。「技術検証を通じて実装／設計ノウハウを蓄積し、企業システムとしての品質を確保できるプロセスの上で扱う」---。こうした「システム屋のプロフェッショナリズム」があれば、むやみに恐れる必要はないのです。