Inside BuildIt

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

ゆるはち.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

「手段を目的化する」と言っていた開発会社のその後について

エンジニアの富田(@tmtysk)です。八王子で開発会社を始めて3年半ほど経ちました。現在の株式会社ビルディットは、Webサービスのデザインフェーズから開発・運用をお手伝いさせてもらう、デザイナー/エンジニア/採用広報担当合わせて総勢7名のチームになりました。これらのフルタイムメンバーの他にも、アルバイトや業務委託の方とのご縁に恵まれ、合わせて15-20人くらいが弊社での開発のお仕事に関わってくれています。

さて、創業時に以下の記事を書いていたのですが、当時は(僕の記事にしては)ちょっとだけ多くの方に届いていたようです。僕にとっては創業の決意表明みたいなものだったのですが、いろんな方に「読んだよ」と言ってもらったことは嬉しく受け止めておりました。弊社のメンバーには、この記事に共感して参加してくれた者も何名か居り、多くの方が仰っているのですが、発信活動って大事です。

medium.com

勝手にイベント名に親近感をもち、その思想にも共感した builderscon には、2017年, 2018年と協賛させていただき、やっぱりこんなキーワードで企画記事を書いていただきました(ありがとうございます)。2018年のトートバッグは、僕も愛用しています :)

lantern.builderscon.io

さて、前置きが長くなったのですが、そんな「手段を目的化する」って言っていた会社が3年経ちまして、実際どうなんよってところをちゃんと発信しておいたほうがよろしかろうと 採用広報担当に詰められまして、 思いまして、今回改めて振り返ってみることにしました。長文のポエムです。ご興味の方にお読みいただければ嬉しいです。

続きを読む

ゆるはち.it 第14回【CSSフレームワークについてゆるく話す】参加レポート

はじめに

7月に入社した日置です。よろしくおねがいします。最近は Rust にお熱です。

ゆるはち.itの紹介

ゆるはち.it は毎月八王子でやっている勉強会で、八王子にもかかわらず新しめの技術を知れるし話せるのが特徴です。

ビルディットに入社する前にも自分は二度ほど参加し、一度目は聞く側で、二度目は話す側で参加しました。最初に乾杯があり、徐々にお酒もまわっていきますので、発表も気楽です。

ちなみに自分は前回の ゆるはち.it では『Rust で学ぶ TOTP』を話しました。

speakerdeck.com

このテーマに決めたのが Rust に入門して 1 週間程度で「さて Vim で書く準備は整った」レベルだったため内心ヒヤヒヤしていましたが、なんとかうまくまとまった気がします。

ちなみに Rust に入門した経緯というのは、代表のとみたさんに『実践Rust入門』を一緒に読まないかと誘われ、ハマってしまいそうで危険だなと思いつつもホイホイ付いていったのがきっかけでした。

gihyo.jp

そんな感じで個人的にはとにかく発表の敷居が低いため、自分のような発表駆動で学びたい方など気軽に申し込んで頂けるとありがたいです。お酒を飲みながらほへーと聞きますので。

ゆるはち.it【CSSフレームワークについてゆるく話す】のレポート

今回のテーマはCSSフレームワークで、以下のような三本立てでした。

  1. 『CSSフレームワーク選びのポイント』
    • CSSフレームワーク界隈の話 (Bootstrap, Bulma, Semantic UI, PureCSS, Tailwind, Tachyons)
  2. 『Tailwind CSSでいろんなUIをつくる』
    • 界隈で満足度 No.1 の Tailwind を使った具体的な実装の話
  3. 『CSSフレームワークに頼らない受託マークアップエンジニアのサイト制作術』
    • 現場感ある熱い話

まずは全体像を話し、その後具体的な実装も見せ、最後には頼るな!という何というかキレイな流れだったように思います。

では、ひとつずつ見ていきます。

トーク1: 『CSSフレームワーク選びのポイント』

speakerdeck.com

スライドで紹介されていた以下のページ、このページを知れただけでも自分には価値が十分にあるというか、

