リッチクライアントはインタラクティブな操作が可能で，表現上の演出をする余地が大きい。自由度が高いだけに，利用者はどのようなユーザー・インタフェース（UI）を実現できるかについてのイメージを持ちづらく，「使い勝手に対する要求は，具体的にモノを見ないとほとんど出てこない」（SIベンダーのクオリテック コンサルティング部 シニア・システムエンジニア 藤原誠氏）という。
しかし，いざモノを見ると，一転して利用者のイメージは広がり，あれもこれもと要求が噴出してしまいがち。「リッチクライアントを利用した開発プロジェクトにとって，最大のリスク要因は使い勝手に関する要求の管理」（日立システムアンドサービス 金融ソリューションサービス部 技師 境丈利氏）である。
つまり，リッチクライアント・プロジェクトの成否は，システム構築の上流工程にあるというわけだ。従来のシステム開発よりも，要求管理や要件定義が重要になる。そこでまず，UIの要求をどのように洗い出し，それらを要件や仕様にどのように反映するかについて，現場のエンジニアの工夫を紹介する。その後，これらの工夫の根底にある方法論を解説しよう。
従来のWebアプリケーションであれば複雑な画面にならないので，画面モックアップ（画面遷移なども行わない簡単なサンプル）を作ることで利用者に完成イメージを伝えることができた。しかしリッチクライアントの場合，「静止した画面モックアップでは，利用時のイメージを利用者と共有できない」（SIベンダーのクラスメソッド 代表取締役 横田聡氏）という問題がある。インタラクティブな操作や演出が利用者に伝わらず，設計者が思い描いている完成イメージと，利用者のそれとのギャップが埋まらない。
工夫1 模型を作って動かす
セカンドファクトリーの東賢氏（シニアエクスペリエンスアーキテクト）は，中央大学のSNS（Social Networking Service）プロトタイプ・システムの開発で，完成イメージのギャップを埋めようと工夫した。
東氏はこのシステムのUIとして，仮想的な三次元空間に学生本人や友人・知人を表す人形を配置するアイデアを考えた。三次元空間に位置する自分との距離感で，友人や知人との親しさを直感的に表現する。人形をクリックすると，その人の情報を参照するメニューを表示するUIである。
最初に手書きのイラストを描いてみたが，メニューが表示される動きや速さはイラストだけでは伝わりにくい。そこで，画用紙でメニューの模型を作り，模型を動かして学校関係者に見せた（図1）。動く様子をビデオで撮影し，要求・要件の補足資料として管理していく。こうした意識のすり合わせを重ねて要件を洗い出し，実際の画面に近いモックアップを作り上げた。
 |
| 図1●イラストや模型でイメージを共有 セカンドファクトリーの東賢氏は，中央大学のSNSプロトタイプ・システムの開発に当たり，イラストや模型を活用した。仮想的な三次元空間に友人や知人を示す人形が点在し，クリックするとその人の情報を参照するためのメニューが表示されるというユーザー・インタフェースを考案。メニューの展開の仕方などを，模型で示した [画像のクリックで拡大表示] |
工夫2 壊しては作る
 |
| 図2●UIをスパイラル開発 大手自動車メーカーの品質管理システムの構築に当たり，SIベンダーのクオリテックはUI部分の開発を先行させた。利用者の要求を確実に反映するため，スパイラル開発にした。ユーザー・インタフェースの仕様が固まりデータ・モデルが確定した後，サーバー側をウォータフォール開発で構築した [画像のクリックで拡大表示] |
高度なアニメーション表現などが不要な業務システム開発では，いきなり“動く”モックアップを作り，それをスクラップ＆ビルドしながら要件を固めるスパイラル開発が有効だ。
ある大手自動車メーカーは，製造・組み立てラインで使う品質管理システムをVisual Basicからリッチクライアントに移行する際，この方法を使った（図2）。
その品質管理システムは，自動車を多角的な視点でとらえることが特徴である。部品一つについても，製造工程から見る場合，部品構成から見る場合，品質管理項目から見る場合――など，いろいろな角度から情報を参照する。例えば，「パワーウインドウ」という部品は，「ガラス窓」「モーター」「ギア」などの部品間の関係を考えながら管理する必要がある。品質階層として，「ドア周り」という見方もすれば，「騒音の侵入口」という見方もする。
「こうした複雑な業務をこなす利用者の完成イメージにマッチするUIを一発で作るのは無理。（利用者のイメージとの）ギャップを埋めるにはトライ＆エラーを繰り返すしかない」と，システム構築を担当したクオリテック社長の福岡博文氏は考えた。
そこで，“動く”モックアップを開発して利用部門に提案し，それを叩き台にして利用者の要求を聞き取り，次のモックアップを作る――というサイクルを4回繰り返した。“動く”モックアップといっても，業務処理までは含まない。見た目や操作性など使い勝手に関する部分のイメージを正確に伝えるだけのものである。
このシステムに用いたリッチクライアント製品は「Curl」である。幸いCurlにはビジュアル開発環境が整っており，作っては壊し，壊しては作る，という手法を採りやすかった。「リッチクライアントの開発ではUIを短時間で作り込めるRAD（Rapid Application Development）ツールが必須と感じた」（クオリテック 藤原氏）。
