見出し画像

試し読み:『UIデザイナーのためのSketch入門&実践ガイド 改訂第2版』 デザイナー座談会

この度、2018年11月に刊行した書籍『UIデザイナーのためのSketch入門&実践ガイド 改訂第2版』に所収されている、「デザイナー座談会」を公開いたします。

前回の刊行より約1年。Sketchの利用者も増え、バージョンも徐々にアップデートされてきたところで本書の刊行に至りました。改訂版を出すことが決まり、著者である吉竹さんにおおよその加筆&修正を終わらせていただいたところでver52.2が登場に……。ギリギリのタイミングでしたが、吉竹さんのご尽力のなんとかアップデートに間に合わせることができました(本当にお疲れ様でした…)。

前回からの大きな変更点は主に4点です。

1つは、新しく加わったライブラリやプロトタイピング機能の解説。

2つ目は新規プラグインや連携サービスの紹介。

3つ目はレッスン編です。前回のレッスン編では具体的なUIの作り方を細かく解説していただいていたのですが、今回は「UIトレース」に焦点を当て、どのような視点から取り組めば自身の設計力が向上するのか、また実務に役立つのかについてのポイントをまとめていただきました。UIの構造や管理にフォーカスした解説は、「グラフィックツール」というよりも「設計&共有ツール」であるSketchを使いこなすうえでとても参考になることでしょう。

そして4つ目が、今回公開する「デザイナー座談会」です。前回はアンケート形式でデザイナーの方々のご意見を伺いましたが、今回は5名のゲスト+吉竹さんでご自由にトークをされていますので、現場の知見から悩みまで、よりふんだんに散りばめられています。本記事が、実務者の方々のお役に少しでも立てることを願います。

長い前置きはさておき、それでは以下よりご一読くださいませ。[岩井]


------------------------------------------------------------

Sketchをどのように扱うかは会社やチームによってさまざまですが、その知見や使われ方が外部に公開されることは稀です。今回、大企業やスタートアップで活躍されている5名のデザイナーを交えて、普段の業務でどのような使い方をしているのか、どういった点を工夫しているのか、などについて、座談会を通して伺いました。現場ならではの貴重なお話がたくさん載っていますので、ぜひ参考にしてみてください。

( ※ この座談会は2018年7月9日に行われたものです)

- - - - 参加者 - - - -

●司会
吉竹遼(THE GUILD)

参加者
宇野雄(ヤフー株式会社)
加田早苗(株式会社ディー・エヌ・エー)
勝島真悟(Amazon Japan)
佐藤通洋(株式会社インテグリティ・ヘルスケア)
鈴木伸緒(株式会社メルカリ)

撮影場所
THE GUILD

- - - - 座談会 - - - -

 (左から時計回りに)佐藤さん、鈴木さん、加田さん、宇野さん、勝島さん


自己紹介

吉竹:本日はよろしくお願いします。まず始めに、みなさんのお名前と所属、どんなことをしているかを教えて頂けますか?

宇野:ヤフー株式会社の宇野雄です。検索統括本部という組織に所属しています。その中にある3 つのデザイン組織のうち2 つの部長をしています。デザイナーは合わせて35 人程度ですね。ヤフー検索はもちろん、ヤフー知恵袋やヤフー乗換案内なども含め、複数のサービスのデザイン統括をしています。

加田:株式会社ディー・エヌ・エーの加田早苗です。所属はオートモーティブ事業本部 基幹システム開発部 スマートタクシーデバイスグループです。具体的に何をしているかと言うと、配車アプリのタクベルというアプリがあるんですけど、そのユーザーアプリのプロダクトマネージャー(PM)をやっています。私はデザイナーのチームの中には入っていないんですけど、一緒にやりとりしているデザイナーは4 ~ 5 名です。常に一緒に動いているというよりは、何か用件があったら一緒に動かせてもらうスタイルでやっています。

勝島:Amazon Japan の勝島真悟です。いま所属している部署はAmazon Appstore です。実はAmazonにはAppstoreがありまして、Fire TabletとかFire TVとかを買うと、その中にAppsというタブがあるんですけど、そこのデザインを担当しています。デザイナーの正確な人数は言えないのですが、僕がやりとりしてるのは4 人くらいですね。各デバイスごとにデザイナーがいて、もちろんグローバルでいたりするんですけど、US に4 人くらいいて、UKとかにも2~3人います。

佐藤:佐藤通洋です。インテグリティ・ヘルスケアという、50人くらいのスタートアップに所属しています。いわゆるCDO(チーフデザインオフィサー)をやっています。YaDoc というオンライン診療サービスを作っています。デザインの関わってるメンバーでいうと、サービスデザイナー、UXリサーチャー、UIデザイナー、アートディレクター、ビジュアルデザイナー、コンテンツストラテジスト、テスターがいます。

