読書感想：コンピュータはむずかしすぎて使えない！

はじめに

会社の課長さん(UI系のエンジニア)から必読書として紹介されたので読むことにしました。

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

ソフトウェア開発において、プログラマにUI作りを任せるとろくなことがないので、ビジネスともエンジニアリングとも異なる人間的な視点を持ったインタラクションデザイナが、プログラミングに先行してちゃんとインタラクションデザインをしましょう、良い事づくしだよ！ という本。

自分自身、デザイナの方と相談しながらプログラミングをする一方で、外注の方に仕様書を出してプログラミングをしてもらったりと、作者の言うところの「プログラマがデザインをする」をやってしまっている人なので、(良い意味でも悪い意味でも)非常にお腹が痛い感じでした。

訳者がおもしろい

訳者がウィットに富んでいて、原著に散見されるロジカルな飛躍や矛盾を訳注や後書きで突っ込んでいるのがおもしろいです。クーパー氏の本書での主張は超人デザイナの存在を前提にしているところが多く、現実味が無い、というのを真っ先に突っ込んでいたのがおもしろかった(笑) それで良いのか訳者。山形浩正さん。

三つの要点

• プログラマが主導でソフトのインタラクションデザインをすると良いことがない
  どんな悪いことがおこるのか、なんでそんなことになってしまうのか。

• インタラクションデザインの必要性
  インタラクションデザインとはどのような物で、そのように達成されるべきか

• デザインの指針
  インタラクションデザインを行う上のTips集

以下では、この三つに括って、本の内容をざっくりとメモっておきます。

プログラマが主導でソフトのインタラクションデザインをすると良いことがない

ホモ・ロジクスの特性

飛行機に乗る際に「コクピットに乗っても良いよ」と言われたら乗っちゃうような僕らみたいな人種のことを著者は「ホモ･ロジクス」と言って、こういった人の視点でインタラクションデザインがされると大変なことになる、と警鐘を鳴らします

• コントロールが欲しい --- かわりに複雑さを受け入れる

一方、ホモ･サピエンス(多くの普通のユーザ)は、単純さを求め、かわりに自分のコントロールを手放す。たとえば検索ツールの話

たとえばウィンドウズ95で、「ファイルやフォルダの検索」機能にはいろいろな制御部分があってやり方をコントロールできる。(中略) 多少、事前の努力と勉強をすれば、検索が高速になって効率も上がる。 ホモ・サピエンスなら、検索機能の働きぶりをいちいち考えずに済むのなら、検索時間が一分余計にかかったところで全く気にしないだろう。 かれらにとっては、パラメータが増えるたびに、入力を間違える可能性が増えるだけなのだ。(p.174 プログラマは単純さよりコントロールをとる)

• 理解を求める --- かわりに失敗してもいい

一方、ホモ･サピエンスは成功を求める。かわりに理解は少なくてもいい。ちゃんと動く時計で時間が分かることがユーザの目的で、時計がなぜチクタク言うのか知らなくてもかまわない。一方エンジニアは直ぐそれを分解したりして、最悪壊してもかまわないと思っている。

プログラマの理解したがりのせいで、かれらは本能的に、製品の内部構造に密着した操作を作り出してしまう。製品がエンドユーザーの目標を反映した物にするかわりに、内部のメカニズムの作用を反映した物となる。プログラマ達はソフトの中身を理解しているから、その使い方も理解出来る。「実装モデル」の操作スタイル。(p.178 プログラマは成功より理解をとる)

• 少しでも可能性があることにこだわる --- かわりに事前の準備をしっかりとする

一方ホモ･サピエンスはありそうなことを考える --- かわりにたまにまちがえてもいい。皆が具体的な細かい作業に使うプロ用のツールは別としても、多くの人は、そのソフトに初めて触れる時に期待している主要な機能がちゃんと使えることが最重要だ。

起こりえるエッジケースにこだわって実装をするあまり、結果としてほとんど大丈夫な場合の方が見えにくくなると言うことがある。このために、操作のほとんどがあまり使われない、あるいは全く使われない機能にばかり向けられて、よく使われる物が分かりにくくなっている。 ユーザーからの一番多い苦情は、「いろんなオプションがインターフェイスにぶち込まれすぎていて、何の区別もないせいでソフトが使いにくい」という物だ。(p.181)

踊るクマ ソフトウェアの横行

• 動いていてる、要求された機能を満たしている、それだけですばらしい！みたいな物で終わる
• ソフトウェアが思ったように使えず、バカにされたような気分を感じるのだが、使えている人は「便利だ！」とか言っちゃうもんだから、使えていない自分が悪いのか？という雰囲気が出来て我慢して使うようなことが起こる

開発のプロセスがおかしくなる

