【前編】エンジニアの会社でデザインがうまくいくワケ〜「エンジニア病」にはダメ出しされよう
ソニックガーデンはプログラマが中心の会社です。そのため「デザインはどうしているの？」という疑問を持たれる方が多くいらっしゃいます。すべての工程を担当するのが「納品のない受託開発」のポイントですが、デザインは一体どうしているのでしょうか。採用に応募するエンジニアの方も、「デザインセンスに自信がないが、自分ひとりですべて出来るのか」と不安に感じているかもしれません。
そこで、今回はソニックガーデンで一緒にお仕事をさせて頂いているデザイナーの方をお迎えして、「納品のない受託開発」でのデザイナーの役割について、現場のエンジニアと共にお話を伺いました。
エンジニア×デザイナーの会社が流行ってきている！？
倉貫
今日は一緒にお仕事をさせて頂いているデザイナーさんお２人をお招きして、ソニックガーデンのエンジニア３人と一緒に、３つのテーマでお話を伺おうと思っています。
倉貫
１つ目のテーマは
「エンジニアだけの会社で、デザインはどうしているのか」
。２つ目は
「エンジニアから見たデザインの謎」
。３つ目は
「エンジニアにデザインを教えるデザインメンター制度」
です。まずは最初に自己紹介をお願いします。
町田
町田哲平と申します。合同会社フィヨルド(
http://fjord.jp/
)という会社でデザイナーをやっています。
倉貫
フィヨルドさんは何人の会社ですか？
町田
エンジニアと僕（デザイナー）の２人だけの会社です。
「怖話」などのサイト運営やアプリ開発をしています。
倉貫
なるほど。
エンジニアとデザイナーがコラボするやり方は、そこでもう確立
されているんですね。
町田
そうですね。
赤塚
赤塚妙子です。フリーランスでデザイナーをやっております。
デザインメンターというのを2014年からソニックガーデンさんと一緒に始めました。他にも何社か一緒にやらせてもらっています。
他にesa.ioというウェブサービスを最近作り、それを会社にしました。
この会社も、エンジニアと２人の会社でやっているんです。
倉貫
なるほど。
最近流行っているんですね、エンジニアとデザイナーがコラボする会社。
倉貫
赤塚さんは他に、pplogも運営されていますよね？
赤塚
そうですね。pplogもやっています。
遠藤
遠藤大介です。ソニックガーデンのプログラマーをやっています。赤塚さんにはデザインメンター制度で、町田さんとはメンターというよりは、直接町田さんにデザインをしてもらうという形でお世話になっています。
松村
ソニックガーデンＣＴＯ松村章弘です。町田さんとはチームとして組んでお仕事を一緒にさせて頂いてます。赤塚さんには最近メンターとしてお世話になっています。
前田
前田 直樹です。ソニックガーデンのプログラマーです。今のところ町田さんとはまだメンターとしてはご一緒していないですね。赤塚さんとは、デザインメンターという形で２案件を一緒にやらせて頂いています。
倉貫
なるほど。先ほど出た
「デザインメンター」
というキーワードがあまり聞き慣れない言葉なので、それも後ほど詳しく聞きたいと思います。
デザイナーにしかないヒアリング能力がある
倉貫
では１つ目のテーマ
「エンジニアだけの会社でデザインはどうしているのか」
について。「納品のない受託開発」だったり、自社サービスにおいて、
エンジニアとデザイナーは具体的にどういう役割分担で、どういう仕事の進め方をしているのか聞かせてください。
松村
「納品のない受託開発」はスタートアップのサービスが多いので、トップページからアプリの中身まで全部作ります。まず一番難しいのはトップページですね。そこの部分に関してはデザイナーの方に主導でやってもらうことが多いです。
そこのノウハウはデザイナーの方でないと、なかなか対応しきれない部分があるかなと思います。
倉貫
機能じゃないっていうことですよね？
松村
そうです。
ユーザーにどう見せるか、ユーザーをどう流入させるかという部分については、トップページの絵をどう選ぶかとか、私にはまだよく分からない部分が多いので。その辺はほとんどデザイナーの方に描いてもらいます。
アプリの中は、僕らが最初作ったところに、一旦デザインをあててもらって、それを更にディスカッションしながら「いや、お客さんはこう言っているんですよね」「なら、こうしましょうか」という風に徐々に作り込んでいく感じです。
倉貫
最初にお客さんだったり、プロダクトの責任者が決めていく感じになるのかな。具体的にはどういう風に進む事が多いですか？
松村
案件によって違いますね。「納品のない受託開発」の場合だと、最初のところはプログラマーとお客さんで進めていきます。色々話が進んでいって、アプリをある程度作り上げていく中で「やっぱりトップページも必要ですよね」という話が出た際に、デザイナーさんに入ってもらうことが多いです。
倉貫
お客さんとの打ち合わせに、デザイナーさんに同席してもらって一緒に話をする感じ？
松村
そうです。同席して頂くパターンもあるし、同席しないパターンもあったりしますが、やはりそこは
お客さんとデザイナーさんで直接話してもらって、いろいろヒアリングしてもらう方が効率がいいですね。そのヒアリング技術が難しくて、僕らにはできないところがあるなと感じています。デザイナーにしかないヒアリング能力があるんですよね（笑）
デザインのヒアリングでもまず聞くのは「どう儲けたいか」
倉貫
その最初の
トップページを作る際のヒアリングというのは、どういうことを聞くんですか？
町田
それもアプリによってバラバラですけど、
「どう儲けたいか」ですね(笑)
倉貫
デザインなのに「どう儲けたいか？」のところから入るんですか？
町田
やはりそこに尽きますね。
どういう問題を解決するのか、ターゲットは誰なのか決めて、そこからシステムの場合はプログラムにしますよね。デザイナーはそれをデザインに落としこむわけです。プログラマーもデザイナーもやっていることは変わらなくて、ただ実装方法が違うのだと思っています。
倉貫
デザインは目に見える部分のところですが、
まず聞かなきゃいけないのは最終的な落とし所というか、そのサービスで何をするのかという部分
なんですね。最初に目的を聞いて、その目的に応じて色んなデザインの選択肢から選んでいくのですか？
赤塚
例えばお客様が「赤にして下さい」と言っていても、
何のために赤にするっていう理由が分かっていないと、正しいデザインはできません。本当は赤にしない方が、その目的に対して効果的かもしれない。
そこはなぜ赤なのかを深くヒアリングしているうちに、お客さん自身が何をやりたかったのか分かってくる場合もあって楽しいですよ（笑）
キャッチコピーからデザインのイマジネーションが湧いてくる
赤塚
やりたいことをきれいな言葉に変換することも大事だと感じています。つまり、キャッチコピーを話しながら掘り起こしをするんです。「このサービス、一言で言うとなんですか？」みたいな感じで。
倉貫
キラー質問ですね（笑）
前田
これがバシッと決まると。。。
町田
あとは早いですね！
赤塚
そう。あとは突き進む感じです！（笑）
前田
それがバシッと決まったところで、僕らはイマジネーションは湧かないですけどね(笑)
倉貫
バシッと決まったキャッチコピーはあるんだけど、それが緑なのか、赤なのか、プログラマーにはイメージできないって事かな？
遠藤
イメージが湧かないですね（笑）表現の仕方として、最近はこういうのが流行りだと分かっても、幾つかある選択肢のどれがベストなのか判断できないんだと思います。
赤塚
理由の基準をいくつか決めておいてあとは、わりと消去法ですね。
遠藤
これはここらへんが違って、こっちはここらへんが違うから、残るのこれ、っていう感じですか？
赤塚
そうそう。わりとそういう感じが多いかも（笑）
要らないものを捨てることで本質を際立たせる
町田
何を捨てて何を残すのか、それはすごく大事ですね。かっこいいサイトは情報量が少なくて、きれいなものが多いです。
いまいちだなと感じるサイトには色んなことがたくさん書いてある。
システムと一緒で、デザインも「要らないものを捨てる作業」をやっていることが多いんですよ。何を捨て、何を残すかを決めるには、どうやって儲けるかが分からないと判断できません。
倉貫
「納品のない受託開発」だと、僕らも言われたことをそのまま作るのではなくて、「この機能要らないのではないですか」とご提案します。
余分なものは外した方が本質的な機能が見えるのと同じで、デザインもたくさん説明すれば分かるんだけど、なるべく外しても伝わるようにすることが大事になってくるんですね。
町田
そうですね。あと、
トップページの場合は、システムを使う前の人にも見せるという点がポイントになります。システムは使っている人に対して作りますが、トップページは使う前の人に対しても必要なものだけを見せる必要があります。
赤塚
使ってみようかなという人達が、どういうことを考えて訪れるのかを考えます。
松村
システム側でも考えるんですけど、デザイナーの人は、使ってみようかなという人の気持ちの部分をすごくじっくり考えて巡らしていますよね。
倉貫
人の気持ちを考えるのは、苦手な部分？
松村
苦手です（笑）プログラムでどう書けば使いやすいかとかは分かるんですけど。
デザインもプログラミングもあえて役割分担しない
倉貫
今、「デザイン」と一言で言っているんですが、
実際開発の時は、どういう役割分担になるんですか？
例えば、プログラムを書くのは？
松村
プログラムを書くのは共同です。分担じゃないです。
倉貫
共同ってどういうことでしょう？普通、デザイナーさんの仕事は、絵を描いて終わりなのかなと思ったんですけど。
松村
プログラマ同士で組むのと同じですね。デザイン部分をメインでやってもらうという違いがある位ですね。
倉貫
どこかで成果物の役割分担があるわけではなくて、一緒に最後まで作り上げていくという感じなんですね。
松村
そうですね。今、ここにいる2人のデザイナーさんはGit、Haml、Sassを使えるデザイナーさんなので、僕らのRailsで組んでいるソースコード上に直接commitします。branch切ってPull Request送ってもらって、それを僕らプログラマが見てmergeします。
倉貫
その説明で読者に伝わるかな？（笑）この辺りがプログラマーとデザイナーの違いかもね。
デザインメンターからひとり立ちする時期
遠藤
案件によっても違いますよね、絡み方は。
赤塚
そうですね。遠藤さんや前田さんとやっているメンター案件の時は違う動きもしてますね。
遠藤
今はもうメンターである赤塚さんにはコードを書いてもらわず、お客様と話す時も、まずは僕たちが考えてお客様の前で説明します。
赤塚さんには途中で「アドバイスないですか？」と聞いたり、フォローを入れてもらったりします。そういったヒアリングの場面でもメンターとして立ち会ってもらったり、コードを書く時も自分たちで全部書いた上で、赤塚さんにコードレビューしてもらって、指摘してもらった点を修正していく感じですね。
赤塚
そうですね。遠藤さんはご自身ですごく書いちゃっているケースが多いです（笑）メンターだったはずなんだけど、もう終わっちゃったみたいな(笑)
遠藤
そうそう。気付いたら全部作っている(笑)
赤塚
遠藤さんとか前田さんのケースはすごく上手くいっています。トップページはこちらで描いたりはしますけど。
前田
どんなプロジェクトなのかにもよりますね。
一般の利用者向けのウェブサイトを作ろうと思ったら、やはりちゃんとデザイナーさんに入ってもらわないとダメだと思うんです。でも企業向けで、今よりもちょっと良くしたい場合や、ちょっとした変化ですごく良くなるといった場合は、デザイナーの方にアドバイスをもらってそれを反映させていくだけでかなり良くなるんですよ。
赤塚
そうですね。だから、案件によりますね。
遠藤
赤塚さんとは、段階を踏んできた感じがあります。
最初入ってもらった時は、ミーティングも全部出てもらうし、画面構成からずっと一緒にやりました。徐々にミーティングに出なくなり、裏でやり取りするようになり、その内に週１のコードレビューでちょっと相談する感じになりました。最初は全然ダメで、めちゃめちゃ指摘されました。そのうち少しずつ慣れていって、今はフェーズが変わってきている感じですね。
赤塚
そうそう。ひとり立ちをする時期ですね！(笑)
前田
やっぱり最初にがっつり一緒にやってもらうのが重要ですね。
赤塚
そうですね。
最初の立ち上げの時にがっつり入って、ある程度出来るようになってきたら、だんだん裏方にまわっていきますよ（笑）
「エンジニア病」とダメ出しされた最初のころ
遠藤
最初、「エンジニア病」って散々言われましたよね（笑）
倉貫
何ですか、「エンジニア病」って？
遠藤
全然気付いていなかったんですけど、
最初に画面を作って赤塚さんに見せた時に、「目立たせる場所を目立たせてない」って言われたんです。
「その画面において、ユーザーが一番気にするべきはこの数字なのに、なんでその数字が周りと同じフォントなの？」と言われました。
赤塚
ありましたね。
遠藤
「え？だって、それは<a>タグで出すから」と言ったら、「エンジニア病や」って言われて、「考え方が違う！」と思いましたね。
とりあえず動けばいいやで突き進めた結果として、「画面に出ているからＯＫ」と思っていたんですけど、それだとデザイン的には全然足りていないと教えられました。
赤塚
あとは、エンジニアさんはプログラムはすごく規則的に、繰り返しも冗長さもなく書けるのに、デザインだとパーツの使い回しとかがあまりうまくなくて。同じ用途なのに、別々に作ったりしていてるので、この辺りはいくつかケースを知っていたらできるようになると思います。
遠藤
デザインでのケーススタディの学び方ってどんな感じですか？いつもそれで困るんですよ。
赤塚
ダメ出しされるしかないでしょうね（笑）「ここは同じにできますよね」という指摘を何回か受けていると、コツは掴めます。
遠藤さんは、多分もうできると思うんですけど。
遠藤
いや、僕はまだ出来てないですよ。最初は全部、別々で作ったんですよ。そうしたら「なんでそれはバラバラなの？」と言われました。「だって見た目バラバラですよね」と答えたら、「見た目はバラバラだけど、情報の並び方に統一性はあって、見た目はちょっと差分で変えればいいだけだから」と。CSSの組み方なども教えてもらいましたが、「プログラムに通じるけど、難しい」と感じました。
赤塚
そうでしたね。
色の使い方だけでも、主要機能はこの色、警告やエラーはこの色とか決められるんですけど、エンジニアの方はわりと気まぐれに使いますね。プログラミングでは気まぐれに書かないはずなのに(笑)
