デザインは結局エンジニアリングにはなりえない
昨日の「『ペルソナ作って、それからどうするの?』発売開始。TB&コメントはこちらへ」でも書いているのですが、僕は、- デザインという作業は、問題発見から具体的な問題解決法の創造、そして、それを実現する方法を編み出す、総合的で創造的な思考・作業だと思いますし、
- また、それは決して一握りの優れた才能の持ち主だけのものではなく、「創造の方法」というものを知り、それを訓練によって身につけることで意欲あるものには可能なことだと思っています。
ただ、この方法というのは、誰もが学べ、意欲さえあれば身に着けられるものだとは思っていますが、その方法を使って導き出されるものが画一的-誰がやっても同じではないという意味では、エンジニアリング的な方法ではないと思っています。
誰にでも習得でき、かつ、その方法を習得したものであれば誰もが同じ結果を導き出せることをエンジニアリングだと定義するなら、デザインは結局エンジニアリングにはなりえないと思いますし、それでいいのではないかと僕は考えています。
ビジネス的に考えればそれはバラつきになるのかもしれませんが、それはビジネスの勝手な都合であって、デザインが生み出したものを利用する側・所有する側からすると、バラつきがあったほうがむしろありがたいと思います。それは製造の品質とは違い、志向性のバラつきだと思いますので、使う側・所有する側もバラつきを承知で選べばいいでしょう。使う側・所有する側が志向性のバラつきまで認可できないほど、自分で選択する目を鍛えられていないほうが問題であって、そんなもの、これ以上甘やかす必要はないだろうし、むしろ、甘やかしてはいけないはずだと思います。
デザイン作業を含む創造性の生態系のメカニズム
そうした意味においてデザインとはクリエイティブな作業です。それはデザインする側にクリエイティビティを求めると同時に、デザインされたものを使う側にもクリエイティビティを求めます。最近、こんなことを思うのです。
- 人びとが意識/無意識的にもっている思想・哲学がモノの形を規定し、
- モノの形は人びとの行動に制約を与えるとともに、行動判断のリソースを提供し、
- 人びとの行動はその思想・哲学を形作る。
と。

