2006-06-03

近所のコンビニに革新的な店員がいる. 彼女はお釣りとレシートと別々にフィードする. これは素晴しい. 体験するとわかる. これまでお釣りをうけとる時に感じていた不安; レシートの上に溢れる小銭をこぼしそうになるそわそわが払拭される. 彼女のアイデアは支払いのユーザビリティに劇的な改善をもたらした.

すごいよあの店員! 興奮して同僚にまくしたてるといつものように諭された. その技術は昔からあるもので, 本来は全ての小売業が採用してしかるべき技術なのだと. しかし実際のところこの革新が他の店員に広がる様子はない. 他の小売で同じ体験をしたことも, 記憶にある範囲ではない. (レシートのサイズが大きい業種ではたまにあるかも.) おまえはなぜ広まらないのか. 流行らないミームを不憫に思った.

ふと, かつて瞬く間に広まった小売のアイデアを思いだす. レジの隅に置かれた不要レシートを捨てる小箱. あの小箱はすぐに流行った. レシート小箱と分割フィードは同じくらい便利なのに, なぜ小箱だけが広まったのだろう. 私はコンビニの味気なさを際立てるあの箱があまり好きではないから, どちらかというと分割フィードに流行ってほしい.

コンビニ店員の立場を考えると二つの違いは想像がつく. 分割フィードは技術がいるし面倒だ. タイミングを誤ると客をあたふたさせてしまう. 小箱は逆に不要レシートに関する気苦労を減らしてくれる. "レシートはご利用になりますか?" こう伺いをたてる必要がなくなる. 要するに手間を増やす分割フィードに対して小箱は店員を楽にする. だから流行ったのだと想像した.

それでも私は分割フィードに流行ってほしい. 末端店員の横着によってユーザの利便性が損なわれるなんて, システムの欠陥であるようにすら思える.

そこで我が身をふりかえる. いくらか後ろめたい. 末端プログラマの横着でユーザの利便性が損なわれても, システムの欠陥だと言い切れるだろうか. ユーザから見れば問題だけれど, 開発者にとってはトレードオフの結果なのだと言い訳したくなる. 苦しい言い訳だ.

要は面倒なんでしょ?

反論はない. 生理的な反感を抑えたいなら, "面倒" を "コストがかかる" と読みえればいい. すくなくとも, レシートと小銭を同時に受け取るくらいの不快感を 私の作ったソフトウェアのユーザは感じているだろう. もうちょっとなんとかしろと思うだろう.

でも面倒なんだよ.

こうして後ろめたさは平行線をたどり始める.

読みやすくバグの少ないコードを書く動機なら, どの開発者にもある. そうした "良いコード" を書けば, 結局は自分が楽をできるからだ. しかし, 良い UI は良いコードと相反することが多い. 端的にいえば context over consistency だからだろう. 文脈に応じた細かな気遣いは安易な疎結合を打ち砕く. だから良い UI を開発者に動機づけようとしても一筋縄ではいかない.

それでもソフトウェア開発者はユーザに良い UI を提供すべきだし, 私も良い UI を作りたいと思う. ただ何も後ろ盾がないと挫けてしまう. なんとか自分を励まし, 面倒がらず UI を良くできるようになりたい.

草の根からのユーザビリティ

ユーザビリティテスト, インターフェイスガイドライン, 専門家の雇用, オンサイト顧客. ソフトウェアの UI を改善する方法は色々ある. ただその多くは上意下達な性格をもつ. 下端のプログラマがおこなう UI の改善はたぶん少し質がちがう. 仕様や標準では曖昧なディティール, 実装者ならではのアイデア. それを生かすにはどうするか.

UI が大事な仕事は UI の得意な開発者を雇えばいい. 彼等に任せればうまくやってくれる. そんな立場もありうる. これもやはりトップダウンだ. それに私は UI の得意な開発者ではない.

パッケージ製品や公開ウェブアプリケーションのような 性格上 UI の重要度が高いソフトウェアを作っているなら, 組織として UI を改善する動機も仕組みもあるだろう. ここでの問題は世の中に散在するそこらへんの専用ソフトウェア, たとえば CRUD に毛が生えたような中小企業の内製 ERP を 少しでも使いやすくすること. 先端を目指すかわりに底辺を押しあげること. 誰かに改善してもらうだけではなく, 自分の手でものごとを良くすること. それが下端や草の根の役割だと思う.

