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

2.
UI UX Designer
必需品 :
sketch3 / photoshop / illustrator
aftereffect / prott / pixate /
Xcode
最近はじめた :
AndroidStudio
主にアプリを作っています（iOS / Android）
https://www.behance.net/mayumi_narisawa
Mayumi Narisawa

3.
iOS / Android アプリ全般
https://github.com/mootoh
Motohiro Takayama Fei YeTakatomo Okitsu
iOS / Android アプリ全般
https://github.com/okitsutakatomo
Android & iOSアプリ開発
意見のご協力をいただいたエンジニアの皆様

4.
「デザイナーが実装に参加する時代はもう始まってる」
「現代のデザイナーにはフルスタックが求められてる」
そんなニュースやブログを良く目にするようになりました。

5.
すでにやること
いっぱいで勉強の
時間ないし…
無理！
まだやらなくても
大丈夫....たぶん
それで、いろいろ思っちゃいますよね
デザイナーはUXを考える
ことに専念すべき
どこ目指してるのか
わからなくなりそう
怖い

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

7.
でも今は、
・自分でmasterから最新版をpullして、
・XcodeのstoryboadでUIの調整して、
・必要があればちょこっとコードも書き、
・エンジニアにPullRequestを送る
までが、自分の仕事だと思ってます

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

9.
それは、
「リリースとして出されるものが
自分のアウトプット力とみなされる」
から。
※ここでのアウトプット力とは、デザイナーが持つ自己都合的なクオリティだけ
でなくユーザーへ有意義な製品を提供できているかどうかまでをいいます。

10.
加えて、
「リーンな開発だから細かいところは
時間があればやろう！」
で、デザイナーが涙目になるパターンから
早く抜け出したかったから。

11.
さらに加えて、
「UIの実現をエンジニアに頼むというのは
実は他力本願なのでは？」
と、ふと思ったので。

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

13.
心のどこかで自分の仕事はsketchやprottの中で完結
したと思っていないだろうか？
自分への問い

14.
自分への問い
リリース時にデザインが思い通りに反映されていないことを、
工数や何かの問題のせいにしていないだろうか？

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

16.
まず「自分の責任範囲はもっと広いのだ」と知ること
ではどうするか？

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

18.
episode1 知る→挑戦
「やりたいことあるなら、自分でやってください。
あなたの使っているデザインツールとstoryboadは
よく似ていますよ。」 by エンジニア
…嘘だ！と思いましたが、

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

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

21.
Interfaceを変更したことだけで、アプリの挙動に影
響しちゃうことがあった。
（例えば、outlet削除したなど。）
なので、デザイナーのコードレビュー時にはよりチェッ
クをするようにしていた(xibファイルの差分など。)
Git でコンフリクトする問題
これからファイルをいじることを口頭やチャットで
宣言し、終わるまでは他のメンバーは手を出さない
ようなやり方にした。メンバーが多いと作業が止ま
り辛そうだけれど少人数チームだと有効。
おそらく、色んなことでフォロー頂いたかと思います…

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

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

24.
文字装飾の実装
すべてのテキストに対して文字装飾（具体的にはカー
ニング）を施したいという要望があり、一見簡単そう
ではあるがiOSの文字装飾はなかなか骨の折れる作業
で、はっきりいって開発終盤に「いいよーやるよー」
と気楽に言える話ではなかった。
ただ彼女はStoryboardであればエンジニアレベルで活用できるため、
@IBDesignableと@IBInspectableを利用したカスタムコンポーネント
をいくつか用意し、Storyboardのみで文字装飾を可能にすることで、エ
ンジニア工数を最小限に抑えて実現することができた。
そんな最中、私の知識不足から困らせてしまったこと
ありましたよね？

25.
Storyboard (InterfaceBuilder) を操作するだけでは
実現できないことがあった
アニメーションや影をつけるところ、コードで色を指
定しているところ、など。コードも多少書けるとのこ
とだったので、できそうなところは書いてもらえたの
で助かった
(色の指定など)
複雑な実装部分は、やはり私一人では不可能でした…