• ソフト開発に時間とエネルギーがかかるため、ユーザー達がそれの理解に手間をかけたがらないことを理解出来ない (p.147)
• 機能一覧と工数を比較して何を実装するかが決まってしまう (p.080)
• 締切がプロジェクト完成の唯一の基準となる (p.074)
• 提案された機能がはっきりと否定されるまでは良い物であると想定され、てんこ盛り仕様になる (P.049)

装置にくっつける物理的な制御ボタンやパネルは、製造コストという負のフィードバックにまだ支配されているけれど、(ソフトウェアに)機能や特徴を追加するプロセスは、そういったフィードバックがない。ソフトメーカーにとって、機能や特徴の追加は基本的に無料なので、提案された機能はすべて、はっきりと否定されるまでは良い物であると想定されてしまう。(p.049)

インタラクションデザインの必要性

インタラクションデザインとは

• ソフトのふるまいやユーザとのやりとりや、情報提示の方法のデザイン

プログラマ達は(中略)それが何をするか(機能)と言う部分はデザインするけれど、そのふるまいや、やりとりや、情報提示の方法はデザインしていない。(p.029 )

• インタラクションデザインは最終的にはコンセプトデザインになる

「ふるまいのデザイン」は、ソフトの各要素がお互いにどう振る舞ってコミュニケーションすべきかを語る。(中略)操作デザイナーはまた、逆方向からも考えて見る。ユーザーの達成したい目標から初めて、そのビジネスのもっと広い目標や技術的な可能性やコンポーネントの仕事も視野に入れて、ソフトの振る舞いを検討する。

もっと深いところへいって、「コンセプトデザイン」までやってもいい。これはそもそもユーザにとって何が大事かを考える部分だ。(p.040)

• 人のためにデザインする。

多くのプログラマは、自分が才能豊かなデザイナーだと思っている。確かにこれは事実であることが多いのだけれど、でも機能のためにデザインするのと、人間のためにデザインするのとでは、話が全然違うのである。 (p.162)

テクノロジーとニーズの橋渡しをするだけでは十分ではない。誰かがその橋を、人間が渡りたくなるようなものにしなくては。 (p.166)

ビジネス的な観点からもインタラクションデザンが必要

ハイテクビジネスの三つの主要性質 (p.130)

1.Engineeringと 2.Businessはお互いに依存しているけれど、目標がずれているので、両者の関係には構造的な弱さがある。そこで第3の性質として「望ましさ」という性質が入ってくる。

1. 何が出来るか Engineering
   製品は、作れてちゃんと動かなければ成功しようがないし、技術的な差異化は強みになる。

2. なにが現実的か。何が売れるか。 Business
   何が利益の出る形で売れるか。

3. なにが望ましいか。 Design
   「何が望まれているんだろう、人々はなにを求めているのだろう」 これは、上記2つの性質をまとめ、安定させる3本目の脚となる。これは厳密には「インタラクション」デザインの話ではないと思うけれど、物作りの現場におけるデザインの性質(残念ながら後回しにされがちである)をよく表していると思う。見た目やインタラクションのデザインは、製品レベルで真っ先に人が触れるところであり「なにが望ましいか」というデザインの主要パーツである。

先にデザインをする・時間を取る。

前節「プログラマが主導でソフトのインタラクションデザインをすると良いことがない」で書いたようなことにならないように、デザインが先に来なければならない。そして、そこで十分な検討を行うために、十分な時間を取る。

デザインの指針

知覚的なずれを無くす

以下のバイオリンの例は、自戒の念を込めてメモっておきますが、シンプルな例で言うとユーザが期待するとおりの挙動をさせようもしくは、何か挙動をさせたい時、それを期待するようなシグニファイアをデザインしよう、という話。

物理的な力と結びつかないふるまい 「知覚的なずれ」問題が変わるにつれて規則が変わるような複雑なシステムを相手にした時の、人間の知性が示す抵抗のことだ。ソフトウェアの操作は、知覚的なずれがとても大きい。(p.032)

バイオリンを弾くのはとてもむずかしいけれど、知覚的なずれは少ない。なぜならーーバイオリン奏者は確かにバイオリンをとても複雑で高度に操作はするけれどーーバイオリンは「メタ」状態になることが無く、操作を変えるとチューバやベルみたいな音がするようになったりはしないからだ。バイオリンの振る舞いはいつも予測可能だーー複雑ではあるけれどーーそして制御が難しくても、物理法則に従う。(p.033)

目標主導型デザインとペルソナ・シナリオ法

これだけを扱う本が大量に出版されているけど、原典はこの本。いつか改めて詳細に勉強する。ABOUT FACE3にも、ペルソナの話が載っているはず。

