デザイナーがXcodeを使って 開発効率をUPさせた 5つのエピソード + 現場エンジニアのコメント付き

Mayumi Narisawa @ DeNA Co.,Ltd.

UI UX Designer

必需品 : sketch3 / photoshop / illustrator aftereffect / prott / pixate / Xcode

最近はじめた : AndroidStudio

主にアプリを作っています（iOS / Android） https://www.behance.net/mayumi_narisawa

Mayumi Narisawa

iOS / Android アプリ全般 https://github.com/mootoh

Motohiro Takayama Fei YeTakatomo Okitsu

iOS / Android アプリ全般 https://github.com/okitsutakatomo

Android & iOSアプリ開発

意見のご協力をいただいたエンジニアの皆様

「デザイナーが実装に参加する時代はもう始まってる」

「現代のデザイナーにはフルスタックが求められてる」

そんなニュースやブログを良く目にするようになりました。

すでにやること いっぱいで勉強の 時間ないし…

無理！

まだやらなくても 大丈夫....たぶん

それで、いろいろ思っちゃいますよね

デザイナーはUXを考える ことに専念すべき

どこ目指してるのか わからなくなりそう

怖い

以前の私も「ガイドを引いて渡す」までが仕事だと思ってました

でも今は、

・自分でmasterから最新版をpullして、

・XcodeのstoryboadでUIの調整して、

・必要があればちょこっとコードも書き、

・エンジニアにPullRequestを送る

までが、自分の仕事だと思ってます

なぜ、そうまでするようになったのか？

それは、

「リリースとして出されるものが 　自分のアウトプット力とみなされる」

から。

※ここでのアウトプット力とは、デザイナーが持つ自己都合的なクオリティだけ でなくユーザーへ有意義な製品を提供できているかどうかまでをいいます。

加えて、

「リーンな開発だから細かいところは 　時間があればやろう！」

で、デザイナーが涙目になるパターンから 早く抜け出したかったから。

さらに加えて、

「UIの実現をエンジニアに頼むというのは 　実は他力本願なのでは？」

と、ふと思ったので。

あと、

「実装するとより現実的なUXを考案できる」ことにも気付けたから。

心のどこかで自分の仕事はsketchやprottの中で完結

したと思っていないだろうか？

自分への問い

自分への問い

リリース時にデザインが思い通りに反映されていないことを、

工数や何かの問題のせいにしていないだろうか？

どれだけ声を大きくしても、 どれだけ想像を豊かにする訓練をしても、 アウトプットの結果はあまり変わらない

わたしの気付き

まず「自分の責任範囲はもっと広いのだ」と知ること

ではどうするか？

知る→挑戦→効果私が体験したXcode開発での5つのEpisode

episode1 知る→挑戦

「やりたいことあるなら、自分でやってください。 　あなたの使っているデザインツールとstoryboadは 　よく似ていますよ。」 by エンジニア

…嘘だ！と思いましたが、

まぁまぁ嘘でした。

≒

　ちょっと数字を動かすとエラーになっては落ち込み... 　storyboadとcodeを繋げている定義をザックリ消すミスをしては落ち込み.... 　似ている部分といったら、レイヤー構造のしくみや、 　色やフォントの指定の操作方法くらいだった。

イニシャルコストが大きかった 最初に Xcode の操作や Storyboard の調整方法などを手取り足取り教える必要があり、時間をとられる。しかし、長い目でみれば必ずや報われるという確信があったので問題なかった。

最初にXcodeを触るきっかけをくださいました。当時の私はどうでしたか？

Interfaceを変更したことだけで、アプリの挙動に影響しちゃうことがあった。 （例えば、outlet削除したなど。） なので、デザイナーのコードレビュー時にはよりチェックをするようにしていた(xibファイルの差分など。)

Git でコンフリクトする問題 これからファイルをいじることを口頭やチャットで宣言し、終わるまでは他のメンバーは手を出さないようなやり方にした。メンバーが多いと作業が止まり辛そうだけれど少人数チームだと有効。

おそらく、色んなことでフォロー頂いたかと思います…

「エンジニアだってちゃんとデザイン反映したい。 　でもやることいっぱいあるんだ。」

episode2 知る→挑戦

