切っても切れないエンジニアとデザイナーの関係性。理解と信頼のために日々取り組んでいることとは 〜デザイナー×エンジニア インタビュー後編〜
フラーはエンジニアを中心に創業された会社です。現在もエンジニアの社員が一番多く、フラーの事業を支えています。
一方で社長と副社長がデザイナーで、教育機関でデザイン講義を開くこともあるなど、デザインの力を非常に大切にしている組織でもあります。
そんなフラーではエンジニアとデザイナーの距離が近く、共同の勉強会を開催するなど、活発に意見を交わし合ってプロダクト作りに励んでいます。
今回は、フラーのエンジニアとデザイナーの協力体制はどのようになっているのかについて、デザイナー側からはCDO（最高デザイン責任者）とデザインマネージャー、エンジニア側からはVPoP（プロダクト責任者）の3名に話を聞いてみました。
なお、記事は前編と後編に分かれており、本記事は後編になります。
前編はこちらからご覧ください。
VPoP主催デザイナー勉強会の目的
櫻井：
デジタルプロダクトの中でもスマホアプリ制作を中心としているフラーではデザインとエンジニアリングが近い存在であるからこそ、「実装可能なデザインを構築する」ことに重きを置いてます。
そのための取り組みの一つでもある、VPoP主催のデザイナー勉強会・通称『しろくま会』について、お話を聞かせてください。
この名前は……。
古林：
自分のSlackでのアイコンがこれ↓なので、そういう名前にしているだけです（笑）
原：
しろくま会の目的は、「デザイナーが、エンジニアリングを理解したデザインデータを作れるようになる」です。
より具体的には、以下4つの目標を掲げています。
実装可能なデザインのために必要な知識を得る
デザイナー全員がアプリデザインについて知識を深める
デザイナーが動きまで考えたデザインをつくれるようになる
デザイナーもエンジニアも操作性を気にかけることでよりよいアプリをつくる
古林：
デザイナー側の目的としては、原さんが言ってくださった通りです。一方で、エンジニア側の目的もあります。
クライアントワークの特性上、やはり案件の受注にデザインという要素は切っても切れない要素です。実際フラーの場合、クライアントからは技術力だけでなくデザインの良さから選ばれることが多い。
「提案されたデザインを見て発注したのに、出来上がったアプリはデザイン通りに実装されていない」などということになれば、それはクライアントへの裏切りになると自分は考えています。
しろくま会のエンジニア側の目的は、そうならないよう「実装しやすいデザインデータについて、デザイナーにきちんと伝えていく」ことです。
櫻井：
どんなに素晴らしいUX設計も美しいデザインも、実装できなければ存在してないのと同じですからね。
また、デジタルプロダクトはアップデートができる、していかなければならないという事情から、時代や技術の変化へ柔軟に対応できるような造りにする必要もあります。そういった観点からも、デザインの時点でシステム的な実装のしやすさ、メンテナンスのしやすさを意識するのはすごく大事なことだと思います。
古林：
デジタルプロダクトにおいては見た目が綺麗だったら良いわけではまったくなく、エンジニアが意図を汲み取れて現実的に実装できるようなデザインにしなければなりません。
しかし、デザイナーがひとりで実装のしやすさやエンジニアリングを意識したデザインを考えるのは酷な話です。なので、そこの知識やノウハウをエンジニアからもお伝えする必要があると感じています。
VPoP主催デザイナー勉強会の内容
櫻井：
ここからは、勉強会でデザイナーにどんなことが伝えられているのか、さらに具体的に話していきましょうか。
例えば、この前は色のコンポーネントに対するネーミングについての話をしていましたよね。
今作っているアプリの主軸が赤色だったとして、その色のコンポーネントに付ける名前は単純に考えたら『Red』になりますが、それで本当に大丈夫？ という話でした。
主軸の色は将来も赤のまま変わらないのか？ クライアントの意見がガラッと変わって違う色になる可能性は？ などと考える必要があるんです。
古林：
そうそう、ダークモードにしても本当に変わらないのか？ とかもですね。
変わりうるなら例えば『PrimaryColor』など別の名前にしておいた方がいいわけです。エンジニアとしては、変数としてその名前の方が明らかに実装しやすい。
……ということを最初から決めておくと、最終的にはクオリティに数倍の差が出てきます。
具体的なデザインシートをお見せすると、こちらはFULLER Designサイトのものです。
基本的には、色のコンポーネントに色自身の名前を付けないというのがここからおわかりいただけるかなと。
例えばテキスト色のコンポーネントについては『Text/Primary』『Text/Error』と使用用途で名前を付けてあります。これが『Gray』『LightGray』では、ダークモードで反転した際にまったく別の色になるので、色と画面が合わなくなってしまうわけです。
例外的にWhiteと付いたものがありますが、ここには「この色はどんな状況でも変わりませんよ」と明示したい狙いがあります。
原：
フォントについてのシートには、名前、ウェイト、ポイント、実際の見た目が載っています。最近のプロジェクトだとさらに、行間、文字間の情報も追加されています。
古林：
行間などは特にデザイナーがこだわって作ってくれるところですが、実際に実装しようとすると結構大変な部分で、諦めてしまっている会社も多いんです。よくあるのが「でも、ここだけは何とかしてください」とデザイナーからの要望で、特定の画面にだけ行間指定のコードを入れるという実装をするとか。
でもそれって、デザインとしてはすごく綺麗に行間が整っている状態でクライアントに見せているのに、実際にリリースしたプロダクトは特定の画面以外はその通りになっておらず、すごく読みにくい……という出来になっているわけです。
先にも言いましたが、それはクライアントへの裏切りだと自分は思います。
一方、エンジニアリングもしやすい形でこのようにコンポーネントをしっかり作っておけば、テキストの行間などもデザイナーが意図した通り実装できるし、提案時にクライアントにお見せした通りになります。
原：
今回は一例ですが、『しろくま会』ではフラーでデザインしたアプリに沿って学んでいきます。
私も、フラーに入る前はこのあたりについての意識はかなり低かったです。フラーに入って、「今のままではエンジニアはこう実装してしまいます」ということをたくさん指摘してもらえました。
古林：
こういうことは、知識としては最近ようやく一般化してきましたが、実際にこのレベルで事前に整えている会社はかなり少ないと思います。デザイン会社や大きな自社開発会社くらいでしょうか。デザインは意識しているけど実装は意識していないようなパターンも珍しくないです。
その点、フラーではデザインするデザイナーも実装するエンジニアも使いやすいコンポーネントを作っています。
こういった細かいところが本当に大事なんです。一つひとつは小さいけれど、そのすれ違いが積み重なると、出来上がったアプリが「なんか違う」になってしまう。そして世の中には、そんなアプリは残念ながら山ほどあります。あるあるなんです。
櫻井：
実際、最初の手間は確かに増えるけど、後々のことを考えたらこれをやっておくとすごく楽なんですよね。
古林：
そうなんですよ。楽だし、抜け漏れなども防げます。
例えば、『TextBody』の大元のコンポーネントには現在は黒が指定されていますが、これを青色に変えるとそれがFigma全体に適用されて該当部分が自動で全て青色に変わります。
この仕組みを作っていないと、変更があった際に一個一個手作業で変えていくことになり、手間も増えるしミスも出ます。
このようなデザインシートを作っておくことは、エンジニアにとってもデザイナーにとっても、細かいメリットが非常にたくさんあるんです。
新たな勉強会とフラーの強み
古林：
現在は、新しい勉強会として『しろくまデザイン塾』を開講中です。
こちらは、実際にフラーが今まで出したプロダクトのデザインを見ながら、僕がちょっと突いていくというか、もっと伸ばせる点について指摘をさせていただく会になっています。
……こういうのって嫌がられることだと自分でも思うんですが、前身のしろくま会を一年間やってきた中でお互いに信頼が培えている、ということを信じて行っています。
例えば他の会社でいきなりこれを始めて、エンジニアがデザイナーに「ここが違う」と指摘をし出したら、かなり軋轢を生むかなと……。
どうしても正論パンチにはなってしまい、人間なので「辛いなー」とみんな少なからず思っている部分もあるはずですが、フラーのみんななら「会社としてこれをやることが必要なんだ」とわかってくれると、自分は信じています。
原：
そこは信頼していただいて大丈夫です。『しろくまデザイン塾』について否定的なメンバーは、私の見る限りですが、いないかなと。
指摘されることが怖い、みたいな気持ちもこちらにはないです。やっぱり、一年間の信頼がありますからね。
櫻井：
そもそも、ご指摘はおっしゃる通りですから。デジタルプロダクトという動的なものについて、実装するエンジニアさんからの指摘は常におっしゃる通りなんです。デザイナーとしてはそれを受け止めて、自分の糧にしていかないと。
それに、古林くんからはデザインやデザイナーに対するリスペクトがすごく伝わってくるんです。そこも大きいかな。
古林：
ありがとうございます。
今ってアプリは山ほどあるので、まずデザインが良くなければ触ってすらもらえません。でも、良いデザインはエンジニアだけでは作れない。なので、自分はそこを作れるデザイナーをリスペクトしています。デザイナーラブなんです。
その気持ちは常々伝えるよう、意識しているつもりです。
原：
古林さんには結構ズバッと指摘してもらっているんですが、嫌じゃない感じがあるのは、やっぱりその気持ちが伝わってくるからかなと思います。
櫻井：
古林くんがデザイナーをリスペクトしてくれるのと同じように、僕たちもエンジニアをすごくリスペクトしています。そういう関係ですよね。
ちなみに議事録を取って録画もしてあるので、新しく入ったメンバーにはオンボーディング期間中にそれを観てもらっています。
これからもフラーではエンジニアリングとデザインの距離が近く、またそういった関係を維持・強化するための体制も作っています。
最後にこのあたりについての魅力をお二人にも語っていただけたら。
古林：
そうですね。世の中のデザインシステムはデザインだけで完結してしまっていることが多く、そこにエンジニアリングの観点が入っているのは、一部の大手自社サービス会社くらいです。
それをクライアントワークでやっているのは、フラーの強みの一つ。クライアントワークでは自社サービスと違って様々な事例から学べますし、何より新規開発の機会があるのはとても大きな魅力だと思います！
原：
エンジニアリングを考えたデザインデータ作りは、今後、デジタルプロダクトづくりに関わるデザイナーとしては必須スキルだと思います。エンジニアさんからも重宝されるはず。
それを学ぶ環境がフラーにはあるので、本当にいいものづくりに取り組めるようにとデザイナーはもちろんエンジニアのみなさんとも取り組んでいるし、これからも取り組んでいきます！
お知らせ
櫻井さん、原さん、古林さん、ありがとうございました！
フラーのデザイン組織『フラーデザイン』についてのデジタルノートはまだまだありますので、ぜひ合わせてご覧ください。
フラーやフラーデザインにご興味お持ちいただけましたら、お気軽にご連絡ください。
採用ピッチ資料はこちら↓