26.
チームで協力。エンジニアもsketchを使い出した
episode3 挑戦 → 効果
「ガイドを引くのは大変でしょう。sketchデータを
くれれば自分で読んで実装します。」
byエンジニア

27.
sketchのガイド表示方法をシェアすると、
なんとstoryboadと操作方法が同一ということが判明！
sketch storyboad
いずれもoptionキーとカーソルの動きで表示される

28.
コミュニケーションツールが変わった
episode4 挑戦→効果
→
小難しいUI調整についてはXcodeでわかるところまでやって、
GitHubにメッセージを残しておく方法へと変化

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

30.
「アニメーションはこうしたい。scaleとalphaと…delayは…、
雛形組んでいただければ、あとは自分で数字調整しまっす！」
episode5 挑戦→効果
https://www.desmos.com/calculator/cahqdxeshd
Bezier Curves
UI実装するのに一番多かったやりとりです。
このコミュニケーションで「何をどうすんの？」
の部分でお互いのフラストレーションがなくなり
ました。
※左記はその時の事前のアニメーション共有方法

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

32.
結果
開発上でのフラストレーションゼロ
自信をもってリリース

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

34.
UI調整は一番最後にやるのが効率的。
開発終盤のプライオリティ調整でデザイン反映が
足切り対象になりやすくなっていることに原因がある。
なぜ？
↑
Xcodeを使って一番よかった気付きポイント

35.
「UI調整は一番最後にやるのが効率的」についての認識変化
before after
デザイン重要視されてない
という思い込み
製品の完全性を求めるには
UI調整は最後であるべき

36.
デザイン作業 エンジニア作業
よく思い返してみると、デザイン作業でも同じことしていた
UIUX設計
↓
議論・修正
↓
グラフィック調整
機能設計
↓
バグチェック
↓
UI調整

37.
エンジニアタスク
開発終盤
やることいっぱい
色んなものと戦ってる
デザイナータスク
残りのUI実装、ユーザーインプット
からの修正、storyboadで調整
自分の
知識・速度では
やりきれない部分
←ここが削り箇所
主に
Codeを書かなきゃ
実現できないUI
そのなかで、削ぎ落とされるUI調整とは？

38.
・Codeで実装するUIもいずれは自分の手で行えるように
・一見簡単に思えるUI調整でもCodeでなければ
実現しないときもあると予測できるように
今後の課題

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

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

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

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

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

44.
・エンジニアの仕事を知る＆挑戦することは
必ずアウトプットの向上につながる
・チーム全体の開発コストを大幅に削減できる
・デザイナーのやるべきことはまだ沢山ある
デザイナーがXcodeでUI調整をすることについて
まとめ

45.
Xcodeはどうやって習得したの？という質問をよくされるのですが、あくまでも私の
場合ですが、「入門編」とラベルが貼られるような書籍は買いましたが、ほとんど読
みませんでした。
最初にエンジニアからXcodeを勧められた時のことです。
「本は読まなくてもよい！Xcodeを触って覚えるのが一番早く習得できるから。」
なので、ひたすらstoryboadの定義設定と向き合い、エンジニアが書いたコードを見
て研究し、必要があれば開発者ブログを検索してコードをコピペして試してみる、の
繰り返しを続けました。
実際、本を読むより早かったと思います。というか、実践でやらなければいけないUI
調整は本に書いてないことばかりだったので…。
良い製品を生み出す為には、今こそデザイナーとエンジニアは互いの垣根を越え、
協力しあうことが求められていると思います。
隣席のメンバーとぜひその１歩踏み出してもらえると幸いです。
あとがき

46.
DeNAはクリエイターが社内で制作した作品を、 個人のPORTFOLIOやSNSに掲載することを尊重する。
より「個」が重視される時代に、一人でも多く「匿名のクリエイター」がいなくなるように。
http://dena.com/jp/recruit/career/portfolio/