→ →

アプリ開発中のエンジニアの仕事（の一部）

・これデータ増えたら動作重くなるな。うーん設計見直さないと。 ・タイムライン系のページングって複雑すぎて泣けてくる。 ・これデータ永続化しないとユーザ体験悪いよね。 ・iOS7だけ発生するバグあるんだよなー。困る。 ・3.5インチのレイアウトってもはやAutoLayoutだけで 　なんとかなる話じゃないよね。個別に対応しないときつい。 ・テーブルビューの高さ可変になるとまじでめんどい。 ・PullToRefreshとか更新差分とかハイライトさせるの地味に大変。 ・APIドキュメント書かないと。 ・インフラ構築してサーバデプロイしないと。負荷対策も。 …etc

どうみてもUIまでにたどり着くには無謀な量ですね

文字装飾の実装 すべてのテキストに対して文字装飾（具体的にはカーニング）を施したいという要望があり、一見簡単そうではあるがiOSの文字装飾はなかなか骨の折れる作業で、はっきりいって開発終盤に「いいよーやるよー」と気楽に言える話ではなかった。

ただ彼女はStoryboardであればエンジニアレベルで活用できるため、@IBDesignableと@IBInspectableを利用したカスタムコンポーネントをいくつか用意し、Storyboardのみで文字装飾を可能にすることで、エンジニア工数を最小限に抑えて実現することができた。

そんな最中、私の知識不足から困らせてしまったこと ありましたよね？

Storyboard (InterfaceBuilder) を操作するだけでは実現できないことがあった アニメーションや影をつけるところ、コードで色を指定しているところ、など。コードも多少書けるとのことだったので、できそうなところは書いてもらえたので助かった (色の指定など)

複雑な実装部分は、やはり私一人では不可能でした…

チームで協力。エンジニアもsketchを使い出した

episode3 挑戦 → 効果

「ガイドを引くのは大変でしょう。sketchデータをくれれば自分で読んで実装します。」 byエンジニア

sketchのガイド表示方法をシェアすると、 なんとstoryboadと操作方法が同一ということが判明！

sketch storyboad

いずれもoptionキーとカーソルの動きで表示される

コミュニケーションツールが変わった

episode4 挑戦→効果

→小難しいUI調整についてはXcodeでわかるところまでやって、GitHubにメッセージを残しておく方法へと変化

GitHubを使ってコミュニケーションがとれるため、UIの確認や反映コストがほとんどかからない。 またsketch上に最低限どういう情報があればエンジニアが実装できるかを把握できているため、sketchだけで実装のためのコミュニケーションが完結できる。 （ガイドやレギュレーションを渡されて実装するより格段に作業効率が良い） またデザイナーとしてもガイドを作る工数が削減できていると思う。

開発上のコミュニケーションの変化はどう感じましたか？

「アニメーションはこうしたい。scaleとalphaと…delayは…、 　雛形組んでいただければ、あとは自分で数字調整しまっす！」

episode5 挑戦→効果

https://www.desmos.com/calculator/cahqdxeshd

Bezier Curves

UI実装するのに一番多かったやりとりです。 このコミュニケーションで「何をどうすんの？」の部分でお互いのフラストレーションがなくなりました。 ※左記はその時の事前のアニメーション共有方法

この方法でお互いのコストを大幅に削減できましたよね？

アニメーションを実装する際、パラメータをコード上の変数に変換して、曲線を実現する必要があるのだが、例えばAfterEffectだと正確な数字（主に制御点）が換算しずらいので、ベジェ曲線作成ツールを使うことでイメージの共有がしやすかった。 デザイナーは見た目で判断するけど、エンジニアは４つのパラーメータを見る共通言語的ツールとなった。

結果開発上でのフラストレーションゼロ

自信をもってリリース

でも、

でも、削り落としたUI調整はもちろんあります

UI調整は一番最後にやるのが効率的。

開発終盤のプライオリティ調整でデザイン反映が

足切り対象になりやすくなっていることに原因がある。

なぜ？

↑ Xcodeを使って一番よかった気付きポイント

「UI調整は一番最後にやるのが効率的」についての認識変化

before after

デザイン重要視されてない という思い込み