2019.stateofcss.com

恥ずかしながら自分は Bootstrap しかちゃんと触ったことがなかったですが、すごく楽しめましたし勉強になりました。

  • ユーティリティ系 or UIパーツ系
  • デザイン仕上がってる or デザインあっさり

というような軸で分析されていて、大変わかりやすかったです。さらっと読めるので自分のような CSS 弱者は騙されたと思ってぜひ読んでみてほしいです。

トーク2: Tailwind CSSでいろんなUIをつくる

speakerdeck.com

Tailwind を使ってモーダルを一から作っていく過程を Storybook でリアルタイムプレビューしながらデモしていくという内容でした。

自分は途中懇親会用のピザを取りに行く必要があり泣く泣く抜けて中途半端にしか見れていませんが、実践的でわかりやすかったのでもう一度見たいと強く思いました。

コードは以下にあります。clone して README どおりに $ npm i, $ npm run storybook, $ npm run dev すればデモ当時の環境がサクッと起動します。ぜひ!

github.com

LT1: CSSフレームワークに頼らない受託マークアップエンジニアのサイト制作術

  • 案件によってはすでにひととおりでき上がったのものに対してスタイルを当てるといったものも多く、そういった場合に後からフレームワークを導入するというのは難しい。
  • そんな時にも便利な自分なりの最小限のフレームワークを持っている。
  • さあ、HTML と CSS を知るんだ!!

というような検索では見つからない現場感ある熱い話を聞けました。心にしみました。

とびこみ LT2

西東京のデザイン系の勉強会がないから作ったというお話でした。デザインの実践に近い勉強会で、次回はバージョン管理の話をするようです。こちらもぜひ!

westtokyowebstudy.connpass.com

次回告知

次回のゆるはち.itは「地味にスゴイ! Webデザインテクニックについてゆるく話す」です。

yuruhachi-it.connpass.com

開催日程は 10/30 (水) です。登壇者もまだまだ募集していますので、ぜひ!

おわりに

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

採用情報|株式会社ビルディット「手段を目的化」する同業組合型IT企業

ゆるはち.it 第12回【スプレッドシート駆動開発】参加レポート

はじめに

こんにちは。
株式会社ビルディットでWebエンジニアをしている佐野です。
最近はLaravelで権限管理のコードに触れていたのですが、ややこしいケースがあって非常に悩みました……。
大半のプロジェクトで権限について考える機会はあると思うので、ぜひこの辺りもお話ができたら楽しいなと思います。

さて、今回も先月に引き続き、私が運営に参加している勉強会 「ゆるはち.it」についてレポートを書きます。

ゆるはち.itの紹介

ゆるはち.itでは、毎月末水曜日に月ごとにテーマを決めて勉強会を実施しております。八王子という都心から離れた場所で、ゆる〜い雰囲気で勉強会をやってます。
「都心までいくのは面倒だけど、新しいITの話をしたい」とか、「ガッツリした講義のようなイベントはちょっと……」という人にオススメの勉強会です。

毎月登壇者も募集していますし、「次回のテーマはデザインについてが良い!」というような声があれば、沿ったテーマで勉強会を開催します。
勉強会のタイトルにもある通り、とにかく「ゆるく勉強会をやろう」というコンセプトです。
ご興味がある方はぜひ参加してみてください。
直接声をかけていただいても嬉しいです!

connpassページはこちら↓

yuruhachi-it.connpass.com

ゆるはち.it【スプレッドシート駆動開発】のレポート

どんな勉強会だったか

今回のテーマは「スプレッドシート駆動開発」でした。
RPA(ロボティック・プロセス・オートメーション)の台頭や、Googleスプレッドシートの登場で、改めて注目を浴びています。
情報システムの現場ではデータの管理から、業務の改善まで。
その他の企業においても発注書をスプレッドシートで作ったり、家庭においても物品のリスティングなどと、さまざまな利用法があります。 最早、誰しもが触ったことのあるツールであることは間違いないと言っていいでしょう。

