三井 英樹

 ユーザビリティの優劣を,できあがったアプリケーションやシステムに対して断じることは比較的容易です。誰であれ,自分という「被験者」が必ず一人はいるわけですから,その被験者の感想がそのまま「判断」になり得ます。

 問題は,その判断の妥当性と,作り上げる前に何に注意すれば良いかです。開発フェーズに入る前に何ができるのか,どんな手が打てるのかがわからなければ,エンジニアリングとは呼べません。

やさしさを「視覚化」「操作」「サーバー連携」の視点で考える

 下図は,「人にやさしい」と思わせる挙動をシステムがどう実現できるかを描いたものです。他にも要素としてはあると思いますが,まずは「視覚化」「操作」「サーバー連携」の中にある6項目を考えてみましょう。


アプリケーションが人に優しくなれるポイント

 一般にRIA(Rich Internet Application)が難しいと思われるのは,こうした項目をすべて兼ね備えようと考える傾向があるからかもしれません。ですので,こうした要素が,アプリケーションの種類によってどういった「分布」で必要とされるのかを考えてみます。

 下図は,六つのタイプのアプリケーションによって,上図の要素のどれに力点が置かれているかを模式化したものです。例えばバナー広告では,一般的には操作性やサーバー連携といったものよりは,人目を引くという視覚化の部分が突出しているでしょう(バナーがRIAかどうかの議論はここでは無視します)。

 eラーニング系では,とにかく操作がしやすいことが本命になり,その操作手順と,そのナビゲーション(操作の視覚化)が中心となります。もちろん,その教材がビデオ系のものであれば,サーバー連携の部分にも力点が置かれることになります。


分野別の力点の分布

 一般的にRIAシステムを構築しようとすると,図の「複雑情報処理系」を目指すのが人情(?)です。エンジニアとしても自分の腕を試したいし,どんなことが可能なのかに惹かれがちです。

 しかし,RIAの代表例にありがちな,グリグリ動いたり,画面がニョキッと飛び出したりすること自体は,ユーザーにやさしいわけでもなんでもありません。そうしたほうが,ユーザーにわかりやすいからそうしているだけで,すべてのRIAにそんな機能が必要なわけではないのです。ユーザーの挙動に応じて複雑な動きをするような情報処理が,本当に必要かどうかを吟味する必要があります。

 下表で,もう少し具体的に何に注意すればよいかを考えてみます。

大項目 中項目 小項目
操作性 操作手順(複雑->容易) 従来手法(キー操作/TAB,Fボタン=マウスレス)
プルダウンメニュー等近代的GUI操作
ドラッグ&ドロップ等現代的GUI操作
グラフを直接操作等新しいGUI操作
操作主体(他人->自分) 自己シュミレーション(試行錯誤)
迷わない(専門的知識レスで操作)
印刷 従来手法踏襲
視覚化 操作の視覚化 ノーリフレッシュ画面(操作文脈をロストしない)
自然なウィザード形式
情報の視覚化 数値データの視覚化(グラフ化)
新しい形の情報の視覚化
サーバー連携 転送データ量 サーバーの負荷軽減
クライアント処理 自動計算
セル内の表記統一などフォーマッティング

操作性を向上させるには手順と操作主体に注目する

 まずは,操作性を向上させる方法について。基本的には,操作手順を複雑なものから容易なものに変えるものと,操作主体を他人任せのものから自分で操作できるような自己申告型にする方法があるでしょう。

 前者では,TABキーによる移動操作やファンクション・キーといった,マウスに依存しない方法のサポートがあります。一般的にマウス操作は自由度が高くて楽そうに思われがちですが,操作が慣れてくるようなものについては,キー操作のみで処理できるものの作業効率は高くなります。これは,どちらかというと,大量データ処理の場合です。あるいは,プルダウンメニュー等近代的GUI操作も判断を楽にさせるものでしょう。直感的なドラッグ&ドロップ等現代的GUI操作も,思考そのものを支援しますし,さらにグラフを直接操作等の新しいGUI操作もその流れです。

 後者では,操作主体が他人から自分に向きます。ローン計算などでおなじみの自己シュミレーション(試行錯誤)は,自分の指定がどのような変化を生むのかを目の当たりにするからこそわかりやすく,専門的知識がなくても迷わないという画面構成(あるいはナビゲーション)も操作性を向上させます。

 また図には描きませんでしたが,印刷もわかりやすさを支えます。紙に出して確認する,あるいは持ち歩けるようにする,という従来手法の踏襲は,ある意味で使いやすさを演出する要素と考えるべきでしょう。

操作の“見える化”を考える

 次に,視覚化の項目です。ここにも基本的に二つの大きな要素があります。操作を視覚化する(=操作を“見える”ようにする),情報を見えるようにする,です。

 操作の視覚化では,ノーリフレッシュ画面(操作文脈をロストしない)が上げられます。今まで何をやっていたのか,これから何をやれば良いのかが一目でわかり,サーバーへの転送時の画面が真っ白になる瞬間をなくします。

 自然なウィザード形式も,別のアプローチです。画面のどこかに,どういったステップに分かれて質問がなされて,現時点はどこなのかを表示したりする方法です。どちらの手法も,地図もなく夜道を進まされる登山者を助けるような気持ちが,画面設計時になされているわけです。

 また,情報の視覚化では,数値データの視覚化(グラフ化)と,新しい形の情報の視覚化とがあります。一般的に数字で示される情報を,円グラフや棒グラフ,レーダーチャート等の様々な適切なグラフで表現すると,理解を助けることになります。また,一般的に数字で考えなかったような情報を,あまり予想もしないイメージを使って捉えやすいようにするという手法もあります。

 下記のサイトは,ML(メーリングリスト)での情報のやり取りを,視覚的に表現して,誰がこの情報共有活動の中心にいるのかの理解を促進しています。発言回数が多いほど大きな半径で,受信回数が多いほど中心の近くに「円」が表示されます。つまり,全体の中心に位置する円の人間が,このMLのキーパーソンと呼べるわけです。

サーバーとのやり取りを最小化する

 サーバー連携の分野では,転送データ量とクライアント処理の二つの方向で,ユーザー支援が可能です。まずは,とにかくやり取りするデータ量を最小化するというものです。古典的HTMLのようにページ単位でサーバーとやり取りしていては,ヘッダー部分のように共通部品までも毎回やり取りすることになり,たとえキャッシュを活用したとしても,その通信負荷はユーザーのストレスの遠因になるでしょう。

 クライアント処理としたものは,サーバーとのやり取りをしないで,クライアント側だけで処理を済ませるものを指します。いくつかの項目を入力させて,その合計を自動計算で算出したり,カンマ区切りなどのセル内の表記統一などフォーマッティングを行うことなどです。

まとめ

 落ち着いて考えてみれば,当たり前のことばかりで,古典的HTML開発手法とあまり変わらない部分も多いことにお気づきでしょう。少しだけ,HTMLだけではできない要素が増えていて,それを操作する人間の立場に立って駆使しているだけです。

 でも,この違いがエンドユーザーにとって大きな違いとなって映るのです。使いやすいアプリケーションなのか,そうでないものなのか——。

参考) RIAシステム 構築ガイド 2005年版 ( RIAコンソーシアム )


三井 英樹(みつい ひでき)
1963年大阪生まれ。日本DEC,日本総合研究所,野村総合研究所,などを経て,現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と,エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や,RIAコンソーシアム日刊デジタルクリエイターズ等で活動中。Webサイトとして,深く大きくかかわったのは,Visaモール(Phase1)とJAL(Flash版:簡単窓口モード/クイックモード)など。