読者です 読者をやめる 読者になる 読者になる

アラタナエンジニアブログ

aratana Engineer's Blog

デザインファイルの管理って、みんなどうやってますか?

※ この記事はアラタナAdvent Calendar 2016 12月2日(金)の記事です。

f:id:aratanakoho:20161130215731j:plain


うぇいです。デザイナーです。
iPhone7にしたのはいいけど、レジで「ApplePayで( ・´ー・`)」と言い出せてないチキンです。初めてってドキドキします。


さて。
ウェブデザインの制作に関わるみなさん、デザインファイルの管理って、みんなどうやってますか?


Twitterでやばいファイル名のあるあるネタであがって、「わかるわーw」って笑っていた身なんですが、
最近「わ、笑えない…(((゚Д゚)))」と思いたち、これからを考えて、きちんと考え直してみました。まとめてみます。

何かのきっかけになれば嬉しいです。


もくじ

  • うぇい流のデザインファイル管理
  • メリットは何だったか
  • いろんな課題もあった気がする
  • 向いているプロジェクトとそうでないもの
  • まとめ




うぇい流のデザインファイル管理

1. システムと同じディレクトリ構造・命名規則

f:id:aratanakoho:20161130212354j:plain


作成するpsdの名称と数を、システムのものと合わせてしまいました。
技術者側もみているのは実際のファイル名だったりするので、そちら側としても助かりますね。
どうしてもデザイン固有の名称で持ってしまうと、実際のファイルとの相対表が欲しくなっちゃうんですよね…そんな手間が減ります。

また、運用・保守をやるなると、全体を修正というよりもページ単体での改修がほとんどの場合が多いので、その修正も入れやすいです。


細かなTipsとしては、

  • ページの表示パターンはpsdファイルのアートボードを使って展開
  • ヘッダーやフッター等の共通パーツなどはリンクファイルにして流用(※ ライブラリは使わなかった)

というところは、AdobeCCの新機能を利用してやっていました。
リンクファイル(スマートオブジェクト)や、アートボードの機能がなければ、この管理方法はまたもや崩れ去っていたと思います。
ほんとに便利になったー!



2. 編集履歴はGitでまとめてしまう

f:id:aratanakoho:20161130212413j:plain


よくやっていた管理方法としては、psdに更新日時を記載する方法です。
それを捨てて、編集履歴はつまりバージョン管理なわけなので、Gitでやってしまいました。

psdに日付を残しての管理でも可能ではあったのですが、ファイル数が多く、
「えっと…あれ、このファイルは日付違うけどこれが一番新しいんだっけ」と、複数人で作業をしていく場合に混線が多かったのも確かです。
Git管理にすれば見るべき場所を伝えやすくなります。「masterにあるデザインが常に最新」「他ブランチは制作途中」と。
ネットワーク図もあれやこれやで見ることができるので、デザイナーにとってもわかりやすくて嬉しい。

また、複雑な状況でウェブデザインの制作をしている時に悩みがちなのが、
「デザインは正しいんだけど、一部はこっちが正しくて」
というデザイン不完全状態。

仕方がない部分もありがちだったんですが、これらをできる限りなくしたいためにも、開発に寄せた考え方を真似てみています。
複数ラインで制作が入っていた場合に、デザインをマージするタイミングも出てきたときの悩みもなんとかできそうだったので。
あと、今回特に書いてはいませんが、レビューもこれを機会に設けています。


まだまだ詰める必要があるのは確かですが、これができれば、現在と今後変更したいデザインの比較がしやすく、
ブランチ=開発機能単位で区切ることで、どんな制作が進行しているのか見えやすくなっていくと思っています。
今でも十分楽になりましたが、まだまだこれからです!
※ 細かくお話すると長くなるので割愛( ˙灬˙ )




メリットは何だったか

1. 開発とデザインとの進行軸を揃えやすい

システム寄りな画面になると、作って終わりの単純なものではなく、
短期・中期・長期的な内容を含めて、デザインをアップデートしながら作っていく必要があり、
情報・カンプ・人がさまざまに入り乱れるシーンが多く出てきました。

デザイナーの脳内整理やいつも通りのコミュニケーション・管理だけでは追いつかないタイミングも往々にしてあるので、
開発と同じ整理の仕方で進められる方法を取り入れたことで、多少は楽になりました。

2.システム理解が深まることでのクオリティアップ

ひとつめで話したように、開発側を見ながらデザインを進めるので、全体の理解度が増していくように感じました。
デザインを作る上での「システムを理解する」ということは、より全体を見渡して考慮したデザインをアウトプットする上でも大切なことです。

知らなければ、作ることができない!大事なことを改めて気づくことになりました。




いろんな課題もあった気がする

1.リポジトリが膨れ上がりすぎる

それほど気にはしていなかったんですが、流石に膨れ上がって大変になりそうですよね、、、
Git LFS入れれば解消はするみたいなのでなんとかなりそうですが。

2.Diffが簡単に見られない

このやりかたを始めるときに出てきたもので、解消していない件。
Githubでは見られるようですが、他は難しいようですね。ここもこれから改善していきたいな〜

3.デザイナーがGitに触れなければいけない

これは大きいかもしれません。やらなくていい方法があるのであれば、手間になる部分はあるので、Gitに縛られる必要はないと思っています。
今回の例はあくまで、全体でやっていることにうまい具合にマッチ・結果開発側へのデザイナー理解度も上がったというだけなので、
これはメリットでもあれば課題、デメリットでもあるなぁと感じました。




向いているプロジェクトとそうでないもの


この管理方法は一例であり、案件によっては向いてないものももちろんあるので全てではないと思います。あくまで一例です。

それこそ、単発改修やLPなどのような、リリースすると頻繁な更新は行われないページなどには向いていないと思います。
制作枚数も多くないものも、向いてなさそうです。
一度のフローで終わることにブランチ切ったりコミットしたりしたら発狂する・・


じゃあどれよというと、デザインとプログラマーがより密接になる必要がある案件や、
運用・保守を見据えて、フロントエンドとデザイナーがタッグを組んで設計を考えたほうがよいものに向いていると思いました。
管理画面寄りなものとか、デザインも大事なんだけど、システムも大事なやつとかとか。
もっと色々なことでチャレンジしてみたい!!




まとめ

f:id:aratanakoho:20161130212436j:plain

お伝えした方法は、前々からあるにはある、Gitを使ったデザインデータ運用方法でした。
しかしながら、やってみないと向き不向き、良し悪しもわからないものですね〜。ためになりました。
何度かGit管理しようぜ!とデザインチームで動き、失敗してきたうえで、ようやくかたちになってきた経緯もあって尚更でした。
失敗パターンもいつか書けるといいなぁ


また、ご紹介した例で回せたのは、デザインが作られた後、彼らがどんなフローや手段で開発をしているのか改めて知ること、
相談してみてお互いにやりやすい方法を考えてみることなど、
フロントエンドやプログラマーと絡めて、意見を聞いたり相談しながらやり直してみたことが大きいと思っています。

フロントエンド側でも、コードレビューとプラスしてデザインレビューを入れてみたり、
デザイン制作の中でフロントも交えてレビューのタイミングを設けたり、色々と教えて手助けしてくれるチームのみなさんに日々感謝です!
共に成長できるって楽しいですね。気づかせてもらえてほんとにありがたいです。


どんな案件にでも!と言えない、結構流用しづらい内容かと思いますが、何かの参考やきっかけになれば嬉しいです。
というかこれがうまい具合にきっかけになってもらって、みなさんのやり方・おすすめツールも聞いてみたいです!!!!もっといろいろ知りたい!!!!よろしくおねがいします!!!




ふう。
明日は、桑畑さんが何か記事を書く予定です。ダイビングの話かな〜ぜったいちがうな〜楽しみ〜




ではでは。うぇいでした〜。






アラタナ Adevent Calendar 2016
f:id:aratanakoho:20161130212444j:plain
http://qiita.com/advent-calendar/2016/aratana