そんなスプレッドシートに関する勉強会ですが、内容としては、

  • Google Apps Scriptを利用して、モダンにスプレッドシート駆動開発をする
  • スプレッドシートと連携したWebサービスの紹介
  • 実際の開発現場におけるエクセル利用の事例

と多様な視点からのトークが集まりました。

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

トーク1: モダンGASプログラミング

手前味噌ですが、私が発表させていただいたトークです。
巷でGoogle Apps Scriptが流行っていたので、Google Apps Scriptに纏わる話をいろいろとさせていただきました。

Google Apps Scriptの紹介から、利用事例、その他Google Apps Scriptの便利機能。
そして、claspを利用してさらにモダンな開発環境を作ろうといった内容です。
claspを利用すれば複数人での開発もやりやすくなり、属人化しやすいスプレッドシート開発をコード化できます。
ぜひ使ってみてください。

資料はこちら

トーク2: Google Sheetsを活用したサービスの紹介

さまざまなスプレッドシート関連のサービスが登場しているので、そのサービスについて調査/紹介しているといった内容です。

f:id:jalemy:20190816113729j:plain

スライドにて紹介されているProduct Huntを利用して、スプレッドシート関連のWebサービスをみてみたのですが、執筆時点で100種類近く存在しました。そんなに種類あるのか……と驚きます。

  • スプレッドシートをデータソースとしてWebサイトを構築するサービス
  • スプレッドシートをDBとして利用できるようにするサービス
  • スプレッドシートと自然言語処理を組み合わせたサービス
  • コラボレーションツール

とさまざまなサービスが存在しました。

最後には、発表者自身がRuby on RailsGoogle Spread Sheetsを組み合わせてWebサービスを作ってみたという内容もあります。

そんな発表の資料はこちら

LT1: ワードとエクセル(と山盛りのVBA)で作る、要求仕様書と受入テスト仕様書の一例

実際の開発現場におけるワードとエクセルの利用事例です。
私はVBAを見たことはあるものの、実際に書いたことはほとんどないため、かなり興味深い、濃い内容でした……。
エクセルに列挙された内容をもとに、テスト仕様書が自動生成される図は必見です。

機密事項が多いため、スライドにはあまり情報が乗っていません(気になる方はぜひ勉強会へ)

Tips

ゆるはち.itでは、トーク終了後に懇親会の時間を設けています。
会場の近くにあるピザ屋さんのピザを食べながらいろいろなことを話しています。
ここでの出会いがもとになり、「次回登壇することが決まった」とか、「新しい仕事が決まった」とか、そんな話もあるとか。
新たな出会いを見つけられることも勉強会のメリットかなと感じました。

f:id:jalemy:20190816114031j:plain

次回告知

次回のゆるはち.itは、「Web開発の認証」がテーマです。
開催日程は、8/28(水)です。

トーク、LTともに登壇者を募集しています。興味のある方はぜひ申し込んでください!
もちろん聞く人枠でのご参加も大歓迎です!

connpassページはこちらです。

yuruhachi-it.connpass.com

おわりに

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

bldt.jp

「協働」で、より良いサービスをつくる。リードエンジニア×若手UIデザイナーインタビュー

こんにちは。広報の大木です。

弊社がサービスデザイン・設計開発に参画した、ジギョナリーカンパニー様が提供するソーシャルロケーションサービスの「MachiTag(マチタグ)」が今年4月にサービス開始しました。弊社からはエンジニアの斉藤とデザイナーのgrapeの二名が関わりました。今回その二人のインタビューをご紹介します。

f:id:miyakmakij:20190725103621j:plain

ビルディットの開発スタイルの特徴として、エンジニアとデザイナーが一つのチームで常に協働していること、いつでも気軽に話せる近い距離で仕事をしていることがあります。

そしてもう一つ、メンバー固有の要素とも言えますが、UI/UXデザインに知見のあるエンジニアと、エンジニアリングの知識があり実装ができるデザイナーがいることによって、社内に職種の境界による分業意識がなく、お互いがより良いもの作りを追求できる環境ということも大きな価値を持っています。

