エンジニアがUIデザインしたがる本当の理由

ハイライトピックアップ

• Web2.0を引き起こしているのと同じ時代の潮流が、エンジニアの地位の低下を引き起し、エンジニアがUIデザインをしたがる動機を創り出している。
• Googleは、「エンジニアの会社」という皮をかぶった「企画・マーケティング・デザイン」の会社である。
• エンジニアよりデザイン能力の低いダメデザイナーがうじゃうじゃでてくる構造。
• 優秀な人ならデザインスキルがなくてもいいデザインができるのは幻想。現実には、デザインスキルの差は容易には超えられない壁。
• デザイナーに必要な技術的知識とエンジニアの技術的知識は別物なので、エンジニアの技術力はデザインをする上でそれほど強みにならない。したがって、技術力とデザイン力を兼ね備えた優秀なデザイナーはエンジニアとデザイナーのハイブリッドではない。
• 一人の人間がUIのデザインと実装を両方やると二兎を追うものになってUIの質が低下する。二兎を追うエンジニアには、ある運命が待ち受けている。
• デザインの方が実装より上流工程なので、エンジニアは、デザイナーの指示(=命令)どおりにGUIを作成しなければならない。つまり、作業上は、デザイナーよりエンジニアの方が身分が低い。エンジニアはこれが気に入らないので、なんとか、命令に服従する立場から抜け出そうと足掻いている。だからエンジニアは自分にもデザインができるのだと主張したがる。

この記事を書いた理由

理由は3つあります。

(1)「エンジニアがUIデザインすること」の背後にある「エンジニアの地位をかけた闘争」を明らかにしたかった

この「エンジニアの方が優れたユーザインタフェースデザインができる理由」という記事が前提としている技術力とデザイン力を兼ね備えたハイブリッド君という概念に欺瞞があるからです。これは、分かりやすい見方ですが、実際には、それは、エンジニアを正当化するために捏造された神話という側面があるのです。つまり、この問題の背後には、「エンジニアの地位かけた闘争」が隠されており、「ハイブリッド君」という概念は、その戦いのために捏造された武器として使用されているという側面があるのです。そして、この武器は、極めて強力で効果的ですが、一方で、この武器を使用すると、エンジニアは、深刻な矛盾に陥ることになります。そしてそこから脱出するために、ある選択を迫られることになるのです。

(2)誤解されているのは、デザインという言葉ではなくデザインという行為そのものだと思ったから

この、なぜ「デザイン」という行為、「デザイナー」という職業は誤解されるのかという記事、および、そのコメント欄では、「デザイナーという言葉の定義が誤解されている」という議論へと発散してしまってますが、この記事の作者は、本当は、タイトルどおりのことを主張したかったのではないかと思ったからです。すなわち、「誤解されているのは、言葉の定義などではなく、デザイナーという職業そのものだ」ということを言いたかったのに、議論しているうちに話がズレて言葉の定義論にすり変わってしまったのではないのかと思うのです。つまり、真の問題は、「デザイン」という行為のとらえ方そのもの、そして、「デザイン」という行為と「エンジニアリング」という行為の関係そのものにあると思うのです。

(3)エンジニア側に偏った見方を中和したかった

この「エンジニアの方が優れたユーザインタフェースデザインができる理由」という記事は、「エンジニアの視点から見たデザイン」に偏っています。しかも、エンジニアを正当化するような理屈ばかりを寄せ集めています。*1
したがって、バランスをとるために、まったく逆の角度、すなわち、主にデザイナーの視点から、同じ問題を眺めてみたくなったので書きました。

この記事では、それらのことを解きあかし、わたしが書いた最初の記事よりも、いくぶんマシな見方がないか探ってみたいと思います。

この記事の構成

エンジニアがUIデザインをすることには、本質的な矛盾と問題点があります。
そのため、過去幾多の悲劇的なUIがエンジニアによって生み出されてきました。
そこで、この記事ではまず、エンジニアが勘違いしてダメなUIデザインをしてしまう原因と構図を洗い出します。
そして、つぎに、そういう問題があるにもかかわらず、エンジニアがUIデザインしたがる動機の構造を描き出します。
そのあと、エンジニアがUIデザインすることの本質的な矛盾を指摘し、
最後に、その矛盾をかかえたエンジニアが必然的に迫られる厳しい選択を暗示するエピソードを提示します。

「「デザイナーの視点から見た「エンジニアがUIデザインをすること」」をエンジニアが見ること」の障害を取り除く

まず、「デザイナーの視点から見た「エンジニアがUIデザインをすること」」をいきなり説明しても、デザインの経験のない人間にとっては、自分の経験や実感と結びつけて考えることができないため、実感がわきません。このため、まずは、エンジニアの感覚世界から、この問題と同じような構造を持っている例を取り出し、その例と照らし合わせて見ることで「デザイナーの視点から見た「エンジニアがデザインをすること」」を直感的に理解する、というアプローチをとります。*2
そして、その例としては、エンジニアの視点から見た「営業や企画が技術的判断をすること」を用います。*3

営業や企画の勝手な判断でソフトウェア開発プロジェクトが泥沼化した?

営業や企画の人間が、技術者との相談もなしに、システムの仕様について顧客と約束しちゃったり、勝手に仕様を決めちゃったりして、プロジェクトが難航することって、会社によってはよくありますよね。*4そして、そのせいで、無理に無理が重なり、エンジニアたちが徹夜をしまくって必死にしりぬぐいするんだけど、それでも、スケジュールが遅れたり、トラブルが起きたりして、問題が起きることは、とくに業務システムがまだよく整っていない急成長中の会社なんかでよく見られます。