About Face 3 インタラクションデザインの極意

• ペルソナとは

ユーザーの正確な描写をつくり、その人が何を実現したがっているかを描け。 (p.225)

ペルソナは我々がでっち上げる物ではない。調査プロセスの副産物として発見される物だ。(p.226)

我々の目標は、ユーザーの方のニーズに合わせて、ソフトが身体を曲げたりのばしたりしてくれるようにデザインすることだ。ユーザーと言っている間は、製作者の都合にあわせてユーザーはゴムのように曲げられる。 (p.231)

• ペルソナを絞る。そのペルソナだけのためのソフトを提供する。

異なる複数のペルソナの要求を満たそうとしてはいけない。(満たせてしまう要求を探すのは大事) 三人のペルソナに対して3つの異なるソフトを提供しよう。(p.228)

市場の10パーセントだけを狙って、それを100パーセント天にも昇るくらい満足させてやる(p.229)

• 目標主導の意義

知覚のずれは操作とともにやってきて、操作というのは目的があってはじめて必要となる。審美的な部分はいささかも減ってはいない。単に、ユーザーの目標を達成するという、もっと大きな要求の前に影が薄れただけだ。

ユーザーの目標という明るい光に照らせば、どのデザインが目標にマッチしているかがわかる。それは誰の意見とも関係ないし、それをいえば審美的な性質とも関係ない。(p.269)

仕事と目標はちがう。 目標は最終状態であり、仕事はその目標を達成するための中間プロセスだ。もし私の目的が、ハンモックでゆったりと日曜の新聞を読むことなら、まずは芝生を刈らなくてはならない。仕事は芝刈りで、目標は急速。もし誰かをやとって芝刈りをさせられるなら、芝刈り無しで目標を達成できる。(p.271)

仕事と目標の違いを見分ける簡単な方法がある。仕事は技術の変化と共に変わるけれど、目標はとても安定している。(p.271)

1850年と1999年における、移動手段の例。スピード、快適さ、安全性という目標は変わらないが、手段（やる仕事）は技術や文化の変化で変わりうる。

• 魔法だと思おう

制約や思い込みをすべてつぶす。白紙の状態からデザインを始め、ペルソナや目標に慎重に配慮する。そしてしばしば「魔法だと思おう」という創造的な思考実験をする(中略) テクノロジーが変わると、仕事も変わるのが普通だが、目標は一定のままだ。魔法の技術を想像してみることで、すべての仕事を変わらせてみて、これで目標をハイライトすることになる。 (p.342)

• ペルソナと目標の不可分性

「良い操作デザイン」というのは、誰かがそれを何かの目的のために使っているという文脈においてのみ、意味を持つ。人がなくては目的もない。この2つは不可分だ。だからこそ、我々のデザインプロセスでも、鍵となる要素2つは目標とペルソナ。つまりは目的と人なのだ。(p.270)

個人的な目標を絶対に満たす

実務的な目標はすべて満たす必要は無い。オプションメニュはそう。細かい設定はあとから。まずは個人的な目標を満たす。テレビはまず真っ先にテレビを見られる必要がある。先にオプションの設定をさせる、などということはあってはいけない。(p.281)

そして、それより何より大事なのは、「ソフトにバカにされた」と感じさせないこと。

(ソフトを思ったように使うことが出来ず) 人がソフトにばかにされた気分になると、他の目標がどうなろうと、かれらの自尊心が傷ついて、能率はがた落ちになる。個人的な目標を侵害するシステムは、他の目標をどんなに上手に達成しようとも、いずれ失敗する。

ソフトウェアの礼儀正しさ

人がコンピュータにばかにされたような感じがせず、間違いをしないために、ソフトウェアが持ち合わせるべき礼儀正しさ。融通が利くこと。詳細は省略。

中級者のためにデザインする

プログラマは無意識にエキスパート向けにデザインをする。マーケティング部門は、初心者向けにデザインしたがる。しかし実際は、多くの人は正規分布に従い中級者である。

さいごに

月並みですが、インタラクションデザインが大事で、そのプロセスをちゃんと構築するのが大事だということを感じました。さーて問題は、これを自分の職場に持ち込めるのか、ということですが…orz

ただ、プログラマは手を出すな、というのは2014年現在では違うのかなぁという気もします。ウェブ技術や様々なフレームワークの登場により、機能を満たす為だけに開発の大半の時間を割くのではなく、デザインを実行するための道具としてプログラミングが活用出来るようになってきていると感じます。スピードが大事という観点からも、デザインとエンジニアリングが同時に行えるなら望ましいことですし、なにより、既存の価値を抜け出して新しい価値をデザインする際には、自らデザインし形に出来る人こそがやはり強いと思います。