「ものがひとつ増えれば世界が変わりうるのだということを想像できているか」で書いたことは、上記の3つの関係性からなるプロセスのうち、2番目のものです。
結局、この3つの関係性からなる世界が視野に入っていれば、自分たちがものをデザインするという行為が人びとの生活・行動に影響を与え、それが人びとの思想・哲学を変化させ、結局はそれが自分たちの思想・哲学も変えうるという輪廻が理解でき、その創造性に気づくことができるのではないかと思うのです。
僕はこういう視点でデザインという作業を捉えたい。
それはこういう巡り巡って自分が変わるという創造のプロセスをつくることを意識しろというのではなく、そもそも、そういうプロセスが動いている生態系に生きているのだから、そのつもりでものづくりに励もうということです。
中途半端なものづくりではこのプロセスに乗ることもなく、いくら作っても何も変わらず、同時に自分たち自身も生態系から押し出されて破滅に向かうことになる。そういう進化論的メカニズムがここに働いているという風に考えた方がいいのではないかと思っているんです。
ものづくりの本質を夢想する
そんな生態系のメカニズムを踏まえたうえで、『ペルソナ作って、それからどうするの?』で紹介しているユーザー中心デザインの方法というのは、創造的なデザインが決して一握りの優れた才能の持ち主だけに可能な特殊な能力なのではなく、意欲あるものなら誰でもその方法を知り訓練によって身につけることで可能になるような、とりあえず現時点ではもっとも優れた手法の1つであると思っています。ようするにこれ、別にユーザビリティを向上するための方法でもなければ、ユーザーのためのものをつくるための方法でもないんですよ。あくまで人間が暮らす思考-もの-行動が織りなす生態系のうちでデザインという方法で発想し創造するための方法でしかないんだと思います。場合によっては、ユーザビリティの向上につながることもあれば、ユーザーが欲しているものづくりにつながることもあるでしょう。
でも、ものづくりの本質って欲深く自分の欲しいものが手に入ればいいなんて思ってるユーザーを満たすことが目的なんじゃなくて、先にも書いたとおり、デザインする側もデザインされたものを選んで使用・所持する側も同時にそのクリエイティブなプロセスに参加することで、生態系のメカニズムのうちに自分たちが存在することを実感するようなそんな行為なんじゃないかと思っています。その意味では、ものづくりという行為は古代の祭りとなんら変わりない行為なんじゃないか。そんな風に考えています。
それには、現時点では最上のものだといえるにしてもユーザー中心デザインの方法もまだまだ非力だと僕自身は認識してるんですが、このへんに気づいて進めている人はほとんど見当たらない。それは僕が不勉強なせいもあるのですが、僕が松岡正剛さんや最近だとバーバラ・スタフォードにこだわるのはこのへんが理由です。
私としてはヴィジュアル・イメージと観念の間の失われた環を、視覚することでのみ思考するような直観的方法をもう一度蘇らせたいのである。バーバラ・M・スタフォード『ヴィジュアル・アナロジー―つなぐ技術としての人間意識』
全体のなかで詩的に部分を描くことと、言語論理的に部分を分析的に取り出すことの違い
そういう全体のなかで僕はペルソナ/シナリオ法というものを捉えています。なので、それだけを取り出して、その手法がどうたらこうたら言うことに僕自身はあまり関心がありません。
だって、それはユーザー中心のデザインのプロセスの全体につながった一部なのですし、さらには創造の生態系のメカニズムのなかで本来ジーニアスなものづくり人たちが日常的に特に意識もせず行っていた行為でしかないのですから、それを無意識にできるくらいに身につける方向で切磋琢磨するならともかく、その部分だけを切りだして殊更その方法の可否を還元論的に分析しようとしたってまともな答えは出てこないはずです。
デザインがエンジニアリング的ではない所以は、方法論を全体性のなかで詩的・視覚的に部分的に捉えることはできても、その取りだした部分を言語的な論理によって分析的に切り出して、非身体的に思考してしまうことができない類いのものだと思っているからです。すくなくともいまの言語にはそれはできないし、いまの科学の人間の理解ではとうていそれはできないと思っています。
それには違う記述の仕方がいる。スタフォードや松岡さんが志向しているのはそういう記述方法としてのヴィジュアル・イメージそのものによる思考法ですし、科学の分野においてもそうした試みは行われていると思っています。
手で線を引いていた時代には見えていたもの
ただ、そのなかで本来視覚的な技法でありはずのデザインの分野で奇妙に、言語論理的な分析の方法に偏りすぎているのが気持ちが悪いのです。本来身体から切り離せないはずのデザインという行為を、やたらと機械や方法論のほうに切り出してしまっていて、それゆえに全体が見えなくなってしまっている感はないでしょうか? 手で線を引いていた時代には見えていたものが見失われていて、ユーザー中心デザインなる方法も過剰に特別視しすぎてしまっているような気がします。
本当はユーザー中心デザインとして方法論化されてることなんて、手で線を引いていた時代であれば、たぶん、みんなが普通にやっていたし、できていたことだと思うんですよね。それができなくなってしまった時代だからこそ、再度、それをいったん体系化した上でさらにそれを体験的に身につけてもらう訓練が必要ななんておかしな具合になってるだけだと思います。まぁ、それもやたらといろんな道具を生み出したおかげで、生態系のメカニズムに従って、思想や行動のスタイルが変化してしまった結果なんだと思うんですけど。
まぁ、このくらい訳のわからんことを僕が書けるのも、いまのところ、このブログ上くらいということで。
関連エントリー
- 『ペルソナ作って、それからどうするの?』発売開始。TB&コメントはこちらへ
- ペルソナ:誰のために何をデザインするかを明示する手法
- ペルソナ/シナリオ法をいかにデザインに活用するか
- ペルソナとISO13407:人間中心設計プロセスの関係に関するまとめ
- ものがひとつ増えれば世界が変わりうるのだということを想像できているか
- ヒット商品、データベース、そして、言葉の壁
- 『ペルソナ作って、それからどうするの?』といっしょに読みたい参考文献:2.認知科学・UCD編
- 『ペルソナ作って、それからどうするの?』といっしょに読みたい参考文献:3.日本文化・ものづくり編
- 『ペルソナ作って、それからどうするの?』といっしょに読みたい参考文献:4.脳と意識、生物編
この記事へのコメント
Kinofumi
ちょっと気になったので2点ほど
●
> その方法を習得したものであれば誰もが同じ結果を導き出せることを
> エンジニアリングだと定義するなら
この定義にとても違和感を感じます。
なぜならば、
> 「+」の使い方を知っていれば、「1+1=2」を導きだせることを
> 数学だと定義するなら
のような(謎な)定義と同じ感じを受けてしまうからです。
> 同じ結果を導き出せること
=その方法を、他の方法と組み合わせるとか、
編み上げるとかなく、ただ単に使う、
杓子定規、思考停止状態?
といった感じに近いような気がしますし、
これはとても、エンジニアリングと呼べない状態だと思いますよ。
松岡正剛の提唱する「編集工学」も「Editorial Engineering」ですしね。
●
> 手で線を引いていた時代には見えていたものが見失われていて、
> ユーザー中心デザインなる方法も過剰に特別視しすぎてしまっている
> ような気がします。
そうですか?
グラフィックデザインの場合に限って言えば
下積みの期間もなく簡単に線が引ける様になって、
結構誰でも一人でコントロールできる工程が格段に増えました。
コントロールしようと思えば、
どこまででもコントロールできるようになってしまっていて、
今まで気にしていなかった部分まで
気にしなくてはいけなくなったのでは?
と思っています。
tanahashi
逆にエンジニアリングを「その方法を習得したものであれば誰もが同じ結果を導き出せる」と定義しないのだとしたら、どう定義するのですか?
「今まで気にしていなかった部分まで 気にしなくてはいけなくなったのでは?」
まさにこれによって、全体が見え、かつコントロールとはいわないまでも全体の生成の過程に参加することができなくなったんだと思います。
そもそもコントロールなんてものづくりにはまったく関係ないことで、むしろ、ものづくりを知っていた人たちはどんなにコントロールしようとしてもできない部分があったから、神をあがめて祭りをしたんだと思います。
田村
私も”誰にでも習得でき、かつ、その方法を習得したものであれば誰もが同じ結果を導き出せることをエンジニアリングだと定義する”という点に疑問があります。
或る手法を習得したしたものであれば確かにその手法を使えば同じ結果は得られます。
しかしそれは低次元での話です。
そして誰にでも習得できとありますがこれも低次元での話です。
本来のエンジニアリングとは習得した知識・技術をもとにいかに効率的に問題を解決するかです。そして問題を解決するために必要な技術は高い精度が必要になり、それには職人の経験や技により左右されます。
機械工学では加工する際の職人の技が精度につながり、情報工学ではロジックを組むプログラマーの技術が効率化に繋がります。職人やプログラマーによって同じものを作るにしても十人十色の中身をしています。
言ってみれば”誰にでも習得でき、かつ、その方法を習得したものであれば誰もが同じ結果を導き出せる”というのはエンジニアリングではなく、ビデオの予約録画などの操作でしかありません。それはエンジニアリングではなくオペレーションなのです。
デザイン同様、エンジニアリングはものを創造することが目的であるため思考のないエンジニアリングはあり得えません。システムエンジニアリングではシステムに扱うユーザーという因子が含まれるためユーザーの思考や行動も必要になってきます。私たちの分野に置いてもUCDの考えは重要であり勉強をさせていただいている次第です。勉強すればするほどエンジニアリングとデザインの境界が薄れて行くことを感じました。Webデザインとシステム構築は大変似ており如何に情報を伝えやすく扱いやすくといった点が重要ですしね。
tanahashi
僕自身、"誰もが習得でき"の部分は、ひたすらがんばればその可能性が開かれているくらいしか思ってないので、その点はアグリーです。
でも、ですね。"誰もが同じ結果を導き出せる”方法じゃないんだとしたら、エンジニアリングってなんなんですか?
Kinofumiさんのコメントへの返信同様、エンジニアリングをそれとは別の形で定義してくださいが僕からのお願いです。
僕は科学の実験での再現性と類似したものがエンジニアリングの分野では求められていると、これまでは定義されていたのではないかと思います(素材が異なることで再現性が損なわれることを除外するのはすでに書きましたね)。
田村
習得の部分で言えばオブジェクト指向が理解できないプログラマーが多数おり習得できる人、出来ない人がいるのは事実ですね。物理がなかなか理解できない人がいるのと同じようなものです。しかしtanahashiさんが仰る通り、ひたすらがんばればその可能性が開かれるのは間違いありません。
再現性は確かに必要ではあります。しかしそれは事象であって、エンジニアリングの一つの要素でそれだけではエンジニアリングではありません。
エンジニアリングは思想に基づきそれらの事象を如何に組合わせ新しいものを創りだすことだと定義できると思います。
したがって車を作る際、設計や生産計画まではエンジニアリングだと言え、組み立てること自体はオペレーションであると言えます。
設計にはどうすれば安全性が高まるか、どうすれば心地よく運転できる、どうすればより良い車になるのかなどの思考が必要になり、設計者によって違った設計が出来上がります。それに対し組み立ての段階では機材の操作を覚え、指示に従って作業をするため、誰しもがほぼ同じ結果になります。(ほぼとは作業者によって若干の違いがでるためです)
tanahashiさんが「デザインという作業は、問題発見から具体的な問題解決法の創造、そして、それを実現する方法を編み出す、総合的で創造的な思考・作業だ」と仰っていらっしゃいますが、エンジニアリングでも同様の思考・作業が必要になります。
我々SEは顧客のニーズをもとにプログラムの大本になる設計書を制作し、それをもとにプログラマがシステムを作り上げます。
言ってみればSEは建築家、プログラマーは大工さんですね。
また英語では設計は”design”と表記されますように本来エンジニアリングとデザインの根本的な違いはないと思います。
もしエンジニアリングが、ある方法を習得したものであれば誰もが同じ結果を導き出せることをエンジニアリングだと定義されるのであれば、車のエンジンはどのメーカーでも加速や燃費、耐久性はほぼ同じなってしまいます。しかしメーカーによってエンジンの性格が違うのは設計思想とういものがあるからです。思想なき設計は所詮コピーでしかありません。ソフトでも同じように様々な思想があるから同じジャンルのソフトであっても全く違った仕様をもっているのです。
よってエンジニアリングとは、思想により様々な事象を用いて新たなものを創造することだと定義できると私は考えます。
翔
kinofumiさんと田村さんは作り手(エンジニア)側からの見解ですね。
tanahashiさんはクライアント側でしょうか。
クライアントは<1+1=2>のシステムを作るようエンジニアに要求し、エンジニアは結果的に<1+1=2>のシステムを作ります。
エンジニアが「誰にでも習得でき、かつ、その方法を~」という部分に同意できないのは
エンジニアの結果とはシステムの全てであり、
クライアントの結果とは<1+1=2>のみであるからだと思います。
だからエンジニアは低次元だとも言いたくなるし、なにもわかっちゃいないと思うのでしょう。
今回の場合、要素を分解して考えたならば、田村さんはデザインをエンジニアリングとして実装することをも含めての全てがエンジニアリングと考えていて、
tanahashiさんは<1+1=2>を導き出すのがエンジニアリングであって、ユーザーにとっての使いやすさ等はデザインと分類しているのではないでしょうか。
つまり、クライアントにとって中身は別の話(みえない)ということでしょうか。
tanahashi
・エンジニアリングとエンジニアをまず分けてください。エンジニアの仕事は別にエンジニアリングの方法を使うだけでなく、エンジニアリングの方法そのものをどう組み合わせて使うかというデザインが含まれます。
・そのうえで翔さんのいう、作る側と使う側の視点を分けてください。エンジニアリング的手法で作られた部分が"誰が作っても同じ結果"を再現できなくては、いかにして現在の商品の品質は担保できますか? 極端な話、エンジニアリングの方法は誰でも以上に、理論上(そして一部は現実にも)機械でも可能な方法を指していると思います。だから、機械的大量生産が可能であり、ある一定の品質の機械生産商品を僕らは使えているという恩恵を受けているのではないですか?
・で、結局、エンジニアリングの定義がないですよね。僕の定義(まぁ、元は僕のでもなんでもないですが)を否定ししているだけではだめですよ。
>翔さん、
・デザインの側も安寧しているわけにはいかないと思ってます。そもそもツールや手法を外部化した時点で、デザインも"誰もができる"方向にシフトした。でも、それが非常に中途半端な状態で外部化して一部外部化できないところが残っています。それであるがためにエンジニアリングのように方法さえ習得すれば"誰もが同じ結果"を再現できるようにならず、中途半端な再現可能性だけが可能になり、残りの部分がオリジナリティなんて呼ばれたりする。クソですよ。そんなもの創造性でもなんでもない。
・だからこそ、田村さんの言うようなオリジナルとコピーみたいな話になる。コピーしきれない不確実性がオリジナルなんて崇められてる現状がおかしい。僕はむしろいまの段階ではエンジニアリングのほうが上だと思ってます。だって、その方が(使う側の)役に立ってるから。
田村
tanahashiさんの仰るエンジニアリングの定義は、数学や物理などで使われる公式や法則と同じ技術事象であると捉えてよろしいでしょうか?
だとすればそれはエンジニアリングではなくサイエンスや基礎研究です。
tanahashiさんの「エンジニアの仕事は(中略)エンジニアリングの方法そのものをどう組み合わせて使うかというデザインが含まれます。」という意見の”エンジニアリング”を”技術事象”におきかえると「エンジニアの仕事は(中略)技術事象そのものをどう組み合わせて使うかというデザインが含まれます。」と言い換えられます。私の言うエンジニアリングとは、このエンジニアの仕事そのものなのです。
私のエンジニアリングの定義なのですが先ほどのコメントの前半で述べていたのですが、「エンジニアリングは思想に基づき様々な事象を如何に組合わせ新しいものを創りだすこと」であると定義しています。最後の文章では若干表現は違いますが同じことを言っているつもりです。この定義で重要なのが、ものを作り出すことなのです。そしてエンジニアとはこのエンジニアリングの定義の思想を基に事象を創造・設計・構築する人であると言えます。よってエンジニアリングとエンジニアを分けて考えることはできません。
援用として学問としてのエンジニアリングの和訳である工学の定義を挙げると、「工学における教育プログラムに関する検討委員会」によって、『工学とは数学と自然科学を基礎とし,ときには人文社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問である.』というように定義されています。つまり設計構築された事象がエンジニアリングではなく、設計構築することがエンジニアリングなのです。しかし構築する際、創造的思考の無い構築はオペレーティングでしかないと言えます。
※ちなみに学問としてのエンジニアリングと書いたのは、エンジニアリングは思想や行動という面もあるためです。
またエンジニアリングは、誰にでも習得でき、かつ、その方法を習得したものであれば誰もが同じ結果を導き出せるものの設計構成すべきである、とは言えます。例えばUIを作ったものの、操作が覚えられない、覚えたのに違った結果がでるではデザインとしてもエンジニアリング(設計)としても出来損ないでしすね。しかしこれは到達すべき事象であり目標であって、それがエンジニアリングそのものを定義するものではありません。
しかし重要な因子の一つであると言えます。
> 翔さん
私が言う低次元はそこに創造の無い事象のことで、それに対して高次元とは創造が必要な事象のことです。噛み砕いて言ってみればビデオの予約録画操作は覚えれば誰でも同じ結果が得られる低次元な事象で、運動会のビデオの編集は同じ素材でも編集者によって出来上がりが違った作品が創造される高次元な事象である言えます。
なのでちょっと違います^^;
tanahashi
あとの主張はご自身のメディアで行ってください。
よろしくお願いします。
田村
ですが最後に言わせてください。返事はなくとも結構です。
エンジニアリングで使われる手法を最後に書いてますのでそれだけでも読んでください。
よろしくお願いします。
tanahashiさんが何を仰っていて、私が何を読み間違っているのだろうと、今までの議論を踏まえてこのブログの記事を一文一文読み返してみたらようやく理解できました。(できつたつもりす。)
tanahashiさんの仰るエンジニアリングとは、エンジニアリングによって作られたもの/もたらされる恩寵は、誰が使っても操作を間違わなければ結果は同じ。だからエンジニアリングはこう定義されると仰っているのだと理解できました。そしてエンジニアリング的手法は操作を間違わなければ誰が使っても同じ結果が得られなければならない考えていらっしゃることが分かりました。
たしかにエンジニアリングによって、作られたものによりもたらされる結果や恩寵は誰が使っても操作を間違わなければ結果は同じとう点は仰る通りです。しかしそれは「エンジニアリングより作られたものによる結果」でしかなく、それ自体がエンジニアリングの結果ではありません。
例えば計算機ではじき出される答えは一つです。しかしそれは計算機の『操作の結果』です。これはエンジニアリングの結果では有りません。オペレーティングの結果です。
エンジニアリングとは散々申しましたが作る/創ることにあります。この例では計算機を作ることがエンジニアリングです。計算機の操作はエンジニアリングではありません。私の定義ではありますが、エンジニアリングの定義は「思想に基づき様々な事象を如何に組合わせ新しいものを創りだすこと」なのです。
よって貴方が言うエンジニアリングというものは、「エンジニアリングによって作り出されたものによる結果」でのことで「オペレーティングの結果なのです。」
今回の議論では私はエンジニアリングとは作ることだと述べ、tanahashiさんはエンジニアリングによっても(作られたものにより)たらされる結果について述べていたのですね。
蛇足ですが同じエンジニアリング畑のKinofumiさんはエンジニアリングとは「1+1=2」ではなくどのようにして2を導き指すかがエンジニアリングなのだと仰っているのだと思います。
エンジニアリングで使われる手法なのですが、試行法(Trial-and-Error Method )、PDSサイクル法(Plan Do See Cycle Method)、XP法(Extreme Programming Method)などがあります。これらは教科書にも載っているような方法です。簡単に説明します。
・試行法:とりあえずやってみてだめだったらまたやる方法
・PDSサイクル法:計画→実行→評価を繰り返す方法
・XP法:顧客と開発者のコニュニケーション→要望の必要最低限を実装→評価→顧客と開発者のコミュニケーション→フィードバックを繰り返し開発する手法。またそれを実行するために良い環境、顧客、開発者を含めた広い思想。
実はこういった手法がエンジニアリング的手法だったりします。
またこちらにUCDとXPを組み合わせた手法の記事が有りますのでご覧下さい。
http://www.ark-web.jp/blog/archives/2005/09/post_11.html
駄文長文その他諸々失礼いたしました。
tanahashi
田村
私はあなたがエンジニアリングを全く理解されていことが理解できました。
エンジニアリングを勉強した者であれば、顧客に電卓を作ってほしいと言われたら、誰でも電卓を作ることが出来る。デザインを勉強した者の場合、顧客に広告を作ってほしいと言われたら、デザイナーによって出来た広告が違う。だからデザインはエンジニアリングになり得ないということを述べたいのかもしれませんが、だからといってエンジニアリングはこうだと定義できるものではありません。エンジニアリングはそれだけではないのです。
ジェームス・ダイソンのインタビュー記事でも読んでエンジニアリングを勉強してください。
http://nd.nikkeibp.co.jp/nd/news/contents/653.shtml
それでは。
tanahashi
別に田村さんがそれをエンジニアリングだと思うのは否定しません。
ただ、僕はそう思わないって考えてるだけです。