【Rails】デザイン〜プログラム作業の連携 KRAYの場合 このエントリをはてなブックマークに登録

2014年06月30日

asachunasachun

お寿司大好き! KRAY の亀井です sushi (好きなネタは炙りサーモンです)
巷ではデザイナーとプログラマーの協業についてのブログ記事を見かけたり、webプログラマーの「HTMLのzip納品つらい」という声が聞こえたりします。
デザイン(HTML コーディング)とプログラムの連携作業については、悩んでいる人が多い印象を受けます。。

デザイナーとプログラマーの協業

KRAY でもデザインとプログラムの連携については改善を試みています。
今回は KRAY でのデザイン 〜 プログラム間の連携作業について書いていきたいと思います。

  • KRAY は Rails を主に使っているので、Rails の場合の話になります
  • どちらかというと HTML コーディング 〜 プログラム間の作業の話が主です

今までのやりかた

KRAY はシステム開発専門の会社なので、社内にデザイナーがいません。
なのでデザインはパートナーのデザイナーに依頼していました。
今まで主にやってきた流れとしては

デザイナーがHTML を組んで zip でプログラマーに渡す

プログラマーが Rails の view にデザイナーの HTML を組み込む

文字にしてしまうとこれだけなのですが、いくつか問題がありました。

  • 渡されたそのままの HTML だと JavaScript やバックエンドの実装をするのにやりにくい箇所もあったりするので、HTML を一部書き換える手間がある
  • バージョン管理されていないので、変更の差分がわからない
  • CSS が得意でないエンジニアもいるので、バックエンド実装段階でデザインが崩れてもどう直せばいいかわからないことがある
  • デザイン組み込みにとにかく時間がかかる

解決策

この状況を改善するべく、弊社の社長は対応策を考えました。
それは、
HTML を書ける人に Rails のフロント部分を覚えてもらって、 view の組み込みをやってもらう」こと。
それから、プロジェクトによっては Rails の view の組み込みを弊社フロントエンドエンジニアがやるようになりました。
(はい、これが私です)

※ここから先は「プログラマー」と呼んでいた役職を「バックエンドエンジニア」と呼びます。

フロントエンドエンジニアが入った場合のデザイン〜バックエンド実装の流れ

  1. デザイナーが PSD をフロントエンドエンジニアに渡す
  2. 生の HTML は書かず、フロントエンドエンジニアが Rails の view に直接デザインを組み込む(Rails プロジェクトをローカルに clone してきて直接組み込みます)
  3. フロントエンドエンジニアがバックエンドエンジニアに GitHub でプルリクエストを出す
    (プロジェクトによっては GitLab だったり Bitbucket だったりします)
  4. バックエンドエンジニアがレビューしてマージ
    ・フロントのレビューというよりは、バックエンドに組み込む際にやりづらい作りでないかを見る
    ・このときにテストの修正などもする

この流れになってから、生の HTML を組み込むフローで起きていた問題がいくつか改善されました。

  • 渡されたそのままの HTML だと JavaScript やバックエンドの実装をするのにやりにくい箇所もあったりするので、HTML を一部書き換える手間がある

    まったく書き換えないというのは難しいですが、書き換える箇所は減りました

  • バージョン管理されていないので、変更の差分がわからない

    フロントエンドエンジニアも Git 使っているので無問題

  • CSS が得意でないエンジニアもいるので、バックエンド実装段階でデザインが崩れてもどう直せばいいかわからないことがある

    フロントエンドエンジニアがやるので、バックエンドエンジニアはノータッチ

  • デザイン組み込みにとにかく時間がかかる

    バックエンドエンジニアはデザイン組み込みをしなくなったので、こちらの不満がだいぶ解消されたようです

ちなみに、弊社フロントエンドエンジニアのスキルセットはこんなかんじ。

  • Git はひと通り使える(GUI は使わず、コマンドラインから操作)
  • Rails のテンプレートヘルパはひと通り書ける( link_to, image_tag, フォームヘルパー系など )
  • Rails の Helper, JavaScript はあまり書けない(これでフロントエンドエンジニアを名乗るのはおこがましいですが、この記事では便宜上そう名乗っています…)