鈴木:株式会社メルカリの鈴木伸緒です。今は株式会社メルペイに出向し、プロダクトデザインリードをやっています。チームとしては僕がやりとりするデザイナーは6 人くらいです。メルペイではFintech事業の立ち上げをしていまして、私自身はPMっぽいことも兼ねたりしつつ、体験設計やUIデザインを担当しています。


Amazonについて

勝島:Amazon はアプリケーションも取り扱っていて、Google PlayにあるようなアプリがAmazonの中でも探せるんです。いまアプリストアをリデザインするプロジェクトをやっていて、US のデザイナーと一緒にAtomic Designを用いてエレメントを分解して設計し直しています。ライブラリでAtomic DesignのAtomsとかOrganisimsで分類されたファイルを共有して、1 つずつデザインをし直しているという状況ですね。難しいのはタイポグラフィで、日本語と英語とか、多言語対応でどうやってデザインしていこうかなっていうのを模索しています。できれば同じファイルを共有したいんですけど、シンボル化とかスタイルの共有をどうしているのかなと。メルカリさんのやり方を参考にしたいなと思ってて……

宇野:1つのデザインで多言語対応されてるんですか?

勝島:できればいいなと思ってる段階ですね。

鈴木:それはすごく難しいですね。

加田:言語によって文言の長さも変わりますよね。前職でグローバルプロジェクトをやっていたんですけど、日本語だとおさまるけど英語だと単語が長くなって「…」で省略表示されちゃうみたいな。

勝島:そのあたりの、例えばサンプルのJSONファイルを使ってやったほうがいいのかなとか、作り方も含めてベストプラクティスみたいなのを聞けたらと思っています。

勝島さん

吉竹:メルカリさんはどういう風にやられてるんですか?

鈴木:もう全リージョン分けちゃったんですよね。僕がUS版をやってた2016年は、UIはほぼ同じでしたが、ファイルの管理はすでに別々で、文言やデザインの管理はUS 版を軸にしていました。日本版はUS 版で効果があった施策で合いそうなものを入れる、という感じでしたので。両方のUIの文言を気にしながら作ってると時間がかかってしまうので、それぞれ別プロジェクトで進めてましたね。実装する時に文言を見て、長さが合わなければその時に変更するというパワープレイでした。

勝島:なんとなくパワープレイしかないんじゃないかな、みたいなのは感じていました(笑)

鈴木:日本版とUS 版のUI は完全に一緒なんですか?

勝島:いまのところは一緒です。line-height とかも英語基準になってて、日本語だと読みづらいんですよね。

鈴木:それで言うと、日本語だとアキすぎちゃうとか詰まりすぎちゃうとか、そういったことはよくありましたね。

吉竹:そういえば勝島さん、前回(第1刷)のインタビューの時にデザインスペックをプリントアウトして社内に共有しているって話があったと思うんですけど、あれは今もやられてるんですか?

勝島:やっています。Amazon だけではないと思うんですけど、外部ツールがほとんど使えなくて、クラウドサービスもほとんどだめなんですよね。Amazonのセキュリティ審査を通ったツールか、内製で作られたものしか使えないので。だから、プラグインとかInVisionとか使いたいんですけどなかなか難しくて……

加田:そうなんですね。

勝島:特にコンフィデンシャルな開発中のものとか、全部だめですね。

加田:サーバーに上がるとだめなんですね。ローカルを使わないといけないんですね。

勝島:なので僕は、Sketch Measureでスペックを書き出して、内部のサーバーにあげて確認してもらうということをずっとやっています。デベロッパーにRedline(マージンやパディングなどの開発に必要な数値)とかを共有してますね。あとRedline は紙にプリントアウトしたほうが伝わりやすいので、A3の紙にプリントアウトしてるのがメジャーなやり方ですね。

宇野:それはすごい。うちの会社も4~5年前まで社外サービスは使いにくい時期がありました。セキュリティ的にやはりどうしても使えないサービスはあります。

吉竹:そのあたりの話をまた順繰りで話を聞ければと思います。

勝島:現代ではどういうやり方がされているのか知りたい……

一同:(笑)

宇野:世界の技術を牽引してるはずの会社なのに(笑)


ヤフーについて

吉竹:それではAmazonさんに引き続き、堅いイメージのあるヤフーさんですけど、Sketch の使われ方はどうですか?