あまり話を広げても仕方ない ... 私が UI を真面目に考えるのはどんな時だろう. まず, 自分が使うソフトウェアは真面目に考える. 使ってみて不便だったら直し, 遅かったら速くし, 思いついたら書き加える. 要らないものは削る.

私の友達の中には, だからこそ開発者は自分で使うソフトウェアを作るべきだと 主張する人がいる. Microsoft には dogfood がある. これらのアイデアは正しい. 一方で世の中にあるのは dogfood できるソフトウェアばかりではない. たとえばば受注先のインハウス ERP なんてのは使いようがない. 世の中全体の多様性がソフトウェア開発者の多様性を包含している以上 この問題は避けられない. 加えてそういうニッチな内製品ほど UI がひどい.

自分はあまり使わないけど, 周りの同僚や友達が使ってくれるもの. これもそこそこ真面目に考える. たとえばイントラネットのサービスをハックする user script を書いたら, それを同僚に広めようと自慢する. そういう時は彼等が使う様子を横で眺め, 改善点をインタビューする. こちらは言ってみれば草の根オンサイト顧客というところ.

フィードバックを(常に)求む

結局, 使ってみる, 使ってもらう. その様子から改善を考えることが多い. それになにより, 使うのが快適だったり使ってもらって反応を得るのは 楽しいし気分がいい. 私は作ったものの手応えを, フィードバックを欲している. 良いフィードバックがあれば面倒な UI でも作ろうという気になる.

仕事で作るソフトウェアにはそれがないものがよくある. 顧客が実物を見るのは納品後か直前. 私は客の顔も知らない. 上司はソフトウェアの画面より工期と売上の Excel 表を気にかける. 同じプロジェクトで働くプログラマは自分だけ. 納品後も顧客が製品をさわる様子を見ることはなく, ただ仕様変更を求めるメールが転送されてくる. 改善の意欲はかけらも湧かない.

うんざりだ.

フィードバックをうけよう.

作っているものを公開しよう. 宣伝, 自慢しよう. 社内に Wiki があるならプロジェクトのページをつくって スクリーンショットを張ろう. 時々新機能の解説をつけた開発版を配ろう. デモアカウントを発行しよう. 寄せられる感想が建設的な意見ばかりとは限らない. へぼい, 遅い, 落ちるとケチがついてもめげないこと. 彼らの作っているものだってへぼくて遅くて落ちるんだから. (開発中は.) 心ない一言も無関心よりはいい.

通りがかりの同僚を捕まえて自分の作っているものを自慢しよう. 別に CRUD でもいい. ログイン画面でもいい. そのうちサムい空気を笑えるようになる. 上司が見回りに来たら, slashdot を隠してヘッドホンで耳をふさぐかわりに 動いているものを見せて迎撃しよう. ユーザビリティテストと称してさわらせよう. 週報やガントチャートよりずっと状況は伝わるだろう. きまぐれな仕様変更はそこそこに受け流すこと.

フィードバックをしよう.

仲間の作ったソフトウェアをさわろう. 同じ部署にいる同僚のそばを通ったら, 今つくっているものを見せてもらおう. 他の部署にいる仲間と昼飯を食べるなら, 食堂やロビーで待ち合わせるかわりに彼等のフロアに迎えにいこう. そこで作っているものを触ろう. そして, 感想を伝えよう.

もし自分に部下や後輩がいるなら, 挨拶や進捗チェックを兼ねてデスクに寄ろう. デバッグ中ならビルドが通るまで待つ. あたらしく作った機能を尋ねながら, 開発中のソフトウェアを試そう. ひとこと感想を伝えよう. 相手が操作するのを眺めるより, マウスやキーボードを奪って自分でさわる方がいい. クラッシュしても怒らないこと.

フィードバックは対話の通貨だ. このソフトはいい, このプロジェクトはまだ先が長そうだね. この画面は自分のと似ている. 真似しよう. いや, 私のやつの方がいい. フィードバックはソースコードよりずっと広く気軽にやりとりできる. 語り手や聞き手が開発者でなくてもいい.

対話という経済にフィードバックという通貨が流れはじめると, 体験できるソフトウェアは財になる. 開発者は財をなそうと良い体験の実装につとめる. こうして草の根のフィードバックは少しずつ経済圏を築き, やがて...

そんな世界に夢を馳せた.

まず, フィードバックをすることから始めよう. なにかに感心したら, それを伝えよう. あなたのお釣りの手渡し方はとても素敵です. いつもハッピーな気分になります. ありがとう. 仕事のあとでごはんを食べにいきませんか. (コンビニ店員(美人)相手の時のオプション.)