読者です 読者をやめる 読者になる 読者になる

道産子エンジニア

毎週好きなこと書きます。

なぜデザイナーとエンジニアは分業するのか

CyberAgent エンジニア Advent Calendar 2015 の6日目の記事です。前回はblackenedgoldさんのScala初心者の新卒が頑張ってLispを作ってみたでした。

kaelaela (Yuichi Maekawa)Androidエンジニアをしています。


なぜデザイナーとエンジニアは分業するのか

僕が思うに、デザイナーとエンジニアは「ものづくり」という卵から生まれた一卵性双生児だ。間違いない。 なぜ、お互いに似ているようで違うということを意識しながらも、時にぶつかり合い、時に励まし合うのか。 自分の現場での体験と調べたことを元にデザイナーとエンジニアの「決定的な違い」について書く。

注意していただきたいのは、僕が根本的に違う星の生き物だと思う「ビジネス(ウー)マン」に向けては書いていない。 なのでこの記事を読んでもらうのは嬉しいが、質問には答えれないし、議論もできない。 ビジネスの考え方を批判しているわけではなく、むしろ、お互いに意識しているものが違うだけだと思っているし、 ビジネスとの掛け合いに関する質問や議論は、まったく別のアプローチや場で思考しないといけないからだ。

この文章はものづくりの現場にいて、なぜか感覚的に捉えようとするデザイナーとぶつかってしまうエンジニア、 なぜかエンジニアの理論武装に同意できないデザイナーへ向けた、一人のエンジニアとしての意見と、 ものづくりという観点から意識すべきことをまとめたものだ。好きな飲み物とお菓子をかじりながらふ〜んと読んでもらいたい。 残念ながら、文字を書く仕事をしているが、文章を書くことについて専門ではないので、 誤字脱字といった美しくないものを見つけてしまったら、ご報告いただけると助かる。

まずは結論

僕の思う答えは二つある。

  1. お互いの役割を理解し、分担してそこに集中して作業を行うため

  2. お互いにゾーンに入ったとき、暴走から連れ戻してもらうため

最初の大きな勘違い

お互いにぎこちないコミュニケーションをしているデザイナーとエンジニアの多くは、 「デザインする」=「目に見えるものを作ること」だと勘違いしているように思う。 そしてエンジニアはよくわからない難しいことをしているとも勘違いしているように思う。 デザイナーもエンジニアも最終的に見えるものを作るが、その作業の多くは見えないものだ。 そして、その作業はほとんどは「なぜそうするか」という原理に基づいて考えられ、 それを ユーザーが無意識で消費して体験できるように隠蔽 している。 だから美しい

僕はデザインするということは ユーザーがモノを通じて感じる体験の邪魔するなぜ? を解決する一連のプロセスやその成果物を作ることであると考えている。

下のすぴかあやかさんの記事は、オリンピックロゴ問題の文脈で語られたものだが、最後のまとめの文章がここで言いたいことにマッチしている。

デザイナーへの批判に「デザインをわかってない」とは言いたくない|デザイナーのイラストノート

私としては「デザイナーの仕事」自体が一般的でなく見えにくいものであった、という事に気がついた一件でした。それを嘆くよりも、どうやってデザインの価値をわかりやすく伝えていくのか、そういうところに注力していけたら、今後こんな事があったときに活かしていけるのではと思います。

エンジニアもデザイナーも美しく設計された魔法を人に説明する、見てもらう努力をわざとしていない。 それはユーザーに対して有効かもしれないが、仕事をするときはそれをお互いに理解する必要がある。この共通認識からスタートしていくべきではないだろうか。

余談だが、すぴかあやかさんの比喩にはケーキとケーキ職人が多く登場して、その度にケーキが食べたくなる魔法にかかってしまった。笑 これもまたデザインされているのかもしれない。

  • デザインとは見た目を作ること「だけ」ではない

  • デザイナーもエンジニアもその作業の多くは目に見えないモノを作っている

キャンバスとコンソールは同じ

「黒い画面」と聞くとなぜかドキッとしてしまう人は多いかもしれない。(エンジニアでも一定数いる)僕は同じようにキャンバスと聞くとドキッとする。 自分には真っ白なキャンパスに筆を下ろす自信はあまりない。またすぴかあやかの記事から引用すると、

デザイナーのわたしがターミナルをこわいと思っていた話|デザイナーのイラストノート