宇野:ヤフーはたしかに使えるツールの制限はあるんですけれど、きちんと基準があって、それをクリアすれば使えます。ZeplinAbstractやInVision、Prottとか、そのへんはひととおり使っています。利用ツールの限定は行っておらず、サービスの特色に合わせて使い分けをしている状態です。以前は多くのサービスでZeplinを使っていたのですが、最近はAbstractに切り替えるサービスも出てきました。UIスペックの機能が付いたので、Abstract に統一してみようという話で移行を進めているプロダクトもありまして、僕のチームではレビューもAbstract 上で始めてみています。まだちゃんとしたレビュー機能はついてないですけど、InVisionみたいに範囲指定してコメントできるので便利に使っていますね。

いま全社で広くSketch が使われるようになってきていて、エンジニアはもちろん、企画職やプロデューサー職の人たちも使うようになってきました。UIKit のようなかたちで配布しているので、いわゆるデザインシステムですね、企画職のメンバーがUIデザインしているみたいなことありますね。

佐藤:みなさんMacなんですか?

宇野:プロダクトサイドだとMacの人が多いです。ただ、どうしてもExcelで複雑な処理をしなければならない人などはWindowsを手放せないので、ブラウザからでも使えるZeplinやAbstractはすごく喜ばれました。

勝島:Zeplin やAbstract ならブラウザからそのままコメントが……

宇野:はい、できます。Sketch が使われる範囲は非常に広くなりましたね。

吉竹:広く使われるようになって苦労された点はありますか?

宇野:他のツールに乗り換えられない(笑)。色々な人に使い方をわざわざ覚えてもらって使っているので、Figmaに移ろうぜとかはちょっと気楽に言いにくいですよね。ただ、1 つのツールに振り切ったのは、それはそれでいいのかなあと思っています。案外デザイナー以外の人たちもSketch を学習コスト低く使えているので。それこそ今までは「こういうモックを作ってほしい」みたいな、社内閲覧用の資料に貼るやつまで頼まれることもありました。でも、それくらいなら依頼するよりも自分たちで作っちゃったほうが早いって人たちが出てきたのはよかったですね。デザイナーだけのアウトプットではなくて、組織としてのアウトプットが増えた印象です。

勝島:ノンデザイナーの方が作られるようになったんですね。

宇野:はい。なので最近は逆にデザイナーがつっこまれるパターンもありますし。ノンデザイナーの方から「そのUI パターンどこから出てきたんですか?」って。「なんとなく感覚で作りました」「それはいいんですか」「よくないですね」とか。

勝島:そういったマージ作業はどうやってやられてるんですか?

宇野:そのマージもAbstract上でやってます。

勝島:Abstractってバージョン管理の……

宇野:そうです。Sketch よりも依存度がちょっと高まっているかもしれないですね。

勝島:プルリク(Pull Request:変更内容を他の作業者に知らせること)は誰がレビューするんですか?

宇野:Abstract に今(2018年7月現在)はプルリクの概念はないんですけど、いちおうIn Reviewのようなフラグは立てられるので、その段階でメンションつけてコメントを書いてもらって、通知が届いてって感じですね。

鈴木:ブランチ(マスターデータに影響しない作業領域)切って最終的にマスターにマージする感じなんですけど、基本Gitと一緒だと思います。

勝島:僕のチームはまだデザインデータを触るのが3~4人なので、まだ重大なコンフリクトは起きてないです。でもこれから機能やページが増えると何のためのパーツか分からないものが増えたりしそうです。

鈴木:US とのやりとりの中ではコミュニケーションしきれない部分も出てくるんですか?紙が渡せない、みたいな(笑)

勝島:そうですね、ビデオチャットで画面見ながら説明したりしますね。でも、まだそこまでプロジェクトが深く進んでないので、これからどうしようかなという感じです。

加田:その時の画面共有は何でやられてますか?

勝島:そういう社内ツールがあります。

一同:へ~!

宇野:社内で内製ってことですか?

勝島:はい。微妙にイケてないところがあるんですけど(笑)。インスペクトモードは、デベロッパーの人とどういうタイミングで見たりするんですか

宇野:実装段階ですね。ただ、インスペクトは使っていない人も多いかもしれません。Sketch 入れてる人たちはSketchで確認するので。

勝島:意図はちゃんと伝わるんですか?

宇野:大丈夫ですね。

鈴木:Zeplinを見れば伝わる、みたいな、そういう共通認識があるんですか?

宇野:Sketch あるあるだと思うんですけど、line-heightを正しく設定すると上に余白が出るフォントのバグがあるじゃないですか。僕らは見た目を正しくする方向でUIを組んでいるので、結果的にそのまま実装するとうまくいかないみたいなことがあるんですね。ただ、変わりにマージンルールを徹底したので、こういう時はルール上12pxですみたいな、そこを周知しています。実装上もそうしていますね。