また基本的には、バックエンドの機能をひと通り実装したあとでデザインの組み込みをしていくのですが、バックエンドができていないときには以下の方法をとっています。
こちらはプロジェクトによってやり方が違っていました。

プロジェクトA

「designs」というデザイン組み込み専用のコントローラをバックエンドエンジニアが作成し、フロントエンドエンジニアが動的な部分はなしに view を書きます。
バックエンドの実装をするときに /designs 以下から view ファイルを組み込み、終わったら /designs からその view を消します。

メリット:動的な部分と分離してデザイン組み込みをするので、フロントエンドエンジニアが動的な部分を壊してしまう可能性がなくなる
デメリット:生の HTML を組み込むよりは楽とはいえ、あとでそのコードを動的な部分に組み込む手間がある

プロジェクトB

最初から controller、view を作りルーティングの設定をし、フロントエンドエンジニアにパスします。
表示に必要そうな動的な要素(インスタンス変数など)もある程度組み込んでフロントエンドエンジニアに渡します。

メリット:あとでエンジニアがデザインを組み込まなくていいので楽
デメリット:最初にルーティングの設定などをする手間がある

エンジニアの声

また、フロントエンドエンジニアがデザイン組み込みをするようになってどう変わったか、弊社のエンジニア2人の声を聞いてみました。

  • ダニーさん(27)
    danny
    今年の夏コミで技術本を出すそうです
  • たくる先生(25)
    takuru
    KRAY で1番ワイルド

よかったこと

ダニーさん

  • フロント組み込まなくていいから楽
  • HTMLやCSSの直して欲しいところを伝えやすい
  • フロントまわりのクオリティが上がった
     UIUXまわりなど細かいところで見てくれるようになったから

たくる先生

  • バックエンドに集中できる
  • デザイン〜バックエンド実装までのフローがすごく早くなった

うーん…なこと

ダニーさん

  • フロントで変更があるとテストが落ちることがあるので、デザインをあてたときにテストも一緒に修正してもらえると嬉しい
  • バックエンド専門の人ほどでなくてもバックエンドを多少知っておけば、フロントとバックエンドどちらでやるのが適切か判断しやすくなるんじゃないかと思う
  • 人によって JavaScript のスキルに差があるので、どこまで頼んでいいのかわからない

たくる先生

  • デザイン組み込み好きだったのでちょっと残念
  • /app/assets/stylesheets 以下に手を加えにくくなった(※でも加える)

話を聞いた印象だと、やはりバックエンドの実装の集中できるのがいいみたいです。

今後の弊社フロントエンドエンジニアの課題としては

  • テストを書く
  • JavaScript を書けるようになる

といったところでしょうか。
今後も改善を続けていきたいと思います!

おわりに

たくる先生のインタビューの最後にした、

たくる先生「社内でまだ亀井さんとチーム組んでない人っていましたか」
私「はい、◯◯さんです」
たくる先生「特に◯◯さんはそういう人材を欲していたので、早くその(デザイン組み込み専門の人間が入ることの)恩恵が受けられるといいですね」

という会話が印象的でした。

デザイン〜バックエンドの開発の流れを円滑にする、というのがフロントエンドエンジニア の役割のひとつだと思うのですが、特に Rails においては「バックエンドエンジニアが気持よく仕事をする手助けをする」という役割も大きいのではないかなと思いました。

こちらの記事はいかがでしたでしょうか?
参考になれば幸いです。

クレイについてもっと知りたい方は…

  1. クレイの3つの強みを見てみる。
  2. WEBシステムのことなら何でもご相談ください。

「いいね!」で応援よろしくお願いします!

このエントリーに対するコメント

コメントはまだありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)


トラックバック

we use!!Ruby on RailsAmazon Web Services

このページの先頭へ