Inside BuildIt

株式会社ビルディットのデザイナー・エンジニアによるブログです

エンジニアからUIデザイナーにジョブチェンジした話(入社エントリ)

akinen

あけましておめでとうございます! デザイナーの小澤(@_akinen)です。

去年の11月にビルディットに入社し、現在は主にUXやUIのデザイン業務に携わっています。前職ではフロントエンドエンジニアだったのですが、いろいろと悩んだ末にデザイナーへと転向しました。

そこで本記事ではデザイナーに転職した経緯や、働き始めてどうだったのかについてご紹介します。デザイナーとして就職を考えている方にとって、なにか参考になるものがあれば幸いです。

目次

  • なぜデザイナーに転職したのか
  • 未経験での転職活動
  • 入社後のいま
  • 今後について
  • おわりに


ーー 🐭ーー


続きを読む

第1回 八王子のデザインチームが八王子のGood Designを探す企画

八王子のWeb開発企業 ビルディットのメンバーは、基本的に八王子が好きです。
「八王子からも質の高いサービスは生まれているんだ」ということを世に知らしめるべく、日々業務に励んでいます。

そんな有志の「八王子応援団」は、もちろんビルディットばかりではありません。
見渡すと意外に多い応援団員。八王子にはいろんな活動をしている「イケてる人々」がたくさんいる。八王子で働く・活動する人はことさら「八王子」にこだわりと愛着を持っている━━。
そんなことを、八王子内外の人に広めたいと思い、今回の企画をはじめました。

目次

  • 八王子界隈の「Good Design」を見つけて語り散らかそう!
    • Member紹介
  • 八王子市公式シティプロモーションサイト
  • 高尾山マガジン
  • オンガタマルシェ(クリープストア)

八王子界隈の「Good Design」を見つけて語り散らかそう!

この企画、「今月見つけた良いデザイン」を題材にして毎月ワイワイやっていきたいと思います!
せっかくの初回なので、八王子のオフィシャルサイト!それと公式ではないものの知名度の高いサイト!にフォーカスしました。

Member紹介

このメンバーでお届け!
🦄イシジマミキ (デザイン顧問)
🐶石崎 (リードデザイナー)
🦊佐野 (エンジニア)
🐧小澤 (デザイナー)
🐷大木 (広報)

🐷大木:一発目は初回にふさわしいチョイスにしましたよ!

続きを読む

デザインレビューをする戸惑いから得たもの。「デザイン」ではなく「デザイナーのしごと」をレビューする。

どもです。デザイナーの石崎うに ( id:uniq )です。
経験年数が多くなりデザインレビューをする機会が増えてきた今日このごろです。

そのデザインレビューなんですが…
「この状況下でデザインレビューするのって、どうしたらいいんだろ〜?」というのがありました。

それは

私が「プロダクトオーナーやチームメンバーとコミュニケーションをほぼとっていない状況」で、レビューをする場合

です。

f:id:uniq:20191216231531p:plain

プロダクトオーナーが何を求めてるのか、どのくらいのクオリティ目指しているのか、デザイナーはプロダクトオーナーの要件をどのように理解しているのか、最終的なゴールと直近のゴールはなにか、どんなスピード感でやっているのか。
SlackやGithubを読んではいるものの、対面で感じる温度感・何に対して熱を持っているか・今までの開発の歴史、など、把握しきれていない状態です。

この件に関してノウハウの発見がありまして、ポエムを投下いたします。

続きを読む

ゆるはち.it 第16回【Flutterについてゆるく話す】参加レポート

こんにちは、エンジニアの日置です。

ゆるはち.it は、毎月月末の水曜日に八王子で行われている勉強会です。前回までは fabbit 八王子というコワーキングスペースで開催していたのですが、今回は弊社イベントスペースで開催してみました。

設営中の様子

f:id:hioki-daichi:20191202112808j:plain

徐々に人が集まってきた

f:id:hioki-daichi:20191202112759j:plain

最中の様子

f:id:hioki-daichi:20191202112751j:plain

ゆるはち.it【Flutterについてゆるく話す】のレポート

今回のテーマは、「Flutter」でした。
トーク内容は以下の通り

  1. トーク1: Flutter Layout入門
  2. トーク2: FlutterでつくったAndroidアプリを公開するまで
  3. LT1: Dartで作るシンプルなCounter App