加田さんと宇野さん


タクベルについて

吉竹:加田さんはいまPMなんですよね。

加田:はい。つい最近までずっとデザイナーだったのですが、2018年6月の転職を機にプロダクトマネージャーにジョブチェンジしました。なので、みなさんみたいにデザインをあまりやってるわけではないんですけど。

吉竹:タクベルチームではSketchを使われてるんですか?

加田:そうですね。入社する時にPhotoshop とIllustrator も欲しかったんですけど、とりあえず毎日絶対使うSketch だけは入れてもらいました。あと、Sketch を落書き帳みたいになんでも使いたくて。私めんどくさがり屋なので、打ち合わせする時にすごく大きいアートボードを作って、その中に今日話すことを書いてスクリーンに映したりするんです。誰が何を話したかとか、次回やることもそこに書いていきます。アートボードを縦にスクロールしながら話して、そのままPDFで書き出して共有しています。

もちろん、デザイナーさんはみなさんSketch を使ってて、あと私が今いるのがタクベルのユーザーアプリのチームなのですが、PMサイドもSketchを持っています。なぜかと言うと、いまどういう画面があるのか、どのような問題が出ているのかを一覧で確認するのに、Sketch ファイルを見るのがいちばん正しいんですね。Sketch 上のデザインパターンから「この先の遷移だとどうなるんだろう」みたいなのを共有したり。他の方法でも見ることはできるんですけど、一覧化されてて見やすいっていうところがSketchを使う理由の1つですね。

あとは今リリースしているデザインの最新版がすべてSketch にあるのと、改修案のプロトタイプを作るのにSketch を使っているからというのもあります。

吉竹:プロトタイプの作成は連携サービスを使われてるんですか?

加田:Sketch のプロトタイピング機能を使っています。あとはFlintoでアニメーションをつけたりとかしているみたいです。でも動きの少ないプロトタイプはSketch でつなげてその場で見ることが多いですね。ユーザーヒアリングの時もそうしています。


メルカリについて

吉竹:メルカリさんはどうですか?けっこう息の長いプロダクトだと思うのですが。

鈴木:各メルカリ本体のチームとメルペイとで使い方が全然違うんですけど、いま僕がいるメルペイは立ち上げ時期なので、デザインデータの共有方法としてはGoogle Drive を使っています。1 つしかないマスターファイルだとコンフリクトしがちなので、機能ごとにファイルをばらばらにしています。最近はマスターライブラリを作って、そこからシンボルを全部引っ張ってきて連携するようにはしましたけど、個々の機能ごとにはそれぞれのメンバーが動けるようにしています。いまのところそれがいちばん作業効率が良いです。

今以上の人数になってくると、おそらくAbstractを使ったりGit にあげたり、違う方法を選んでプルリクやレビューができるようにしなきゃいけないなとは思っていますね。

吉竹:エンジニアさんとの共有はどのようにされていますか?

鈴木:Zeplin を使っています。最近Zeplin がアップデートされてコンポーネントライブラリの機能が追加されたので、それはいいなぁと思いつつ、ただシンボルを49 個までしかアップロードできないんですよ。それ以上アップロードしたい場合は上位プランを契約してくださいみたいな。なのでエンジニアとはZeplinでやりとりをしていますが、人によっては直接Sketch ファイルを開きたい場合もいるので、そういう人は直接開いてもらって見ています。


インテグリティ・ヘルスケアについて

吉竹:続きましてインテグリティ・ヘルスケアさん、いかがでしょうか。

佐藤:インテグリティ・ヘルスケアではデザイナーが働きやすい環境づくりを任されてます。少しでもストレスが少ないようにしています。Adobe製品は全員フルインストールして、Sketch もインストールして、InVisionもAbstractもZeplinも、ぜんぶ使えます。

宇野:すごい(笑)

佐藤:デザインの行程を、できる限りすべてリアルタイムでひらいて共有することを前提にしています。だからうちのデザイン部のルールとして、デザインデータのローカル保有を禁止にしています。

一同:へ~!

佐藤:Abstractから起動して、作って、手を入れていくって流れにしています。なのでSketch を選んだのも、そういった開発フローをオープンにして、連携が前提となる柔軟なワークフローがいちばん作りやすかったからなんですね。あとは、ステークホルダーが特徴的で、医者がいるんです。ぼくは医者じゃないので、作ってるプロダクトの良し悪しを実際に使う医師に見てほしい。InVision には外部からでもコメントできる機能があるし、InVision上に人が集まるように運用しています。エンジニア陣へはZeplinで全部渡していますね。

