多言語・マルチデバイス対応のPairsを、チームでデザインするためのデザインデータ管理方法とは？

Published in

Pairs Engineering

10 min readDec 6, 2015

はじめまして。デザイナーの原です。エウレカの自社サービス「Pairs」でリードデザイナーをしています。

さて唐突ですが、自社サービスを開発・運営している会社では、

「デザインデータはどう管理してるの？」

と、きっと気になっている人もおられるのではないかと思います。私は正直気になります。いろいろな企業に聞いてまわりたいです！

Pairsで展開しているデバイスは、「Web版PC」「Web版スマートフォン」「iPhoneアプリ」「Andoridアプリ」の4デバイスです。かつ言語は「日本」と「台湾」の2ヶ国語でリリースしています。
そのため、1つの画面や機能を改修するだけでも、単純計算で「4デバイス x 2ヶ国 = 8個分」のデザインデータを変更・管理をしなくてはなりません。あぁぁぁ〜大変。

今回は、その膨大なデザインデータをPairsデザイナーチームではどのように管理し、工夫しているのかをお話ししたいと思います。

1.「.psd」「.ai」「.sketch」などのデザインデータの作成単位

エウレカデザイナーチームでは、Photoshopで作っていたデザインデータをSketchに乗り換えました。
Sketchに乗り換えたとはいえ、Sketchはあくまで「UI作成ツール」という位置付けとし、ビジュアル（バナーやメインビジュアル）を作成する場合はPhotoshopを使い、イラストや綺麗なアイコンを作る時はIllustratorを使用しています。しばらくはツールの並列運用の使い分けになると思います。（乗り換えた理由は、後半のおまけで触れますね。）

現在、そのデザインデータの中身をどうやって作成しているかというと、
「1デバイス：1機能：1言語 = 1Sketch」の単位とし、1つのSketch内にたくさん詰め込まない、という方針で進めています。
機能内で条件によって表示方法が異なる場合や、複数画面での遷移がある場合は、アートボードで対応としています。

(※例えば…上記は「さがす」機能、日本語、iOSのSketchデータになります)

なぜこのように作っているかというと、理由は下記2点です。

① 複数人がデザインを修正する

現在Pairsのデザイナーは、私を含め5名います。
日々チームでデザインをするため、1Sketch内に多くのデザインデータを詰め込むと、同時に編集ができなくなり、コンフリクトを起こしてしまいます。
チームでデザインをする際は、複数の施策を並列で進められるよう、データをあまりまとめず個別に管理する必要がありました。

②「4デバイス x 2ヶ国語」対応していること

ブログの冒頭で触れた通り、Pairsは「Web版PC」「Web版スマートフォン」「iPhoneアプリ」「Andoridアプリ」の4デバイスと、日本・台湾の2言語でリリースしています。
Sketchは動作が軽く、Artboardを増やして作成してもPhotoshopに比べれば相当耐えうるポテンシャルを持っています。しかし、Artboardを多用しすぎてしまうのは問題があります。動作が重くなってしまうのと、「あのデザインデータってどこのファイルにあるんだっけ？」ということになり、デザインデータを開いてみないとわからなくなるため、とても効率が悪くなります。

また、以下の内容も検討しましたが、Pairsには合わずボツにしました。

A.「1機能の全デバイス」をpage/Artboardで管理するとした場合
これは、1機能内でデバイス毎の画面をすべて把握できるというメリットがあります。その反面、共通パーツをまとめるSketchのシンボル機能を使う際、デバイス毎の共通部品が多くなり、動作が重くなってしまう可能性があるため、案としてはボツとなりました。

B.「1デバイスの全機能」をpage/Artboardで管理するとした場合
これは、全画面を網羅的に管理できるメリットがある反面、①で述べた通り、複数人が同時に編集はできないことと、画面数も少なくないため、この案もボツ。
あー、エンジニアのソースコードのように、githubでマージとかできたら素敵だろうな…

C.「1機能：1デバイスで全言語」をpage/Artboardで管理するとした場合
これは、1機能・1デバイス・全言語で、言語の違いを網羅的に確認できるメリットがある反面、今後の言語が増えるたびにpage/Artboardが増えるのは、データが重くなっていく原因にもなるのでこれもボツ案でした。

結果的に「1デバイス：1機能：1言語 = 1Sketch」の必要最小限の単位で作成し、管理しています。

2. デザインデータのフォルダ階層・管理について

データは最小限の単位にし、そのフォルダ構成をどうするか。

