アートボード_1

越境のススメ

この記事は InHouseDesigners Advent Calendar 2018 13日目の記事です。

こんにちは。@toi_toi_yです。インハウスデザイナーです。

自分はサイボウズという会社で自社プロダクトであるkintoneのデザイナーをしています。
チームにはプロダクトマネージャー、エンジニア、QA、ライター、デザイナーなどなどいろんな役割の人がいます。
一般的に事業会社はしっかりと分業されていて、それぞれのロールに割り振られた仕事をしています。自分はデザインをして、エンジニアはコードを書いて実装するのが主な役割です。

自分はサイボウズに来る前に製作会社でWebサイトを作っていました。自分でディレクターもやるし、デザインもするし、コーディングもやるという分業とは程遠い環境にいました。
2年半前サイボウズに転職してきた当時、「ちゃんと分業されている! 専門家がいるって素晴らしい!」と感動したのを覚えています。

ところが最近、この分業の境目を曖昧にして越境していくのも良いな、と思い始めました。

きっかけはモブプロ

少し前から、チーム内でモブプロが当たり前になりました。
新人もベテランも一緒になってワイワイと一緒に実装する姿がそこかしこで見られるようになりました。
このモブプロが実に楽しそうで(実際楽しい)、自分も混ぜてもらうようになりました。
JSに関しては素人レベルなのですが、HTML / CSSの面ではエンジニアのメンバーに負けない知見があります。
こうしてデザイナーとエンジニアで一緒にDOMを設計し、CSSを書くようになりました。
デザインの意図はより正しく伝わるようになり、誤解を防ぐためのピクセルパーフェクトなデザインカンプ は徐々に必要なくなりました。
ちなみにエンジニアのメンバーはみんなめちゃくちゃ優しく、今では積極的にモブプロに呼んでくれます。感謝。

デザインをもっと正しく実装したい

デザインとエンジニアががっつり別れていたころ、デザインを最終的にどう実装するかはエンジニアの裁量にお任せでした。
DOMはどう区切るべきか、クラス名はどうするべきか、といったところはそれぞれの解釈に任されていたのです。ところがモブプロで一緒に実装を始めるとそれぞれの解釈が異なることで色々問題があることがわかってきます。

- AというUIとBというUIは同じパーツとしてデザイナーは意図していたが、実装では別物になっていた

- Bというパーツは違うページでも使いまわせると思っていたけど、CというUIのロジックに密結合していて実は無理なんです などなど

そこから、このデザインの設計の意図は何? どういうユースケースなのか?などなどデザインと実装の間を埋めるための様々なコミュニケーションがデザイナーとエンジニアの間で交わされるようになりました。

共通言語を作りたい

今はデザイナーとエンジニアの共通言語を作ろうとしています。モデル、ユースケース、インタラクション...デザインの分野でもプログラミングの分野でも使われる様々な言葉があります。こうした言葉の解釈は立場によって異なります。まずはお互いの言葉の意味を共通化していくところから始めています。
お互いの知識が足りないところも多く双方の歩み寄りが必要です。
モデルとは?ユースケースとは? 地道なコミュニケーションを続けています。

もっと越境しても良いんじゃない?

これまで自分はデザイナーで、デザインすることが仕事であり、エンジニアの仕事に踏み込むべきではないと思っていました。
しかし、エンジニアと一体になって仕事をするうちに、デザイナーとエンジニアのその境目にいろんな問題や可能性があることがわかってきました。

ということで、来年はもっとデザインからエンジニア側に寄ってみて、よりその中間領域に近づいてみようと思っています。
少なくともエンジニア白帯ぐらいまではたどり着いてスタートラインに立ちたいです。
チームのメンバーは非常に協力的で優しく、自分にいろんなことを教えてくれます。

逆にエンジニアもデザインに興味を持ってくれて、今は一緒にUXや、UIデザインの勉強会をやっています。
エンジニアのメンバーにFigmaの編集権限を渡して一緒にモブデザインする日も遠くないかなと思っています。

こうした越境ができるのも周りにいろんなロールのメンバーがいる、Inhouse Designerの特権ではないかと思います。
もしデザインとその境目でもやもやしていることがあれば、思い切って向こう側へ越境してみるのはどうでしょう。意外とみんな受け入れてくれるかもしれません。

以上越境のススメでした。

この記事が気に入ったらサポートをしてみませんか?