どの発表にもコードが出てくる実践的な内容となっていました。

それでは1つ1つのトーク内容に触れていきます。

トーク1: Flutter Layout入門

docs.google.com

画面の左半分にコードを、右半分にシミュレータのスクリーンショットを表示しながら、Layout に関して 『こういうコードを書くとこんなふうに表示されるよ』 というのがひと目で分かるようになっていて非常にわかりやすかったです。

iOS っぽい見た目にしたい場合は Cupertino widgets というのがある。

flutter.dev

が、まだ整いきってなく widgets は 20 種類くらい。Material widgets の方が 50 種類くらいなので半分以下という話だったり、

iOS や Android での処理の分け方の話だったり、大変ためになりました。

『Hot Reload 最高!提供されている Widgets を使った UI なら爆速で作れる!』とのことでした。同感。Flutter よさそう。

f:id:hioki-daichi:20191202112727j:plain

f:id:hioki-daichi:20191202112535j:plain

トーク2: FlutterでつくったAndroidアプリを公開するまで

speakerdeck.com

Flutter 製のアプリから HTTP Request をして取得した JSON を描画するといった実践的な内容でした。

ディレクトリ構造の話などやり始めたら気になりそうなところも解説していました。

https://flutter.dev/docs がすごく丁寧でよかったとのこと。

$ flutter doctor コマンドが用意されているとのことで、入門しやすそうな雰囲気を感じました。

テストの仕方は Go とかと同じで _test.dart を付けるだったり、アプリ公開時にはインターネットに対するパーミッションの付与が必要だったり、Codemagic の話だったり、大変ためになりました。

codemagic.io

f:id:hioki-daichi:20191202112716j:plain

LT1: Dartで作るシンプルなCounter App

github.com

Counter app を Dart で実装した話で、実際のコード(上記リンク参照)を見ながら、ソースのエントリポイントから表示されるところまで解説していくといった流れでした。

Dart と JS の書き味を知るために Dart 単体で書いてみたとのこと。