技術の人間:「そもそも、最初から技術的に無理/問題のある仕様だったんだ。なんで、オレたちエンジニアに相談もなく、勝手にそういう技術的判断をしてしまうんだ。そのせいでトラブったんだぞ。」
営業や企画の人間:「なんで、その程度のものが普通に作れないんだ? 他の会社のエンジニアだったら、これくらい問題なくこなしてるよ。単におまえらに技術力がないだけなのを、人のせいにするなよ。」

そういう言い争いが起きているとき、エンジニアの方は、「営業や企画のやつらは、この程度の技術的判断なら、自分にもできると思い込んじゃっているんだけど、それは大間違いだ。やつらは、技術を甘く見てるんだよ。」とか、上司のところに不満をぶちまけに来ることがあります。

営業の技術的判断の方が正しいこともある

こういうトラブったプロジェクトを、あとから調査してみると、エンジニアの主張どおり、営業や企画が技術を甘く見ていたということが多いです。
しかし、そうでないケースもときどきあります。もちろん、エンジニアとの相談もなしに勝手に技術的判断をした営業や企画は、業務システム上は、越権行為であり、それ自体は、会社の意思決定メカニズムをオペレーションする都合上では、「間違った行為」と定義しなければならないのですが、単純に判断の内容だけを切り出してみると、そのときの営業や企画の技術的判断自体は基本的には的確であり、実情は、単にエンジニアのアーキテクチャ設計が間違っていたり、技術チームのマネージメントに失敗していただけなのに、エンジニアが、その失敗を営業や企画の責任だと思い込んでいるというケースというのも、ときどきあるのです。*5
とくに、ITビジネスにおいて、優秀な営業や企画の人間の技術的判断能力は、少し引いて眺めてみると、エンジニアの多くが考えているほどには低くないことが多いです。そもそも、ITシステムの営業や企画をするには、ITシステムの本質的な部分が分かっていないと、十分な成果をだせませんから、頭が切れ、向上心に富んだ、優秀な営業や企画は、日頃から技術の勉強も熱心にやっているし、よく研究・分析するので、少なくとも、営業や企画をする上で肝となる技術的な側面については、エンジニアを凌駕してしまうことがときどきあるのです。*6

営業は技術を甘く見る。エンジニアはデザインを甘く見る。

で、ここからが本題です。冒頭でも述べたとおり、上記の文章を、技術→デザイン、営業→技術、と置き換えても、ほぼ同じことが言えます。たしかに、ヌルいデザインをしているデザイナーはたくさんいますし、そういう並のデザイナーを凌駕するデザイン能力を持ったエンジニアもときどきいます。とくに新しいデザイン分野では、ヌルいデザイナーは適応力が低いために、この傾向が顕著です。しかし、「多くの営業や企画の人間が、技術というものを甘く見ている」のとまったく同じように「多くのエンジニアが、デザインというものを甘く見ている」ということが言えるということもまた事実だと感じるのです。そして、もちろん、逆に、たいしたデザイン能力を持たないプロのデザイナーの能力を、単にその肩書やキャリアだけから盲信し、必要以上に過大評価していることも、よくあると思うのです。
つまり、人間という生き物は、自分の専門外のスキルを、実際以上に過大評価したり、逆に、とんでもなく過小評価してしまうことが多いのです。自分がそれをよく知らないものだから、それが大きいのか小さいのか、よく把握できずに、トンチンカンな価値評価をしてしまうものなのです。
そして、デザインという行為を過小評価してしまったエンジニアが、ときとして、自分もそれくらいのUIデザインならできると思い込み、目も当てられないようなUIデザインができあがることがときどきあります。*7

「営業の技術的スキル」と「エンジニアの技術的スキル」は知識の深さの違いではない

そして、二つ目の、そして、もっと本質的かつ重大なポイントは、「技術が分かる」という、技術的な知識・スキルには、複数種類あるということです。その混同が混乱を招いているのです。「優れたITシステムを企画したり営業提案したりすることを目的とするときの意識構造で知覚される技術」というのと、「ITシステムをイメージ通りに作り上げ、実際にきちんと動くものにすることを目的とする意識構造で知覚される技術」というのでは、かなり違うものなのです。そして、ここでいちばん肝心なのは、それらは技術理解の深さによる違いではない、ということです。
そもそも、この記事で説明しているようなソフトウェアシステムのカオス的性質があるため、どちらにおいても、技術を、ときにはビットレベルまで精密に認識しなければいけないので、どちらがより深いとかそういうことではないのです。そうではなく、「同じビットが、同じビットではない」ということなのです。
以下に、その記事のカオス的性質についての記述を引用します。

ソフトウェアアーキテクチャというのは、カオス理論で言うところのカオス系の特徴に類似した性質をたくさん持っている。カオス系では、ミクロとマクロに本質的な違いがない。すなわち、極小の部分のごくわずかな差異が、すさまじい規模の効果の違いを生み出す。俗に、バタフライエフェクトと呼ばれる性質だ(アマゾンの森林の小さなチョウチョの羽ばたきが、一カ月後に、ハリケーンとなってメキシコ湾を襲うことだってありえることから、気象のカオス的振る舞いを説明する例に使われた)。これと同じように、ソフトウェアの絡んだビジネスでは、最後のほんの数バイトが、ビジネスモデルを根本から覆すようなことが簡単に起こりうる。

「知覚」というものを直感的に理解する

この章には、二つ目的があります。
一つめは、前章の「同じビットが同じビットではない」ということの直感的な意味を説明することです。もう一つは、「デザインとは知覚構造の設計である」ということが、この記事の基本的な前提になっているのですが、その「知覚」というものを直感的な把握を助けるための「知覚の絵」を提供することです。
以下がその「絵」です。

