リードデザイナーとリードエンジニアが語る越境。リードデザイナーとリードエンジニアが語る越境。2019-11-06リードデザイナーとリードエンジニアが語る越境。Tweetこんにちは。採用広報担当の大木です。弊社ではデザイナーとエンジニアがチームを組み、同じ空間で協働しています。チームやお互いの立場などの枠組みに囚われることなく、日常的に両者が相互の観点でレビューしあい、それはリリース前のピリピリとした空気の中でも途切れることはありません。することで、UI・エンジニアリング・デザインと全ての観点において完成度の高いプロダクトになり、それが弊社が大切にしている行動指針である「真摯に技術と向き合い、手段を目的として腕を磨き続け、つくり手が幸せに働ける居場所を作る」の持続的実現に繋がると考えています。こちらはデザイナーの石崎さんです。社内の呼び名はuniq(うに)さん。この対談中も「uniqさん」で通しますね。デザイナーだけどエンジニア寄りなこともできる人で、最近は手を動かす仕事が多いみたいですね。マークアップよりのことがかなりできるし、HTML・CSSだけじゃなくJavaScriptも知ってます。イベントの運営側をよく手伝っていたりして活動範囲広いですよね。勉強しているなと思う。使いやすさを主軸においたデザインができるデザイナーさんです。キャリア面でいうと、ドワンゴとか大きい組織の経験があって、自分にはないので参考にさせてもらうことも多いです。プライベートでは「犬一色」。埼玉在住で、社内では通勤が一番遠いんですが、自分も地元が埼玉で同郷です。はい、フロントエンドエンジニアの斉藤さんです。社内ではshuntaさん。私も対談中shuntaさん呼びでいいでしょうか。私がビルディットに入りたいなと思って調べていたときに、「社長がバックエンドエンジニアなのでエンジニアリング優先の環境なのかな?」と少し心配に思ったんですが、shuntaさんの前職の紹介を見て、そこは心配しなくても良さそうだな〜と思ったのを覚えています。実際は社長もわかってくれる人だったんですけどね。UIデザインについて、デザイナーのツラミややりがちなミスも察して先回りして対応してくれる、本当に有り難い存在です。フロントエンドっていうとJavaScriptばかりかと思いきや、バックエンド、ミドルも知識が深くて、フロントエンドのくくりでいいの?!と思いますね。仕事でいろいろ調べたりするときに、和訳されたまとめサイトの情報じゃなくて原文(一次情報)を辿っているのがすごいと思うところ。外国語のドキュメントに対してハードルを感じてないように見えます。あと、エンジニアって「何事もググれ」という文化だと思ってましたが、学生アルバイトさんにしっかりレビューするし、質問されたことの回答だけじゃなく周辺情報も含めて幅広くアドバイスしているのをよく見かけるので、良い先輩エンジニアだと思います。仕事以外だと、とにかくめっちゃ食べるし食べるのが大好きな感じ。ランチは皆で行くことが多いですけど、自分がお店の提案するときは斉藤さんが満足する量かどうか気にしちゃいますね。あとゲームと音楽に詳しい。いま八王子に家を建築中だから本人の興味はいま家のことに集中しているのかな。奥さんとすごく仲良しでたまに出るエピソードがほのぼのしてます。デザイナーとエンジニアで共同で案件を進める機会は多いかと思います。デザイナーとしては、エンジニアさんのタイプによっては、この大きさ・幅は何ピクセル、スペースは・・とデザインの全てを一個ずつ書き出して指定しないと、見た目を綺麗に実装してもらえないことがありますね。パーツは一応全部入っているんだけど、レイアウトが全然違うとかね。エンジニアの視点からは、UIが揃っていない、デザインの段階でUIが決まっていないことも結構ありますよね。あと少し昔には画像が無いとかよくありましたね。これはZeplinやFigmaとかのツールが解決してくれて、今はほとんど問題は起こらなくなってきましたけど。あとWeb画面のビジュアルを「アプリみたいにしたい」って簡単に一言でいうのとか。あるある!デザインだけを考えていると、アプリだとできるからWebでもできるでしょと思いがちなんですよね。ある程度実装をやったことがあれば、アプリと同じようなUIをCSSとHTMLとJavaScriptで作るのは結構難しいってことが分かるんだけど。そうそう、元のデザインは一枚の絵みたいなものなんだけど、それをベースにしてPCの画面、サイズ毎のスマホ画面、縦と横で見る場合、処理速度の遅い古い端末の場合、、とエンジニアはそれらを考慮して実装をしないといけないから。画面遷移の仕方やその間のインタラクションなんかは、曖昧な指示にせず、統一性をもってデザインする必要がありますね。デザイナーにしてもエンジニアにしても、各種のガイドラインを読み込んでいたり、色んなサービスを触ってる人はそんなに違和感のある実装にはならないですよね。最初にshuntaさんがuniqさんを「エンジニア寄り」と言っていたとおり、uniqさんはエンジニアの視点も持っていそう。実装しやすさを考えてデザインを作っていますよね。文章量が可変になる場合でも違和感の無いコンポーネントのデザインをしてくれてたりします。コーディングに参加しない・実装を全然知らないデザイナーさんとは、「文章がはみ出る場合にはどうなんですか?」なんていうやりとりがしょっちゅう発生するんですが、そういった手戻りがかなり少ないですね。あとコーディングするときに繰り返しで済むようにデザインを作ってくれますね。たしかに実装を知らないからこそ、自由に発想できるというのはあるかもしれないですね。私は実装自体が結構楽しくて好きなので、それに縛られて嫌という感覚はあまりないけど。実装がわかるメリットは他にも、デザインを考える時に全くのゼロベースからよりは実装ありきで必要な枠の中で考えられるから、早くデザインを上げられるようになるということもあります。プロダクトによっては、デザインを考える上で枠を取っ払ってとにかくアイディアを出して発想を広げることが必要になるタームもありますね。いうときはちゃんとそうするようにバランス持ってやりたいですが、どこかで「枠」は意識しちゃっているかもしれない。最初に言った「デザイナーのツラミややりがちなミスを分かってくれて先回りして対応してくれる」ということが大きいかな。細かい部分を作り込まずに全体を作る時、空白部分とか細かいところの部分がどうしても甘くなるんですよね。いうところをいちいち確認せずとも「よしなに」やってくれたり、スマホのビューをデザイナー側で作らなくても、作ってくれたり。デザイナーによってはPCとスマホの両方をしっかり作れない人は結構いるんですよね。自分は「よしなにやろう」って結構言うんですけど。対応すると良いのかなと思います。エンジニアのスタンスとして、ちゃんとデザインを作ってくれないと開発に全然着手できない、だとアウトプットが遅くなってしまうので、作りながら調節していけるように考えています。聞きたいんですが、Sketchで画面を作ったとしてもブラウザで見れるわけではないし、そのまま実装できるわけではないですよね。実際ブラウザで表示させたら違和感ある場合もあるし。基本的にはデザイナーさんが作った通りに実装するんですけど、ちょっとした誤差なんかは各デザインガイドに則ってやることが多いですね。「よしなに」は感覚ではなくて、そういう知識や経験のベースに基づいてやっています。逆にデザイナーさんによってはOS別のデザインガイドを把握していないこともあって、指示通り作ると違和感がある場合はちゃんと確認します。Designのような、再利用性を意識したデザインをしていただける事が多くなってきたかなと思います。再利用できるというのは大事ですよね。斉藤さんはデザインガイドもよく知っているし、UIデザインの全体的な知見があるし、デザインとの距離が近いですよね。フロントエンドエンジニアなので、Webにも応用の効きそうな、マテリアルデザインガイドは一通り読みました。OSごとにそれぞれの哲学があるからデザインガイドもそれぞれで、一緒でしょという人もいるけど自分はそんなに甘くないと思ってる。私は必要に応じて必要な箇所をその都度読んでいる感じですけど、エンジニアさんにデザインを説明する時にどう表すか、デザインガイドがかなり参考になることに気づきました。デザインガイドは共通言語になりますよね。いう共通言語を使って、お互いの領域を超えて知っていくことで良いものを作れるってことなのかなと思いますね。知っていたほうが仕事がしやすいから。そんなの無くてもいいという人もいるし、実際はそれでも仕事はできないわけじゃない。自分はデザインのことに限らずですが、色々知りたくなって勉強してます。性質的に探究心が強い傾向があるみたいで、それが関係している気がします。以前に自分の強みを知れる「ストレングスファインダー」をやった時に、探究心とか収集癖がとくに強い傾向が出てきて、なるほどなと納得しました。前に別の記事のインタビューでも話したことがあるんですが、ドワンゴでの経験からですね。最後まで関わりたいと思うようになったきっかけは、デザインしたものが実装されたら全然違うものになっていた経験です。自分がいいと思ったものをちゃんと作りたいなと。それぞれの領域内の知識から一歩も出なくても仕事はできる。自分の思うものをより良い形で作りたいとか、もっと仕事をやりやすくしようと思ったら、領域の外に一歩踏み出して知識を取りにいくべきだと思う。あとエンジニアだったら、常にデザイナーと一緒に仕事する環境ばかりでもないですからね、コミュニケーションとりにくかったり、そもそも実装の段階ではデザイン作ったデザイナーがすでに離れていることもある。その時にいちいち細かいことまで時間かけて確認したり、毎回ゴリゴリコミュニケーションして、だと自分も辛い。わかっていれば自分で判断できる範囲が広い。ビルディットではデザイナーもエンジニアも同じ空間にいてスムーズにコミュニケーションしていますよね。一緒に開発しているし相互にレビューもしている。わたしはありがたいな〜と思います。自分はレビューするのに結構気を使ってしまうから苦手意識があって、ちゃんと言える人のことは関心してしまいますね。実際、デザイナーがエンジニアのコーディングについて意見するなんて場面はほとんどないんですが、デザイナーからデザイナーへのレビューも、チーム外からのレビューも、緊張しちゃいますね。気を使いつつ、自分がレビューする場合は、自分の立場とか向かうべきゴールとかタイミングを意識してレビューするようにしています。デザイナーからエンジニアの場合、ロードが遅く感じる、画面の切り替えがキビキビしてないとかが気になったとしたら「早くしたい」とかの結論は言わずに、「ここのユーザー体験をよくしたいけど、何か良い手立てはないか?」という聞き方をするとか。!自分もデザイナーさんに対してデザインへの意見をいうことは実際ほとんどないですね。プロフェッショナルの部分には信頼を置いてます。手が回らないところを手伝うスタンスです。お互いに適度に配慮しつつのコミュニケーションも、良い議論の一要素なんですね。適度に配慮ができるのも、相手の技術への理解があるからこそ。お互いに仕事の効率が上がるようなツール、プロジェクトやタスク管理ツールに結構興味がありますよね。自社事業としてそういうのやれるとかっこいいですよね。いま二人は同じプロダクトに携わっているわけではないのですが、同じ空間にいて、境界を踏み越えた知識で切磋琢磨しているからこそ、ビルディットの協働しあう空気がさらに濃くなったいるんだなと実感しました。こんな空気感で一緒に成長したい仲間を少しずつ増やしていきたいと思っています。ご興味をお持ちくださった方、ご応募・問い合わせお待ちしています!bldt.jp*1:Uniqが運営スタッフとして参加しているDIST(ディスト)は、職種や技術の垣根を越えてWebに関わるすべての人を結ぶクリエイティブコミュニティとして定期的に勉強会などを企画開催されています。11:00リードデザイナーとリードエンジニアが語る越境。Tweet関連記事2019-10-24「手段を目的化する」と言っていた開発会社のその後についてエンジニアの富田(@tmtysk)です。7月に入社した日置です。