途中に pub コマンド ( https://dart.dev/tools/pub/cmd ) や --auto restart で Hot Reload できる webdev ( https://github.com/dart-lang/webdev ) の話も挟んだりなど、かなり実践的な内容となっていました。

f:id:hioki-daichi:20191202112649j:plain

懇親タイムの様子

f:id:hioki-daichi:20191202112431j:plain f:id:hioki-daichi:20191202112418j:plain f:id:hioki-daichi:20191202112407j:plain

ピクニック感が出てますね。非常にほのぼのとしています。

座り込んでしまうため移動しづらいという点はありましたが、より気軽に話せるようになった点はよかったように思いました。

発表者からも『目線が合うのがよい』というような意見が出ました。

次回告知

次回のテーマは、Rust です。

yuruhachi-it.connpass.com

開催日程は12/18(水)です。

今回と同じ、弊社イベントスペース (東京都八王子市東町1-14 橋完ビル3F G室 / 京王八王子駅徒歩2分, JR八王子駅北口徒歩3分) で開催します。

おわりに

ビルディットでは、「つくることで生きていきたい」クリエイターを募集しています。 新しい技術に関心のある方はぜひお気軽にご連絡ください。

株式会社ビルディット|東京都八王子市の同業組合型IT企業

ゆるはち.it 第15回【Webデザインテクニックについてゆるく話す】参加レポート

はじめに

こんにちは、エンジニアの佐野です。

最近は↓みたいなことをしてました。(雑)
tailwindcss v0.7→v1.xへのupgradeを自動化した - Inside BuildIt

では前置きを短く、本題のゆるはち.it勉強会についてレポートを書きます。

ゆるはち.itの紹介

ゆるはち.it は、毎月八王子で行われている勉強会です。
毎月テーマが変わります。今回はWebデザインテクニックがお題でした。
タイトルにある通りゆるーく進行する勉強会なので、気楽に参加できます。

懇親会の時間に地元・八王子のピザ屋No.8 pizzeriaのピザを提供するのですが、絶品です!

No.8 PIZZERIAでオシャレランチ!!本格ピザが絶品!!│八王子情報サイト | 八王子ジャーニー

f:id:jalemy:20191114111348j:plain

発表したい方、ピザを嗜みながら懇親したい方はぜひconnpassへ

yuruhachi-it.connpass.com

ゆるはち.it【地味にスゴイ!Webデザインテクニック】のレポート

今回のテーマは、「Webデザインテクニック」でした。
トーク内容は以下の通り

  1. パパッと伝わる資料・スライドの作り方
  2. ここを抑えるといい感じ♪Webサービスのデザイン
  3. フロントエンドエンジニアから見たノンデザイナーズ・デザインブック
  4. デザイン初心者に色々教えたらこうなった

資料・スライドという誰もが触れるデザインの内容から、より具体的なWebサービスのデザインについて。
そしてエンジニア目線でのデザインについてのトーク。
最後には、このようなデザイン知識を初心者に教えたらどうなったか実例を見れる貴重なLT。
と豊饒な内容になっています。

また今回の ゆるはち.it では、株式会社ビルディットのデザイン顧問であるイシジマミキさんが駆けつけてくれました。
進行役としてゆるふわなトークを交えながら補足もしてくれたので、とてもわかりやすくなりました。

それでは1つ1つのトーク内容に触れていきます。

トーク1: パパッと!伝わる資料スライドの作り方

www.youtube.com

f:id:jalemy:20191114111520j:plain

画像を見てわかる通り、登壇者とリモート通話を繋げての発表という初の試みです。
発表内容は動画になっていたのですが、動画の中に登壇者の五藤晴菜さんが映っており身振り手振りがあったので違和感なく聞くことができました。昨今流行りのyoutuber動画を見ている心持ち👀

内容については「資料スライドの作り方」ということでデザイナーとかエンジニアとか職種関係なく役に立つ内容です。

「いきなり手を動かすのではなく、先にポイントを書き出して不要な部分を削ってまとめていくようなアプローチの方が、最終的に時間もかからないし、クオリティの高いものができる」

この手順って日々の仕事にも活かせるのではないでしょうか……

また、晴菜さんはiPadエバンジェリストのため、iPadのノウハウがいろいろと詰め込まれています。
iPadユーザーの方はぜひ

トーク2: ここを抑えるといい感じ♩Webサービスのデザイン

f:id:jalemy:20191114111607j:plain

Webサービスデザインのノウハウをさまざまな視点で話していました。

個人的に興味深かったのはデザイン素材の集め方、使い方のお話。
発表者のuniqさんは freepicks や pexels といったサービスを利用して素材を集めているようです。
このあたりの知見がまったくないのでとてもためになりました。

LT1: フロントエンドエンジニアから見たノンデザイナーズ・デザインブック

f:id:jalemy:20191114111639j:plain

こちらはスライドなしで本を片手にLTするという試み。
ノンデザイナーズ・デザインブックの中で重要な点を押さえながら、実際の現場においてのフロントエンドエンジニアあるあるを語っていました。
発表を聞いている側からは同意の頷きや、思わず笑い声が上がるような盛り上がり。

私も最近読んだのですが、ノンデザイナーズ・デザインブックは名著なのでぜひご覧ください。

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

LT2: デザイン初心者に色々教えたらこうなった

www.slideshare.net

f:id:jalemy:20191114111622j:plain

タイトルの通りデザイン初心者に半年ほどかけてデザインを教えたら劇的に進化した!という内容です。
uploadされているスライドからは実際のデザイン画像は抜かれています(残念……)

発表中には「一体何があったんだ……」「こんなに劇的に変化するのか!」といった声が上がるほどの変わり映えでした。脳内補完しつつご覧ください。

よく、デザインはセンスのようなことを思われがちですが、デザインには基本となる考え方・技術があり、その基本だけでも押さえればとても良いデザインを生み出せる。
そんなメッセージがこもっているLTでした。

エンジニアでもデザインの素養はあった方が良いと常々思っているので身に沁みるLTでした。

Tips

今回の ゆるはち.it では、株式会社ビルディットにて保管していた技術雑誌のバックナンバーを無料頒布しました。
Software Design や、 WEB+DB PRESS が十数冊程度です。
思った以上に人気があって一瞬でなくなってしまいました。

f:id:jalemy:20191114130129j:plain

たまーにこのようなプレゼントもあるので気になった方はぜひ ゆるはち.it にご参加ください。

次回告知

次回のテーマは、「Flutterについてゆるく話す」です。

yuruhachi-it.connpass.com

開催日程は11/28(木)です。
いつもと会場が違って橋完ビル3Fでやるのでご注意を

おわりに

ビルディットでは、「つくることで生きていきたい」クリエイターを募集しています。 新しい技術に関心のある方はぜひお気軽にご連絡ください。

株式会社ビルディット|東京都八王子市の同業組合型IT企業

tailwindcss v0.7→v1.xへのupgradeを自動化した

はじめに

こんにちは、エンジニアの佐野です。
とあるプロジェクトで tailwindcss というCSSフレームワークを利用しているのですが、今回 tailwindcss をupgradeすることになりました。
upgrade前のversionが v0.7 で、upgrade後のversionは v1.1.2 です。
メジャーバージョンが上がるので変更点がかなり多いです。
職人による手作業でやろうとすると、ファイル数 × 変更点 という膨大な量になります……
これは手作業でやりたくない……ということで、できる限り自動化してみました。

最終的には、正規表現でカバーしきれない部分以外は自動化できてとても楽だったので紹介します。

tailwindcssとは

tailwindcss.com

CSSフレームワークでは Bootstrap が有名ですが、 tailwindcssBootstrap とは大きく異なります。
Bootstrap がボタンなどのレイアウトを準備してくれているのに対し、 tailwindcss はCSSのユーティリティを提供してくれます。
迅速なUI開発のためのユーティリティファーストCSSフレームワーク というのがキャッチコピーのようです。
実際に使ってみると軽快にCSSを記述していけますし、 Bootstrap っぽい見た目にならないというのも嬉しい点です。

The State of CSS というプロジェクトで、CSSフレームワークの満足度調査がされていました。

2019.stateofcss.com

知名度こそ低いものの、満足度が 81% でとても高い数値になっています。
今後もきっと盛り上がっていく と期待している ので、使ってみてはいかがでしょうか。
具体的な利用方法については割愛……

tailwindcss v0.7 -> v1.xへ……

今回の本題である tailwindcss のversion upgradeについて。
tailwindcss 公式にupgrade guideが準備されており、かなり丁寧に記載されています。

Upgrading from v0.x to v1.0 - Tailwind CSS

大雑把に大きい変更だけかいつまむと、

  • configファイルの記述方法が変更
  • 一部class名の変更
  • カラーパレットの定義変更

あたりでしょうか。
他にも <ul><ol> タグがデフォルトでCSSリセットされるようになったり、<img><video> タグに display:block がつくようになったりと変更ありますが、雰囲気的にはそんな感じ

上記の 一部class名の変更カラーパレットの定義変更 が作業量が多くなってしまうので手作業でやりたくない……

そうだ、自動化しよう
というのがモチベーションでした。

手動でやりたくないので出来るだけ自動化する

今回のプロジェクトでは、バックエンドに Laravel、フロントエンドに Vue.js という構成だったので、

  • bladeファイル(Laravel)
  • scssファイル
  • vueファイル

と3種類のファイルで置換を行う必要がありました。
いろいろ考えた末に、sedコマンドで置換を行うことに決定。
そして出来上がったものがこちら

👀目がチカチカする

こちらのsed scriptを作業環境に配置して、 sed -i -f ./tailwind-replacer.sed {対象ファイル名} で実行すればclass名が置換されます。
cssファイルだけ一括で実行したいというときには find ./resources/css -name '*.css' | xargs -t -n 1 sed -i -f ./tailwind-replacer.sed という感じにfindコマンドで対象ファイルを選択して実行してください。
このscriptでは tailwindcss をカスタマイズしないで使っている環境向けに記載してあるので、カラーパレット定義など変更している際は、合わせて変更してください。
(ちなみに弊社はカスタムして使っているので書き換えました)

css class名に上手くマッチさせるために
(単語境界)(置換前class名)(スペース or 改行 or タブ or :;") と条件を書いたあたりが肝です。
前後とも単語境界でマッチさせてしまうと、各class名の - が単語境界と認識されてしまって、 bg-bluebg-blue-500 に置換した際に、 bg-blue-500-900 みたいなclass名が生成されてしまいます……
置換先で、class名後部にてマッチした文字を後方参照して、再度配置すれば構文エラーも発生しません。

正規表現でカバーできない部分

残念ながら、 <img> タグの display: block 変更や、 <a> タグの下線が消えてしまう変更などは正規表現だとカバーできませんでした。
このあたりは手作業で修正しています。

おわりに

UNIX/Linuxコマンドを利用することで、かなり楽をしてupgrade作業を終えることができました。
UNIX/Linuxコマンド最高!!

GitHubにて変更量をみてみたらこんな感じでした

f:id:jalemy:20191108115438p:plain

この量は手作業ではやりたくない……
できる限り自動化していきたい心持ちです。

リードデザイナーとリードエンジニアが語る越境。

こんにちは。株式会社ビルディット 採用広報担当の大木です。

弊社ではデザイナーとエンジニアがチームを組み、同じ空間で協働しています。 そしてチームやお互いの立場などの枠組みに囚われることなく、日常的に両者が相互の観点でレビューしあい、それはリリース前のピリピリとした空気の中でも途切れることはありません。

そうすることで、UI・エンジニアリング・デザインと全ての観点において完成度の高いプロダクトになり、それが弊社が大切にしている行動指針である「真摯に技術と向き合い、手段を目的として腕を磨き続け、つくり手が幸せに働ける居場所を作る」の持続的実現に繋がると考えています。

異職種同士がうまく協働してプロダクトの開発をスムーズに行うために、どのようなコミュニケーションを取っているのか、デザイナーとエンジニアの双方から現場の話を聞いてみました。

目次

左:斉藤(shunta):リードエンジニア  右・石崎( id:uniq ):リードデザイナー

登場人物紹介

━━ 改まって自己紹介するのはなかなか恥ずかしいので、お互いに「他己紹介」お願いします!

エンジニア斉藤(以下、shunta): 僕がuniqさんを紹介する?

━━ ハイ(笑)

shunta: なるほど(笑) じゃあ、こちらはデザイナーの石崎さんです。社内の呼び名はuniq(うに)さん。この対談中も「uniqさん」で通しますね。

デザイナーだけどエンジニア寄りなこともできる人で、最近は手を動かす仕事が多いみたいですね。マークアップよりのことがかなりできるし、HTML・CSSだけじゃなくJavaScriptも知ってます。DIST *1PyConJP などイベントの運営側をよく手伝っていたりして活動範囲広いですよね。勉強しているなと思う。 使いやすさを主軸においたデザインができるデザイナーさんです。

キャリア面でいうと、ドワンゴとか大きい組織の経験があって、自分にはないので参考にさせてもらうことも多いです。 プライベートでは「犬一色」。ビルディット入社後に飼い始めたと思うんですが、それ以降Facebookの投稿がほぼ犬になってます(笑) 埼玉在住で、社内では通勤が一番遠いんですが、自分も地元が埼玉で同郷です。そのほかに楽器をやることとか共通点が多い人です!

━━ 予想以上に詳しくありがとうございます!では逆に、石崎さんから斉藤さんを紹介してください

デザイナー石崎(以下、uniq): はい、フロントエンドエンジニアの斉藤さんです。社内ではshuntaさん。私も対談中shuntaさん呼びでいいでしょうか。

shuntaさんは前職がデザインに強い受託開発会社出身。 私がビルディットに入りたいなと思って調べていたときに、「社長がバックエンドエンジニアなのでエンジニアリング優先の環境なのかな?」と少し心配に思ったんですが、shuntaさんの前職の紹介を見て、そこは心配しなくても良さそうだな〜と思ったのを覚えています。 実際は社長もわかってくれる人だったんですけどね。

UIデザインについて、デザイナーのツラミややりがちなミスも察して先回りして対応してくれる、本当に有り難い存在です。 フロントエンドっていうとJavaScriptばかりかと思いきや、バックエンド、ミドルも知識が深くて、フロントエンドのくくりでいいの?!と思いますね。 仕事でいろいろ調べたりするときに、和訳されたまとめサイトの情報じゃなくて原文(一次情報)を辿っているのがすごいと思うところ。外国語のドキュメントに対してハードルを感じてないように見えます。

あと、エンジニアって「何事もググれ」という文化だと思ってましたが、学生アルバイトさんにしっかりレビューするし、質問されたことの回答だけじゃなく周辺情報も含めて幅広くアドバイスしているのをよく見かけるので、良い先輩エンジニアだと思います。

仕事以外だと、とにかくめっちゃ食べるし食べるのが大好きな感じ。 ランチは皆で行くことが多いですけど、自分がお店の提案するときは斉藤さんが満足する量かどうか気にしちゃいますね。あとゲームと音楽に詳しい。

いま八王子に家を建築中だから本人の興味はいま家のことに集中しているのかな。奥さんとすごく仲良しでたまに出るエピソードがほのぼのしてます。

━━ すごい!こちらも詳しい!これ二人を知らない人でも人物像描けそうですね(笑)

現場で起こりがちなことは?

━━ さて本題です! デザイナーとエンジニアで共同で案件を進める機会は多いかと思います。「協働」して作業を進めるにあたって実際にどういう所が難しいのでしょうか?課題やそれに対する対処など、あるあるな具体例を聞かせてもらえますか?

二人: まあ色々ありますよね(笑)

uniq: デザイナーとしては、エンジニアさんのタイプによっては、この大きさ・幅は何ピクセル、スペースは・・とデザインの全てを一個ずつ書き出して指定しないと、見た目を綺麗に実装してもらえないことがありますね。 パーツは一応全部入っているんだけど、レイアウトが全然違うとかね。

shunta: エンジニアの視点からは、UIが揃っていない、デザインの段階でUIが決まっていないことも結構ありますよね。 あと少し昔には画像が無いとかよくありましたね。これはZeplinやFigmaとかのツールが解決してくれて、今はほとんど問題は起こらなくなってきましたけど。

あとWeb画面のビジュアルを「アプリみたいにしたい」って簡単に一言でいうのとか。

uniq: あるある!デザインだけを考えていると、アプリだとできるからWebでもできるでしょと思いがちなんですよね。 ある程度実装をやったことがあれば、アプリと同じようなUIをCSSとHTMLとJavaScriptで作るのは結構難しいってことが分かるんだけど。 Webでは見た目をそれっぽくUIを作ってもOSやブラウザによっては想定通りに動かないということも結構あるし、環境ごとに見た目の崩れやアニメーションの挙動の確認などをやらなくちゃいけないので大変...

shunta: そうそう、元のデザインは一枚の絵みたいなものなんだけど、それをベースにしてPCの画面、サイズ毎のスマホ画面、縦と横で見る場合、処理速度の遅い古い端末の場合、、とエンジニアはそれらを考慮して実装をしないといけないから。

uniq: 画面遷移の仕方やその間のインタラクションなんかは、曖昧な指示にせず、統一性をもってデザインする必要がありますね。 ただデザイナーにしてもエンジニアにしても、各種のガイドラインを読み込んでいたり、色んなサービスを触ってる人はそんなに違和感のある実装にはならないですよね。

━━ 次々に出てきますね(笑) 今の話から、両者ともお互いの作業の過程について理解することが大事なんだというイメージが湧いてきました!

越境するとどうなるか

━━ 最初にshuntaさんがuniqさんを「エンジニア寄り」と言っていたとおり、uniqさんはエンジニアの視点も持っていそう。実務ではどうですか?

shunta: 実装しやすさを考えてデザインを作っていますよね。 例えば文章量が可変になる場合でも違和感の無いコンポーネントのデザインをしてくれてたりします。

コーディングに参加しない・実装を全然知らないデザイナーさんとは、「文章がはみ出る場合にはどうなんですか?」なんていうやりとりがしょっちゅう発生するんですが、そういった手戻りがかなり少ないですね。 あとコーディングするときに繰り返しで済むようにデザインを作ってくれますね。

でも逆に、実装面を優先してデザインを作るというのは、デザイナー的な楽しさは減るんじゃない?という気もするんですがどうです?

uniq: たしかに実装を知らないからこそ、自由に発想できるというのはあるかもしれないですね。 私は実装自体が結構楽しくて好きなので、それに縛られて嫌という感覚はあまりないけど。

実装がわかるメリットは他にも、デザインを考える時に全くのゼロベースからよりは実装ありきで必要な枠の中で考えられるから、早くデザインを上げられるようになるということもあります。

ただ、プロダクトによっては、デザインを考える上で枠を取っ払ってとにかくアイディアを出して発想を広げることが必要になるタームもありますね。 そういうときはちゃんとそうするようにバランス持ってやりたいですが、どこかで「枠」は意識しちゃっているかもしれない。

━━ uniqさんからみて、エンジニアshuntaさんのデザイナー視点はどんなところ?

uniq: 最初に言った「デザイナーのツラミややりがちなミスを分かってくれて先回りして対応してくれる」ということが大きいかな。 細かい部分を作り込まずに全体を作る時、空白部分とか細かいところの部分がどうしても甘くなるんですよね。そういうところをいちいち確認せずとも「よしなに」やってくれたり、スマホのビューをデザイナー側で作らなくても、作ってくれたり。 デザイナーによってはPCとスマホの両方をしっかり作れない人は結構いるんですよね。

shunta: 自分は「よしなにやろう」って結構言うんですけど。 PC、スマホなど多様な画面サイズでのマージン指定などを、きっちりデザイナーさんがやりきるのは時間が足りなくなるので、判断できる部分はエンジニアが "よしなに" 対応すると良いのかなと思います。

エンジニアのスタンスとして、ちゃんとデザインを作ってくれないと開発に全然着手できない、だとアウトプットが遅くなってしまうので、作りながら調節していけるように考えています。

uniq: 斉藤さんの「よしなにやる」はほんとに頼りになるんですよ! ちょっと聞きたいんですが、Sketchで画面を作ったとしてもブラウザで見れるわけではないし、そのまま実装できるわけではないですよね。実際ブラウザで表示させたら違和感ある場合もあるし。そんな時に斉藤さんはどんな風にやってます?

shunta: 基本的にはデザイナーさんが作った通りに実装するんですけど、ちょっとした誤差なんかは各デザインガイドに則ってやることが多いですね。「よしなに」は感覚ではなくて、そういう知識や経験のベースに基づいてやっています。 逆にデザイナーさんによってはOS別のデザインガイドを把握していないこともあって、指示通り作ると違和感がある場合はちゃんと確認します。

共通言語はデザインガイド

shunta: 最近はAtomic Designのような、再利用性を意識したデザインをしていただける事が多くなってきたかなと思います。

uniq: 再利用できるというのは大事ですよね。 斉藤さんはデザインガイドもよく知っているし、UIデザインの全体的な知見があるし、デザインとの距離が近いですよね。

shunta: フロントエンドエンジニアなので、Webにも応用の効きそうな、マテリアルデザインガイドは一通り読みました。 AndroidとWebはマテリアルデザインガイド、iOSはヒューマンインターフェイスガイドライン(HIG) とか、OSごとにそれぞれの哲学があるからデザインガイドもそれぞれで、一緒でしょという人もいるけど自分はそんなに甘くないと思ってる。

uniq: その通りで、必要なことはデザインガイドを見れば全部書いてある…んだけど、実はUIデザイナーでもデザインガイドをちゃんと全部読んでいる人は少ない気がしますね(汗) エンジニア向けの内容かもしれない! 私は必要に応じて必要な箇所をその都度読んでいる感じですけど、エンジニアさんにデザインを説明する時にどう表すか、デザインガイドがかなり参考になることに気づきました。 デザインガイドは共通言語になりますよね。

shunta: そういう共通言語を使って、お互いの領域を超えて知っていくことで良いものを作れるってことなのかなと思いますね。

越境に踏み出した、それぞれのきっかけ

━━ エンジニアなのにデザインの知見を広げ始めたことに、何かきっかけがあるんですか?

shunta: やっぱり知っていたほうが仕事がしやすいから。。でもそんなの無くてもいいという人もいるし、実際はそれでも仕事はできないわけじゃない。 自分はデザインのことに限らずですが、色々知りたくなって勉強してます。もともとの性質的に探究心が強い傾向があるみたいで、それが関係している気がします。 以前に自分の強みを知れる「ストレングスファインダー」をやった時に、探究心とか収集癖がとくに強い傾向が出てきて、なるほどなと納得しました。

あと一番初めのきっかけは、2社前に勤めていた会社の上司と実は折り合いが悪くて、、エンジニアの仕事をあまり振ってもらえなくてデザインの仕事をさせられていた、というのがベーススキルになっている気もする(苦笑)

━━ uniqさんが実装もするようになったのはいつから?なぜですか?

uniq: 前に別の記事のインタビューでも話したことがあるんですが、ドワンゴでの経験からですね。自分がデザインしたものに最初から最後まで関わりたくて、やりたいやりたいと言っているうちにこうなりました(笑) 最後まで関わりたいと思うようになったきっかけは、デザインしたものが実装されたら全然違うものになっていた経験です。自分がいいと思ったものをちゃんと作りたいなと。

shunta: そこですよね。 それぞれの領域内の知識から一歩も出なくても仕事はできる。 でも、自分の思うものをより良い形で作りたいとか、もっと仕事をやりやすくしようと思ったら、領域の外に一歩踏み出して知識を取りにいくべきだと思う。

あとエンジニアだったら、常にデザイナーと一緒に仕事する環境ばかりでもないですからね、コミュニケーションとりにくかったり、そもそも実装の段階ではデザイン作ったデザイナーがすでに離れていることもある。 その時にいちいち細かいことまで時間かけて確認したり、毎回ゴリゴリコミュニケーションして、だと自分も辛い。わかっていれば自分で判断できる範囲が広い。

越境コミュニケーションの現場

━━ ビルディットではデザイナーもエンジニアも同じ空間にいてスムーズにコミュニケーションしていますよね。一緒に開発しているし相互にレビューもしている。 でもそうする中で、自分の範疇に領域外の人から意見されると嫌な気持ちにならない?どんな感じですか?

uniq: わたしはありがたいな〜と思います。ただ自分はレビューするのに結構気を使ってしまうから苦手意識があって、ちゃんと言える人のことは関心してしまいますね。 実際、デザイナーがエンジニアのコーディングについて意見するなんて場面はほとんどないんですが、デザイナーからデザイナーへのレビューも、チーム外からのレビューも、緊張しちゃいますね。

shunta: いや、uniqさんは場数踏んでるから伝え方すごい上手いと思いますよ(笑)

uniq: ありがとうございます! 結構気を使いつつ、自分がレビューする場合は、自分の立場とか向かうべきゴールとかタイミングを意識してレビューするようにしています。 デザイナーからエンジニアの場合、ロードが遅く感じる、画面の切り替えがキビキビしてないとかが気になったとしたら「早くしたい」とかの結論は言わずに、「ここのユーザー体験をよくしたいけど、何か良い手立てはないか?」という聞き方をするとか。

shunta: さすが!自分もデザイナーさんに対してデザインへの意見をいうことは実際ほとんどないですね。プロフェッショナルの部分には信頼を置いてます。手が回らないところを手伝うスタンスです。

━━ お互いに適度に配慮しつつのコミュニケーションも、良い議論の一要素なんですね。そして適度に配慮ができるのも、相手の技術への理解があるからこそ。

協働の現場だから生まれる、共感と創造

━━ では、今はuniqさんとshuntaさん、別のプロダクトを担当していますが、一緒のプロダクトを作るとしたらどんなの作りたいですか?

shunta: お互いに仕事の効率が上がるようなツール、プロジェクトやタスク管理ツールに結構興味がありますよね。

uniq: ですね!Sketch、XDのプラグインとか、、「こういうプラグインあったらいいな」っていうイメージを私が作って、shuntaさんが実際にそれを作ってくれるとか! 私はデザインの仕事しなくていいかもしれない(笑) プロダクトのランディングページを作ろうかな〜

shunta: 自社事業としてそういうのやれるとかっこいいですよね。

uniq: やってみますか!


ありがとうございました! いま二人は同じプロダクトに携わっているわけではないのですが、同じ空間にいて、境界を踏み越えた知識で切磋琢磨しているからこそ、ビルディットの協働しあう空気がさらに濃くなったいるんだなと実感しました。

こんな空気感で一緒に成長したい仲間を少しずつ増やしていきたいと思っています。 ご興味をお持ちくださった方、ご応募・問い合わせお待ちしています!

bldt.jp

*1:Uniqが運営スタッフとして参加しているDIST(ディスト)は、職種や技術の垣根を越えてWebに関わるすべての人を結ぶクリエイティブコミュニティとして定期的に勉強会などを企画開催されています。運営指針に共感し、この11月からビルディットもスポンサーとして協賛しています dist.connpass.com