たしか、萩尾望都のマンガで、普通の人間と可視光域がずれていて、赤色よりも下の波長の光だったか、紫よりも上の波長の光だったかも見えるので、同じ景色を眺めているのに、通常の人間とは、違った世界が見えている人間というのがでてきます。人間は、美しい色彩に満ちあふれたお花畑や春の野山を見ていると思い込んでいますが、「世界そのもの」には、色はついてないんです。周波数の異なる電磁波を分類し、色を塗っているのは、人間の脳なんです。世界には、ただ電磁波が飛び交っているだけで、世界それ自体には、色も、光も、暗黒すらもないんです。ついでにいうなら、匂いだって、感触だって、形だって、世界には存在しない。単に、空気中に漂っている無数の分子パターンを、人間の鼻の細胞のレセプターが捕まえ、それを、人間の都合にしたがって、人間の脳が分類し、「匂い」をつけているんです。匂いを創り出しているのは、ウンコでも花でもなく、脳なんです。ものの形だって、人間が、人間の都合に従って、世界に線引きし、境界線をいれ、区切ることで、人間の脳が形を創り出している。世界それ自体には、色も匂いも形もないんです。人間の脳が世界を不完全に知覚しているとかじゃなく、世界のすべては、人間の脳が創り出しているんです。われわれが世界だと思っているものの正体は知覚なんです。だから、「知覚の設計」であるデザインという行為は、おおげさな言い方をすれば、「世界」を設計する行為なんです。もちろん、環境が人間を規定するからこそ、デザインという行為をするんだけど、その環境自体が、人間の知覚によって規定されているんです。じゃあ、人間の数だけ世界があるかというと、そうとらえた方がいい場合と、そうでない場合があります。たとえば、実際には世界はだいたいは共有されている。なんで世界が共有できるかというと、ほとんどの人間が、だいたい同じ構造をしているから。世界を共有しているというより、だいたい同じ目が二つあり、だいたい同じ足が二本あり、だいたい同じ手が二本あり、だいたい同じような構造の言語を話し、だいたい同じように音を立体的に聴き、だいたい同じような筋力で、だいたい同じような体温で、だいたい同じような脳神経システムだから、意識が創り出す世界が共通し、互換性があるわけです。*8
なので、エンジニアがバックエンドのシステムアーキテクチャについてごちゃごちゃ言うと、「目に見えるものが全だ」というような言い方をするデザイナーがいたりするんです。*9

プロのデザイナーの方が技術力が高い?

そして、各物事にどのような色を塗るか、というのは、その人間の立場・欲望・意図・目的が決めます。今週号のSPA!に、「知られざる妙な職業病」という記事がありますが、土木作業員は、「人の家をみると、どこから解体すれば効率的なのか考えてしまう自分がいます」だし、普段ウォーキングの指導をしているスポーツインストラクターは、「人の歩く姿を見ると、着地や足の振り方などついフォームチェックしてしまい、アドバイスしたくなる」だし、まったく同じ家を見て、マイホームを欲しがっているお父さんは、「この家は住み心地がよさそうだな」と思い、まったく同じ人が歩くのを見て、モデルの女性は、「こうすれば、もっと美しく見える歩き方になるのに」と思う。
つまり、「その家自体をどのくらい深く理解しているのか」ではなく、「どのような視点からその家の理解を創造するのか」という問題で、その認識や理解の深さは、どの視点から見るかで、ぜんぜん異なってくる。同じ井戸のように見えて、別の井戸を掘っており、その深さは、井戸別に計らなきゃならない。なぜなら、先程の章で説明したように、人間の意識は世界を認識しているのではなく、世界を創造しているからです。 *10
だから、「エンジニアの方が技術を理解している」とか、「いや、ときには営業の方が技術を分かっているんだ」とかいう議論そのものが間違っている。客観的に存在するテクノロジーというものそれ自体がありえない。単に、個々のソフトウェア設計を見て、それにどのような色を塗るか、あるいは、「人々によって塗られている」と塗るか、という話で、客観的に技術を深く理解しているのはエンジニアの方だ、という考え方は間違っている。ある一つのテクノロジーを、「営業的に色塗りする」のと、「実装的に色塗りする」、という複数の塗りかたがあるだけです。そして、営業的・企画的・デザイン的な技術認識(=創造)というのは、長い時間をかけて深めていくものであって、エンジニア的な技術認識を長い時間をかけて深めた人間が、営業的・企画的・デザイン的な技術認識も深まっていると単純に考えてしまうのは、違うんです。それは、別の井戸なんです。自分が持っているその種類の井戸は、浅いかもしれないんです。つまり、ことデザインという視野から見るかぎり、エンジニアよりデザイナーの方が、技術力ははるかに高いことが多いのです。だから、エンジニアが、技術力を武器に熟練したプロのデザイナーと互角に戦える、と単純に考えてしまうのは、とても危ういのです。

エンジニアよりダメなデザインをするプロのデザイナーがうじゃうじゃいる理由

