フロントエンドのエンジニアはデザインにどこまで責任を持つべきか
フロントエンドエンジニア初心者「フロントエンドのエンジニアはデザインをするべきなのだろうか…？ デザインカンプをどこまで忠実に再現するべきか…？」
こういった疑問にお答えします。
本記事の内容
- フロントエンドのエンジニアはデザインをするべきかどうか？
- フロントエンドのエンジニアはデザインカンプをどこまで忠実に再現するべきか？
- 納期に間に合わせることを第一にスケジューリングすべきです
- よく起こる問題点
- よく使われるデザインツール紹介
この記事を書いている僕は、フロントエンドのプログラマー(フリーランス)として、これまで３年以上のWeb制作経験があり、HTMLやCSSのマークアップからJavaScriptのフレームワークであるVue,React,Nuxtなどフロントエンドの開発を得意としています。
フロントエンドのエンジニアはデザインについてどこまで、コミットするかはケースバイケースになるため、解説していきます。
フロントエンドのエンジニアはデザインをするべきかどうか？
デザインはデザイナーに任せて、フロントエンドエンジニアはコーディングに専念すればよいと僕は思います。
最近は分業化が進み、デザインは専門のデザイナーが作ることが多くなっています。フロントエンドはReact・VueなどJavaScriptでの実装がデザイナーだと難しくなってきているため、HTML/CSS実装はフロントエンドエンジニアが専門で実装することが普通です。
フロントエンドのエンジニアは最低限、デザインカンプから画像の切り出しができれば十分です。画像の劣化がないレベルで軽量化して書き出ししたり、スマホ画像はRetina対応するために2倍のサイズで切り出す（iPhoneでぼやけないように）など対応をしっかり行います。
また運用フェーズでは、簡単な写真加工などはフロントエンドエンジニアが行うこともあるため、PhotoShopの基本操作はできる方がよいです。ただし必須ではなく、他に優先順位が高い学習すべきことがあればそちらを優先して学習しましょう。
フロントエンドのエンジニアはデザインカンプをどこまで忠実に再現するべきか？
デザインカンプは正論を言えば、1pxのズレもなく忠実に再現すべきです。デザイナーはそう思ってデザインをしていることが多いと思います。
それに対してフロントエンドエンジニアの立場からは、できる限りデザインカンプ通りに進めたいが、度重なる変更・納期スケジュールなどで対応しきれないケースは多いと思います。品質担保は大事ですが、納期も重要なので臨機応変に対応しなければなりません。
どこまで対応すべきかの考えを、僕個人の考えですが述べさせてもらいます。
数値でそのまま表現できるものは完璧に再現する
「文章の行間」「カラーコード」「文字の太さ」など確実に数値で再現できる部分は、当たり前ですが完全にデザインカンプ通りにします。
数値以外の要素が絡む部分
「段落の行間」などはフォントやline-hightを考慮したマージンにするのかどうかによって調整が変わってくるなど、解釈によって変わってくる部分はデザイナーに確認するようにした方がよいでしょう。最近はデザインカンプ上にCSSが表示されるケースも多く、その数値どおりに組んでいいのか、行間のline-hightなどまで考慮すべきかなど細かい部分まで確認しておいた方が無難です。
ピクセル単位でmargin確認するときに「Dimensions」というChrome拡張が便利なのでおすすめです。
複雑なデザインを完璧に再現するべきかどうか
一方で要素と要素が重なり合うような部分でリキッドする度に少しずつ変化するような、CSSがやや複雑になる部分については人によると思います。
複雑な計算が入ってしまう場合はコメントを入れるべきだと思いますし、敢えて引き継いだ他の人がわかりやすくするためにわずかなズレには目をつむって分かりやすいHTML＆CSSを書くという場合もあると思います。メンテナンスに強い構成にするということはよいことです。
1pxもズレないように対応を優先するか、他の人(特に初心者など)が見てもわかりやすいCSS構造にするかは、会社やチームの事情で変わって来る場合があるかもしれません。
たまに見るケースとしてmargin等が小数点単位の%で直値で書き込まれていたり、複雑な計算式のみが書かれていたり、後からメンテナンスする時にどういう根拠で計算しているかわからないこともしばしばあります。
デザイナーによっては1pxのズレも無い方が好ましいと考えている人もいるので、その時々で変えるのがよいと思います。
個人的には売上や利益を常に第一に考えています。僕はメンテナンスのしやすさは利益につながると思っており、バランスを見ながら対応するようにしています。
行間などの細かい調整が文章の読みやすさにつながり、読み手に影響を与えるのは事実です。一方で、1px単位でデザイン通りにすることが売上につながるかはわかりませんし、どの程度まで忠実にデザインを再現すればUI・UXに影響するかはわからないです。
状況によってできる範囲でデザイン通りに近づけるようにするという心がけで十分だと僕は思います。
このあたりは職人気質な人ほど、宗教論争のような議論になってしまうので難しいところです。
ちなみに僕はできるだけデザイナーと仲良くなって関係を良好にしておき、難しい場合は妥協案を相談してデザインを変えてもらうということをすることもあります。重要な部分でなければ、すんなりデザインを変えてくれることも多いと思います。
納期に間に合わせることを第一にスケジューリングすべきです
ではどこまで忠実にデザインカンプを再現すればいいかについては、納期に間に合うようにスケジューリングして、その範囲でできる限りのことすればよいと思います。
納期が第一なので、まずは納期に間に合うようにコーディングを行うということです。
２つポイントがあります。「まずは一通り作って完成させる」「スケジュール管理」です。
一通り作って完成させる
まずは一通り、コーディングを完成させることに意識を集中させるのがオススメです。
特に経験が少ないマークアップエンジニアの場合、想定外に上手く実装できないことがあります。
あまりにもざっくりとやり過ぎると逆に二度手間になり効率が落ちますが、全体に手をつけることにより早めに時間が掛かりそうなところが分かり、場合によっては、相談して他のエンジニアに手伝ってもらうということも有り得ます。
また経験が少ないと難しいデザインできれいにマークアップできず悩むということは少なくありません。後回しにして、後で先輩エンジニアなどにまとめて質問するなどした方が効率がよいです。
再度、確認をする際にデザインカンプと見比べ、細かい部分まで時間が許す範囲で手直しを行うようにしましょう。
スケジュール管理
殆どの場合、デザイン通りにコーディングできるかどうかは、スケジュール管理にかかっていると思います。ある程度の経験がある場合は、想定通りの作業時間が取れればある程度、理想に近づけられます。
問題は多くの場合、予定がどんどん入ってきたり、やっかいなのは差し込みでいきなり作業が緊急で入る場合です。リスケしてもらえないことも多く、決められた時間内で作業をするためにとりあえず形にするということになり、細かい部分まできちんと仕上げられないパターンだと思います。
後からデザイン変更が入る
後からデザイン変更が一部入ったりすることはよくあると思います。以下のようなケースがあるので注意してください。
・デザイン変更があっても連絡漏れがあり、コーダーが気づかない。
・変更箇所がわかりづらく変更を見逃してしまう。
※作業したい時に相手がいなかったりして直接聞けないことも多く、Slackなどチャットでのやり取りだと結局よくわからず自分で変更点を探すしかないということは結構あるので、常に納期までの時間には余裕を持っていたいところです。
よく起こる問題点
僕の経験からよく起こる問題をまとめました。
指示が曖昧、もしくは指示が無くて聞いたら詳しい仕様が伝えられたというケース
デザイナーとの意思疎通が不十分で仕様認識の相違が起こるケースがあります。
デザインカンプが上がってきたら、すべて一通り細かく見て、実装をイメージしつつわからない点は先にチャットなどで箇条書きにして質問するとよいと思います。
デザイナーの力量によっては何となくデザインしている場合もあるため、仕様や動作がすぐに決まらない場合はToDo、Issueとして課題に上げて忘れないように残しておきましょう。
後から変更が入り、見落としてしまうケース
仕様変更が入るケースや、質問した時などにやっぱりデザインを変えようというようなこともあります。
既にマークアップ済みの箇所なら忘れないようにToDoとして記録しましょう。変更が入った時に連携がとれていないと見落としてしまうこともあります。
後からの変更で連絡ミスにより、デザイン変更の見落としをしてしまうことは多いと思うので、最終確認をする前に十分な時間を取っておくことをオススメします。
ツールを使いこなせていなくてコメントを見落とすケース
figmaやZeplin、XDなどはコメント機能があり、コメントアイコンをクリックするとコメントが表示されるという機能があります。
この機能を知らない人は、後から詳細な仕様に気づいたり、追加でデザインが変更された時にコメント内の変更に気づけなかったということもあるため、よく確認するようにしましょう。
フロントエンドエンジニアはサービスに関する意見を言うべきかどうか
少人数のベンチャー企業で自社サービスを持っている場合などは、マーケティングやSEO、UI/UX、データ解析まで全員で情報を共有してアイディアを出し考えるというケースがあります。この場合はフロントエンドエンジニアもアイディアや意見を出すことが良いとされます。
しかし少し規模が大きくなってくるとマーケティングのプロなどが入ってきて分業が進み、得意分野はプロに任せる方向になります。フリーランスで企業に入る時は、フロントエンドエンジニアならデザイナーの指示通りにコーディングできればそれで良しとされます。逆に意見をいうと、「素人が何か言っている…」としか見られず口出しするなと怒る人もいるので、遠慮した方がいい場合もあります。
ディレクターが意見を求めることもあると思いますし、このあたりは自分のポジションと求められていることを考えて臨機応変に対応しましょう。
よく使われるデザインツール紹介
主に僕がフロントエンド開発をしていて、使われるツールを紹介します。
デザインチームなどが選定をするので、フロントエンドエンジニアとしてはデザインカンプを閲覧する・画像データの書き出しをする程度でしか使いません。そのため、すべてを事前に覚えておく必要はありません。
ある程度、定番の操作・機能は備わっていることが多いため、知らなければ使い方をググるか、デザイナーに軽く教えてもらうなどすれば問題ないと思います。
※フロントエンドエンジニアから見て触れる頻度が多いかも記載しています
- Adobe PhotoShop
頻度高：
カンプはこれが多い。加工も含め、ある程度の操作はできるようにしたい。 - Adobe Illustrator
頻度低：
ロゴ作成などで主にデザイナーが使う。カンプがイラレのこともある。 - Adobe XD
頻度高：
最近はXDでのカンプも多い印象。 - Figma
頻度高：
最近かなり増えていてFigmaのカンプが多い印象。ある程度までFigmaだけでデザインが完結できる。 - Sketch
頻度低：
スマホ画面開発や個人開発で使われていることが多いが、カンプでは見ることが減ってきた印象。 - Zeplin
頻度低：
最近見ることが少なくなってきた印象。
上記からまとめると僕個人の印象ですが、「PhotoShop」「XD」「Figma」のデザインカンプが最近は多いと思います。
初心者はとりあえずはPhtoShopに慣れておくとよく、有料なので使えなければXDかFigmaを無料で使って慣れておくのもよいかもしれません。
※最近はデザイナーの間で流行り廃りが激しく、いろいろなツールがあるのでフロントエンドエンジニアとしては都度、必要になった時に使い方を学習するという程度で基本は問題ないと思います。
まとめ：フロントエンドエンジニアは納期を優先しつつデザインカンプに極限まで近づけるのが良い
デザインをどこまで忠実に再現するかは、人によって違いが出るため、できる限りデザインカンプを忠実に再現するのが無難です。
デザイン変更が多いケースもあるので、その度に1px単位で忠実に再現することがいいとは限らないと個人的には思っています。納期や状況に応じて臨機応変に対応するのがベターだと思います。
フロントエンドエンジニアになる方法の記事も書いているのでよければ参考にしてみて下さい。
» フロントエンドのエンジニアのロードマップ 【身につけるべきスキル・収入アップ手順】
ご参考になれば幸いです。
※当サイトでは一部のリンクについてアフィリエイトプログラムを利用して商品を紹介しています