吉竹:お医者さんがInVision を使われているってことですか?

佐藤:そうです。

吉竹:どうですか、使われてみた反応とか。

佐藤:割と普通にみんな自由に使ってくれていますね。チャット機能があるんですけど、ビデオチャットとかしながら、あーでもないこーでもないとやりとりしています。

加田:使いこなしてますね。

佐藤:今日、実はもう見せちゃえと思って持ってきてるんですけど(Macの画面を向ける)、Abstractでは、Webアプリ、モバイルアプリなどを分けて、必要なデバイスのUI デザインを管理しています。アイデア出しやプロトタイピング・テストをするプロジェクトと、開発実装するためのプロジェクトに分けて管理しています。

Zeplin はシナリオや細かいIssue ごとにグループを分けて共有しています。あとはRealtimeBoardと連携して、画面だけではなく業務オペレーションやサービスフローを確認する時に使っていたりします。

佐藤さんと鈴木さん


他ツールとの併用

吉竹:他ツールとの併用についてはどうでしょうか。アイコンとかもSketchで作られてるんですか?

宇野:僕はIllustratorでアイコンを作ってます。

佐藤:僕はPhotoshopをちゃんとPhotoshopとして使ってますね(笑)

鈴木:本来の使い方ですね(笑)

勝島:僕のチームは役職が分かれているので、ビジュアルデザイナーがルック&フィールを考えていますね。

吉竹:XDやFigmaなどのSketchに近いツールの併用をされてる方っていらっしゃいますか?

鈴木:Figmaとの併用はトライアルで始めました。

吉竹:どういう使い分けをされているんですか?

鈴木:そもそものニーズとして、加田さんがやられているようなことをメルペイのPMもやったりするんです。Sketch を使ってストーリーボードを作るんですけど、そういう時にファイルを開きたいって要望が出るんですね。中身が見れて、できれば触りたい。そういう時にFigmaだと、UIデザインに対して、フィードバックとアウトプットを1 つの画面に一元化できるんですよね。

あとFigma自体をスペックシートにできるのも良くて、ドキュメント内で「ここはこうで、こういう風に仕様が変わりました」ってコメントがきてデザインを直す、とか。そういうのをリアルタイムでしたり最終的なドキュメントにできるので、そういう用途でFigmaはアリかもねって話をしていますね。

宇野:UI デザインを作るのにもFigma を使ってるんですか?

鈴木:使ってます。使い勝手的にはSketchと変わらないので。

加田:実際に使ってる人の話、初めて聞きました。

勝島:昔からデザイナーって、採用の時にPSD ファイルの中身とか見たがるんですよね。レイヤーの法則とかまったくない人とかいたり。Sketch を使い始めると、基本的にフレームを考えながら設計をしなくちゃいけないじゃないですか。Photoshopの場合ってそういうことをしない人もいるんですよね。ビジュアル的にはイケてそうに見えるけど、実はなにも考えないで設計している場合もあって。エンジニアが採用の時にコードを見るように、デザイナーはPSD ファイルを見れるようにしてほしいみたいなのは結構あったりしますね。

佐藤:それで言うと、Sketch になってからレイヤー構造は気にしなくなったかもしれないですね。ゼロから考えて作るというよりは、最適なUIモジュールを選ぶような意識で作るようにしてます。モジュールはAtomic Design のコンセプトで作ってあって、命名規則を持たせているので、持ってくるだけで終わります。気にするのは丁寧なレイアウトくらいですね。

吉竹:レイヤーリストにシンボル名だけ並ぶ感じになりますよね。

佐藤:そうですね。規則だけデザインしてある、みたいな。

宇野:マスターの部分だけしっかりしていれば、あとはなんとかなっちゃうのはありますよね。

加田:試行錯誤した結果って、ちゃんと反映させられていますか?デザイナー時代に、マスターのモジュールは使うけど、ここはカスタムしたいってなる人もいて。それでいつの間にか知らないモジュールが増えてて、マスターと違うじゃんってことがありました。

佐藤:そのあたりはAbstract が吸収してくれた感じはしますね。

宇野:マスターにマージされる前に「なんじゃこりゃ」って言えるので。

加田:なるほどー。

吉竹:ヤフーさんだと大人数で作業されてるイメージがあるんですけど、さっきFigmaの話がちらっと出てきましたが、宇野さん的には興味ありますか?

宇野:あります。いまさら言いにくいですけど(笑)。でも社内でFigma を使っちゃいけないってルールがあるわけではないです。なので社内での精査は必要ですが、やりたいという要望があれば、ですかね。あと、同時にデザインするシチュエーションって、実際はそんなにないんです。

