結論はないですが最後にいちコーダーとしての個人的なわがままがあります。
事の発端
この発言。TLで「モバイルファーストでCSS書く」みたいな話を見かけて、そういえばないなあっていう思いから漏れ出たツイーツでした。
レスポンシブでモバイルのデザインがこない現場にいたからモバイルファーストでコーディングしたことない
— なゆぴ (@nayucolony) 2017年6月16日
注意事項
まず、ツイッターで意見を募る系の世論調査、業界全体でみると「意識高い人（NOTただ意識高い系の人）」が意見をくださる場合が多いです。 なので、わりと「アンテナはってる」層の意見が多いパターンが多く、一般世論とは乖離している可能性が高いことをご留意ください。
また、「モバイル/SP」のような表現をしますが「小さい画面」という意味で言っており、特定のデバイスをさしているわけではないのでご了承ください。
あと、私は元デザイナーでありコーダーですが、互いの職域に対する文句やdisではありません。 いただいた意見を元にした現状の解釈と、個人的な意見です。
ツイートに対する反応
この辺は、僕のツイートが「つらみのぼやき」に見えてしまったのか、デザイナーの「そんなことないよ」という反応とコーダーの「だよなー」という反応が多くを占めました。
デザイナーの反応
- まじで？そんなパターンあるの？
- PCとSPを想定してつくる
- 大中小の画面パターン用意する
- 実装者が社内のウェブデザイナーとかならコミュニケーションで回す
etc.
コーダーの反応
- あるある
- やっぱどこもそんな感じなんだな
- 「よしなに」の指示が来ることが多い。工数増えるっていう話をすると辞退される
- 完全なカンプは予算によっては存在するが、ディレクターが手書きワイヤーフレームで指示くれてコーダーが実装する
- 元デザイナーなのである程度汲み取る
- SPはトップだけくる
etc.
デザインカンプの持つ側面
たくさんの意見をいただいて、次のような側面が存在することに気づきました。
- デザインカンプは、次工程への指示書である
- デザインカンプは、前工程への報告書である
前者はコーダーに渡すカンプとして、後者はクライアントに見せるカンプとしてという意味合いです。
コーダーは「別バージョンのカンプ」が欲しいのか
そもそも、欲しいのか、欲しくないのか、ということから考えました。 結論からいうと、場合によるよね、とはなるのですが（笑）
前職では、クライアントの性質上「PCからの流入が圧倒的」であり、「小さい画面」については存在さえしていればいい、本当によしなにやってくれればいい、という感じでした。 しかし、「じゃあ適当にやっときますわ」というわけにもいかないのが現実でした。
なぜなら、「PC向けのデザインが本当にPCの画面いっぱいを使って表現するようなデザイン」であり、段組を変えてレイアウトを変更すればいいという話ではすまなかったからでした。
webコミックの話
具体的なサイト名を出せないので、下手くそなたとえ話をします。
例えば、スマートフォンでマンガを読む場合は、見開きではなく１ぺージずつスワイプを行なって読むことが多いですよね。もしくは、縦スクロール。 その際「見開きをぶち抜いて表現しているページ」が本来作者の意図した見せ方ができなくなりますよね。
もう、web連載なんかでは縦スクロールを前提としたコマ割りを行われているケースが多いですが、もし紙の本にむけて書いたものをその形式で出してしまうとほんとうに悲惨なことになります。 （その場合、そのコマにさしかかたときだけ横にスクロールするマンガもありますが）
・・・とまあ、話がそれましたが、その辺に近いものがありました。
そのため、「まあよしなにやってくれや」というオーダーがきた場合、かなり無理があるので、狭い画面向けのデザインの再構築をお願いしたいという気持ちがあるというのが当時の状況でした。
デザイナーは「別バージョンのカンプ」を作りたいのか
まず、多かった意見が「クライアントのビジュアルチェックがあるので絶対に必要になる」というパターンでした。これは私もやっていました。
特にコンペとかだと、おそらく100%のデザインを出すんでしょうし、それがそのままコーダーに渡って来る可能性が高いです。 レギュレーションとかもありますし、前職ではプレスチェックのために完璧なデザインを提出していました。
そのフェーズで「クライアントのビジュアル的要求」と「文書構造の一貫性」を両立することが困難になるケースも多くて、カンプのデザイン以外は「誰も知らない中間の姿」となってしまうこともありました。 当時はとにかくデザインのOKをもらうことを優先していたため、いつも、そこの調整を闇雲に行っては消耗していました。
その辺を確実に実装させるための戦略として、別バージョンのカンプを用意すると言う意見もありました。 それだけの予算をとる説得ができるかどうかは、もう一つ上の工程に掛かっているのかとはおもいますが、納期と予算の都合で難しいケースもあるとのことです。
コーポレートデザイン的な部分も含めてサイトを作ることのウェイトが高い場合は、そういう予算も惜しまずだしてもらえるのでしょうか。
ワイヤーフレームをしっかり決めることが大切
たじまさん（@DesignHumore) という、ブランディング戦略から現場のデザイナーまでを担当されている方がいて、その方の意見がすごく参考になりました。
複数ツイートに渡っての会話だったので、要約すると以下のような形になります。
- ワイヤーの時点で仕様を徹底的に詰める。必要な要素に抜け漏れがないかの確認が目的。
- デザイン（ビジュアル的な話）はイメージボードを使って方向性を決める
- 「とはいえ実物見ないとわからない」場合も当然あるが、その場合は30%くらいの力でデザインしてイメージを見せる。
- コーダーへの指示書ではなく、お客さんへのイメージ共有なので、最適レベルで見せるという意味だと思う。
- デザイナーとしては、装飾の変更は言うほどつらくない。情報構造の変化は、大変。
デザイナーはデザインツール上で完結することはテクニックで完了させられますが、インフォメーションアーキテクト的な話は、そこだけでは完結させられないのでクライアントを巻き込んだ手戻りが発生しがちです。
実装でもそうで、CSSの書き換えはSassなんかを駆使すればけっこう簡単に終わらせられます。 しかし、情報構造が変わると、HTMLも含め考慮することが増えがちです。サーバサイドと連携している場合はなおのことです。
たじまさんは「その手戻り・修正にかかる費用と時間はお客さんのものだから勝手に資源にしてはならない」とも仰っていました。
作業の大変さとかしか考えてなかったので感心しました。
文書構造の変更は大変だが、あしらいの調整はそうでもない
たじまさんの話をうけて、下手くそなたとえ話をします。
家を建てる過程で、もう色々な作業が動いているときに「すみません！忘れてたんですけど、2Fにもトイレが必要なんでした！このスペースに置いてくれればいいんで！」みたいな話をされた時の話です（なんだそれ）。
- 「いやいや、スペースはあるけど、このスペースは居住者の使いやすさをいろんな面から考慮してデザインしてまして・・・」
- 「水道管の整備、電源の確保、換気ダクトの設置、収納、あらゆる要素を改めて考慮するので、一旦全作業をストップしてもらって、もう一度打ち合わせが必要です」
- 「モノがありません、完了予定日は決まっています、無理です」
みたいな問題が生まれると思うのですが、コーディングもなんか、似たようなことが起こります。 なるべく文書構造のぶっこわしは発生してほしくないと思っています。
しかし、「すみません、外装なんですが、やっぱりクライアントのイメージと少し違っていて、もう少し濃い茶色のモノに変更してください！」という場合。
- 「塗装業者をもう一回呼びましょう。最悪、材変えましょう。お金はかかりますが、いけますよ」
- 「壁紙剥がして張り替えですかねー、内装業者のスケジュールにもよりますが、無理はないですよ、そのぶんお金はかかりますけど」
- 「この色は、全体の調和を考えてデザインしていて、他の部分もトーンを変えないと変な感じになっちゃいそうですが、本当に必要ですか？」
みたいな、割とお金で解決できるフェーズじゃないかとおもいます。 この辺は、CSSを書くときにだいたい想定しているので、割と変更は楽です。
web制作の現場、家とかに例えると「なんだそれ」ってなりますが、結構頻繁にこういう事が起こっているのを考えるとおかしな部分がありますね。 リアルの物体じゃないという性質上、修正が簡単なのは、わからなくもないんですが。
私なりのわがまま
最後に、個人的な意見です。
大きな画面でないと表現できないようなデザインならば、画面が小さくなった時のデザインも欲しい
例えば、横長のヒーローイメージをドカンと置いているような場合、「よしなに」と指示をすると「画面幅に合わせて縦横比を合わせて縮小」されて、すごくダイナミックな表現だったはずのものがすごくみすぼらしくなったりします。 デザイナーとしては「私はこんなの認めないぞ！これはこれに向けたデザインをしなおす！」という気持ちになるのではないでしょうか？ その辺りを放棄されると実装側は萎えるということもあり、お互いいい仕事をするためにも、ビジュアルの共有をしてほしいです。
レイアウトの変更だけでいけるようなサイトならば、ワイヤーレベルの指示書が欲しい
複数のカラムで構成されていて、１カラムに並べ替えるとか、１カラムを表示させないとか、そういう操作だけで行けるような場合はカンプはそこまで重要ではないかなとおもいます。 逆に、ケツの姿が決まってしまっていて、クライアントにも「これでいきます！」と固めてしまうと、中間の処理なども含めて無理が発生することが多いです。
・・・まあ、クライアントのチェックが入る以上、必要なものは必要なので、仕方ないのですが。
ただ、要素の増減が発生する場合、何を削ったらいいのかとかは実装者の独断では決められないので、指示書レベルで欲しいという気持ちがあります。 手書きワイヤーでもいいです。デザインも、デザインをかじったレベルでいいのならばまかせてくれという感じです。
結局、コミュニケーション
中間成果物がなくても、コミュニケーションで巻き取れる部分はかなりあると思っています。
- 「ふってきたデザインがこれで」
- 「ふってきたオーダーがこれで」
という風に何か超常現象のように捉えてしまいがちですが（いや、あいつぶっ殺すという人もいるとは思いますよ）、やはり決めてるのは人なのでコミュニケーションを大事にしたいですね。
そのコミュニケーションのためのベースとして、実装者はデザインに対する理解を深めておきたいし、デザイナーは実装に対する理解を深めていけるといいなと思っています。
最後に
元も子もないような感じではありますが・・・
「手戻りが発生することも含めて、お金で解決するのがプロフェッショナル」
ということもあるということを忘れてはならないと思います。
とはいえ、湯水のようにお金を使う事がプロフェッショナルかというと、そうではないということも合わせて肝に命じておきたいですね。
最後まで読んでいただきありがとうございました。