fujiken design blog

でざいんをやっていく

開発スピードを上げるため、Sketchを辞めてFigmaに移行した話

f:id:kenshir0f:20180713002356p:plain

こんにちは、ふじけん (@kenshir0f) です。
普段はモバイルアプリを主としたサービス開発のデザイナーを担当しております。

業務ではSketchを使ってアプリのUIを組んでいるのですが、 先日チームの開発体制を見直すときにFigmaというデザインツールに移行しました。
Figmaに乗り換えるに至った経緯やプロコンなど、ざっくりまとめてみます。  

なぜsketchから乗り換えたのか

今まで他の人と共同で同じsketchデータを作業することがなかったのですが、メンバーが増えてからはabstractで共同で作業していました。
ライブラリを分けたりbranchを切ったりしながらデザインを行っていたのですが、しばらく経つと不満点がいくつか見えてきます。

  • 影響範囲がでかいライブラリを更新するとコンフリクトしやすい
  • branchを切って作業してマージするなどスピードが遅くなりやすい
  • デザイナーにbranchの概念を説明するところから始まるので理解が難しい
  • sketchをもっていない人がデザインデータを見れない

特にデザイナーが増えてくるとデザインスピードが落ちる傾向にあって、これはチームとして良くないためなんとかしたいなー。。。なんて思っているときに見つけたのがFigmaです。
いまのところ開発の中で一番スピードを出せるデザインツールだと感じています。

Figmaに決めた理由

Figmaweb上でデザインデータを作成することが出来るサービスです。
google docs や spread sheetみたいに共同で編集できるイメージですね。

基本的なことはSketchと同じですが、Figmaならではの圧倒的に強い点がありました。

  1. 同期的に作業ができる
  2. webから(招待すれば)誰でもデザインデータを見れる
  3. 誰でもコメントを付けられる
  4. 相手の作業状況やマウスカーソルを視認できる
  5. sketchのデータをそのままインポートできる

特に 1. 同期的に作業ができる が優れていて、
一つのデザインデータを全員で同時に作業できるため、誰かのデザインデータのアップロードを待つ必要がありません。
また 5. sketchのデータをそのままインポートできる が文字通りライブラリや継承されているsymbolなどのデータをそのままインポートすることができます。

しばらく使ってみて致命的な問題はなかったどころか、sketchにはない機能で前よりも作業スピードが早くなったのを実感したので、そのままFigmaに移行完了しました。  

移行するときに注意したこと

Figmaは業界で標準的なsketchと比べて比較的新しいサービスなため、いくつか懸念点を考慮した上で移行しました。
移行するときに判断基準とした項目はこちら。

  1. 今よりもチームとしてスピードを出してデザイン出来ること
  2. 僕が突然いなくなっても誰かが運用できること
  3. コストがかかりすぎない
  4. 数年後にデザインデータを移行できること

1, 2, 3は触っているうちにクリアになりました。
ただ4に関しては不安が残ります。というのも、Figmaがサービスを停止した場合はデザインデータがまるっと消えてしまうためです。また新たに使いやすいデザインツールが出たときに移行できるか、という点でも疑念が残ります。
しかし、sketchもデザインデータをエクスポートする機能はないにも関わらず丸っと移行することができたので、先のことを意識しすぎて現状を放置するよりも改善して先に進むことにしました。

実際に開発スピードが上がったと感じるところ

  • エンジニアがデザインデータを直接見て、マージンやフォントサイズなどを確認できる
  • デザイナーはデザインデータの持ち方を気にせず、デザインに集中できる
  • ディレクターがデザインデータに気になった箇所や仕様に関する疑問を直接コメントできる
  • デザインの変更がリアルタイムで変わるので、コミュニケーションの待ち時間が発生しない
  • プロジェクト、ファイルごとに細かくデザインデータを分割できるためAtomicDesignと相性がよい && デザインデータを管理しやすい
  • ライブラリの参照データを選択して見れるため、コンポーネントを選びやすい

Figmaのまだまだな点

  • 英字フォントだと日本語が表示されない
  • プロジェクト(ファイル)をまたいでコンポーネントをコピーできない(うまくやらないと再設定がしんどい)
  • プラグインがない
  • レイヤーでの操作がたまにこちらの期待している動作をしないことがある(sketchに慣れているせいもある)