製品の完全性を求めるには UI調整は最後であるべき

デザイン作業 エンジニア作業

よく思い返してみると、デザイン作業でも同じことしていた

UIUX設計 ↓

議論・修正 ↓

グラフィック調整

機能設計 ↓

バグチェック ↓

UI調整

　エンジニアタスク 　 開発終盤 やることいっぱい 色んなものと戦ってる

デザイナータスク 　　残りのUI実装、ユーザーインプット 　　 からの修正、storyboadで調整

自分の 知識・速度では やりきれない部分

←ここが削り箇所

主に Codeを書かなきゃ 実現できないUI

そのなかで、削ぎ落とされるUI調整とは？

・Codeで実装するUIもいずれは自分の手で行えるように

・一見簡単に思えるUI調整でもCodeでなければ

　実現しないときもあると予測できるように

今後の課題

改めて、デザイナーがXcode実装に参加してどうでしたか？

以前の問題点: コード変更→ビルド→デバイスにインストール→渡して見せるという作業は、エンジニアのタスク的にはごく些細なものだが、ここにかける時間が多く、その間ほかの作業はできない。また、微調整するためにコミュニケーションも必要なため、さらに開発が遅くなっていた。 変化: デザイナーだけで UI の微調整ができるようになったことで、別のエンジニアリングタスクに集中することができ、 圧倒的に開発効率が上がった。

エンジニア・デザイナー間工数の均等化とプロダクトの品質の向上: エンジニアにはエンジニアの優先順位があり、開発後半になればなるほど目の前の対応に追われ、どうしてもUIの実装が疎かになりがちになる。 逆にデザイナーは後半稼働が空いてくることが多い。その時にStoryboardでUIのディティールを調整してもらえるのは非常に助かったし、結果的にプロダクトの品質も向上した。

改めて、デザイナーがXcode実装に参加してどうでしたか？

改めて、デザイナーがXcode実装に参加してどうでしたか？

・エンジニアのstoryboard作業工数がだいぶ減った ・デザイナーの開発を如何にしやすくさせるために、 　エンジニアの実装力も上がってきた ・互いに仕事の仕方への理解が深まった気がする

エンジニアの皆様、ありがとうございました！

ここで私も、正直な感想

AutoLayoutへの理解 storyboadでUIを調整する際はAutoLayoutを理解している必要があり、例えば、デザイン時は要素間のマージンを考えるのですが、storyboad上では親要素から要素それぞれのマージンが設定されることが多く、そういうプロセスの違いに驚きの連続でした。 AutoLayoutへの理解が深まると、おのずとデザインの設計方法も変わり、「これどう実装されるのかな？」という自問自答時間も減り、UI Review時のコミュニケーションもエンジニアにとっては、理解しやすい説明に成長できたように思います。

・エンジニアの仕事を知る＆挑戦することは 　必ずアウトプットの向上につながる

・チーム全体の開発コストを大幅に削減できる

・デザイナーのやるべきことはまだ沢山ある

デザイナーがXcodeでUI調整をすることについて

まとめ

Xcodeはどうやって習得したの？という質問をよくされるのですが、あくまでも私の場合ですが、「入門編」とラベルが貼られるような書籍は買いましたが、ほとんど読みませんでした。 最初にエンジニアからXcodeを勧められた時のことです。 「本は読まなくてもよい！Xcodeを触って覚えるのが一番早く習得できるから。」

なので、ひたすらstoryboadの定義設定と向き合い、エンジニアが書いたコードを見て研究し、必要があれば開発者ブログを検索してコードをコピペして試してみる、の繰り返しを続けました。 実際、本を読むより早かったと思います。というか、実践でやらなければいけないUI調整は本に書いてないことばかりだったので…。

良い製品を生み出す為には、今こそデザイナーとエンジニアは互いの垣根を越え、 協力しあうことが求められていると思います。 隣席のメンバーとぜひその１歩踏み出してもらえると幸いです。

あとがき

DeNAはクリエイターが社内で制作した作品を、 個人のPORTFOLIOやSNSに掲載することを尊重する。

より「個」が重視される時代に、一人でも多く「匿名のクリエイター」がいなくなるように。

http://dena.com/jp/recruit/career/portfolio/