アプリケーションを開発する場合，開発する側がその開発にかけられる「コスト」という意味で，「リソース（資源）」という言葉がよく使われます。開発マシンやテスト環境を「ハードウエア・リソース」，開発者（の数）を「人的リソース」。言い方は企業などによって異なりますが，限られた資源で開発に臨み，その資源を無駄なく最小化することが開発生産性を高めることになるとされています。
こうした考え方は，Rich Internet Application（RIA）の時代にはどのように変わるのでしょうか。結論からいうと，開発の視点が「開発サイド」から「エンドユーザー」に変わるのを受け，利用者（エンドユーザー）の「資源」も考慮することが重要になってくるでしょう。
ユーザーが面倒だと思うこと
簡単なユーザー・インタフェース（UI）で，こうした「エンドユーザー・リソース」を考えてみましょう。下にあるのは，性別を指定してもらうどこにでもあるUIです。どれが一番便利だと思われるでしょうか。
「A」と「B」の違いは，クリック数の違いにあります。「B」は奥まったところに選択すべき情報があるので，どうしてもワンクリック増えます。多くのユーザーはそれを「面倒だ」と感じるでしょう。「A」と「C」は一見同じように見えますが，クリックできる有効な場所（領域）が違います。「A」はラジオボタンそのものをクリックしなければ選択状態を変更できません。しかし，「C」は「男」や「女」の文字部分をクリックしても，それができます。よくアクセシビリティの考慮すべき項目として紹介されるもので，一般的に“便利”だと思えるものでしょう。
この例では，まだ「開発サイド」と「エンドユーザー・サイド」の関係がよく見えないかもしれません。次の例ではどうでしょうか。
「A」から「C」までの関係は，前述のものと同じです。「D」だけが新たに加わったものです。「D」の違いは，選択肢を整列させたことです。個々の選択肢の長さや内容から，同じグループのものが縦に並ぶように配置されています。その結果，九つある選択肢の認識が早まっていると思います。ブラウザ名とバージョン番号の組み合わせだと理解したなら，実はブラウザは5種類しかないことが，瞬時に「回答者（エンドユーザー）」に伝わっているのではないでしょうか。
この例は，もう一つ大きなことを示唆しています。先ほどの性別の話と異なるのは，選択肢の数です。アプリケーション開発者なら，こうした選択肢の制御は，何らかの形でデータベースから自動的にもってきたいと思うでしょう。そうしたほうが，選択肢に変更があってもいちいち手作業で画面を作る必要がないからです。
その結果，おそらく多くの開発者が「B」の方法でUIを設計するかもしれません。ところが，多くのエンドユーザーが「D」を「答えやすい」と感じるだろうと思うのは前述した通りです。視認性の良さとクリックのしやすさが他よりも高いからです。ここで，開発者の利便性とエンドユーザーの利便性とが，不一致を起こします。
開発者が苦労するか，利用者が苦労するか
こうした矛盾を整理すると，つまるところ「開発者が苦労するか，利用者が苦労するか」という問題に行き着きます。そして，「何のためにこの質問をしているか」と問い直すことで，答えは自ずと見えてきます。基本的には，「設問」は答えてもらうために準備されるものであり，答えやすいことが第一で，準備しやすいかどうかを考慮するべきものではないのです。
もう一歩踏み込んで考えてみましょう。なぜ開発者にとって「B」が作りやすいのでしょうか。それは，「B」以外だと，選択肢が増えれば増えるほど開発者が画面上でのスペース（空間や領域）を考慮しなければならないからです。一方「B」のプルダウン・メニューは，メニューとなる領域が決まってしまえばクリックさせて領域を拡大できるので，開発者はどれくらいの面積をこの設問が占めるのだとか，並びが美しいかどうかなどを考える必要はありません。「B」を選ぶ開発者とそれ以外を選ぶ開発者では，考える量が異なっていると言っても良いかもしれません。
ただし，この例（多くの場合に当てはまりますが）は，そう単純な問題でもありません。確かに「B」はクリック数が増えますが，クリックした後には“整列された情報”が手に入ります。しかも，選択後はその選択肢のみが見えることになります。これを望むユーザーが多いのも事実なのです。したがって，「B」を選ぶ開発者は，次善の策を採っているということも言えるのです。
もう一つ，開発者が手をかけて，ユーザーに答えやすくしている例を見てみます。
この例では，情報の塊を開発者がまとめてからエンドユーザーに選択させています。そのおかげで，エンドユーザーは設問や選択肢を理解する時間を短縮できます。少数が開発し多数の者がそれを利用する状況では，やはり「上流」である作り手が配慮をたくさんすればするほど，「下流」のエンドユーザーが恩恵を受けることになります。これは，その良い例でしょう。
ここまで，RIAの時代と言いながら，HTMLでのごく基本的な情報の選択を例に説明をしてきました。それでも，いくつもの考えるべきポイントがあったと思います。そして，こうした考え方が基本なのだと考えます。RIA的に言えば，マウスの移動距離（連続操作や不慣れな人への配慮），クリックしてからのボタンの反応（ユーザーの選択を明示），アイコンやビデオ映像を用いたナビゲーションなど，もっと多くの「配慮できる場面」が存在します。しかし，小手先のテクニックではなく，どうすれば使いやすく思ってもらえるかを考えながら開発をすること自身が大切なのです。
作り手のことではなく，使い手の気持ちに立っての開発。開発者の「リソース」だけでなく，利用場面での「エンドユーザー・リソース」をできるだけ最小化する配慮。ますます表現が豊かになってくる今，こうした「おもてなし」や「人に優しい」といった観点で，アプリケーションを作っていくことこそが，使われ続けるアプリケーションの根幹になっていくのではないでしょうか。
| 三井 英樹（みつい ひでき） 1963年大阪生まれ。日本DEC，日本総合研究所，野村総合研究所，などを経て，現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と，エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や，RIAコンソーシアム，日刊デジタルクリエイターズ等で活動中。Webサイトとして，深く大きくかかわったのは，Visaモール（Phase1）とJAL（Flash版：簡単窓口モード/クイックモード）など。 |