吉竹:そうなんですね。

鈴木:同時には僕らもやらないですね。海外拠点とリモートワークしているチームが以前抱えている課題として、勝島さんの時と一緒で、日本で作ったSketchファイルとUKやUSで作ったSketchファイルがそれぞれあるんですよね。あと時差があるので、限定的な時間で画面を見ながら打ち合わせしたかったり、どのファイルが最新なのかわからないっていう迷いも避けたいのですが、「これって最新?」って聞いても向こうは寝てるっていう状況はどうしても発生するんです。Figma はそのソリューションになるんじゃないかなと思います。たしかに、同じフロアにいる分には、同じタイミングで同じ画面をデザインすることはほとんどないと思いますね。

吉竹:じゃあコミュニケーションに寄ったところのメリットが大きかったんですね。

鈴木:そうですね。

宇野:僕のところでも、ファイルをすごく分割してあるところもあります。マスターがあって、その下に2~30個ファイルがぶら下がってるような、1モジュール単位でファイルが分かれているような整理をしています。それはやっぱり同時作業がしやすいようにしたくて、いかにAbstract でマージができるようになったとしてもコンフリクトは起こるので。


シンボルの活用法

吉竹:せっかくのSketchの座談会なので、シンボルの話にも触れたいと思います。先ほどもAtomicDesign の話が出てきましたが、シンボルをどう作ればいいですか?という質問はまだまだ多くて。みなさんがどういう風に作られているのか興味があります。
勝島:僕は4月からいまの部署に入ったんですけど、すでにAtomic Designができあがりつつあるので、空気を読みつつ、日本で制作したエレメントを取り入れてますね。

吉竹:Atomic Design の分類のルールは社内であるんですか?

勝島:明文化されているものはないですね。みなさんレビュー会とかされてるんですか?

鈴木:メルペイではまだ運用しているものがないのでレビュー会というほどではないんですけど、チームの中で共有する意識は高く持っています。作ったら誰かに見せずして進まない、みたいな。ユーザビリティテストも兼ねて4 ~ 5 人には必ず見せるようにしてるので、デザイナー間で少なくとも3 人くらいからはいろいろなフィードバックがあって、最終的には収束します。マスターファイルは最近できたばかりなので今後どうするかはまだ決められていないんですけど、Atomic Designの構成で言うと、メルペイはAtomsとOrganismsしかないです。それ以上は作らないようにしました。

一同:へ~!

鈴木:作ろうとしたんですけど、逆に使いづらくなるっていうのと、あと運用性が下がるのでやめました。いまのところは。

吉竹:ヤフーさんはどうですか?社内の統一ルールとかあるんですか?

宇野:プロダクト単位で自由にやっています。そのうえでAtomic Designを採用するところもあれば、してないところもあります。僕のところではAtomic Design を採用しなかったですね。どちらかと言うと、使う時に便利なやり方にしようよって。Atomic Designは管理ありきだと思うんですよね。それこそさっき言ったみたいに企画職や開発職の人が使い出すと、逆に理解が難しいと思うんですよ。エンジニアさんは喜ぶかもしれないですけど。ルールを知らない人に対してもわかりやすいことを重視しています。なのでコンポーネント単位ですね。直接配置する単位をいちばん上の階層にしています。

吉竹:画面に配置、ってことですよね。

宇野:はい。そういう意味では、ボタンというAtomsもありますし、検索ボックスみたいな、ボタンとセットのものも並列で置かれています。レイアウトする時にそういう風にあったらいいなって感じですね。ざっくりカテゴライズはしてあるんですけど。基本的に、いかに階層を浅くしてラクできるかみたいなところですね。

吉竹:インテグリティ・ヘルスケアさんは先ほどおっしゃられてたみたいにAtoms から作られてるんですか?

佐藤:これは実際に見てもらうのが早いと思うのですが(画面を向ける)、Material、Component、Layout、Page、あとその上にRuleとGuidanceって概念があります。

一同:へ~!

佐藤:Atoms にはアイコンと色を置いています。サービスプロダクトのユーザーには高齢者もいるので、カラーコントラストはすごく重要視してて。色の用途を限定して、いわゆるWCAG(ウェブコンテンツ・アクセシビリティ・ガイドライン)の適合レベルがAA以上にならないとNGにしています。なのでカラールールのマネジメントは徹底しています。ロゴやアイコンなども完全にシンボル管理しています。こういったルールはリードデザイナーに管理してもらっていて、スプリント開発単位で共有しています。新しいUI が開発された時に、公式なComponent として採用するかどうか有用性を判断しています。より効果のありそうな新しいUI開発も自由にできますが、公式と実験が混ざらないように管理しています。

