エンジニアがデザイナーに知ってほしい４つのこと

柄にもなく仰々しいタイトルをつけてみました。
現在私はソーシャルゲームの主にクライアントエンジニアという立場で開発をしていますが、前職ではFLASHアニメーションを含めたデザインっぽい仕事もしてきましたので（Illustrator、Photoshop、3ds Max、あとFrameMakerというadobeのDTPソフトを使用していました）、最低限のデザインの知識とデザイナーの心情というのにも少しは理解があると思います。そういった経緯もあったため今回のエントリ書いてみました。
会社によってエンジニア・デザイナーの役割も違ければ仕事の進め方も当然異なるでしょうから、あくまで参考程度に読んでいただければ。他にもこういうのあるでしょだとか反論含め意見いただければ光栄です。

名前重要

こないだデザイナーさんからいただいたファイル名があまりにもおかしいもの（つまり中身がどんなファイルなのかがわからない！）だったのでこの名前で相応しいのかと伺うと、「まあファイル名なんてどうでもいいのですがね」と返されてしまいました。
エンジニアは変数名、パッケージ名、APIなどの名前をいかに「相応しい」ものにするかに苦心する人種です。その大きな理由としては、「後々別のメンバーがその名前をみたときに、それがどのようなものなのかをすぐに理解できるようにするため」です。「名前付けがうまくできないときは、設計を見直したほうがよいことが多い」と言う人もいます、つまりそれくらい重要なことなのです。
他にももっと理由はあると思います。ポイントは、デザイナーも名前付けを重要視する価値があるのではと思えることです。たとえば先に挙げた「設計力」。設計力があれば、「こういったパターンのデザインも発生しうるだろうから、それも考慮してこういったデザインにしておこう」「こことここは共通化できそうだらからそれを踏まえてデザインしよう」といったように、後々のデザインの修正だったり漏れの発生を少なくすることができると思います。そしてより正しい設計になっているかを確認する指針として名前を一つ一つ丁寧に考えてみる、これは案外大事なことだと思います。

ファイルサイズを意識する

開発環境でテストをしていて、どうも画像の読み込みに時間がかかるなぁなんてことがあります。よくよくみてみると、デザイナーがサーバにアップした画像のファイルサイズがめちゃくちゃ重いのが原因だったりします。
そんなことがあったので、昨年デザイナーが納品する画像についてはPNGGauntletなどのツールを用いた、ファイルサイズの圧縮の手順をまとめた仕様書を作成して仕組み化したのですが・・・中には忙しくなるとそれをサボるメンバーがいるようです（つまりその仕組み化が不十分であるということでありますが）。
ポイントはなぜファイルサイズを意識する、つまりファイルサイズを極力抑えることに必死ににならなければならないのか。これは私のような人間がプロファリングツールなどでページの総ファイル容量が十分小さなものであることを確認してニヤニヤするためではありません。
当然ユーザのストレスを極力少なくするためです。大雑把ですが、圧縮によってファイルサイズが50%になるとします。それによってユーザの待ち時間が半分（例えば300ms→150ms）になるとします。
・・・これって凄いことじゃないですか？我々が想像している以上に劣悪な通信環境でサービスを利用してくれているユーザがいるということを忘れてはいけないと思います。そういったユーザにとってはその効果・恩恵はより大きなものになっているはずです。
これでもまだファイルサイズを意識する必要はないというのであれば、個人的にはそういった方はユーザにサービスを提供する素養がないのではと思います。

共通化したがり

エンジニアには「DRY原則」というものが存在します。"Don't Repeat Yourself"の略で、つまり「同じことを繰り返すな」というものです。わかりやすり例でいうと、同じコードをあちこちに書くなということです。なぜならばそのあちこちに書いたコードに誤りがあった場合、そのすべてに修正が入るからです。これは手間でありまたバグを産む可能性も高くなります。これでエンジニアはとかく共通化したがる人種だということがわかっていただけたと思うのですが、そうなってくると、エンジニアはデザイナーがデザインするときにもこの共通化を意識してほしいと思ってしまいます。たとえば、ほとんど同じ機能なのに若干デザインだったりその見せ方が異なるというだけでコードの共通化が難しくなる・・・これはエンジニアにとってはかなりもどかしいことだと思います。
これについては反論するデザイナーが数多くいると思います。つまり共通化することを意識しすぎるあまりに、デザインの質・創造性が落ちるのではというものです。その点についてはもちろん理解しています。
ただしデザインにおいても共通化によるメリットはあると思います。たとえば同じUIによるユーザの認知向上などです。それを踏まえると、やはりまずは共通化を念頭に置くのは悪いことではないと思います。

仕様を知る

チームの規模は会社の方針なんかもあると思いますが、私はデザイナーやエンジニアといった実際にモノをつくっているメンバーは、手を動かすのと平行して、今携わっているサービスが本当に良いモノか、ユーザにとって喜びを感じられるものか（ストレスのたまるだけのモノになっていないか）についても考察し、早い段階でのフィードバックをするべきだと思っています。なぜなら、企画者が頭の中で考えたこと、またはそれを企画書に落としたものが完璧なものであるわけがない（これは悪口ではなくそういうものということ）、そしてその不完全さを誰が一番始めに気づけるかというと・・・実際にモノをつくっているメンバーだと思うからです。
ここまでいうからには、自分も当然先述したことを実践しているつもりです。仕様の不適切なところを指摘したり、このUIだと極めて操作しづらいのではと指摘したり。
ポイントは、エンジニアよりもデザイナーのほうが１つ前の工程にいるということです。当然ながら問題点は早い段階で気づくにこしたことはありません。より無駄な作業をしなくていいからです。というか要はエンジニアの不要な仕事が減るのですw
１つ前ということはそれだけ気づくことがより難しくなるということだと思いますので多くは望みません。ただ今以上にそういった姿勢で取り組むと、より良い効率の良い開発になるのではと思っています。

とか色々書いてみましたが、逆の話も聞いてみたいですねw
つまり「デザイナーがエンジニアに知ってほしいこと」も。これもたくさんあると思います。たとえば工数だったり状況次第で、エンジニアがある文字の色を指定すること（つまりちょっとしたデザインをすること）なんかもあったりするのですが、その色のセンスの無さに気を悪くしていたデザイナーもいたと思います。