インタビューは、若手デザイナーであるgrapeの視点をメインに、開発の様子、デザイナーの役割、デザイナーとエンジニアがチームで協働することがサービスにとって、また自分にとってどんなメリットがあるのか、などを聞いていきたいと思います。

また、grapeは現在大学院に通う学生でもあり、若いメンバーがどう成長しているかを知っていただき、同じく学生で将来デザイナーを目指す方や、若手デザイナーの皆さんにも、自身が働く場を考える際のヒントがあればと思っています。

目次

人物紹介

grape(デザイナー)

大学院でUI/ UXを専攻する中国からの留学生。現在は週3日勤務。 日本に来る前は中国で大学卒業後、新卒で上海Uber社(世界規模の配車Webサービス事業)でUI・グラフィックデザイナーとして1年間の実務経験。 学生アルバイトでありながら、ベーススキルもしっかりある頼もしい存在。

※学業が本分なので、本名でなく社内のニックネームでご紹介します。

斉藤(リードエンジニア)

ビルディットでは代表の富田の次に二人目のメンバーとして参画。得意分野はフロントエンド(React, Vue…)、前職はグッドパッチ社でUI/UXの経験を積み、デザインにも深い知見をもつエンジニア。

f:id:miyakmakij:20190724151254j:plain
(左)grape  (右)斉藤

「MachiTag」開発、そしてリリース

f:id:miyakmakij:20190724150706p:plain
https://www.machitag.com/

──MachiTagは「今いる場所で、探さなくてもいきたい場所が見つかる。ユーザー中心のロケーションプラットフォーム」をコンセプトとしていますね。 クライアントと最初にサービスについてお話ししたときの印象は?

斉藤)そうですね。最初にサービスのコンセプトをお聞きした時には、汎用的に使える、業界問わず広がりのありそうなサービスだなと思いました。 技術的には、地理情報(GIS)を使ったサービスということで、初めて取り組む機能もあり、ワクワクしながら開発を進められました。

──開発が始まったのはいつ頃からですか?

斉藤)今年の年明けくらいです。grapeはそれまではリードデザイナーの石崎と一緒に仕事をしていましたが、MachiTagはデザイン提案からgrapeにメインでやってもらいました。

grapeがビルディットにきて半年強の頃ですね。

──grapeさんにとっては、要件からローンチまでをメインで携わった初めてのプロダクトということですね。最初にアサインされた時と、リリースの時の気持ちを聞いてみたい!

grape)アサインの前、別案件で石崎さんの手伝いをしていました。ある時富田さんから「新しいサービスを作りたい?」と聞かれて、「もちろんやりたいです!」と答えました。

それからMachiTagの話を聞いて、その開発に自分がメインデザイナーを担当できると知ったときは、興奮と、正直にいえば少しだけ不安もありました。もっと頑張ってもっと成長しないといけないと。 リリースのときは、本当に何もないところからゼロから携わったので、それはもうとにかく興奮です。やりきった感、達成感のひとことです!

それぞれの役割分担

──エンジニアとデザイナーとでチームで開発するというのは具体的にはどんなふうに役割分担をして進めていくんですか? f:id:miyakmakij:20190726132533j:plain

斉藤)クライアントとのやりとりやヒアリングは主に私が担当しました。 クライアントのやりたいことを理解した上で、grapeに相談して、デザインを作ってもらいます。

役割分担としては、デザイナーにはデザインを作る段階ではユーザーニーズに思いきり寄せたデザインを作ってくれることを期待しています。

エンジニアは実現性の視点が最初にきてしまうので。

実装面でのレビューが必要な分、より時間がかかってしまうのですが、最初から実装のことを考えたデザインに収めるとユーザーにとっての最適を追求しにくいし、なによりも面白いものが作れないですよね。

デザイナーにはユーザーがワクワクするようなデザインとか、ブランドイメージに思いきり寄せてデザインを作ってもらって、現実的な仕様とそれの最大公約数を探るのが良いサービスを作るっていうことだと思っています。それが役割分担のベースです。