使わなくても生きていけるじゃん、なんで?というと、Githubのあるリポジトリにプルリクエストを送ろうとしたとき、手順説明がコマンドだけで、GitのGUIツールSourceTreeを使っていたわたしは「フォークしたリポジトリに追従する」というボタンをどうしても見つけられず、苦労したことがありました。GUIツールがあるものでも、なるべくコマンドで触れておいた方が話がしやすいなと思ったきっかけです。

ほんの少し、自分の不便を解消しようと思っただけでももしかしたら見える世界が違うんじゃないだろうか。

絵を描ける人はペンを持つと何をすればいいか、どこから描けばいいか、 最初の一筆がどこへ向かうべきかわかっている。プログラムを書ける人は、キーボードに触れると何をすればいいか、何から書けばいいか、 最初の一文字をどこへ打てばいいかわかっている。キャンバスとコンソールはその白さ、黒さのおかげで創造を駆り立てる媒体なのだ。

もしかして、やり方、使うもの、考え方が違うだけで本質的に同じことをしているのがデザイナーとエンジニアではないだろうか。お互いの共通点をどんどん見つけていくことが、お互いの理解につながると僕は信じている。

デザイナーとエンジニアの違い

WEB+DB PRESS vol.89の161ページからリクルートライフスタイルが作るAirレジに関する、 UXのこだわりや開発の話が書かれている。そこではユーザー目線であることの大切さを伝えながらいい言葉が書かれていた。

「すべてのUXやモノのデザインはちゃんと理由が説明できるはずだ」

これは確かにそうだなと共感して読んでいたが、そのあとこうも書かれている。

直感や主観に落とし込むのではなく。背景を理解した上でUXを考えていく

これについては少しだけ違うように感じた。

僕のチームでプロダクトデザインの責任者はよく「〜を見たことがない」とか「違和感がある」という。 実際、自分も同じように感じる部分が多く、あとからその違和感について考えてみると説明ができる。 僕はそこにデザイナーとエンジニアの共通点と「考え方の違い」について発見があった。

その発見とは デザイナーの直感とエンジニアの閃きは同じ かもしれないということだ。

閃きと直感の違いについては池谷裕二さんの本を読むとよく出てきて、わかりやすく解説されている。 脳科学的に直感とは、ストリアツムが膨大な計算を行って、無意識に何かの選択を正しいと判断することだそうだ。 また閃きとは、一つ一つの現象の理由を説明できて、それらを組み合わせたときに新しい答えが見つかる思考のことだそうだ。

両者の違いを一言で言うと 「直感はなぜ?を説明できないが、閃きはできる」 ということだ。

将棋の羽生さんは「思いついたあとに、なぜ正しいか考える」という。 デザイナーとエンジニアはこの順番が違うだけで同じことをしているように思う。

デザイナーは膨大な情報のインプット、アウトプットを繰り返し、 プロダクトが表現しようとしているものに対して直感で良し悪しを判断している。そしてこれは経験が多いほど間違っていないことが多い。なぜなら直感の方が情報の計算量が大きいのだから。

エンジニアは情報の悪魔に取り憑かれ、小さな問題を即時に解決することを日々行っている。そのおかげで、レゴブロックで何かを作るスピードがとても速くなっている。プログラミングはなぜ?を高速で解決していく、反復練習のように思う。

両者の良い部分を生かして、二つのことを考えた。 - エンジニアの丁寧に説明するなぜ?を直感で表現するのがデザイナーであるべきではないだろうか - デザイナーの直感にまとわりつくなぜ?を一つ一つ解決して閃くのがエンジニアであるべきではないだろうか

両者の決定的な違いは 直感型思考なのか、閃き型思考なのか だけだと信じ始めている。あとはやりかたが違うだけかもしれないと。

なぜ分業するのか

僕がデザイナーとエンジニアの違いを意識するようになったのは大学の頃だと思う。デザインのコースもあったので、普段から分担して何かを作ることが多かった。そして、その時はまだデザインを任せてしまって、自分はコーディングに集中すべきだと考えていた。去年の3月に発売した、 MdN vol.240を見たとき、キルラキルのタイポグラフィへかけるグラフィックデザイナーの仕事に感動した。奇抜なデザインというだけではない、メッセージをもっている。ラグランパンチのフォントを使っているというのは知っていたけど、それにもっともっと工夫を加えて作品の世界観にマッチさせている。エンジニアが見えにくいけどパフォーマンスを改善していく地道な作業に共通点を強く感じた。

