こんにちは、sKawashima（@_sKawashima）です。
最近、たまに「開発とデザインの両方ができる人材は強い/弱い」みたいな記事を見かける気がします。
実際出来ることが増えることは良いことだとは思いますが、特にデザイナーはそれによって失うこともある気がします。
そんなわけで、「デザイナーがエンジニアリングを学ぶメリットとデメリット」を考えてみました。
少しでも自分が何を学ぶかの参考になれば幸いです。
この記事は「くふうカンパニー Advent Calendar 2019」の3日目です。
https://qiita.com/advent-calendar/2019/kufu
この記事は、ルームシェア相手にして普段グラフィックデザイナーやりつつ業務としてUnityなどの開発を経験がある友人との対談を元に執筆しています。
協力ありがとう。
この記事は個人ブログの記事の転載です。
https://skawashima.com/blog/2019/12/designer-develop
個人ブログの方にはコメント記事がまだ無いので、Qiitaにも投稿しました。
自己紹介
僕は2019年4月にくふうカンパニーのみんなのウェディングにUXデザイナーとして入社し、8月からZaimにデザイナーとして出向している、新卒デザイナーです。
先日リリースした面白いデータを発信するサービス「Zaim トレンド」アルファ版では、デザイナー兼フロントエンドエンジニア（ちょくちょくReact書いた）として開発に関わりました。
たまにSQL叩いてデータの検証もしてました。
このサービスでは、リポDが買われる時間は極端に16時に偏っている、みたいなデータが見られます。
興味がある方は是非覗いてみてください（圧倒的宣伝）。
また、先日出場したハッカソン「SPAJAM2019」ではサーバーサイドエンジニア（Node.js/TypeScriptとMongo in Dockerで画像受け取れるCRUD API作っただけ）として参加し、チームとして全国優勝を果たしました。
ちなみに、対談相手はこのハッカソンで同チーム内のデザイナーとして参加し、開発するアプリのUIとめっちゃわかりやすい発表プレゼン資料を作っていました。
彼も色々と開発経験があるなどエンジニアとしての側面を持っています。
そして、何のとは言いませんが二人して適合者です（某アニメネタ）。
では、早速始めていきましょう。
デザイナーがエンジニアリングを学ぶメリット
整理してみるとわかりますが、ほとんどUX/UIやWebを扱うデザイナー目線の話ですね。
プロトタイピングができる
エンジニアやUX/UIデザイナーなどの人は画面一覧とその説明だけでなんとなく画面遷移をイメージできます。
ですが、そうでない人にとって画面と画面のつながりをイメージすることは簡単ではありません。
これはデザイナーとして考えたアイデアを人に説明しようとしたときに痛感できます。
だからこそ、動くものを作って見せられることはとても大切で、それを実際に動く形で見せられることは理想だと思います。
とはいえ、最近はツールの進化に伴ってそのメリットが弱まってきたように感じます。
例えば、SketchやAdobe XD、Figmaなどは単純な画面の遷移の再現がとても容易になっています。
また、AtomicやFramerなどを用いれば画面遷移間中のアニメーションまで表現できます。
さらに、STUDIOなどのGUIでWeb開発できるツール群はレスポンシブなどに対応し始め、復活しつつあります（STUDIOは少なからずHTML/CSSの基礎程度の能力が求められている気もしますが）。
言い換えれば、開発に手を出さなくとも、アイデアを動かしてみせるためのツールを扱う能力は必須ということです。
ただ、開発に手を出してしまえばプロトタイプのその先、実現も視野に入れられるということは確かですね。
工数を意識したデザイン提案が出来る
開発経験があれば、どういう開発が大変であるか、大変でないかを想像できます。
なので、「理想はこういうデザインだけど、時間が足りないならこっちのデザイン」のように段階的提案をすることが出来るようになります。
さらに、開発に用いられるライブラリを調べる能力、ドキュメントを読む能力が有ればこれは一気に飛躍します。
エンジニアにとってのライブラリとそのドキュメントとは、デザイナーにとってのデザインのパーツライブラリです。
エンジニアがどういった技術（言語やすでに使用しているライブラリ）で開発しているのかを知り、それに対応したライブラリを探すだけで、開発工数を一気に理解できます。
エンジニアの手札からアイデアを得られる
↑でさらっと「ライブラリを調べる」「ドキュメントを読む」という話を出しました。
エンジニアは当然のようにやってますが、意外と僕の周りのデザイナーはそれらを調べてないらしいんですよね。
理想のデザインのために色んな事例を調べるという行動はデザイナーの仕事の中でよくやることですが、たまにはライブラリなどを調べてみるのも悪くないです。
特にUIを伴うライブラリ（CSSフレームワークも含めて）は、デザインの知識がないエンジニアが扱えるように作られているものが多く、少なからず参考になります。
少なくとも、網羅性がすごいのでアイデアのきっかけにはなると思います。
エンジニアと議論ができる
エンジニアもデザイナーも、独自の世界の中での用語を使いがちです（戒め、本当に注意したい）。
これは、単に理解できない単語が使われるだけでなく、ある単語を別の意味で捉えている場合も含まれます。
例えば、同じ「デザインパターン」という言葉をとっても、エンジニアとデザイナーはそれぞれ全く別の概念を想像しそうです（これに関しては、デザインという言葉が便利に使われすぎてよくわからなくなっているのも否めない）。
こういったときに、両方の言葉を理解できる人が一人いるだけでコミュニケーションが一気に捗る気がします。
ファイルの命名ができる
これは同居人が割と強く推していたもの。
Webというよりはアプリ開発の方で納得できそう（ほとんど関わったことがないから僕はあまりわからない）。
同居人がスタートアッププロジェクトにエンジニアとして参加した際に、関わっていたデザイナーがファイル名に規則性のない色んなパーツの画像をアップロードしてしまい、困ったという体験談が出てきました。
Web開発ではある程度CSSで書けてしまうようなボタンなども、アプリ開発では画像パーツにしてしまうことがあるらしく、そういうときに困るとのこと。
パーツの場所や状態による違いを伝えやすくするという意味では、最低限いくつかのCSSのクラス命名について勉強しておくと幅広く活かせるかもしれません。
デザイナーがエンジニアリングを学ぶデメリット
さて、打って変わってデメリットの話です。
昨日、先輩に「こういう記事を書いてるんですよ〜」と話しかけたら「デメリットなんかねえよ」と一蹴されたりしましたが、僕は少なからず感じていることがあるのでそれを並べていきます。
頭固くなる問題
開発を触ってしまったことで、開発前提だからと良くあるデザインや自分が作れそうなデザインしか作れなくなる現象です。
妙に固く考えてしまって、既存の飽きられた枠組みにカチッとハマってしまう感じ。
たとえば、先日自分がとあるツールのデザインをしていてこつこつ色々組み上げていたときに、エンジニアの人がふと落書きで「こんなのとかどう？」と見せてくれたものに「めっちゃええやん…自分が作ってるコレよりええやん…」とちょっとショックを受けたりしました。
（良いところはもらいつつ、自分の組んでたデザインの意図と組み合わせてなんとか形にしました）
開発経験があると、気づかないうちに陥ってることがあります。
ので、最近はデザインするときに「夢や無茶を語るモード」で一旦広げるフェイズを設けるようにしました。
PC内で作業するとどんどん硬くなるので、PCを閉じて紙とペンで枠にはまらないアイデアを作るよう意識しています。
どっちも中途半端になる（時間、金、体力）
これは明らかです。
人一人が使えるリソースは限られています。
そして、何でも出来る人は何にも尖っていない人に映りがちです。
スタートアッププロジェクトみたいな人材が足りていない/分業が成立しきっていないような場では活躍できるかもしれませんが、プロジェクトが成熟したときに存続できなくなりそうで怖いです。
なんせ、幅を広げずにある1点だけに集中できる人には、その1点については戦えないでしょうし、そういう人材を幅広く集められるならある意味の「チーム」として理想形を作れそうですから。
ただし、少なくともUIやWebを扱っているなら1点に収まるなんてことはまず無いはずで、その時点で幅が広がっていることを自覚すべきだとは思います。
だからこそ、軸をどこに置くのかは大切にしていきたいですね。
デザイナーなのかなんでも屋なのか、或いはアイデアを広げるのか固めるのか、或いは――。
自分はまず何が出来るようになるのか――ある種のデザインについてはまず「出来る」と胸を張れるようになる、みたいな漠然としたもので良いと思っています。
僕は、少なくとも「UXデザイン」に軸を置いたつもりです。
なんせ、デザイナーは理想を語れる役職で、UXデザインなんてその根本です。
その理想を実現する仕組みを語れれば、色んな事ができそうで楽しそうじゃないですか？。
どこからやればいい？
散々、メリットとデメリットを語りながら手がかりに触れないのはどうかと思ったので追記してます。
勉強しようと思ったときは、とりあえずドットインストールなどの基本が学べるサービスを使いつつ、作りたいものを作ってみるという活動が一番だと思います。
本当にシンプルなものでいいので、チャレンジしてみると色々見えてきますよ。
おまけ：エンジニアがデザインを学ぶメリットとデメリット
これ、案外考えてみたことなかったです。
実を言うと、僕は中学2年の頃に「Perlの絵本 Perlが好きになる9つの扉」という本に触れたのをきっかけにエンジニアリングを学んでから大学2年でデザインコースに所属し転向した身なので、どちらかというと僕はエンジニアがデザインを学んだ人にルーツは近いんですよね。
そんなわけで、本当におまけ程度、ざっくり触れていきます。
エンジニアがデザインを学ぶメリット
仕組みをエンジニア以外に伝えることができるようになる
どういうデータのやり取りが起きているのか、どういう仕組みが動いてるのかについて、フロントエンドの人やデザイナーに語れるようになります。
現状でもUMLとかありますが、あんな分かりにくい図解は世の中探しても珍しいです…。
数式みたいな感じで、余分なものを削ぎ落とした形と言えばたしかにそうですが、デザイナーに対して「なぜそれが難しいのか」「なぜそれが簡単なのか」を主張するときなど、伝えるための図解能力などは色々と武器になるスキルな気がします。
自分で自分が作るものをデザインできる
最高でしょ？
これを諦めているエンジニアを何故かそれなりの数見てきました。
が、少なくとも工学的な、ユーザーのためのデザインであれば、少し日常の意識を変えるだけである程度考えられるようになると思います。
なんせ、普段自分がユーザーとして使いやすいと思いながら使っているアプリやツールのデザインがそのまま教科書になりますから。
と、難しいことを考えなくても、まず「ゲシュタルトの法則」を調べてみるとそれだけでも色んな見え方が変わるかもしれません。
是非。
同居人いわく「ゲシュタルトの法則は義務教育で教えるべき」とのこと。
エンジニアがデザインを学ぶデメリット
時間、金、体力
そらそうよ。
逆に、それ以外のことは思い浮かびませんでした。
はい。
はいじゃないが。
どこからやればいい？
先にも話題に出しましたが、「ゲシュタルトの法則」を軽く読むだけで世界が変わって見えます。
内容は被りますが、「ノンデザイナーズ・デザインブック」は名著なので読んでみるとよいかと思います。
以上です
とまあ、最後は駆け足感がありましたが、読んでいただきありがとうございました。
途中から勢いで書いてるので穴だらけかもしれませんが、大目に見てください。
リソースを何の経験値に振るのかは一人ひとりが決めるものだと思うので、少しでもその参考になれば幸いです。
自分のブログの方にはまだコメントつける機能つけてないので、是非Qiitaの方でコメントをお願いします。
では。