まず、Pairsのデザイン業務でよく行う行動としては、
（ケースバイケースですが）1機能を改修する際は、全デバイスを変更する必要があり、もちろん他言語にも影響がでるため、下記を行う機会が大変多くなっています。

・デバイス間での違いを確認・変更する
・言語間での違いを確認・変更する

多言語・マルチデバイスなので、仕様揺れや反映漏れ、考慮漏れは絶対に防ぎたい！！
そのため、現在では、下記のようなフォルダ構成になっています。

こうすることで、1機能内でのデバイス間のデザイン確認をスムーズに行うことができ、
言語の違いを確認するときも1段上がるだけで、探したいデータにたどり着けます。
あ、Finderを複数開けばいいじゃんってツッコミは受け付けていません(笑)。

ちなみに、現在の構成になる前は、以下の構成でした。

これだと、普段の業務を行うにはかなり手間がかかり、ストレスでした。
デバイス毎のデザインを確認するのに、1段上の階層を開く必要があり、ちょっと確認したい時だけでも移動ステップがとても多いのです。
また、国ごとにデザインを確認したい際も、一番上の階層まで戻らなければならずかなり非効率でした。

サービスのフェーズや規模、環境でもこういうものは異なってくると思いますが、
フォルダ構成を考える時は、実務で一番何をするかなど優先順位をつけ、優先順位が低いものを上へ上へと階層をあげると良いと思います。

3. （おまけ）PhotoshopからSketchに乗り換えた理由

おまけ。Sketchに乗り換えた的な話は、いろいろなブログで語られているので、あまり多くを語りませんが、今回エウレカが乗り換えた理由を簡単にお話したいと思います。

学習コストが低いとか、安価とか、Sketchと互換性のあるサービスが豊富など、もちろんいろいろな背景がありますが、大きく分けると理由は以下の3つになります。

・1つ目は「動作が軽快・豊富なプラグイン」

・2つ目は「開発スピードの向上・効率化」

・3つ目は「採用とキャリアなど外向けの話」

「動作が軽快・豊富なプラグイン」
（これはあえて言う必要もありませんが）Phtoshopを使ったことがある人は誰しもが経験したことのあるであろう、「起動が遅い」「保存が遅い」など、すべての動作が重くイライラします。Sketchの軽快さを1度体験すると、もう戻れないですね。
プラグインも豊富で、ボタン一つでいろいろできますし、自分でもカスタマイズできるので本当に便利で仕方ないです。

「開発スピードの向上・効率化」
Photoshopでデザインをしていた時は、結構時間を割いて事細かく指示書等をガチガチに作成していましたが、Sketchにすることで、プラグインなどを利用してpxを自動で測ったり、ドキュメントをわざわざ作らず、そのままSketchデータを渡して実装してもらうことも可能です（もちろん開発体制にもよりますが）。そうすることで、今まで指示書に作成していた時間分を別のタスクがまわせすこともできます。

「採用とキャリアなど外向けの話」
業界では、徐々にPhotoshopからSketchに移り変わっていく中で、業界のデザイナーとして遅れをとることは、デザイナーのキャリア的にも採用的にもあまりよろしくないと思っていました。

昔、転職活動をしていた時に、どこの会社もPhotoshopを使っていた時代で「弊社のスタンダードツールはFireworksです」みたいな会社を見かけると、「あーこういう企業は変化に対応できない企業なんだなって」って正直思って敬遠していました。

今後、例えばUIデザインバリバリやっている会社が「弊社のスタンダードツールはPhotoshopです」なんて言っている企業が敬遠される日も、遠くない未来にやってくる予感がしています。
採用側としても、こういった些細なことでも機会損失の可能性をつぶしていきたいし、エウレカで勤めているデザイナーも、古い人材と思われたくないため、乗り換えを決めました。（もちろん使用ツール以外で測れることはたくさんありますが…。）

最後に…

今回ご紹介したデータの管理方法は、1人あたりで考えると一見大したことない効率化かもしれませんが、チームに関わるため、全体として効率があがるものだと考えています（実際、効率が上がりました）。複数のデザイナーそれぞれがストレスなく良いデザインを作成するための環境づくりも大切な仕事だと日々実感しています。

デザインデータもフォルダ構成も、後から考えてみれば結構当たり前だなとは思いますが、
「1人のデザイナーのデザインワーク」と「チームでのデザインワーク」は全く違うもので、会社の規模・事業フェーズの変化とともに仕組みや管理も変えていかなければいけないですね。

今の形がベストだとは全然思っていないので、今後もいろいろ変化させながら対応していき、デザイン・開発がよりやりやすい環境を模索し、構築していきたいと思います。