最近ふと気づいたのですが、こうやって書いているエントリを
複数のブログに書き込むことが多くなりました。仕事に関する
ニュースなどはこのブログと社内ブログに、お遊び系はMixiに
といったような具合です。
feedpathの「Blogエディタ」のようなものが今後は重宝される
のかも知れません。
そこで思ったのが、ブログに限らず今後は「同じ入力内容を
効率よく複数個所で登録・編集する」というニーズが増える
のではないかということです。
例えば、ボクの事業部ではGoogleカレンダーを使っています。
営業、開発、マーケといった役割を固定せずに一人が何役も
こなしますので、スケジュールの微調整が頻繁に起こります。
そのときにはD&Dで予定変更できるGoogleカレンダーのGUIが
欠かせません。一方で社内ミーティングや訪問客などで部屋
を予約するときには社内グループウェアに登録をする必要が
あります。(どこかで時間をとって、GDataで連携させたいと
思っています)
あるいはパートナー様と短期間に開発プロジェクトや販促活動
を展開したい場合にはBackpackでコストをかけずに情報共有を
行っておき、一定の区切り毎に社内のプロジェクト管理アプリ
に反映するというのが効率的である場合もあるかと思います。
つまり、TPOによって利用するアプリやサービスを適宜変える
ことが効率アップにつながるのではないかということです。
一方「ユーザビリティ」というと一つの閉じたアプリケーション内
での操作性に着目することが多いですが、理論的に正しくても
それが個々のお客様にベストフィットするとは限りません。
先日、訪問したパートナー様から大変貴重なインプットを頂き
ました。タブブラウジングというのはもはや市民権を得たUIで
IEもOfficeもタブを多用したものになっていくこともあるので
もはや定番といってもいいだろうくらいに思っていました。
ですが、お客様によっては画面が遷移したことと、タブが切り
替わったこととの判別がつかず、かえって混乱してしまうこと
もあり得るのだそうです。
そういったお話を踏まえると、著名な研究者の書籍に記載された
UI理論を踏襲すればベストのユーザビリティが具現化できるわけ
ではないことがわかります。お客様にとっては優れた理論よりも
「慣れ」の方が大きく作用することも多いでしょう。
ユーザビリティについてはメーカー側がある特定のUI理論を押し
付けるのではなく、ユーザーが選択できる仕組みを提供すること
が重要と考えています。
その「選択」というものが従来は一つのアプリの中のメニューの
並びや位置といったレベルに留まっていたものが、ここ最近では
TOPに応じて利用するアプリやサービスそのものを切り替えると
いうレベルに広がりを見せているように思えるのです。
前段で述べたようにスケジュール管理やプロジェクト管理に際して
無理に一つのアプリで完結させようとせず、Web2.0的なサービスと
社内の業務アプリを併用するということが今後は増えていくと思わ
れます。
従来のEAIのようなバックエンドでの連携ではなく、ブログのクロス
投稿のようなフロントエンドでのライトウエイトなデータ連携が重要
と考えています。ユーザーは状況に応じて最適なアプリやサービスの
画面からデータ登録・編集を行うけれども、そのデータを必要とする
一連のアプリやサービスには同じデータがきちんと同期されてストア
されているという具合です。
ソフトウェアを開発する立場としても、書籍で書かれたUI理論をユーザー
に強制するのではなく(もちろん、大原則を抑えることは大切です)個々の
状況(「慣れ｣ということも含めて)に応じてユーザーが利用するアプリや
サービスを変えるという現状を積極的に受け入れて、手軽に使える入出力
APIを公開したりといった部分を整備していくことが重要と考えています。
そのためには「まず現状をきちんと見つめる」ことが必要です。書籍を
脇に置き、机上でユーザビリティ理論の議論を繰り返しても、今の世の
中に何が必要か？の答えは出てこないと思います。もちろん基礎理論の
研究や啓蒙は大切で、それらを専門にされている研究者の方やコンサル
会社もあり、それが大切な役割であることは言うまでもありません。
ですが、実際にソフトウェアを開発する立場の人が閉ざされた密室の中で
自前の基礎理論の構築に時間を掛けたとしても、現場で実際に役立つモノ
は生まれてこないのではないかと個人的には考えています。書籍を読んで
机上の議論を繰り返すより、今の世の中に出回っている様々なアプリや
サービスを実際に利用してみて、ユーザーが見ているのと同じ視点で実践
や試用をしてみることが大事なのではないかと思います。