PR

 リッチクライアントはインタラクティブな操作が可能で,表現上の演出をする余地が大きい。自由度が高いだけに,利用者はどのようなユーザー・インタフェース(UI)を実現できるかについてのイメージを持ちづらく,「使い勝手に対する要求は,具体的にモノを見ないとほとんど出てこない」(SIベンダーのクオリテック コンサルティング部 シニア・システムエンジニア 藤原誠氏)という。

 しかし,いざモノを見ると,一転して利用者のイメージは広がり,あれもこれもと要求が噴出してしまいがち。「リッチクライアントを利用した開発プロジェクトにとって,最大のリスク要因は使い勝手に関する要求の管理」(日立システムアンドサービス 金融ソリューションサービス部 技師 境丈利氏)である。

 つまり,リッチクライアント・プロジェクトの成否は,システム構築の上流工程にあるというわけだ。従来のシステム開発よりも,要求管理や要件定義が重要になる。そこでまず,UIの要求をどのように洗い出し,それらを要件や仕様にどのように反映するかについて,現場のエンジニアの工夫を紹介する。その後,これらの工夫の根底にある方法論を解説しよう。

 従来のWebアプリケーションであれば複雑な画面にならないので,画面モックアップ(画面遷移なども行わない簡単なサンプル)を作ることで利用者に完成イメージを伝えることができた。しかしリッチクライアントの場合,「静止した画面モックアップでは,利用時のイメージを利用者と共有できない」(SIベンダーのクラスメソッド 代表取締役 横田聡氏)という問題がある。インタラクティブな操作や演出が利用者に伝わらず,設計者が思い描いている完成イメージと,利用者のそれとのギャップが埋まらない。

工夫1 模型を作って動かす

 セカンドファクトリーの東賢氏(シニアエクスペリエンスアーキテクト)は,中央大学のSNS(Social Networking Service)プロトタイプ・システムの開発で,完成イメージのギャップを埋めようと工夫した。

 東氏はこのシステムのUIとして,仮想的な三次元空間に学生本人や友人・知人を表す人形を配置するアイデアを考えた。三次元空間に位置する自分との距離感で,友人や知人との親しさを直感的に表現する。人形をクリックすると,その人の情報を参照するメニューを表示するUIである。

 最初に手書きのイラストを描いてみたが,メニューが表示される動きや速さはイラストだけでは伝わりにくい。そこで,画用紙でメニューの模型を作り,模型を動かして学校関係者に見せた(図1)。動く様子をビデオで撮影し,要求・要件の補足資料として管理していく。こうした意識のすり合わせを重ねて要件を洗い出し,実際の画面に近いモックアップを作り上げた。

図1●イラストや模型でイメージを共有
図1●イラストや模型でイメージを共有
セカンドファクトリーの東賢氏は,中央大学のSNSプロトタイプ・システムの開発に当たり,イラストや模型を活用した。仮想的な三次元空間に友人や知人を示す人形が点在し,クリックするとその人の情報を参照するためのメニューが表示されるというユーザー・インタフェースを考案。メニューの展開の仕方などを,模型で示した
[画像のクリックで拡大表示]

工夫2 壊しては作る

図2●UIをスパイラル開発
図2●UIをスパイラル開発
大手自動車メーカーの品質管理システムの構築に当たり,SIベンダーのクオリテックはUI部分の開発を先行させた。利用者の要求を確実に反映するため,スパイラル開発にした。ユーザー・インタフェースの仕様が固まりデータ・モデルが確定した後,サーバー側をウォータフォール開発で構築した
[画像のクリックで拡大表示]

 高度なアニメーション表現などが不要な業務システム開発では,いきなり“動く”モックアップを作り,それをスクラップ&ビルドしながら要件を固めるスパイラル開発が有効だ。

 ある大手自動車メーカーは,製造・組み立てラインで使う品質管理システムをVisual Basicからリッチクライアントに移行する際,この方法を使った(図2)。

 その品質管理システムは,自動車を多角的な視点でとらえることが特徴である。部品一つについても,製造工程から見る場合,部品構成から見る場合,品質管理項目から見る場合――など,いろいろな角度から情報を参照する。例えば,「パワーウインドウ」という部品は,「ガラス窓」「モーター」「ギア」などの部品間の関係を考えながら管理する必要がある。品質階層として,「ドア周り」という見方もすれば,「騒音の侵入口」という見方もする。

 「こうした複雑な業務をこなす利用者の完成イメージにマッチするUIを一発で作るのは無理。(利用者のイメージとの)ギャップを埋めるにはトライ&エラーを繰り返すしかない」と,システム構築を担当したクオリテック社長の福岡博文氏は考えた。

 そこで,“動く”モックアップを開発して利用部門に提案し,それを叩き台にして利用者の要求を聞き取り,次のモックアップを作る――というサイクルを4回繰り返した。“動く”モックアップといっても,業務処理までは含まない。見た目や操作性など使い勝手に関する部分のイメージを正確に伝えるだけのものである。

 このシステムに用いたリッチクライアント製品は「Curl」である。幸いCurlにはビジュアル開発環境が整っており,作っては壊し,壊しては作る,という手法を採りやすかった。「リッチクライアントの開発ではUIを短時間で作り込めるRAD(Rapid Application Development)ツールが必須と感じた」(クオリテック 藤原氏)。