「しかし、すぐ目の前に横たわっている現実として、どうみても、エンジニアであるオレよりも、ダメダメなデザインをしているデザイナーがほとんどで、デザインのプロだからといってエンジニアよりデザイン能力が優れているとは到底思えない」と考えるエンジニアも、たくさんいるでしょう。
それに対する答えが、三つ目のポイントであり、この記事の右上の図です。この図は、「営業や企画の人の、技術的判断能力が、エンジニアの技術的判断能力を凌駕するケース」があったり、「エンジニアのデザイン能力が、デザイナーのデザイン能力を凌駕するケース」について説明しています。
まず、世の中には、地頭の良い人と、地頭の悪い人がいます(ここでは、説明をシンプルにするため、二種類の地頭に分けていますが、現実には、これらはグラデーションであり連続量です)。どちらの地頭の人も、教育、学習、経験の質が高く、量が多いほど、能力は向上していきます。この意味で、すべての人にとって、教育・学習・経験の質と量を増やすのはとても、有意義なことです。しかしながら、原因はわかりませんが、現象として、教育・学習・経験の蓄積による能力向上グラフの傾きが、人によって、大きく異なるのです。
ここで注意しなければならないのは、ここでの論点は、この傾きが、生まれつきのものなのか、生きる姿勢や態度によるものなのか、それとも学習方法自体の改良によって変わりうるものなのか、ではないということです。この傾きは、変えられるものかもしれませんし、変えられないものかもしれませんし、あるいは、ある程度は生まれつき決まっていて、ある程度は可変なものなのかもしれません。しかし、ここでポイントは、そこではなく、原因はともかく、現象として、このように解釈できる構造がある、ということです。
この構造があるために、キャリア10年のエンジニアが、ヌルい技術的判断をし、営業や企画などの、技術については素人のはずの技術的判断がそれよりも的確になってしまったり、また、キャリア10年のデザイナーのデザインが、どうしょうもなくはずしていて、むしろ、エンジニアの方が、優れたデザインをしてしまうことが珍しくもないのです。

図中の青丸、赤丸、緑丸の関係

たとえば、この図が、UIデザイン経験と、UIデザイン能力についてのグラフだと見てみます。そして、図中の赤丸を、キャリア10年の地頭の悪いUIデザイナー、青丸を、デザイナーから渡されたデザイン仕様に従ってGUIプログラムを書く地頭の良いエンジニアだとしましょう。そして、GUIプログラマは、渡されたデザイン仕様を実装するのに、まず、仕様を理解しなきゃなりませんし、デバッグしなきゃならりません。そして、デザイン分野に関して地頭の良いエンジニアは、自然と自分がユーザの気持ちになってデバッグしますので、単にプログラムのバグだけでなく、「ここの画面遷移、ユーザが混乱しない?」「これじゃ、どこをクリックしていいのか、分かりにくくないか?」などと、デザインの仕様のバグも感じ取り、デザイナーと相談しながら、微修正しているうちに、自分自身のデザイン能力も、知らないうちに高くなっていってしまいます。そうしているうちに、とくにデザインの勉強をしたわけでもないし、仕事時間と思考エネルギーの９割を、実装のための工夫に費やしていたとしても、残り一割の思考エネルギーをデザイン仕様のデバッグに費やすだけで、青丸の位置に来てしまうのです。傾きが急になっているからです。とくに、地頭の良いエンジニアが、緑丸のところにいる地頭の良いデザイナーと組んで仕事をした場合の学習効果は巨大で、あっという間に、デザイン一筋で10年のキャリアを持つプロフェッショナルな地頭の悪いデザイナーを凌駕してしまったりします。

「ニッチなand/orいままでにない分野」のデザインでは、キャリアよりも地頭の善し悪し勝負が決まる

そして、いままであまりなかった、新しい分野のデザインや、普段あまり遭遇しないニッチな商品のデザインにおいては、その分野のデザインの特殊性への適応能力が、勝負を決めます。なので、重要なのは、その人のデザイナーとしてのキャリアよりも、地頭が良いのか悪いのか、ということになることが多いのです。たとえば、はてなツールバーについては、もしかしたら、ツールバー、もしくは、それと似た条件のGUIのデザインの経験のあるデザイナーの数は少ないかもしれません。*11その場合、現実には、デザインのキャリアよりも、地頭の善し悪しの方が、はるかに重要になってくるのです。

使えないプロフェッショナルデザイナーの典型的なパターン

もちろん、地頭が悪くても、しっかり仕事をするデザイナーというのはたくさんいます。ただ、彼らは、応用が効かないのです。彼らは、デザインスキルを蓄積しているだけで、デザインに対する洞察を深めているわけでもないし、デザインセンスを磨いているわけでもないからです。たとえば、主に紙のデザインばかりやってきた地頭の悪いデザイナーにGUIデザインをやらせると、見た目は美しいけれども、非常に使い勝手が悪かったりします。

地頭の良いプロフェッショナルデザイナーの適応能力

ところが、世の中には、キャリアを磨いてきた地頭の良いデザイナーというのがいます。そういうデザイナーのデザイン能力は、知識とかテクニックとかいう表面的なものじゃないです。単なるテクニックではなく、「そのデザインテクニックをなぜそこに適用すべきなのか」について、徹底的に考え抜きながら、魂を込めた仕事をしつづけてきています。エンジニアで言えば、なぜ、ここでそのツール/ライブラリ/言語/インフラ/サーバ構成/アルゴリズム/クラスデザインにするべきなのか、なぜそれがもっとも賢い選択なのかについて徹底的に考え抜いた上でシステム構築するタイプです。決して「安易に」「なんとなく」重要な意思決定をしないタイプのエンジニアです。そういうデザイナーは、なんていうか、剣の達人が、無駄な剣の動きをせず、とても靜かで、気がついたら、一瞬ですごい踏み込みをしてくるのに似ています。たとえば、あるデザインを依頼したら「この場合、デザインしないのがデザインだから、基本的にはこのままで、こことここを直すだけでいい。オレのやることはなにもない。」と言って、断ってくることまであります。
そして、本当の剣の達人が、格闘というものを本質のレベルで会得しているために、素手の格闘でもかなり強いのと似ていて、そういう長いキャリアの地頭の良いデザイナーの適応能力は究めて高く、いままで経験のない分野のデザインでも、すばらしいパフォーマンスを発揮します。つまり、デザインを「学んだ」とか「理解した」とかじゃなく、デザインを「悟った」といういう状態なのです。表面的なデザインテクニックではなく、デザインそのものを会得しているのです。

デザイナーであるかどうかということと、デザイン能力は、大きな相関がある

