画面制作(html, css)をエンジニアが行うようになってからの課題と取り組み

暮らしニスタのPMを担当しているウィルゲートの水口と申します。 暮らしニスタの開発チームでは、2016年のリニューアルリリース以降、画面のコーディングをエンジニアが行っています。今ではスムーズに開発ができていますが、最初はうまくいかなかった事もありました。今回はエンジニアが画面コーディングを担当するようになってからの問題点と、これまでどう改善してきたかについて紹介させていただきます。

リニューアルまでの制作フロー

f:id:mizuguchi-harumi:20181010194019p:plain

デザイナー(制作会社など)からHTML、CSS(scss)を受け取り、エンジニアはフレームワークへの反映のみ行っていました。

リニューアル以降の制作フロー

f:id:mizuguchi-harumi:20181010194030p:plain

デザイナーはデザインまでを担当、エンジニアがHTML、CSS(scss)をコーディングするようになりました。

エンジニアが画面制作するようになってからの問題点

画面制作スキルのバラツキ

ほとんどのエンジニアが画面コーディングを担当してなかったので、メンバーごとに画面コーディングの得意不得意がありました。はじめはフロントが得意なエンジニアに画面制作の担当を寄せていましたが、それだけでは工数が足りないこともありました。ただし不得手なメンバーが担当すると、工数がかかってしまい、全体的な開発コストが膨らんでしまっていました。

デザインの連携

一部を除いてエンジニアは高機能なデザインソフトを持っていません。デザインコーディングに必要な色、サイズ等の詳細な設定値を図る方法が確立されていなかったため、デザインの把握に時間がかかっていました。

修正・手戻りの発生

デザインの連携が上手くいかなかったこと、制作に慣れていないなどが影響して、制作後のレビューとその修正に膨大な時間がかかっていました。また、画像では伝わらない画面動作等の動的な部分について、後から指摘を受けることもあり、手戻りが沢山発生していました。

上記のような問題が半年くらい続き、デザイナーも含め、メンバー間の協力体制も揺らぎかけてきました。
もっとスムーズに開発が進められるように、デザイナー、フロントエンジニアを中心にチームで改善を行ってきました。

現在のフロー

f:id:mizuguchi-harumi:20181010195008p:plain

フローと担当者は変わっていませんが、連携方法が変わりました。

改善したポイント

デザイン連携にZeplinを導入

以前は画像での連携でしたが、Zeplin(https://app.zeplin.io)というツールを使うようにしました。 このツールの導入により、デザインコーディングの制作工数と手戻りが減少できました。 ZeplinはSketchデータから簡単に作成でき、連携に使える機能が色々あります。

①要素の設定値が表示される

コーディング時に必要なサイズや色等の設定値が表示されます。 f:id:mizuguchi-harumi:20181011201106j:plain

②スタイル属性値の自動生成

ある程度の表現は自動で出力されるので、コーディング時に細かい属性を考えなくても良くなりました。

③コメント機能

Zeplinは画面にコメントをつけることができます。 デザイン画像からは判断できない事などデザインの不明点を書いたり、制作後レビューのフィードバック連携にも利用しています。 f:id:mizuguchi-harumi:20181011201113j:plain

デザインパーツの共通化

デザインの体系化・デザインガイドライン作成

ページ毎、エリア毎にデザイン制作が行われていたため、サイト内に様々なデザインが混在していました。似たようなデザインなのに、要素が統一されていないため、バラバラにCSSをコーディングする状態になっていました。
デザイナー中心にガイドラインの整備を行い、色、文字サイズ、間隔等設定値の整理からはじまり、ボタン、見出し、リスト等のデザインについても統一されました。
今では各ページのデザインについても体系化されたデザインに沿って作成されるようになっています。

スタイルガイドの整備

フロントエンジニアを中心に、CSSの構造の見直しと、体系化したデザインをもとにスタイルガイドを整備しました。

設定値の共通化(色、文字サイズ等)
f:id:mizuguchi-harumi:20180903133317p:plain

パーツ(ボタン、アイコン、画像等)の共通化
f:id:mizuguchi-harumi:20180905165656p:plain

レイアウト(グリッドシステム等)の共通化
f:id:mizuguchi-harumi:20180903134746p:plain

リスト型のレイアウトやグリッドシステムについても共通化され、楽にレイアウトを表現できるようになりました。

デザイン共通化によって、同じようなデザインを何度も書くと言うことが減りました。また、必要なコーディング量が減ったので、画面制作が得意ではないメンバーもスムーズに画面を作ることが可能になりました。

コミュニケーションの増加

デザイナーとエンジニア間でデザインの要件や意図の連携がうまくいかず手戻りが発生したり、デザインのコーディングの難易度が高すぎて、最初の見積りより工数がかかってしまうことがありました。
デザイン制作前に要件と方向性の確認し、画面制作に取り掛かるまえから認識齟齬を減らすようにしています。また、デザインコーディングの前や途中でも、密にコミュニケーションをとり、コーディングの難易度が高すぎる場合に簡単な表現に変更できないか、デザインガイドラインから離れている箇所があれば統一できないかなどの実装上の相談を都度行うようにしています。

最近の課題

これまではデザイナーが常に社内にいることが多かったのですが、最近ではデザイナーがリモートにいる事が増えてきました。基本的にはSlackで連携していますが、文字では伝わりにくい場合は、電話やSlackの動画チャットを使うようにしています。

まとめ

今回はエンジニアがコーディングを担当するようになってからの問題とどのように改善してきたかについてご紹介しました。
改善を通して、エンジニアメンバーが画面制作をスムーズに行えるようになりました。その結果、デザイナーはデザインに専念することができ、エンジニアも画面制作以外の開発にも時間を避けるようになり、チームの全体の生産力向上につながったと感じています。