最近は仕事で、デザインを検討しながら実装して、実装してまたデザインを検討するというプロセスを繰り返している。 そうするとふと気がつくことがあって、自分の専門でものづくりに集中すると驚くほど周りが見えなくなるということだ。 そのとき、デザイナーと一緒に議論すると、本当は何をしようとしていたのか思い出す。 デザイナーに限らず、他のエンジニアと話しているときもそうだ。自分はとっても利己的で、自分にとって良いものを作りやすい。 冷静にユーザーにとって良いものを作ろうとしたとき、お互いの深い専門性が邪魔をして、本質を見失ってしまうことがある。 だから議論して、問題を捉え直して、本当に必要なことは何か?を再認識して修正していくべきだ。

僕はデザイナーのほうがすごい、エンジニアのほうがすごいとか、デザイナーにしかできない、エンジニアにしかできないとは思わない。 尊敬をしていないわけではない。お互いにしあうべきだと思う。でも、似ているけど違うということを意識すべきだ。

それぞれやってきたことと考え方が少し違っただけだ。 「良いものを作る」上で多くの共通点を理解しあい、 お互いのカバーし合えない専門性から生まれた少しの「考え方の違い」から、もっと良いものを作るために分業しているんだ。

僕があえて分業と書くのは「デザインする」=「良いものを作る」という点において同じことをしているから、 やっていることは違えど、全く別の世界の作業だという認識がおかしいと思うからだ。

サイバーエージェントでは、デザイナーとエンジニアが寄り添ってものづくりをする環境が、 少しずつ増えてきている。これはとてもいいことだと思う。僕は上司が満足するものじゃなく、ユーザーが嬉しいものを作りたい。 自分は会社員だが、同時にものづくりをする人であるということを忘れないで開発していきたい。 そのための鍵をデザイナーとエンジニアが握っていると僕は信じている。

デザイナーとエンジニアの架け橋

デザイナーがエンジニアに、エンジニアがデザイナーに歩み寄ったとき、その考え方の違いを理解したとき、 そのシナジーが生み出すプロダクトの美しさは極限に達すると思っている。そしてたいてい、それをビジネスが徐々に醜くしていく 。そうならないために自分が準備し、普段から実践するのに役立った文献や記事を載せておく。デザイナーとエンジニア的にのもっと抑えるべき、それぞれの主張が強いものもたくさんあると思うが、共通点と相違点を的確に表していて読むのが簡単なものを選んでいる。

デザイナーというのは基本的に情報の整理整頓が仕事である

という考え方を教えて貰った本。また、マヨネーズの星形について、 石油からできた容器、養鶏から始まるマヨネーズ作りの果てであるとかいた次の文章もすごくかっこいい。

壮大なプロセスの果てに「ぴゅっ」と絞り出される小さな結末。勝負は一瞬である。まあ、本当に他愛ないことだが物事の性質は、このような一瞬に左右される。…デザインの小さな哲学はそういう場所に潜んでいる。

最後のほうでは、数学とデザインについての話が出てきて、より一層、 デザイナーとエンジニアの共通点が発見できるのでおすすめ。

脳科学を知ることは自分の思考プロセス、相手の思考プロセスがどうなっているかを俯瞰するのに役立つ。

強調すること、整頓することの大切さを説いた本に感じた。そして、 細かい整列、グルーピング、強調などを繰り返していくことはリファクタリングのそれと同じじゃないか!と気がついた。

僕が書いたこの記事の冒頭は、この本の影響もすこし受けている。エンジニアにとってのバイブル的な本だ。 デザイナーの人に是非読んでほしい。アメリカ志向が強すぎる部分もあるので、適宜はしょってもらえばいい。後半は多分読みにくい。

すこし僕とは意見が違うと思うが、エンジニアの立場から自分たちを理解してほしいと思う歩み寄りの一つだと思う。

プログラマーとデザイナーの関心領域の違いについての図があるが、 これがもっともっと近づいて、ほとんど重なった状態になるべきだと思う。しかし、完全に重なってはいけないということが重要。

たびたび登場したすぴかあやかさんのブログ。デザイナーの仕事、考え方をイラストと一緒に紹介してくれて、とても参考になった。

他にもいろいろ


以上です。次回はstormcat24さんのWebアプリをDocker構成にした場合にフロントエンドリソースを扱うためのデザインパターンです。

stormcat.hatenablog.com