特に英字フォントだと日本語が表示されないiOSの場合辛くて、SF Pro Textで日本語が打てないためHiragino Kaku Gothic Stdにして英数字もそれで許容する、みたいなことしないといけません。
合成フォントで解決するか、英数字だけの部分はSF Pro使うなど解決方法はいくつかありますが、僕はしばらく様子見でアップデートに期待ということにしました。
本当に辛くなったら合成フォントでカバーします。

移行した感想

実は最初、Figmaに移るつもりは全くありませんでした。
sketchに慣れていましたし、Figmaに移行するコストもでかいし、、、みたいに思っていたのですが、「あれ、考えが保守的になってるのでは??新しい技術を採用してスピードを上げ、成長する機会を無意識に失ってないか?」など冷静に振り返ってみて、メリット・デメリットを洗い出したあとに移行の決断をしました。

安全地帯から飛び出てトライするのは、やはり勇気がいることだと思います。
今回は大胆に挑戦してよかったと思っていますが、運用でなにか知見を得られたらまたブログにまとめてみます。

ではでは👋

 

2018年の上半期を振り返る

f:id:kenshir0f:20180709005211p:plain

雑に2018年の前半戦でやってきたことを振り返ってみた。
初めての取り組みが多くて成長を感じている(気がする)

ブログを運用し始めた

kenshir0f.hatenablog.com

去年の11月にメモを雑に上げていたが、本格的に書き始めたのは今年の4月から。 これからも学んだことを知見公開としてちょっとずつでもいいからやっていく。

ポートフォリオサイトを公開した

kenshir0f.hatenablog.com

かなり雑に作ってすぐに公開できるのFirebaseのすごいところ。
個人で使う分にはほんとに良いと思う。 このブログもポートフォリオに移行したいが、焦らずにやっていこう。

一眼レフ始めた

kenshir0f.hatenablog.com

まだ仕事では使っていないが、ポートフォリオサイトに載せる写真でもよいので継続的に撮っていきたい。

フルデザインしたアプリを初めて公開した

ゼロから全部デザインしてリリースしたのは初めてなので、めちゃくちゃ緊張した。

今の所評価も高くてほんと嬉しい。。まだまだこれからなのでどんどん改善していきます!

デザインガイドラインを作った

これも初めて。開発しやすいガイドラインというのは今もよく分かっていないので、調査した上でどんどん良くしていきたい。

f:id:kenshir0f:20180708233157p:plain

デザインシステムを作った

これも初めてだ。
新規事業でこんなにもチャレンジさせてくれる環境ないので本当によいチームに恵まれていると思う。
これもまだまだ中身がないのでガンガンやっていく。

f:id:kenshir0f:20180708233412p:plain

登壇した