つまり、いちばん重要なのは、地頭の善し悪しですが、だからといって、デザイナーが蓄積しているスキルを軽視できるわけじゃないんです。プロのデザイナーの知識やスキルについて、軽視することができるのは、そのデザイナーが、地頭の悪い場合だけです。なので、「10年、20年と技量を磨き上げてきた地頭の良いデザイナー」と「デザインには素人の地頭の良いエンジニア」が、デザインの技量がたいして変わらない、という考えは間違っていると思います。

優秀な人ならデザインスキルがなくてもいいデザインをする、という幻想

たしかに、どんな分野の仕事をやらせても、すばらしい洞察と判断能力をする人というのは、います。たぶん、「本質的な優秀さ」というものがあるのでしょう。しかし、だからと言って、この記事で説明しているような餅は餅屋という、分業、選択と集中の原理がなくなったわけじゃないです。
以下に引用します:

近代社会とは、専門家どうしによる分業によってここまで発達してきたのであって、その分業なしでは、現在の世界の経済規模ははるかに小さなものになってしまっているはずだ。なぜ、分業によって豊かになるのかは、サミュエルソンだかだれだかうろ覚えだが、昔の経済学者が言っていた比較優位の原理があるからだ。その古典的な例では、ある弁護士は、タイプをうつのがとても早く、一時間に8ページもタイプできる。しかし、その弁護士は、自分でやった方がはるかに速いにもかかわらず、自分ではタイプを打たず、一時間に2ページしかタイプすることのできないタイピストをわざわざ雇ってやらせている。タイプで1ページあたり500円稼げるとすると、その弁護士はタイプで一時間に4000円稼げるが、弁護士として働けば、時給2万円稼げる。だったら、１時間に2ページしかタイプできないタイピストを時給1000円で雇ってやらせて、その間弁護士の仕事をした方が、一時間当たり1万6000千円得する計算になる。だから、どんなに得意なことがたくさんあっても、すべてを自社でやってしまえたとしても、企業は選択と集中をし、最も得意な仕事以外はできるかぎりアウトソースしようとする。つまり外注を使う。また、どんな国でも、国際貿易をすれば豊かになれるのも、この原理によるものだ。

たしかに、本質的に優秀な人は、自分の専門外の分野においても、その分野の平均的な専門家の能力を凌駕しますが、だからと言って、「その分野に選択と集中をしている本質的に優秀な人」を凌駕できるわけではないのです。結局のところ、餅は餅屋なのです。空手の達人が、剣の達人に、剣で勝負したら、やはり勝負にならないのです。

同一人物がGUIのデザインと実装の両方をやるということのメリット

「同一人物が、GUIの実装をしながらGUIのデザインをする」のと、「GUIのデザインだけに選択と集中する人と実装に選択と集中する人の二人がペアになって仕事をする」のとでは、どちらの方がいいデザインができるかについて、考えてみます。
たしかに、デザインと実装を同一人物がやることのメリットというものがあるようにも見えます。そもそも、あるデザインアイデアを思いついたとき、それが実際に実装できるかどうかは、実際にプログラミングしてみなきゃ分からないこともあるし、また、実際にプログラミングして、動くものを見てみたら、感触がなんか違和感のあるものだったりしてやり直したりと、そういう、試行錯誤やフィードバックループがあるからです。
もっというと、プログラミングしながら、自分が何をデザインしたいのかがしだいに明確になっていくということが、よくあるのです。プログラミングとは、実装というより、アイデアを練る作業でもあったりするからです。
分業すると、この、プログラミングする過程における、試行錯誤、フィードバックループ、アイデア練りが、デザイナーによってなされないために、そういう面からのデザインの深まりが弱いのです。そして、これは、一見、極めて重大なことのようにも見えます。

デザインだけに集中することで見えてくるシンプルで美しい世界

しかしながら、デザインだけに選択と集中をすることのメリットというのもあります。それは、実装のごちゃごちゃした問題を意識から追い出し、純粋に、「知覚の設計」を練りに練ることに、集中できるということです。ほんとうにユーザをすばらしい世界へ導けるGUIについて、考えに考え抜き、そもそも論までどんどんさかのぼって、現在の自分たちのGUIについての思い込みや偏見自体にまで気がつき、それを外側から見つめなおし、根本的に新しい概念や発想でとらえ直し、ゴチャゴチャしたものが、ばっさりなくなって、とてもシンプルで美しいデザインでありながら、極めて汎用的かつすばらしく実用的であるという仕様になるまで、徹底的に煮詰めるための時間と思考エネルギーを確保できるのです。GUIの実装に時間と思考エネルギーをとられてしまっていては、けっして到達できない、シンプルで美しい世界にたどりつけることがよくあるのです。それは、気がついてみれば、なんてことはなし、ごく単純なものの見方なのですが、そこにたどりつくには、自分が無意識のうちに思い込んで閉じ込められている思考の檻を、いくつも破って、その外側に出て行かなければならないので、とても時間とエネルギーがかかるものなのです。

地頭の良いデザイナーの技術的知識