加田:そこに使うのは、先ほど言われてたComponentから参照するんですか?

佐藤:そうです。なので、新しいUIはリードデザイナーと相談しないと開発できないやり方にしています。

宇野:徹底してますね!

加田:いいですね。

佐藤:その他に、エンジニアとやりとりするためだけのファイルを用意してて。UI っていろんな状態のデザインがあるじゃないですか。これ押したらどうなるんだとか。作っていて検討が漏れたりする時はエンジニアからの指摘があるので、そういったコミュニケーションをすべてZeplin でやってたんですけど、コミュニケーションが盛り上がって量が多いと(笑)。なので、UI の挙動を全部説明できるように、主要なものを入れています。そこから選べば作れるのと、あとから入ってきたメンバーでも理解できるのがメリットですね。どんな検討があったか歴史までは載せられないんですけど、それはAbstract の履歴を見てくれと。なので、ここにあるルール、挙動でやってくれと言っています。あとテスターの人とかもこのファイルを見ながらテストできるように整えたというのもありますね。

勝島:Abstract にあるファイル以外のドキュメントってないんですか?wikiとか。

佐藤:ないです。

宇野:すごい。ステートメントファイルに置かれてるデータってそれ専用に作られたんですか?それともライブラリから引っ張ってきてるんですか?

佐藤:全部ライブラリです。なので生データはないですね。

宇野:じゃあ勝手に更新されるんですね。

加田:めっちゃいいですね。

佐藤:こういうのを好きなデザイナーがジョインしてくれたのが大きいですね。

宇野:管理者は絶対必要ですよね。

佐藤:立ち上げる時は大変だったんですけど、動かしちゃえばあとはスムーズにいくので。

加田:QAもやりやすそうでいいですね。

佐藤:そうですね。なのでUI のガイドラインはなくても大丈夫なようにしています。

勝島:プリントアウトはしないんですね……

一同:(笑)


プラグインの利用

吉竹:ほかに何か聞いてみたいことはありますか?

宇野:プラグインってどうされてますか?たくさんチームでやっているとどう管理するのか気になります。

鈴木:同じのを使わないといけないから、ということですよね。

宇野:ですです。おそらくは今そういうベストプラクティスって存在しないと思うんですよね。チームとしてそのプラグインを採用するかどうか、とか。

吉竹:たしかに導入はタイミング合わせないと難しいですよね。

佐藤:うちは管理してますね。

吉竹:どういうフローでやられてるんですか?

佐藤:試すのは全員自由です。試したものはチームの共有会の時に「これ便利でした」と共有して、リードデザイナーがOKしたら入れていきます。入れているプラグインはリストで管理して、後から入ってきた人もわかるようにしています。

鈴木:便利ですね。

佐藤:あとリストに「便利」「絶対入れろ」ってフラグを立てています。

鈴木:プラグインも、個人で完結するものと全体に影響するものと両方あるじゃないですか。ボタンのパディングを常に固定してくれるPaddyとか。そういうのはみんなでエイヤで入れないといけないと思うんですけど、単純にAlign を綺麗にしてくれるとか、整理ツールみたいなのは個人がカジュアルに入れてますね。

加田:社内用のプラグインリストみたいなのがあるんですか?

鈴木:InVisionを使ってるのでCraftは入れてください、みたいなリストはもちろんあります。あとはさっき言ったPaddyとかは入れてないとファイルがバグるので入れといてね、みたいなのもあります。

宇野:ファイルの中に使用プラグインがメタデータとしてあって、このプラグインが使われてるよっていうのがウィンドウ右上のアラートで出てきたらいいなって思うんですよね。どのプラグインを使って作られたファイルかがわかるような仕組みがあると、もっと気軽にプラグインが入れられると思うんです。昔、Anima のAuto Layout(現Launchpad for Sketch)がファイル自体を書き換えちゃうタイプで、プラグインを持っていない人がファイルを上書きするとその時点で設定が無効になるということがありました。

加田:それめちゃめちゃ怖いですね。

宇野:だから全員に入れてって言ったんですけど徹底しきれなくて、結果ダメだったことがあって。うちのチームでは鈴木さんが言ってたみたいに操作を快適にするためのプラグインは個人の判断で利用をしていますが、ファイル依存プラグインは禁止にしてますね。

鈴木:ファイル依存も種類はそんなに多くないですよね。ただやってるところはすごい魔改造して作ってるから怖いですね。

宇野:そうですね、だから魔改造プラグインは禁止です。あと、いずれSketchが純正で実装するパターンも多くて。待ってたらBohemian がいつか作ってくれるはずだと(笑)。Auto Layoutも一部はResizingという形で実装されましたし。