──なるほど。仕様をもとに実現性から考えるエンジニアと、ユーザー体験や使い勝手の優れたものを考えるデザイナーが、それぞれ自分の領域を思いきり膨らませるんですね。

日々の仕事のすすめかた

──日々の実務はどんな感じに回っているんですか? f:id:miyakmakij:20190724150914j:plain

grape)流れとしては、クライアントとの窓口である斉藤さんがIssueを書いて、それを見える形にするのが自分、デザインしたものをクライアントに確認にして、また必要なIssueが上がって、を繰り返していきます。Issueの管理はGithubです。

Issueには細かい補足も丁寧に全部書かれていて、ちょっと確認したいことなんかはいつも側で仕事しているので気軽に聞いてますね。

斉藤)普段からよく話しているから話しかけにくいとかは全然ないよね。

自分がIssueに書いたことが伝わりにくいかなと思うことは事前に口頭で認識合わせもしますけど、分かりにくいことがあればすぐ聞いてくれると思っているから全く不安に思うことはないですね。

grape)先輩デザイナーの石崎さんはMachiTagではアドバイザー的な関わりですが、必要に応じてレビューをお願いしています。 斉藤さんはUIが分かるエンジニアなのでデザインについても意見がもらえるんですが、UIデザインの専門性がより高い人にもらえるレビューはまた違う視点があります。

斉藤さんからの意見はどちらかといえば実装よりで、石崎さんはデザインより、それは当然なんですが、UIが分かるエンジニアである斉藤さんと、実装が分かるデザイナーである石崎さんからのアドバイスは、普通のエンジニア・デザイナーとは一味二味違って、すごく勉強になります。サービス作りは刺激的ですごく面白いです。

新しいサービスの開発は難しい

──「MachiTag」のサービスは、既存のグルメサイトやSNSとはコンセプトにかなり違いがありますよね。そういう今までにないサービスの設計は、開発が難しいですか?

grape)そうですね、自分にとって難しいことはたくさんありました。

タグの導線とか、ユーザーの動き方とかが今までにない新しい仕様なので、ユーザーにどうやって使うメリットを伝えるか、直感的に使ってもらうにはどうしたら良いか、が課題でした。

──どんな風に課題を解決していくんですか?

grape)自分のアイデアをまず斉藤さんに話して、OKが出たら週に1回のクライアントとの定例会で相談します。週に一度直接話せる場があるのが、課題を共有しやすくて良かったです。

──定例会はいつもスムーズに進む?

grape)いや、スムーズにいかないこともあります。

クライアントからの要望は、デザイナーが考えるユーザー最適とは一致しないことがあります。 お互い主張するだけでは平行線なので、その場で適切な落としどころを話し合って決めていきますが、やはり難しいです。 だからこそ定例会で毎週直接相談できるタイミングがあるのは良いですね。 f:id:miyakmakij:20190724151020j:plain

協働のメリット

──「協働」というキーワード、そのメリットはなんですか?

斉藤)協働のメリットというよりは、自分は以前の会社でもデザイナーと一緒に案件を進めることが多かったので、そうじゃない環境で良いサービスを開発するのはすごく難しいと思いますね。

一度、デザインが決まっていてこの通りに作ってくれ。という案件があったのですが、実現性を無視したデザインになっていたりして、実装に苦労したことを思い出します。 「協働」することは自分にとっては良いサービスを作るための重要なファクターですね。

さっき話が上がった通り、デザインが分かるエンジニアと、エンジニアリングが分かるデザイナーというメンバーだからこそ、それぞれの境界があまりなくて、お互いがそんなに努力することなく協働できる環境をより醸成しているのかもしれませんね。 お互いへの理解が薄いと、協働するための歩み寄りがほんとうはもっと必要なのかも。

grapeがそんな感覚を身につけてきたのと同じように、これから新しいメンバーが増えていく中でそれが標準になったら良いですよね。

f:id:miyakmakij:20190724151112j:plain

ビルディットにきた経緯

