コンピュータはむずかしすぎて使えない

原著のタイトル「The Inmates are Running the Asylum(患者が仕切る精神病棟)」の邦題が「コンピュータはむずかしすぎて使えない」になるのは、デスメタル界で「Incarnate Solvent Abuse」の邦題が「硫酸どろどろなんでも溶かす」になるくらい直球。確かに、直訳だとコンピューター関係の本だと気付かないかと思いつつ読了。


筆者が「精神病患者」呼ばわりする批判の対象がプログラマーであり、シンプルで快適であることを求める一般人と比べると、内部構造の理解を重んじて複雑さを受け入れる点でズレている。そのくせプログラマーがものづくりの主導権を握って離さないせいで、一般市民の周囲には使いにくいコンピューター製品で溢れるようになり、バカにされたような気持ちにさせられているとプログラマーを糾弾している。

外野から批判されるとソフトウェア技術者が「ムッ」となりそうなところ、Visual Basicの生みの親であるアランクーパー先生に言われるのでグウの音も出ない。いや、むしろ筆者自身がVisual Basicを生み出した結果として、インタラクションの酷い製品を世に氾濫させたという自戒の念を込めて自分を含めて批判している感じがする。


ユーザビリティ問題は解決済なのか?


本書は初版2000年で既に絶版になっており、私も中古本を買った。IT業界では新技術がすぐ時代遅れになるのは自然だし、筆者が問題提議しているインタラクション問題は解決したのか。
世間の動向で言っても、書籍出版に近い1999年に制定された「ISO 13407」でユーザビリティが定義されたのが、2010年に改訂された「ISO 9241-210」での関心はUXへと向かっている。

でもそれって本当だろうか?机上では「その通り」かもしれないけど、私の周囲では未だにソフトウェアがユーザーをバカにし続けている。
身の周りの仕事がペーパーレスで済むようになったけど、もともと紙の書類が10種類あったとすると、電子化の代償としてアカウントも操作性も違うシステム10種類を使いこなさないと仕事が進められなくなった。個々の書類を電子化する対処療法からは、ユーザーのシナリオに基づいてデザインする視点が抜けている。
モノづくりの中で「ペルソナ」は有名になって誰でも知っているけれど、「ペルソナ作るのは歓迎だけど、あんな使い方をするユーザーも考慮してあげなきゃ駄目だよ」というエッジケースを持ち出されて機能が増え、そもそもペルソナを導入した意味が無くなる。

本書の事例は古くとも、扱っている問題そのものは目の前の問題と通じるように感じられた。残念ながらユーザビリティ問題は現役なのだ。ユーザビリティとソフトウェアの両方に携わる私にとって、恥ずかしいことのように思えてきた。


ペルソナが生まれた背景

ペルソナ・シナリオ法を学ぶと、元祖として本書が参照されるけれど、それらの内容は中盤以降の一部に限られる。けれど、どういう時代背景があって、何を解決したくてペルソナ・シナリオ法が生まれたのかを再確認しておくことに意味がある。

私の主戦場であるソフトウェアの世界では、気軽に機能追加ができてしまう特徴のせいで、ハードウェアに無い不幸を生み出している。バズワード的に「ユーザビリティ」を口にする人の多くが、機能を増やすことがユーザビリティ向上だと勘違いしておられる。私はいつも下の画像を持ち出して「こんなものを作るつもりですか?」と反論する。

多機能化による使いにくさを無くすために、八方美人をやめねばならない。誰に好かれるよう努力すべきかと言う話で「ペルソナ」が活躍する。
マーケティング用ペルソナとデザイン用ペルソナでいちばんちがうのは、前者が人口統計や流通チャネルに基づいているのに対して、後者は純粋にユーザーに基づいているということだ。
統計に基づいた「30代男性」で区切ると広がりが無いところ、皆が共感する価値観を持った「33歳 二児の父 T.O.さん」という人物に狙いを定めて好かれるよう全力を尽くせば、結果として周辺の20代・40代や、女性にも好かれることがある。

主要ペルソナを作る過程で落選してしまったキャストにも意味があるように感じられた。注目すべきでないユーザーを明らかにすることで、搭載しなくてよい機能の意思決定ができるから。

「ペルソナ」ばかり注目されるけれど、本書には「シナリオ」の節も設けられていることに着目したい。ISOがユーザビリティについて述べる際にも、「特定のユーザ」だけでなく「特定の利用状況」が出てくる。両面から人の個性が浮き彫りにするのが、マーケティングと違った「ユーザーに基づく」扱い方なのかなと思う。


エンジニアとデザイナーの関わり方


全体を取り巻くテーマとしては、エンジニアとデザイナーの関わり方であるように読めた。

アラン先生が仰る「操作デザイナー」に相当する役割が、少なくとも私の組織には不在なので、私自身が操作デザイナーの立場になれないかと模索してきた。ところが、プログラマーは作りやすさに惹かれる傾向にあり不適切らしい。あるべき姿で言うと、専任の操作デザイナーを置いて、開発着手の前にデザインを済ませていることが望ましい。

たまたま2000年にはIT技術が新技術であったけれど、昨日までに無かった技術の誕生に立ち会うのはエンジニアなので、エンジニアが主導権を乗っ取る問題は将来の新技術誕生でも起こるだろう。何らかの技術革新によって実現可能性が一歩進む現場に立ち会いながら、デザインに主導権を渡すような役割のエンジニアが要るんじゃないかと思えてきた。


UXデザインの予感


Deep Purpleは明らかにハードロックバンドなんだけど、burnあたりからはヘヴィメタルっぽさが感じられる。同じく、本書籍は操作デザインを扱っているけれど、当時は無かったであろうUXデザインのような視座が垣間見られる。具体的に引用すると...。

↓バリュー、アクティビティ、インタラクションの3階層で分ける「構造化シナリオ」に通じそう。
ユーザーにパワーとよろこびをもたらすには、まずはコンセプトを考えて、それからふるまいを考えて、そしてインターフェイスは最後にくる。

↓サービス提供側も含めたエコシステムとして捉える考え方がサービスデザインに通じそう。
操作デザイナーにとっては、心理の理解はとてもだいじだけれど、ユーザーの心理だけでなく、ソフトウェアエンジニアの心理も含めて理解する必要がある。

↓実現可能性に囚われて古い解決法の延長でしか考えられない問題への対処について、リフレーミングに通じそう。
制約が実は思い込みにすぎなくて、実は存在しないというのもよくあることだ。裏にまわってみるまでは、それが見えない。

訳者あとがきにて「問題提議は良いけど具体的にどうしたら良いの?」と訳者が筆者に物言いしている。それに対して2017年現在に読んでみると「UXデザインをやれば良い」という回答につながるのかなと思う。

コメント

このブログの人気の投稿

東神戸マラソンを走ってきた

ワークショップのチーム分けを組合せ最適化問題として解く

想い出がいっぱい