地頭の良いデザイナーと、ペアでGUIプログラミングをしてみれば、すぐに分かりますが、地頭の良いデザイナーは、技術についても、すさまじく貪欲で、デザインの肝となるところについては、プログラマーですら把握できていない深いレベルのパフォーマンスについてまで、徹底的に質問責めにします。そのため、最初のうちは、単にそのデザイナーの質問に答えるためだけに、ゲーム機なりPCなりOSなりの制限事項や、APIの調査や、パフォーマンスの調査に明け暮れるのが、GUIプログラマの仕事になります。また、地頭の良いデザイナーは、自分自身でもプラットフォームの技術仕様書を読み、「あれはどういう意味だ?」、「これは何が嬉しいんだ?」、と徹底的に聞いてきます。
でも、ここが肝心なのですが、それらの技術的質問は、すべて、Whatについての質問なのです。何が、どのくらいの工数で、どのくらいのパフォーマンスで実装できるのか、という質問であり、Howの質問などしないのです。Howなどには、興味がないのです。どんなライブラリを使うのか、どんなアルゴリズムを使うのか、どんなクラスデザインにするのかは、まったく興味なしです。彼らが興味があるのは、そのライブラリやアルゴリズムを使うことで、どのくらいGUIレスポンスが速くなるのかとか、そいういう、ライブラリ、アルゴリズム、アーキテクチャの外部仕様だけなんです。
また、デザイン的に肝とならない部分については、あまり詳しく質問してきません。すべての技術的質問は、そのデザイナーの頭のなかの、デザインイメージと密結合されているのです。
つまり、地頭の良いデザイナーは、デザインをするのに肝となる知識を徹底的に見極めることにこだわっているために、結果としてデザインに関係する技術的知識にも貪欲なだけであって、多くのエンジニアのように、技術そのものに強い興味があるわけじゃないのです。

エンジニアの技術的知識

一方で、エンジニアは、もちろん、こういうGUIデザイナーからの要求に答えるための技術的な知識も蓄えますが、そこだけをやっているわけではなく、もっと別の、実際にシステムをどのように組み上げ、問題なく動作するようにし、また、安定して、手間なく運用できるようにするか、ということにも、たくさんの時間と思考エネルギーを使います。また、開発の生産性を上げるための工夫や開発支援ツールの導入、また、保守性のよいアーキテクチャにするための設計やインフラ構築などにも、気を使います。よいデザインにするために考え抜くことを完全に他人任せにしたとしても、単に決まった仕様を普通に動かせるようにするための「実装」という作業は、それ自体極めて高度な頭脳労働であり、高度な知性と判断能力と膨大な思考エネルギーが必要とされるものなのです。

高い技術力とデザイン能力を兼ね備えた地頭の良いデザイナーはハイブリッド君ではない

上記のような作業の流れになるため、実際には、「技術のデザイン的な意味」についての知識や、技術をデザインに応用する能力は、エンジニアよりも、地頭の良いデザイナーの方が、はるかに高いことも多いのです。もちろん、「デザイン仕様を実装するための技術的知識」では、地頭の良いデザイナーといえども、エンジニアには、まったくかないません。それらは、同じ技術についての知識なのだけれども、同じ知識ではないのです。知覚する人間の意識構造が違うと、同じテクノロジーが、まったく別の知覚オブジェクトとして、それぞれの人の脳内に生成されるのです。だから、すばらしい技術的知識を持つ地頭の良いデザイナーは、エンジニアとデザイナーのハイブリッドなんかじゃないんです。
もちろん、それらの技術は異質ではあるものの、片方の技術理解は、もう片方の技術理解を強力に助けますから、エンジニアの「自分は技術に強いのだからその技術的強みを生かして、デザイナーにはできないようなデザインをしよう」という考えは、地頭の悪いデザイナーに対しては、十分通用するのです。
しかし、それがすぐに、「経験を積んだ地頭の良いデザイナー」のレベルに到達しうるものだ考えているとしたら、それは違うと思うのです。

デザインスキルの蓄積は、容易には超えられない壁

そして、いちばん肝心な点は、地頭の悪いデザイナーだけ見て、「デザインスキルの蓄積なんて意味ない」と思い込むことの恐ろしさです。同じ地頭の良い同士なら、デザインについての思索と洞察を重ねた時間が十分にあるデザイナーと、そうでないデザイナーでは、桁違いの実力差があります。たぶん、同じことは、エンジニアリングについても言えると思います。地頭の悪い場合、キャリアの違いなど、たいしたことはないかもしれませんが、地頭の良いエンジニアが二人いれば、学習曲線の傾斜がキツイために、片方が1年のキャリアで、もう片方が10年のキャリアだった場合、おおきな実力差が生じます。地頭の良い場合、学習・経験が、加速度的に血肉になっていくので、キャリアというものを無視するというのは、非現実的なのです。

エンジニアが自分でデザインしようとしてしまうわけ

にもかかわらず、なぜエンジニアが、「エンジニアにもデザインができる」とか、「GUIをプログラミングするヤツがデザインもいっしょにやるのが上手くいくよ」などというふうに考えてしまうのかについては、以下の4つの理由が考えられます。

(1)地頭の良いデザイナーの供給不足

現実には、地頭の良いデザイナーが、あまりにも少なく、たまにいたとしても、なかなか引っ張ってくるのが難しいからです。*12地頭の良いデザイナーというクジラをとろうとして、結局なにもとれないよりは、「地頭が良いなら誰でもいいから、やらせてみよう。やらせているうちに、地頭の良いデザイナーになっちまうだろ。」という、クジラよりマグロを、という現実的な戦略なのです。これは、ポジティブな側面です。

(2)デザインという行為を理解していると勘違いしている

人間は、自分が十分に知らない専門性を、過大評価もしくは、過小評価してしまうからです。そして、とくに地頭の良いエンジニアは、過大評価ではなく、過小評価をする傾向にあります。地頭の良いエンジニアから見れば、地頭の悪いデザイナーなど、ゴミに見えますから、デザイナーなど恐るるに足りず、と思い込んでしまうのです。

(3)エンジニアの自己正当化

自己正当化の欲求からくる偏見を持っているからです。エンジニアにとって、エンジニアリングは、価値ある仕事でなければなりません。だから、GUIを実装するということが、「下」になってはいけないのです。ところが、デザイナーとGUIプログラマーのペアを組ませると、デザイナーの方が、「上」になってしまいます。たとえ、同じ地位にしたとしても、現実には、デザイナーがプログラマーに指示を出すという関係になってしまいます。それは、「実装の設計」よりも「知覚の設計」の方が、よりユーザに近いところにあるからです。それが、エンジニア的なイデオロギーからは、受け入れられないものなのです。

