Winograd, T (eds.) "Bringing Design to Software," ACM Press, 1996.
(邦訳:瀧口紀子訳「ソフトウェアの達人たち」ピアソン・エデュケーション)
この本は、以前妹尾大先生に紹介していただいて以来、私の座右の書になっている。ソフトウェアのデザインがテーマだが、広い意味でのデザインについていろいろ考えさせてくれる良書である。編者は「コンピュータと認知を理解する」のウィノグラード。
広い意味での良いデザインは、
価値観や必要性というコンテキストの中で人に役立ち、クオリティと満足のいく経験を生み出す
ユーザーとその世界の間のインタラクション、そしてデザイナーとその素材の間のインタラクション・・・最も重要なのは、このふたつのインタラクションの間のインタラクションである。(イントロダクション)
このように広くとらえると、革新的な製品を生み出すのも、創造的な仕事をするのにも、新しい技術を使いこなすにも、デザインの視点は欠かせないことになる。概念的につきつめているタイプの本ではないが、経営に関する社会科学が見過ごしがちな大事な視点が含まれているように思い、ことあるごとに読み返している。
本書には研究者と実務家から多数の著者が参加しているのに関わらず、優れたデザインを生み出すにはどうしたらよいかという問題に関してメッセージはほとんど一貫している。
・概念モデル、ユーザーが自然に想定できるやり方をデザインする
伝統的に使われてきた物理的なモノのデザインでは意識しにくいが、ユーザーがそれが何であるか認識し、どのように操作すれば思いどおりに動かせるのかを直感的に理解できるようにするためには、優れた概念モデルが必要である。(ノーマン「人を賢くする道具」「誰のためのデザイン?」も参照。なお、ノーマンは本書にも書いている。)
本書を読むと今日のマックやWindows PCの源流となったゼロックスPARCによるスター・システムのユーザーインターフェースは、ユーザーとのインタラクションしながら概念モデルを驚くほど意識的にデザインしたのだということがわかる。
コンピュータ・メタファーは、・・・ユーザーに何かを思い出させるためではなく、思い当らせるためのものです。(2章)
この違いは重要である。何かというとヘルプやメニューを出すことがユーザーフレンドリーなのではないのある。
家計簿ソフトのクイッケンはカレンダーという概念モデルが適していることをつきとめて成功を博した。(13章)スプレッドシートがビジカルクから始まってLotus 1-2-3、エクセルに至るまで受け継がれ常に主要なアプリケーションであったことは優れた概念モデルのパワーを証明している。(11章)
また、アプリケーション間でコマンドの共通性を持たせることなどもユーザーに思い当らせるのに広く使われている有効な方法である。
概念モデルやユーザーになじみのあるスタイルは、本書ではデザイン言語(4章)、ジャンル(7章)とも呼ばれており、一貫したデザイン言語を提供することはユーザーに余計な負担をかけないだけでなく、一貫したイメージを作り出し、また、ある種の業界標準となることで企業の競争力にもつながる。
・ユーザーとのインタラクション
本書の豊富な事例には、ユーザーの声の聞き方として伝統的なフォーカス・グループインタビューやユーザーにプロトタイプを実際に操作してもらうなどの方法が出ているが、この方法が決定版というものはなく、おそらく一番大事なのはデザインを担う人が観察者としての目を養い、ユーザーと対話する技を持つことであろう。
その際のポイントとして挙げられている、ユーザーが使うその場独特の用語、標準的なやり方、使っている道具、例外事項、共通した関心や問題点に着目する(6章)というのは、まさに経営学分野でのインタビューでおこなう際に留意する点そのものであって初めて読んだとき少し驚いた。広義のデザイナーには、社会科学の方法論の教育がなかなか有効なのではないか。
・素材とのインタラクション
ユーザーとの対話の一方で、デザイナーは素材とも対話しながらデザインをすすめていく。素材と対話することはエンジニアも同じだが、自ら表現したものが自分にとって想定外である状況を重視する点が異なる。
デザイナーはあらかじめ答えを頭の中に蓄えていて、実際にはそれを翻訳するだけというようなことは滅多にありません。たいていは、前進的な動きの中にあって、作業をすすめながら判断を下しているのです。・・・中でも私が関心を持っている判断は、「バックトーク」と呼んでいますが、「こんな風になるとはおもわなかったけれど、何ともおもしろい」というような、まったく予期しないものを発見することです。(9章)
著者たちが、エンジニアリングは基本的に失敗は許されないが、デザインは失敗も大いにあり得、またそれを許容しなければならないとみているのも興味深い。多くの失敗の中から優れたアイディアを拾い上げるためには、デザインはプロジェクトの初期に十分遣唐使、その段階ではあまり集権的な意思決定をおこなわない。
・プロトタイピング
ユーザーや素材との対話を有効に機能させるためには、未実現の製品を何らかのかたちで表現するプロトタイプが必要である。スペックが決まれば、すべてをトップダウンで計画できるものと思ってしまうのは明らかに間違いであり、反復発展的にプロトタイプをつくりながらユーザーや素材とのインタラクションを繰り返していく。
どんなデザインの革新も、互いに相容れない二つの要素が関わることから生まれる。ひとつは新しいアイデアを記述し定義したスペックのリスト、もうひとつはそれらを内包しようとしているプロトタイプである。プロトタイプはしばしば、われわれが望んでいることが非現実で間違っていると念を押す。反対にプロトタイプによって、デザイナーの夢がまだまだ十分でないことが明らかになる。(10章)
プロトタイピング・サイクルは製品開発の定番の概念だが、ここでは、問題解決だけでなく、何をつくるべきかの方向性を定めるインタラクションがより明確になっている。同じようにプロトタイピングがおこなわれていても、スペック主導の場合とプロトタイプ主導の場合ははっきりと異なるというのが10章を書いたシュレーグの主張だ。
・専門職としてのデザイナー
建築に施工技術者以外に建築家がいるように、ハードウェアやソフトウェアにもエンジニアだけでなくデザイナーが必要だというのも本書でほぼ一貫した意見のようである。もちろんここでいうデザイナーは意匠デザインだけをおこなう工業デザイナーよりはるかに広範な役割を果たす。
デザイナーとエンジニアの違いは何か。エンジニアは分析的な視点を持ち、既存の枠組みの中で生じた問題を解決する役割を果たし、デザイナーは既存の枠組みを超えようとする(8章)。もちろん、この2分割は少々乱暴であって、優れたエンジニアや科学者は大なり小なりデザイナーとして役割も果たすが、実際にうまく働くものをつくるという使命があると、技術的な革新はともかく、ユーザーや社会のコンテクストにおいて今までにないものを考えることを阻害する側面があるのは確かだろう。
したがって、デザイナーには、エンジニアよりもさらに、アートの部分、本能、勘などを全面に押し出し、論理のつながりでは到達できないある種の飛躍が求められるが、それは社会から切り離された独創性ではなく、あくまで社会的なコンテクストの中で新たな意味をみつけるための飛躍である。
(アーティスト・)デザイナーの基本的な訓練と技能は、文化的、情感的な意味を探り、それを生み出してコントロールすることである。(3章)
・チームとリーダーシップ
優れた飛躍は多分に個人の能力に依っているが、デザインそのものは多様な人間のさまざまな視点のインタラクションから生み出される。アイディア出しをする初期の段階では、なるべく人数を増やした方がよい(8章)という見解は、なるほどと思った。その後、リーダーシップやユーザーとのインタラクションによって絞り込んでいくのである。
リーダーは、自動車のような重量級マネージャーというよりも、その場で自然と浮かび上がってくるようなイメージである。(8章)どうつくるかよりも何をつくるかがより重要な場面では、リーダーシップのあり方も変わってくるのだろう。
・良いデザインを評価できるか
客観的に測定することが難しいからと言って、デザインの評価は完全にパーソナルなものではない。プロのデザイナーの間では、良いデザインというものの(少なくとも最低限度の)認識が共有されているものらしい。その尺度は生来のものではないが、個人の中で育つのは何年もかかる(9章)。
学生に良いデザインだと思うものを持ってきてその理由を説明するように言うといろいろ個々の性質に言及しがちだが、
そうした性質は必ずしも中心的なのではなく、そのものが全体として持っているデザインに何かがあったのです。(9章)
この何かをつかむ訓練が必要だと言うのである。
私たちの分野で、良い論文とは何かを知るのに訓練がいるのとかなり通じるものがあるように思う。先日、ワークショップで学生が韓国語で研究発表しているのを何となく聞いていたとき、私には(言葉の問題で)詳細はまったくわからないのだが、その日一番の賞をとった論文がどれだかはわかった。何かそういうものなのだ。
=ソフトウェア独特の問題=
以上の原則は、ソフトウェアだけでなくハードウェアと両者の混合物全般にも通じるものである。ただ、ソフトウェアの比重が高いものに独特の問題があるようにに思う。以下に、必ずしもはっきりと書いてあることではないが、私が本書を読んで考えたことを少しまとめてみる。
・既存の概念モデルがない、あるいは、準拠する概念モデルを間違いやすい
自動車には自動車、洗濯機には洗濯機のかなり確固とした概念モデルがある。もちろんこのようなモノでも新しい概念をつねに取り入れて進化していくのだが、既存の概念モデルの比重の大きさはソフトウェアの比ではない。
概念モデルを作りださなくてはならないということは、デザイナーの役割、プロジェクト初期に発想を広げる段階の重要性がより大きいということである。ソフトウェアの比重が高まるにつれ、組織体制の在り方や道具立てが全く変わってくる可能性があるのではないか。
準拠するモデルを間違えやすいという点も結構深刻である。システムを作る人は、たとえ丹念にユーザー環境を調べていても、明示化されやすいプロセスに目が行ってしまい、重要な役割を果たす周辺状況を見落とすことが少なくない。(14章)このことは、企業の情報システムがうまく働かない主要な原因になっているような気がする。
消費者向けにも、例えば、伝統的に形成されてきた新聞の紙面の形式を電子化するだけで電子新聞になると思うのは間違いである。紙面にはディスプレイに移し替変えただけではこぼれおちてしまう、読者の認知にとっては重要な周辺的なリソースが存在している。(7章)
・素材との対話、ユーザーとのインタラクションにおいて、内部表現の制約が少ないことがかえって仇となる
内部的にさまざまな物理特性の制約を受ければデザイナーやユーザーからの要求があった場合自然と選択肢が絞られるが、ソフトウェアの場合、その柔軟性がかえって仇になって潜在的な選択肢が多すぎてしまい、何をつくるべきかにフォーカスが絞れない。既存の概念モデルの弱さとの相乗効果で、。
また、ソフトウェアの開発では、プロジェクトの途中でハードウェアでは考えられないような大幅な変更が繰り返されることは珍しくない。原因は、開発を委託してきたユーザーの要求、並行するハードウェアの開発状況のしわ寄せなどいろいろであるが、一見対応可能だと思えてしまうところに落とし穴がある。なるほど、ソフトウェアには高価な金型はないが、プロジェクト初期をすぎた人月はほとんどサンクコストになってしまう点は同じである。
コストに見合った範囲で製品の価値を高める変更となしくずし的な変更は、現実にはなかなか難しいものの区別する必要がある。デザイナーは発想を拡張する役割なので、そのバランスをとるのはコーディネータ的な役割をする別の人のほうがよいかもしれない。
・プロトタイピングの仕方が確立していない
ハードウェアの開発に比べ、試作やモデル、最近では3次元CADモデルなどにあたるプロトタイプの作り方、使い方が十分に発達していないのかもしれない。
ソフトウェアのプロトタイピングの技法はいろいろあるがソフトウェアだからといって必ずシステムでおこなう必要もなく、特にユーザーとのインタラクションには「ペーパープロトタイピング」のように案外ローテクがよいのかもしれない。
Recent Comments