これも初(ry
下期はすでに発表1つしていて、あと2つ出ることも決まっている。
やっていくぞー。

下期の目標

上期はいろんなことを試してみて、人生で最も成長したなーと実感した半年間だった。
下期にトライすることはざっくりこんな感じ。

  • 新しいデザイナーの育成(というとおこがましいので一緒に相互作用で成長していく体制を作る)
  • 開発メンバーが働きやすい環境の整備
  • Figmaの運用
  • 分析の数字からデザインの改善とユーザーさんの体験をもっとよくする取り組み
  • ポートフォリオサイトの充実
  • 管理画面とアプリ本体の実装
  • デザインシステムの公開

こうやってみると夢があるなー。成長しか感じない気がする。。。
さーこれからだ、下期も引き続きやっていくぞ!!!!

ポートフォリオサイトをFirebase + Next.jsでシュッと作った

f:id:kenshir0f:20180617202552j:plain ちょろっと前にこんな話があったので、簡単にポートフォリオサイトを構築した。

業務でFirebaseを使うため、慣れつつ新しい技術を使ってみたいという思いで手を出してみた感じです。

ポートフォリオはこちら

触りたかった技術

  • Firebase
  • Next.js
  • React
  • Typescript
  • Storybook
  • (AtomicDesign)

デザイン

シュッと公開したかったので中身はほぼなしの一枚ページをsketchで作りました。
細かいところは後で直す予定。

f:id:kenshir0f:20180617200950p:plain

構成

最近は業務でAtomicDesignの思想を取り入れてるので、コンポーネント単位で区切るのを意識して実装しました。
今回のページ構成はこんな感じ。めちゃくちゃシンプル。 f:id:kenshir0f:20180617201826p:plain

Firebase

個人のポートフォリオでFirebaseを選んだ理由として

  • 無料でhttpsの設定が出来る
  • デプロイが簡単
  • (業務で使ってるので慣れたい)

という感じ。
httpsは自動で行ってくれるので何もしなくて良くて最高。
デプロイもfirebase deployと入力するだけなのでちょっとした修正もすぐ反映できます。
ただデプロイ時間がめちゃくちゃ長いのはなんとかしてほしい。。。

Next.js

Next.jsはpagesディレクトリにindex.tsxを入れとくと/につながり、hoge.tsxを入れると/hogeにルーティングしてくれる非常に便利なやつです。
いちいちページを作るたびにルーティングの設定をしなくて済むので気軽に作れます。
今回はindex.tsx_error.tsxを用意しました。後者は404ページのデザインを適用させています。

React

モダンなのとAtomicDesignと相性がいいので使ってみた。
現状のペライチだと恩恵が少ないが、今後拡張していく予定なので真価はこれから発揮されるであろう。

Typescript

単純に型定義をしっかりしてプログラミングしたかったので採用した。 それ以外の理由は特になし。

Storybook

AtomicDesignの参考書に導入方法が乗っていたのでそのまま使ってみた。
Typescriptに変換するところだけ注意すれば、コンポーネント単位でデザインをテストできるので便利。

(AtomicDesign)

前のブログで書いたとおり、デザインと実装の変更に強い仕組みなので採用。
今回は実装の部分で練習がてらいろいろ試してみた。

その他細かいところ

metaタグと共通のcss

共通で使いたい要素はutilsというフォルダに分けてimportしています。
こうするとHeadタグにタイトルやogpの設定ができるのでページごとで分けられて便利。
cssも共通のカラーを定義したファイルを置いてimportしているので変更があっても一箇所で済むのはよい。

SpeedTest

デプロイ後に https://gtmetrix.com/ でサイトのスピードテストをチェックした。
画像の圧縮で改善ポイントが見つかったのでそのとおりに従った。
キャッシュするともっと良いらしいがやり方が分からなかったので後で改善する予定。

f:id:kenshir0f:20180617201636p:plain

終わりに

とにかくスピードを優先して実装したのでこれからちょっとずつ直していきます。
今後はブログもhatenaから自前のものに移していきたい。。。やっていくぞ!!!

Atomic Design本を写経して感じたこと

f:id:kenshir0f:20180505232824j:plain

Bonfire Design #3で一緒に登壇した五藤さん(@ygoto3_)が書いた「Atomic Design - 堅牢で使いやすいUIを効率よく設計する」を読みました。基本はAtomicDesignに関する話がメインですが、現在の開発状況に至るまでの過程や仕組みから話が展開されるので非常に分かりやすかったのと、少し前のweb開発体制を知らない僕にとっては視野が広がり読んでて純粋に楽しかったです。

デザイナー視点で読んだ感想

エンジニアが書いていることもあって、「エンジニアリング的思考」をコンポーネント単位で解説している点が非常に参考になりました。デザイナーはデザインの観点だけでなく実装のしやすさも考慮に入れてコンポーネントを作るのですが、「どういう単位で」「どういう命名規則で」「どうやって管理するのか」などはエンジニアとコミュニケーションを取って進めていくことが多いと思うので、そういったエンジニアリングの観点からの言及があるのはありがたいです。

写経した感想

本書にはサンプルプロジェクトが載っていてReactを使ってコンポーネントを作る過程を体験することができます。僕自身Reactはほとんど触ったことなかったのですが、実装まで入ってサービスを作っていきたいので写経してみました。全部終わってませんが、コンポーネント作成を一通り終えた時点で感じたことは「デザイナーこそ写経すべき」と強く思いました。

主な理由は2つ。

  1. エンジニアがコンポーネントをどうやって作っているか体験できるため、デザインデータを渡す時に何を配慮すればよいかが自然と見えてくる
  2. (実装まで触る人は)デザイナーがコンポーネント管理まで入ることでエンジニアの負担を減らせる

特に実装まで入るデザイナーはReactの思想とAtomicDesignは強力な組み合わせだと実感できるので、「なんとなくよさそう」から「デザイナー、エンジニアにとって確実に有益」に考えがシフトすると思います。またコンポーネント開発フローを体験することでいざ、チームに導入しようした時の判断材料も見えてくると思います。 最近はSketchを使ってデザインデータを作ることが主流なのもあり、Symbolを上手く使ってAtoms, Moleculesと組み合わせて作ることはデザイン製作のスピードを上げるのにも非常に役立つと思います。

個人的には4-3のプレゼンテーショナルコンポーネントとコンテナーコンポーネントの表示と見た目のロジックの話は目から鱗でした。エンジニアにとっては当たり前?なのかもしれませんが、メンテナンスしやすい仕組みづくりに感動した感じですね。僕もデザインデータを管理しやすいように意識して制作していますが、「管理しやすいデザインデータの仕組み化」はデザイナーにとって課題なので参考にできる部分がありそうに感じました。

写経してハマったポイント

サンプルコードは解説が丁寧で非常に分かりやすかったのですが、React(というかJavascript?)がほとんど未経験だったからか、途中から急にサンプルコードが難しく感じました。というのも構文に関する説明はほとんどないため、試しに触ってみるか〜と軽い気持ちでやって予想してたよりも(理解のために何度もコードを読んだため)時間がかかりました。

特にハマった点を振り返りのためにざっくりまとめます。

アロー関数

hoge = function(x){
  x > 0 ? x : 0;
}

const hoge = (x) => { x > 0 ? x : 0 }

のように書ける。手前の括弧は引数だと読んでるうちに気づいたのですが、次のコードを見て不安になりました。

参考: http://ushumpei.hatenablog.com/entry/2016/09/06/235336

二重のアロー関数

const fuga = x => y => x + y;

これを見たときは???となりましたが、どうやら下のコードと同じ模様

const hoge = (x, y) => x + y;

引数が複数ある場合はこう書けるらしい。

参考: https://stackoverflow.com/questions/32782922/what-do-multiple-arrow-functions-mean-in-javascript

export default の意味

jsファイル冒頭に書くimportで

import InfoTxt from ... import { InfoTxt } from ...

の二種類があり、どうやら

  • export default InfoTxtと書いてあれば中括弧はいらない
  • export const InfoTxt = () => ...と書いたら中括弧は必須

らしい。エラーメッセージにも出てこなくて、ここのエラーでめちゃくちゃハマった。。。

まとめ

AtomicDesginの思想・考え方だけでなく、サンプルを使って実際に手を動かすところまで体験できるのが非常にためになりました。時間が経つに連れ開発環境は変わってくるとため、サンプル付きのものは出版されてすぐ取り組むことに価値があると思います。ただ、すぐに開発に組み込むためというよりも、仕組みをきちんと理解し数年先で活かせるよう一回身体に入れてみるという意味合いでトライしてみましたが、エンジニアの視点を少し理解できた気がします。AtomicDesignを体系的に学んでみたい方は読んでみてはどうでしょうか。

個人ワークだとAbstractが高いのでPlantを使って無料でsketchファイルを共有する

f:id:kenshir0f:20180428230341p:plain
sketchのデータ管理をDropboxだったりgithubだったり試行錯誤しながら運用していたのですが、Plantという「sketchバージョン管理ツール」がお手軽だったのでまとめてみました。

知人とデザインデータを共有して作業したかったので、サクッと導入できてすぐ稼働できたのが個人的にはよかったです。(まだベータ版)
Abstractとの違いも含めてツラツラと書いてみます。

Plantとは?

複数人でひとつのsketchファイルを共有してデザインする時に、同時にsketchを開いていても差分を簡単に反映して作業しできるツールです。

f:id:kenshir0f:20180428221131p:plain

具体的な特徴としては

  • 複数人でも無料プランで始められる(5人までいける)
  • pluginを入れるだけで簡単に始められる
  • sketchだけで完結できる
  • コンフリクトの差分が視覚的で分かりやすい

ざっくり使い方

pluginをインストールすると出るツールバーでだいたいの操作ができます。 f:id:kenshir0f:20180428222349p:plain

アップロードが簡単

手元で加えた変更を共有したいときは[↑]のボタンを押すとメンバーにデザインを共有できます。
メッセージで更新内容を伝えられるので共有される側は簡単に理解しやすい。

f:id:kenshir0f:20180428222036p:plain

手元に変更を反映させるのも簡単

メンバーの誰かがデザインをアップロードするとツールバーの[↓]にバッジがつき、クリックするだけでメンバーのデザインを手元に反映できます。
f:id:kenshir0f:20180428224237p:plain

メンバーが作ったデザインが手元のデータと変更箇所が被ってなければ、手元のデザインを残してそのまま編集を続けることができます。

f:id:kenshir0f:20180428224414p:plain

ただ反映させる時プレビューが出ないので、何を変更したかはやり取りする必要がありそう。。。 まだベータ版なので今後に期待。

コンフリクトした場合は?

メンバーが変更したデザインが手元のデザインと被っていた場合は反映することができません。

f:id:kenshir0f:20180428224936p:plain

そのときは反映したいアートボードを選択(もしくは修正)して、採用しない方を削除することで解決できます。

選択前

f:id:kenshir0f:20180428225058p:plain

選択後

f:id:kenshir0f:20180428224944p:plain

これが分かりやすくてめちゃくちゃ便利だなーと感じました。

abstractとの比較

同じバージョン管理ツールとして有名なのがAbstractですが、Plantはとにかく無料で使えるのが素晴らしいです。
Abstractは機能がしっかりしている分設定などの導入コストがかかりますが、Plantはそこら辺がなくパッと初めてすぐに共有できます。

つまづいたところ

最初にProjectを作るときは 「Plugins > Plant > New Project」からしか作れないため
他のアプリケーションと比べ分かりづらいなと感じました。

f:id:kenshir0f:20180428225624p:plain

(pluginに全部収めたいという気持ちがひしひしと伝わってくる...)

まとめ

お金をかけずに個人ワークでサッと共有するにはかなりよいと感じました。
業務でも十分使えると思ったので、sketchのバージョン管理で悩んでいる方は試してみてはいかがでしょうか。

Bonfire Design #3 「小さく始める新規事業のデザインシステムについて」登壇してきました。

先日Yahoo!さん主催のbonfire design #3というイベントに登壇してきました。

デザインシステムとは、ブランドからUIコンポーネントまで体系的にデザインを統一するための仕組みを見える化したものになります。

立ち上げから関わっている新規事業のデザイン全体を体系的にまとめる取り組みについてざっくりと喋りました。

登壇資料

発表してきた感想

他の登壇者ではサイバーエージェントさんやレバレジーズさん、Yahoo!Japanさんなど、既にあるサービスにデザインシステムを導入する話が多い印象でした。 中でもサイバーさんのAtomic Designの話は僕自身よく理解できていないところもあったので非常に参考になりました。

逆にゼロから実際に作り始めている事例は僕だけだったからか、発表後は色んな方から具体的にどう進めたらいいかなど相談に乗ることが多かったです。 ちなみに、聞きに来ている人の8~9割の方の会社ではデザインシステムをまだ導入していないということでした。(デザインシステムやっている人!の挙手で確認していた感じ)

ちょっとびっくりしたギャップ

弊社ではサービスのほぼ全てに関する議論をgithub上でするのでコミュニケーションの仕方で問題を感じたことはなかったですが、 僕が話していた他社さんではディレクターとデザイナーとエンジニアでコミュニケーションツールが違ったりしていて議論がしづらいという話が多かった印象です。

当たり前になりすぎていて気づかなかったですが、githubにログを残すの今のところは最適解な気がしています。

グラレコが可愛かった。

一眼レフ初心者がAdobeを使い倒して簡単にそれっぽくする

こんばんは、フジケンです。
最近一眼レフ買ったのですが、カメラだけでプロのような写真を撮るのは難しいので
そこそこきれいに撮れたと思う写真を「簡単にそれっぽく」することができたのでまとめます。

一眼レフ

買ったのはこれ。
僕は家の事情でPENTAX縛りだったのですが、CanonでもNikonでも良いと思います。

今回使ったレンズはこれ。
ざっくりと近距離〜中距離なイメージ。

Adobe Bridge

写真を選定するときに使います。
f:id:kenshir0f:20180408225537p:plain

Finderでも十分ですが、クリックしてPhotoshopを直接起動できるのは便利。 サムネイルも見れるし、ホワイトバランスでフィルターかけられたりラベル付けもできます。

Adobe Photoshop

皆さんご存知の最強画像詐欺ツール。 まずは写真を「スマートオブジェクト」にします。

f:id:kenshir0f:20180408230012p:plain

調整内容をレイヤーとして保持できるようになり、
後からやり直しが効くためスマートオブジェクト化はした方がいいと思います。

次に「フィルター -> Camera Raw フィルター」で画像の色味などを調整します。

f:id:kenshir0f:20180408225733p:plain

コツは少しずつ変えるのではなくわざと大きく値を変更して良さそうなところに合わせるのがいいかと。

完成

あとは「画像解像度」でサイズを小さくすればTwitterにも投稿できるサイズに変えれます。 カメラ楽しい!!!