「ユーザビリティ」記事の一覧
「利用者の立場を考えたペルソナ／シナリオ法による開発とは」がやはり話題になっていますね。全体的に良い指摘が続く中で、もっとも注目すべき点は以下の部分ではないでしょうか。
ペルソナ／シナリオ法による開発は「シナリオファースト」と呼ぶことができます。最初にペルソナとシナリオを使って仕様をかなり細かいところまで固めて、それを基にしてソフトウェアの仕様を作っていくのです。仕様についてはイテレーションを行うことよりも最初に多くの部分を固めてしまうことを重視するため、ある意味ではウォーターフォールに近い形になります。
世の中の流れに逆らっているのかもしれませんが、まったく同感です。設計段階でもっと使い勝手を詰めるべきでしょう。
システムの設計はどうしても機能ベースや画面ベースで進みがちなので、設計プロセスにユーザーの視点を導入するという意味で、シナリオによる検証は価値があります。それだけでなく、実際の機能とシナリオで要求される機能をマッピングしてみて、機能の漏れがないかどうかを検証できるという面でもシナリオによる検証は必須と言えるでしょう。ただ、業務システムに関しては、厳密なペルソナを設定する必要はないような気がします。「いつ・誰が・（具体的に）どのような業務を行うか」のコンテクストを明確に設定することで、シナリオだけで基本的な使い勝手は検証できるはずです。
それよりも、業務システムに関しては別の問題があります。つまりシナリオによる検証を行うかどうかもさることながら、納期やコストの制約からシナリオ検証の成果を十分に活かすことができない（検証結果を反映すると納期／コストを超過するので、現状で見切り発車する）という、根本的かつ慢性的な問題です。ここをクリアしないと、いくら検証プロセスを導入したところで「システムが使われないのは設計が悪い」（使い勝手的に実業務に負荷となってしまう＝まともに運用できない）から抜けられません。
これは機能の実装と使い勝手（の向上）の実装を分けて考えているために発生する問題ではないでしょうか。そうすると、「機能の実装には使い勝手の実装も含まれる」つまり「機能と使い勝手の実装は不可分である」ことが、発注者／開発者の共通認識として徹底されない限り、設計の品質は永遠に向上しないということになります。だからこそ、前述の記事中で触れられている通り、設計段階での使い勝手の検討が重要になってくるのです。
業務システムの設計工程に関する書籍をいくつか読んでみても、設計段階における使い勝手の作り込み／検証に関しては、ほとんど触れられていないのが実情です。まずはこの辺りから変えていく必要があると思うのですが、いかがでしょうか。
ここまで業務負荷のかかるのは久しぶりという状態で、更新が停滞しております。このまま更新停止する訳にもいかないので、UI関係の気になるニュースを中心にちょっとクリップ（旧聞ものも含みます）。
今週〜来週を乗り切ることができれば、更新頻度も元に戻すことができるかと思います。まだしばらくは散発更新になりそうですが、スキを見て更新できるように頑張ります（苦笑）
先日のMicrosoft PDC 2003でLonghornが公開（PC Watch記事）された訳ですが、データベースをファイルシステムに組み込んだWinFSが当研究所的には気になるところです。MacOSXでもWinFS的なシステムを実装するのでは？という噂も以前からくすぶっていましたし、大量の情報を今後どのように扱っていくのかを考える上でも、自然な流れと言えるでしょう。
さて、このようなシステムではファイルの様々な属性を基準にして、情報の表示を動的に組み替えて利用・表示することができるようになります（まさにデータベースそのものです）。ディレクトリに依存せずに検索をスムーズに行うことが可能になるので、大量の情報から必要なものを検索する際の使い勝手が向上することが期待できます（類似したファイルが多い場合や、極端にファイル数の多い場合などは、別の問題が出てきてしまいますが...）。ただ、実際に「使える」ものになるのかどうかは、どのような属性を標準でサポートするのか、ユーザーが属性を独自に拡張できるのか、拡張時の操作性はどうか、などといった点が鍵になってくるでしょう。この辺は「メタデータをどこまで、どのように保持するのか？」と同様の問題ですね。
そうは言っても、属性を拡張するという作業は、一般ユーザーにとってかなり面倒な作業になります。自分に合わせた属性の拡張という作業は、地味な割に手間ばかりかかる（笑）、情報設計作業そのものだからです（まあ程度にもよりますけど）。したがって、システム側がユーザーや文書形式に合わせた属性を自動的に付加する仕組みを用意するなどして、使い勝手を向上させつつユーザーの負荷を下げることが重要になるでしょう。特に知識労働（ナレッジワーク）で大量の情報を活用する場面を前提とするのであれば、必要十分な情報を必要なタイミングで入手できるようにするためにも、この辺の出来具合が非常に重要になってきます。
しかし、Microsoftはこの辺の仕組みはWindows本体ではなく、Officeに任せそうな気がしてなりません。つまり、WinFSはOffice文書を中心とするワークフローを支援するプラットフォームという位置づけで、ナレッジワーカーの生産性向上はOffice文書側で行う属性拡張を最大限に利用するという方策をとるのでは？ということです。まあこの辺は完全に邪推ですので、Longhornを前提としたOfficeが登場したときに、どの程度ナレッジワークのワークフローが変わってくるのかに期待しましょう（ちなみにMicrosoftによるナレッジソリューションのサイトはこちら）。
といいつつも、3年後（Longhornのリリース予定は2006年）というのはかなり先の話です。果たしてその頃まで、いわゆるデスクトップ・コンピューティングが今の形そのままで残っているのでしょうか？ 少なくともナレッジワークに限定するならば、デスクトップ・コンピューティングの必然性はかなり下がるのではないでしょうか。これは大企業に属する会社員だけでなく、ほとんどのナレッジワーカーにも同じことが起こってきそうな気がします。どんなきっかけでそのような移行が進むのか？移行を実現するために必要な条件は何か？ということは、まだ漠然としか見えていませんけれども。
おそらく言えることは、WebサービスやWebアプリケーションの普及が、この変革のきっかけになるのでは？ということです。ここ最近の流れを見ていると、Longhornで実現しようとしていた世界が、Longhornのリリース前に実現してしまう領域もかなり出てきそうに思えます（その流れに対応するための.NET、そしてIndigo＠Longhornなのでしょうけれども）。Webアプリケーションのコンソーシアム設立という興味深い発表（INTERNET Watch記事）もありましたし、今後もWebアプリケーション界隈の動きを注意深く見守っていきたいと考えています。
すっかり出遅れた感がありますが、先日のCEATECで公開されたPSXのUIについて気になる点を書き留めておきます。
既存の家電製品以外のバックボーンを持つ製品としてどのようなUIを採用するかと期待していたのですが、正直なところ期待外れと言わざるを得ません。操作デバイスとしてゲームコントローラーが使えるので、思い切ったUIが実現できるのでは？と考えていたのですが、なんとゲームコントローラーは別売りとのこと。GUIのデザイン表現自体は個人的に好みだったりするのですが（詳細なメニュー構造や操作仕様などはわからないので無評価）、操作システム全体をみると、あのリモコンがすべてを台無しにしそうな予感...。
十字方向キーと決定／取消キーの組み合わせというシステムこそ、無駄に操作ステップを増やして煩雑感を与えてしまう、かったるい家電GUIの主犯のように思えます（これはマニュアルを制作していれば実感できます）。ユーザー体験の向上を狙ってGUIの質感や操作感を改善すること自体は良いのですが、操作デバイスや操作システムに関わる根本的な部分の改善にも、そろそろ目を向けて欲しかったなあと。などと考えていたら、先日発表されたばかりのWindows XP Media Center Edition 2004のリモコンも同じシステムを採用している模様。もうイヤ。
ところでPSXのGUIに関しては、表示文字数の基本設計も気になります。
TV画面を利用する家電製品のGUIは、32×24文字程度の情報量を基準として設計されているのが通例です。これはハードウェアやコストなどの制約によるものだけでなく、TV画面上の文字の可読性や視認性の問題を回避するためでもあります（PCのディスプレイであれば問題にはならないようなことでも、通常のTV画面では問題になることが多いのです）。ですが、PSXの静止画像表示デモで画面上部に表示される画像情報を見る限りでは、どうも表示文字が多い（文字が小さい）ように見えます。この文字の大きさであればD1/D2で色差信号入力しててもキツイような気がするのですが、通常のアナログ入力の場合にちゃんと読めるんでしょうか？
まあPSXのGUIに関しては当初のデモ（当初発表時）から比較しても結構変化してきているようですので、製品出荷までにより一層の使いやすさを実現してくることを期待したいものです。
1年ほど前にslashdot.jpでGNOMEのHuman Interface Guidelinesが話題になっていたことに、今更気付きました。スレッド中の関連リソースも含めて、HIG（Human Interface Guidelines）に対するアンカーをまとめてみました（それぞれの記事の詳細はまだちゃんとチェックしていません）。なお、すべて英語版の記事になりますので、ご了承ください。
（前回Tablet PCを取り上げたついでに）現在のWebサイトは、マウスやカーソルキーなどといった間接操作デバイスによって操作されることを前提にし過ぎているように思えるのです。これだけでは意味が分からない方がほとんどだと思いますので、ヒントを1つ。直接操作しか存在しない銀行ATMと多くのWebサイトの違いは、一体どこにあるのでしょうか？
その違いは、クリック対象オブジェクト間の間隔、つまり誤操作を防止するための考えかたにあります。Webサイトでは誤ったオブジェクトをクリックしても、復帰が比較的容易であることに加えて、現在選択しているオブジェクトをロールオーバーで明示していることが多いため、（不適切なラベリングによる誤認を除いて）誤った箇所をクリックするという操作をしにくいのです。つまり、「選択（ポイント）→決定（クリック）」という間接操作の利点が出ている訳です。
これに対して「選択＝決定」という直接操作を前提とするATMには、「選択されているオブジェクトのロールオーバー」などという観念は存在しませんから、押し間違えのないようにオブジェクトの配置間隔にはかなり神経を使います。ATMでは操作デバイスが指（笑）なので、間隔を広めに確保しておかないと誤操作を誘発するという事情もありますが、実は他にも原因があります。
直接操作を行うデバイスの表示エリアにはタッチ検出用のシート（PC Watchの記事によるとTablet PCでは背面配置のようですが）に加えてガラスなどでデバイス表面を保護するのが常ですから、どうしてもユーザーが視線で把握するオブジェクトの位置と、実際にデバイスに触れる位置（デバイス側で認識される位置）にズレが生じることになります。直接操作系の機器ではこのような視差による誤操作対策が非常に重要であり、そのためにもオブジェクトの配置間隔に十分注意を払う必要があるのです。
ここで話を元に戻すと、現在のWebサイトのデザインは、間接操作系のデザインに振れ過ぎているように思えます。特にFlashに多用しているサイトに顕著ですが、ロールオーバーなしでは成立しないナビゲーションがあまりに多すぎませんか？ もちろんロールオーバーを捨てろとは言いませんが、TabletPCをはじめとする直接操作系のデバイスが今後増加するならば、この辺の問題に真剣に対処せざるを得なくなるでしょう。（直接操作を主体とする）組み込み機器のフロントエンド標準UIの地位をFlashMXが狙っていることも考えると、特にFlash使いの方々にこの辺の事情を頭に入れておいて頂きたいところです。
このコーナーにしては異常に長くなってしまいましたが、直接操作系UIデザインの感覚がWebデザインにも活かされるべきでは？というお話でした。
MicrosoftのTablet PCのリリースが近付き、関連記事も増えてきました。
現状のキーボード＋マウスがディスプレイに表示されているオブジェクトを間接的に操作するのに対して、タブレットとディスプレイが一体化しているTablet PCでは直接操作が実現できることになります。これは言わば表示デバイスと操作デバイスが紙と鉛筆の関係に近くなることですから、今後の情報デバイスの一般化を考える上で、大きな強みとなるでしょう。
ですが、情報デバイスは紙と鉛筆の関係を実現するだけでは困るのです。
PCのアプリケーションと異なり、入力様式に制約されずに自由に筆記／表現できることが手書きの一番の利点で、特に会議などで問題構造や関係図を速記するときなどは、ボードやメモ用紙の方がノートPCよりも圧倒的に有利です。しかし、取ったメモをすぐに（テキストやベクターデータとして）再利用できないのが泣きどころ。ですから、手書きシステムを採用する情報デバイスには、手書きの軽快で自由な感覚を維持しつつ、取ったメモを必要に応じて編集可能な情報として再利用できることが一番に求められるのではないかと思うのです。
ところが現状では、PDAなどを含めて一般的に「文字入力モード」で書かれたものはテキスト扱い、それ以外の自由入力モードで描かれたものは画像扱いになるケースが多いようで、評価記事を見る限りではTablet PCもこの例に漏れないようです。従って自由でありながら情報の再利用性も確保するという、上記の要求機能は実現できていないことになります。これは認識精度のように実装レベルの問題ではなく、根本的なコンセプトの問題です。
手書きをサポートするシステムで、このような書かれた（描かれた）オブジェクトをシステムがどのように認識／管理するのか？という問題は見過ごされがちなのですが、一般層までに浸透する「使える」手書き入力システムを今後構築しようとするのであるならば、この問題を素通りすることはできません。この問題にきちんと触れている評価記事も出始めているようで、ベンダー各社が今後どのような解決策を用意するのか、楽しみに見守りたいところです。
盛り上がり時期を外したようでなんなんですが、コードネーム「ジンジャー」として世間を騒がせていたデバイスがついに登場しましたね。「絶対に倒れない」という姿勢制御や、超時間駆動を可能にするバッテリーなど注目すべき技術はいろいろあるかと思いますが、当研究所としてはUIの側面、つまり操作（運転）方法に興味を持ちました。
実際に乗っている状態の動画ファイル（ダウンロードページ）を見ていただければおわかりになるかと思いますが、ユーザーの姿勢（重心移動）で前進／バックをそのまま制御できる（前進したいときは前傾姿勢）ようになっています。さすがに左右方向の指示は他の乗り物同様にハンドルで行うようですが、前進／後退に関してはデバイスの介在なしで、乗り手の意思を忠実に反映できるようになっています。これは直接操作UIとしてかなり面白く、良くできているのではないかと思います。
操作で指定しなければならない機能数のレベルがまったく異なるSEGWAYと比べるのは酷ですが、直接操作の世界から遠く離れたところに行ってしまった家電やパソコンのUIにも、こうしたブレークスルーが期待できるのでしょうか。スイッチやボタンなどのコントロールの数が多くなりすぎると極端に操作性が低下することもあって、家電製品やパソコンではできるだけ少ないコントロールで数多くの機能を制御する方向に向かっています。これは直接操作と比較して、間接操作というコンセプトを採用しているといえるでしょう。メーカー各社はコンテクストに応じた自動化／操作の絞り込みや音声認識などによってユーザーの負荷軽減を狙っているようですが、自動化がユーザーの意思を忠実にトレースすることは困難で、どうしても人に背中をかいてもらうようなまどろっこしさがつきまといます。自動化のアルゴリズムとユーザーの意思が一致したときは良いのですが、外したときのイライラ感はかなりのものがあるでしょう。
ユーザーの意思を確実に体現するには、やはりユーザーの操作によるものが一番なのです。操作の煩雑性を回避しつつユーザーの手間を省くために、直接操作という考えかたをもう1度見直すべきときに来ているのかもしれません。
研究所長には突発性難聴から聴力が元に戻らない家族がいるため、音響設備（というかラジカセ）選びも大変です。 え？二年半前からまだ探しているのかって？ 良く覚えていらっしゃいますね、その通りでございます（苦笑）。
さて、聴覚に問題があると、それこそ曲ごとに頻繁に音質調整をしたいというニーズがあるようです（曲によって聞こえたり聞こえなかったりの差が激しいようです）。そうすると、いかに音質調整機能にスムーズにアクセスできるかが重要になりますから、低音域と高音域を独立して、直接に調整できる仕組みを持つ商品を選ぶ必要があります。ところが、最近のラジカセには高音域と低音域の独立した音質調整つまみを持つものは存在しないのです。いわゆるマイクロコンポのクラスまで目を向ければ独立したつまみを持つものも存在するのですが、価格帯としてラジカセの代替感覚というわけにはいきません。それにマイクロコンポといえども、普及価格帯の商品は低音増強機能だけのものの方が多いのです。
そんなこんなで音質調整機能の有無と操作性を確認するために秋葉原中を駆けめぐったのですが、音質調整をメニュー操作で行う商品があることには驚きました。メーカーの設計者の発想としては、設置スペースを固定しているので音質調整機能には頻繁にアクセスされることがないという前提なのかもしれませんが、聴覚に問題があるユーザーにとっては前提条件がまったく異なるため、お話になりません。また、音質調整がデジタル化されているために、あとどれくらい調整範囲に余裕があるのかをすぐに確認できないものもあり（これは音量も同様ですね）、かなり厳しい商品選択を余儀なくされました。
確かに、現在の商品の方がコストダウン的には都合が良いのでしょう。しかし、実装がユーザーの利益につながらないのであれば、機能の存在自体に疑問符がつきます。要するに、ユーザーが使用する現場で役に立たない機能であるならば、その分を削ってコストを下げた方がマシということです。このような問題は、そもそも「その機能がなぜその商品に必要なのか？ どんなときに使われるのか？」ということを意識せずに設計プロセスが流れてしまうことに原因があるのではないかと思われます。これはハードウェア商品設計だけでなく、ソフトウェアやWebサイトの設計にも共通する問題ですが、こうしたことをどれだけ意識して設計作業が行われているか、現状の設計プロセスを問い直してみる必要があるのではないでしょうか。
旧聞になりますが、「3ペイン型ウィンドウはユーザーインターフェイスの終着駅？」という記事が複数のところで取り上げられていたので、当研究所もコメントをしたいと思います。
そもそも3ペイン型電子メールソフトって、本当に使いやすいのですか？
当研究所はMacintosh環境でEudora Proを利用しているのですが、検証の関係でWinows版Microsoft Outlook Expressを起動すると、あまりの使いにくさに愕然とします。3ペイン型のウィンドウを採用している電子メールソフトは、「WindowsのMDI（複数文書インターフェース）アプリケーションのウィンドウ内で、メールフォルダとフォルダ内メール一覧、メール表示の3つの画面をどう配置するか」という妥協の産物にしか思えません。
そもそも、この3つの要素が要求する画面の形状を考えてみると、
このことから考えても、現状のウィンドウ配置がユーザーの要求を満たしているとは思えません。ユーザーによるカスタマイズの余地を考えても、現状の3ペイン型には問題があることは明らかで、こんなインターフェースが終着駅であるはずがありません。
そもそもMDIアプリはウィンドウを最大化して使うことを念頭に置いているのに背景が透過せず、デスクトップ領域が無駄なことこの上ありません。「文書作成系ではMDIアプリが主流のWindowsにドラッグアンドドロップなんて操作体系を持ち込んでも、うまくいくわけないだろう？」とか言いたいことはいろいろあるのですが、話がどんどん逸れていくので、今回はこの辺で。
最後に補足をしておくと、MicrosoftもMDIをやめてSDI（単一文書インターフェース）に移行しろと言っているようです。賢明な判断かと思いますが、その前にOfficeなどの自社アプリを早く修正してください。
情報大工のひとりごと