(4)エンジニアの地位をかけた闘争

それは、単なる自己正当化ではなく、エンジニアの地位闘争という側面があるからです。これについては、この後の章で別途説明します。

Googleと「地頭の良いデザイナーの技術力」の関係

先進国の産業構造における権力集中ポイントは、時代と共に、下流へとシフトしてきています。昔は、メーカーが作ったものを売るだけだった小売業の力が、しだいに強くなっていき、いまでは、逆にセブンイレブンなどの小売業がメーカを支配するという構造になっています。よりユーザの顔の見えるところ、ユーザに直接接することのできるものが、権力を手にするような流れになってきているのです。よりユーザに近いところに、権力がシフトしていくのが、時代の流れなのです。なぜなら、力関係的に、ユーザの実質的なパワー(権力)が、年々強くなっているからです。*13
そして、Web2.0も、この大きな流れの一環であって、それは、権力が、ユーザの手にわたっていく流れの中にあるものなのだと思うのです。だから、マイクロソフトやGoogleなどの技術会社の、ビジネス的な力の源泉をよくよく分析すると、「技術というよりマーケティングの勝利なんじゃないの?」というように見えます。つまり、Googleを成功させた技術力の正体は、エンジニアの技術力というよりも、地頭の良いデザイナーの技術力、あるいは、地頭の良いマーケターの技術力なのではないかと。

「エンジニアがデザインをする」のは、エンジニアの地位をかけた闘争の一形態である

つまり、会社の組織構造を、時代の流れに沿った意思決定システムにしようとすると、権力者であるユーザにより近い職種、すなわち、マーケター、企画、デザイナーが、権力を握るような構造になりがちなのです。知覚構造の設計という作業に比べ、実装構造の設計という作業は、権力者であるユーザと距離が離れているため、どうしても、エンジニアは命令される側になってしまうのです。
そして、それは、エンジニアの地位をかけた闘争という視点から見ると、決してエンジニアが、受け入れるわけにはいかない組織構造なのです。
このため、ソフトウェア開発における意思決定メカニズムにおいて、この時代の流れに逆らい、エンジニアの地位自体を向上させようとがんばりつづけるエンジニアたちがたくさんいます。
そして、もしかしたら、Googleなんかも、その一つかもしれません。しかし、結局のところ、エンジニア主導の会社のはずのGoogleがたどりついたのは、エンジニアのデザイナー化であり、企画屋化であり、マーケター化であるようにしか、ぼくには見えません。Googleは、たくさんの地頭の良いエンジニアを集めて、「デザイナーとしての高い技術力を持つ地頭の良いデザイナー」、「マーケターとしての高い技術力を持つ地頭の良いマーケター」、「企画屋として高い技術力を持つ企画屋」を、「この人たちは、エンジニアなのです」というラベルを貼って養成しているようにしかみえません。ぼくの知り合いの会社のCTOが、エンジニアの地位向上のためにやっている手口と同じです。企画でも、デザインでも、マーケティングでも、なんでも「あれも、これも、技術なのだぁ。エンジニアにもできるし、エンジニアがやることによるメリットもたくさんあるのだぁ」というように、やたらと技術の定義を拡張し、あいまいにし、言葉の定義をどんどん広げていくのです。

エンジニアがデザインすることの本質的な矛盾

この、エンジニアの技術力と、企画屋としての技術力の両方をわざと混同するという戦法で、このエンジニアの地位向上を実現するという手口は、それはそれで一つの戦法であるどころか、実際に、極めて効果的な作戦なのじゃないかと思います。
しかし、これをやると、一人の人間のエネルギーが、実装と企画に、あるいは実装とデザインの両方に分散し、選択と集中が甘くなってしまうのです。つまり、「二兎を追うもの」になってしまうのです。両方やっていると、どちらか片方に選択と集中をしている地頭の良い人には結局敵わないのです。

二兎を追うエンジニアの未来を暗示するあるエピソード

先日、あるエンジニアと、ランチを食べたとき、面白いことが分かりました。そのエンジニアの場合は、技術とマーケティングの二兎を追っていたのですが、結局この、エンジニアとしての技術力とマーケターとしての技術力の二兎を追うことの非効率性を悟り、結局は、自分のコアコンピタンスを、マーケターとしての技術力の蓄積に定め、そこに軸足をおくようになってしまっていたのです。

あとがき

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
というわけで、お約束ですので*14予定通り(そして、ご期待通り)、ひっくり返しました。
で、気分を害された方へのいいわけなんですが、これが、ぼくのブログ記事のスタイルなんです。現実というのは、立体的、もしくは多次元的なのに、記事にするには、分かりやすくするために、平面的にしなきゃならないのが、気持ち悪いんです。その矛盾を解決するために、自分が前に書いた記事を、全面否定するような記事を、いくつもチェインしなきゃならないんです。そうして、直行する平面をいくつも交差させ、少しでも立体化、あるいは多次元化させることができたらと思うんです。
そして、逆順に記事を思いつくこともあります。だから、ある記事を書きたいと思ったら、その前に前フリの記事を書きます。その記事は、あらかじめ、自分自身で、全面否定することを予定して書きます。*15
そういう記事の書き方をすると、はてなの方からは、「ネタ」とか「釣り」とか言われてしまいます。たぶん、それがはてな的な定義なんでしょう。だから、そういわれても仕方がないし、最近は、自分でも、ネタでしたwwwとか、釣りでしたwwwとかいうようにしています。
そして、この記事自体も、はてな用語で言うところのネタであり釣りです。なぜなら、このあと、この記事の内容を全面否定するような記事を、また書く可能性があるからです(気が向いたらですけど)。