最後に

吉竹:最後に〆の言葉を一言ずつ頂きたいと思います。この本は初学者の方向けでもあるので、Sketch に触れてデザインを学び始めた人も多いと思うんですよ。それで、この本を読んで道具の使い方はなんとなく分かると思うのですが、次のステップとしてどういうことを学べばいいかとか、どういう視点を持てばいいかって、それはまた道具の使い方とは別かなと思っていて。そういうコメントをみなさんから一言ずつ頂ければと思います。

ちなみに僕は情報設計が大事だと思っていて、情報設計の話ってUI デザインを作ろうっていう文脈だと最近はそんなに語られてないかなと思うんですね。なので情報設計だったり構造を学んでみてください、みたいなことを初学者向けのワークショップでは言ったりします。

勝島:考えるツールとして優秀だなと思っています。安心して探索もできるし、仕組みを考えながら作っていけるので。これが実装されたらどういうステートがあって、みたいなのを細かく設定しながら見れるので。思考するのに向いてますよね。あとコミュニケーションツールとしても優秀だなと思います。

加田:私が思うSketch の一番良いところって、使いこなすのがすごくラクなところだと思うんです。あと金額も安くて導入もしやすいですし。私、デザイナーだった時にPhotoshopを10年くらい使っていて、ある時「Sketchに変えるから」って前々職の上司から言われて、でもPhotoshopが大好きすぎて変えたくないって言ってたんです。でもチームでデザインデータを統一させるためにはしょうがないと、Sketchを渋々使い始めたら30分くらいで楽しくなってきて、3 時間くらい没頭したらその上司よりも大好きになっちゃったみたいな、それくらい楽しくて。(プラグインの)Craft も入れたらURLやJSONファイルからデータ入るし、めっちゃくちゃ面白いです。それくらい楽しいので、使いこなすのはササッとやって、あとは皆さんが言ってるみたいに思考する時間を増やすのが良いのではないかと思います。例えば、どうやったら効率化できるかなとか、ユーザーさんに喜んでもらう為にはどうしたらいいんだろうとか、デザインツール使いこなすために費やしてた時間を本質的な部分に向けて、サービスのクオリティを上げていくのが良いのではないかと思います。

佐藤:面白いプラグイン探すみたいな、Sketch の使い方を広げていく遊びをやってもらうのがいいなと思います。あとMediumに良い記事が多いので探してみるとか。画面を作るだけで終わらすのではなく、Flinto でアニメーションを付けてみるとか、動くものを1 回作るとワクワク度がぜんぜん違うので強くお勧めします。画面を触ったら遷移するとか、マイクロインタラクションの実験をしてもらうと、Sketchに加えてそのツールもいい!みたいな、連携感を覚えてもらうのがおすすめです。面白い!と思えることに広げていって欲しいと思います。

鈴木:僕自身の使い方としては2 通りあって、Sketch って良い意味で散らかせるので、自由帳みたいな感じでいろいろアイデアを広げられますね。ファイルが軽いからページをばーっと作ってバージョン1から10までとっておくこともできます。例えばリリースバージョンに至るまでにこういう過程があったよっていうファイルをすぐとりだせるように保存しておけるのは、すばやくいくつものパターンを作る上で非常にありがたいですね。

あとは実際に仕様を詰めていく時に、例えばフォルダの構成とか、レイヤーネームとかをちゃんとやろうとすると、divの構成のような、エンジニアが作ろうとしているものにほぼ近いものができあがると思うので、デザイナーとエンジニアの中間みたいになるというか。それに両方の人が触れるツールになるから、お互いの気持ちが分かるのがSketchのいいところだなと思います。

宇野:一番は学習コストの低さが魅力だと思います。加田さんが言ってたように、Photoshop をずっと触ってきた人でもSketchを使えるんですよね。その一方で、先ほど言ったようにノンデザイナーでも抵抗なく使いやすい。非常に直感的なUI/UX をしてると思うんですよね。だからなんとなくそれっぽいものが作れるようになるし、デザインレベルによって使いこなしができるのがいいと思います。デザインを知らない人でも、パーツが用意されていればそれを組み合わせることで画面ができるだとか。他のツールと連携させると複雑なこともできるようになりますし、相当浅いところから触れるし、深いところまで使えるし、その辺が魅力ですね。それこそ自分でプラグイン作るっていうのも良い方法だと思います。そういう間口の広さっていうのが魅力なのかなと思います。だからいろんな人がいろんなことに使える、そのへんが僕のSketch の好きなところですね。

吉竹:ありがとうございました。

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