──話は遡りますが、grapeさんがビルディットにきた経緯を教えてください。

grape)ビルディットにきて1年ちょっとです。

大学院に入学して、大学と自宅から近い場所で仕事があればと思ってWantedlyで「八王子 デザイナー」で検索してビルディットの求人を見つけて。 日本での仕事はビルディットの前にもう一つ、都心にあるシェアサイクルのスタートアップ企業でインターンをやりました。

斉藤)grapeは学生だけど、UIの経験もあるし中途採用のメンバーと同じような感覚でしたね。最初からベーススキルはしっかり持っていたし。初めからそれなりに任せてました(笑)

grape)中国での仕事はグラフィックデザインがメインだったので、UIを本当にやったのは日本に来てからですけどね。 それと以前はデザイナーだけのチームで仕事をしていて、エンジニアとの関わりは全くなかったんです。完全に分業で、デザインを渡すのもマーケティングチームでした。

UIデザインとかアプリは作りながら改善が必須だからいろんな人と関わりながら仕事しますよね。環境は全然違いますが、今の方が自分のやりたいことができています。

成長の実感

──ビルディットで1年、成長したって感じますか?

grape)感じます! 一つはデザインのプロセスですね。

サービス開発はグラフィックのようにビジュアルを作って終わりではないので、デザイン提案から始まってリリースしてその後の分析・検証…とかの一連のサイクルに関われるようになって、それが前よりもうまくできるようになった気がしています。

もう一つは「アプリ」の理解、というか、日本と中国では「使いやすい」の仕様・ロジック・考えが全然違うんですよ。 その違いに戸惑っていることが多かったのが、日本のアプリへの理解が追いついてきました。

あと大学院で勉強していることもUXなので、勉強で得た知識を実務に反映してみたり、その逆もあったりで両得な感じです。

──斉藤さんからみて、grapeさんの成長ってどんなことですか?

斉藤)もとからちゃんと経験もあって、できる人だと思っているけど、アプリとWeb両方をバランスよく経験つめているし、ローンチして終わりじゃなくて運用改善までやってもらっていて、そこに必要なコミュニケーションもさらにうまくなっているなって思いますね。

これはビルディットにきてからの成長ではないのかもしれないけど、グラフィックセンスがあっていつも綺麗なものを作ってくれるので信頼してます!

grape)(照)ありがとうございます! f:id:miyakmakij:20190724151210j:plain

この先の進路

──大学院を卒業した先の進路は決まっているんですか?

grape)まだちゃんと決めていないですね。。

もし中国に戻るとしたら、アリババのような大きい会社でUIUXをやりたいと思うし、チャンスがあれば日本で就職したい気持ちもあるし。 両親と離れてずっと日本で生活し続けるのは親が心配なんですけど、両親からは日本で就職したら?とも言われたり。すごく迷います!

──クライアントに自分の意向をちゃんと伝えられるくらい日本語は堪能だし、今までの経験と実績があれば、そのどちらでも希望する道を選択できそうですね! ビルディットという選択肢ももちろんありますよね(笑)

f:id:miyakmakij:20190726132900j:plain お二方、ありがとうございました!

エンジニアとデザイナー、それぞれの専門職が「協働」するのに、双方で何らかの努力、または何らかのノウハウが必要なのではないかと思っていましたが、お二人の話を聞いているとあくまで自然に役割分担と相互補助の関係ができているように感じました。

デザインが分かるエンジニアと、エンジニアリングが分かるデザイナー、そのメンバーたちのチームワークが、クライアントにとって、そしてユーザーにとって最適なサービスを生み出せるだけでなく、若手のメンバーを広域のスキルを持った次世代のクリエイターへ育成することにも繋がっているのだなと思いました。

ビルディットは現在のところ少数精鋭といった所帯ですが、若手が育つ環境もしっかりあると感じたインタビューでした。


弊社デザイン顧問イシジマミキとリードデザイナー石崎の対談リポートも 合わせてぜひお読みください! inside.bldt.jp

inside.bldt.jp

bldt.jp