*1:人は、自分の利害が関係している議論を冷静に行うことができません(もちろん、わたしを含めて)。すなわち、無意識のうちに、自分を正当化する理屈には安易に賛同・同調し、自分を否定する理屈には脊髄反射的に反発してそれを否定するための屁理屈を探してしまうものなのです。このため、これらの記事に賛同した人や反発した人の中には、安易な賛同や脊髄反射的な反発をしてしまった時点で思考停止してしまっている人が一定数含まれている可能性があります。

*2:もちろん、アナロジー(比喩)を使った説明は、あらぬ誤解を招く危険性もありますが、一方で、それは適切に使うと、極めて効果的なことも、また現実だと思うのです。

*3:この問題のもう一つの難しさは、冒頭に述べたように、それが、エンジニアとデザイナーの利害に関係していることです。だから、冷静に議論することができません。したがって、いきなり、デザイナーの目から見た「エンジニアがUIデザインすること」について記述すると、デザイナーは単に感情的に共感し、エンジニアは単に感情的に反発するという、いつもの、「デザイナーの自己正当化ロジック」という決めつけで終わってしまうリスクがあります。この「利害関係が発生させる認識障壁」を壊すため、「お互いさまだろ」という空気を創り出す必要があります。その意味からも、エンジニアの視点から見た「営業や企画が技術的判断をすること」を最初に取り上げる必要があると考えました。

*4:小さな会社で、CTOががんばってすべての案件に目を通している場合や、大企業で完成度の高い業務体制を築き上げている場合、これがほとんど起きない状態もあるんですが、そのことのありがたさを十分に理解していない社員というのがたまにいたりしますね。

*5:もちろん、その意思決定は、エンジニアチームの技量まで推し量った上で判断すべきなので、そんな簡単な話じゃないのですが、ここでは、単に説明のための比喩として使えれば、それでいいかな、と。

*6:もちろん、だからと言って、営業や企画の人間にプログラミングができるわけでも、システム設計ができるわけでもありません。

*7:実名を上げるのは問題がありすぎるので控えさせていただきます。

*8:だから、天動説でも辻褄があったり、「天球儀」のように天動説をモデル化した方が物事の理解が分かりやすくなるように、客観的世界というものを仮定しても、辻褄があうだけではなく、むしろその方が分かりやすいこともある。だから、人間の行動を規定するのは人間の環境である、などと、外部の客観世界から見る見方もいろいろあって、それぞれそれなりの説得力があったりする(ないやつもあるけど)。詳しい議論は略。

*9:多くの人が、客観的世界を主観的に知覚していると思っているけど、そもそも、客観的な世界などというものは、存在しないんです。単に人間の意識が、世界を境界線で区切り、塗り分け、「世界を創造している」だけなんです。それが世界と呼ばれるものの正体であって、そこには主観も客観もないんです。だから、個々の技術やデザインやビジネスモデルを、主観的ではなく、客観的に認識できているかどうか、なんていうことに悩む必要はないんです。客観がそもそも存在しないんだから、主観なんていう対立概念を考えるのも意味がない。主観←→客観という、ものの見方そのものが、そもそも大きな勘違いなんです。主観←→客観という精神の牢獄からいったん外へ出て、その外側から眺めてみないと、見えてこないことがたくさんあると思うんです。そいて、ついでにいうなら、リアル←→バーチャルというのも、かなり危うい対立概念、ものの見方、あるいはわれわれの思考を閉じ込める檻だと思うんです。

*10:ついでに言うと、人間は文章を「読む」ことはできない。「理解」することもできない。人間ができるのはただ「その文章の解釈を創造すること」だけです。

*11:ツールバーは、HTMLではなく、ネイティブアプリなのでネイティブアプリならではのUIデザインができるのと、それがHTMLサイトと連動して動作するものであるというのと、それがブラウザと連動して動作するものであるというのと、ローカルにインストールされているという性質を効果的に利用したUIが可能であるというのとか、いくつかの条件が重なっているため、それを総合的に考えてその持ち味を十分に引き出したシンプルで美しいデザインするのは、なかなかニッチな技量がいるかもしれないとかなんとか?。。見当違いな妄想ですねwww。ま、説明のための比喩ということで。

*12:報酬額の問題もありますが、仕事内容自体に十分なデザイナー的な魅力がないので難しいことが多い

*13:これは、ぼくのごく個人的な見方(勘違いとも言う)としては、(1)ケータイとインターネットによるユーザの情報判断能力の増大(たとえば、電子辞書を買う場合、ケータイですぐに電子辞書に詳しい友人の知見を聞ける、ネットの口コミ掲示板、などなど)、(2)ユーザがものを買うのに、より「時間」をかけるようになった(よく調べて、比較してからモノを買うようになった。しばしば店員よりも(笑)。)、(3)モノあまり(同じカテゴリのモノがあふれ、ユーザは選べるようになった。選ばれる側は、選ぶ側に服従するしかない。)、というあたりが要因ではないかと妄想しています。

*14:ぼくの記事を以前から読んでいる人は、みなさん、分かっていると思いますが

*15:その際に、記事が分かりやすくなるように、自分の中に、人工人格を作り上げて書くことも多いです。漫画家や小説家が、キャラクターを設定し、そのキャラクターにしゃべらせるというやりかたです。だから、ぼくの各記事は、互いに矛盾しているだけでなく、正反対のことを言っていたりします。でも、マンガや小説の登場人物は、それぞれ思想や性格が異質だからこそ、作品に深みがでて、おもしろくなるものだと思うので、ぼくが、書き手の人工人格を練るときも、実際の自分とはかけ離れた意見や思想を持つ人物として、設定することが多いです。