読者です 読者をやめる 読者になる 読者になる

inFablic

Fablic開発者ブログ

フリルのiOSアプリ開発におけるエンジニアとデザイナーの作業分担について

こちらはFablic Advent Calendar 2016の記事です。

こんにちは。FablicのiOSエンジニア、shobyです。

iOSエンジニアの皆さんは、デザイナーとどういった形で仕事を進めているでしょうか。

iOSアプリの開発はWebの開発と異なり、UIとロジックを完全に分離することが困難なため、エンジニアとデザイナーの責任範囲が曖昧です。 どこまでエンジニアが担当し、どこまでをデザイナーが担当するかは悩みが多いと思います。

現在、フリルのiOSアプリ開発は、デザイナーがSketchでデザインし、エンジニアがSketchファイルを見ながらUIを実装する方式で進めています。

フリルではこの方式を取り入れることで、デザイナーにStoryboard上でのUI調整を任せていた時期に比べ、開発速度が向上するメリットが得られました。

この記事では、フリルのiOSアプリ開発における、エンジニアとデザイナーの作業分担を、どのように行ってきたかお話しします。

概要

  • デザイナーにStoryboard上でのUI調整を任せる方式
  • デザイナーにStoryboard上でのUI調整を任せる方式のデメリット
  • Sketchファイルをエンジニアが触る開発方式

デザイナーにStoryboard上でのUI調整を任せる方式

かつてフリルのiOS開発は、デザイナーにStoryboard上でのUI調整を任せる方式で進めていました。

デザイナーはエンジニアに画像でモックアップを渡し、エンジニアは大まかにUIを実装、最後にデザイナーがStoryboard上でUIを調整するという進め方です。

f:id:shoby:20161214184333p:plain

iOSアプリ開発においては、UIとロジックは完全に分離できないため、UIの責任範囲が曖昧になってしまいます。 そのため、基本的にはエンジニアがUIに責任を持つが、細部はデザイナーに責任を負ってもらうという考えでした。

この方式では、エンジニアからすれば、UIの細部に悩むことがなく、「うちではデザイナーがXcodeも触る！」と誇らしく言っていたものでした。

しかし、うまくいかない点が出てきます。

デザイナーにStoryboard上でのUI調整を任せる方式の問題

デザイナーにStoryboard上でのUI調整を任せていたのは良いのですが、チーム開発という点では以下のような問題が出てきました。

簡単な画面が少なくなり、デザイナーが調整できるレベルの画面がなくなっていった

近年、iOSアプリは、どんどん多機能化、複雑化してきていますが、フリルも改修に伴い、多くの画面が複雑化してきました。 そういった複雑なUIにStoryboardだけ対応するのは困難であり、デザイナーがStoryboardだけで簡単に調節できる画面はほとんど無くなっていきました。

そのため、ほとんどの画面の最終調整は、エンジニアがすることになりました。

AutoLayoutがデザイナーにとって学習コストが高い

AutoLayoutはとても学習コストが高く、デザイナーに覚えてもらうのはかなり非効率ということが分かりました。 AutoLayoutの制約の設定はこれといった正解がなく、複数端末でも崩れづらい制約を設定するのは、経験則に基づくパターン化が必要です。 iOSエンジニアでさえ難しいAutoLayoutを、デザイナーに覚えてもらうのはかなり非効率でした。

AutoLayoutはコードレビューしづらい

diffだけでは変更が分かりづらく、これといった正解がないため、各制約の妥当性を考えるのが難しいためです。

ここに関しては未だによく分からないため、皆さんがどのような基準でAutoLayoutのコードレビューをしているか、是非教えてください。

デザイナーによる変更はコードレビューが通りづらい

デザイナーが難しいAutoLayoutを覚え、頑張ってUIを変更してくれた場合でも、エンジニアによるコードレビューは通りづらいことが分かりました。 単純にデザイナーがAutoLayoutに慣れていないという点もありますが、エンジニアはデザイナーの変更に対して辛口になってしまうようです。

Pull Requestに多くのコメントがつき、何度も修正の往復があるため、お互いに疲弊していました。

Sketchファイルをエンジニアが触る開発方式

Storyboardがエンジニアとデザイナーの作業分担には向かないということに気づいてからは、デザイナーがSketchでデザインし、エンジニアがSketchファイルを見ながら実装する方式に変更しました。

f:id:shoby:20161214175848p:plain

この方式にはデザイナーがStoryboardを触る方式と比べ、以下のように多くのメリットがあり、結果的に開発速度が向上しました。

Sketchがエンジニアにとって学習コストが低い

Sketchはかなりエンジニアフレンドリーで、使いやすいツールでした。 PhotoShopやIllustratorと比べ、エンジニアも抵抗感なく使用することができます。 雑に言うと、使いやすいStoryboardのような感じです。

SketchファイルがUIの設計書として優れている

使い始めて気付いたのが、SketchファイルがUIの設計書として優れていることでした。 UIパーツのサイズ、フォントサイズ、マージンなどがSketch上で簡単に参照できるため、画像でモックアップを渡されていた頃よりも開発速度が上がりました。 また、エンジニアがデザインを忠実に再現することができるようになったため、余計なデザイン調整の手間が減りました。

以下のように、Sketch上ではオブジェクト間のmarginも簡単に測ることができます。*1

f:id:shoby:20161214173417p:plain

エンジニアとデザイナー、お互いに慣れたツールで開発が進む

お互いの仕事は、デザイナーはSketch、エンジニアはXcode上で進みます。 デザイナーがStoryboardを触らなくなったことで、無駄なストレスを与えることは少なくなったかなと思います。

画像パーツの書き出しといった細かい作業をデザイナーに依頼しなくて済む

以前、画像ベースでデザイナーとエンジニアがやりとりしていた際には、画像の書き出しをデザイナーにお願いすることが多く発生していました。 Sketchベースの場合は、エンジニアが自分で画像を書き出せばそれで済み、余計なコミュニケーションが減りました。

お互いの専門性を尊重でき、信頼感が増した

デザイナーに慣れないAutoLayoutを書いてもらっていた頃は、お互いが疲弊していましたが、責任範囲が明確になることにより、お互いの専門性を尊重できるようになりました。

私の場合、デザイナーの作成してくれたデザインを極力再現するようになり、確認時に細かくダメ出しされることが減りました。

まとめ

iOSアプリ開発はWebの開発と違い、デザイナーとエンジニアの責任範囲が曖昧です。 フリルのiOSアプリ開発では、デザイナーにStoryboardを変更してもらうのをやめ、エンジニアがSketchファイル見ることで、開発速度が向上しました。

責任範囲が曖昧な領域では、お互いの歩み寄りが必要です。 エンジニアから歩み寄ってみてはいかがでしょうか。

*1:オブジェクトをクリックして、Option＋マウスカーソル

shoby