バックエンドのシステム設計がRIA成功の第一歩

バックエンドとフロントエンドの疎結合を実現

－そのために、何か手を打っていますか。

疎結合を実現するフレームワークを使っています。基幹系システムでは当たり前になりましたが、その考え方をUI の部分まで広げて展開しています。

少し前になりますが、「Flashを使えばどんなUIも柔軟に構築できます」という謳い文句に飛びついたものの、結局のところ誰もメンテナンスできずお蔵入りしてしまったという話をしばしば耳にしました。

そうした失敗プロジェクトの場合、サーバー側を含めてシステム設計に問題があるケースがほとんどです。特にコンシューマー向けFlashの延長線上で着手してしまった案件は、業務向けのシステムであるにもかかわらず、業務向けではない設計や作り込みをしているケースが多く見られました。悪い意味で、一点ものの設計になっているわけです。

これに対して、クラスメソッドのスタンスは日常品の茶碗を提供していくイメージです。ほとんどの企業では、既存のシステムが存在します。クラスメソッドでは、その既存システムと顧客が実現しようとする将来像の間にあるギャップと課題を調査し、それを解決する方法を「一点もの」としてではなく、情報システム部門の技術者であれば誰でもメンテナンスできることを目指して提供しています。そのために、Javaのフレームワークに加えて、Flashのフレームワークである「Flex」を使っています。

引き継ぎが必要ない優れたUIを目指す

－既存システムの中には長い歴史を持つものもあるので、その場合、設計方法が今とは大きく異なっていたりしませんか。

5～10 年前のクライアント・サーバー（C/S）やその前のダム端末の時代から稼働しているシステムもあるので、特殊な設計手法が使われているケースは少なくありません。例えば、10万件のデータを最初に取得して、それをクライアント側で処理するといった形態は、C/S では一般的でした。ところが、Flashを使う場合には少し勝手が違います。上手に使うには、バックエンドのサーバー側の設計から発想を変える必要があるわけです。

－理想的なUIとはどういったものでしょうか。

私はしばしば「良いUIとは引き継ぎが必要ないもの」と説明しています。業務システムの場合、ボタンを1つ押し間違えることで業務が止まってしまうようでは困ります。そのためには、間違いを少なくするようにUIを工夫するか、もしくはそれを取り消せる仕組み、つまりシステムの特性に合わせた対応が施されたUI である必要があります。

また、慣れを強いるUI は良いものではないでしょう。例えば、新幹線切符の自動券売機のUI 上の問題で、グリーン車のチケットをすぐに買うことができなかったとします。すると、その人は難しい操作に慣れようとするのではなく、次回からは自由席で我慢してしまうでしょう。これは、まさにビジネス機会の損失です。業務の中でも、そうしたUI がないか注意が必要です。

また過剰なUIは、その後のシステム変更の際に融通が利かなくなることもあるので、なるべく避けるべきです。まずは、標準で用意されているコンポーネントでの実現を検討するところからはじめ、シンプルに設計していくことを心がけるべきだと思います。

（聞き手：蒲生 達佳）

• クラスメソッド株式会社 [classmethod.jp] （所属企業のサイト）
• Flex User Group [fxug.net] （設立コミュニティ）