こんにちは、投稿開発部の市川です(@masaichi)
主に、クックパッドiOSアプリの投稿周りの機能を担当しています。
はじめに
みなさんはiOSアプリを開発する際に、どうやってレイアウトを調整していますか？ クックパッドでは大体の場合は、デザイナーにZeplinなどでレイアウトの指示書を貰いエンジニアが実装するという流れで組んでいます。 しかし、このやり方の場合、終盤の細かなデザインの調整の際に、修正と確認が細かく発生してしまい、デザイナーとエンジニアの時間を細切れに使ってしまう、という問題がありました。
今回、この解決の手段として、終盤のデザインの調整をデザイナーさん自身にInterface Builderで調整をしてもらうトライを行いました。 10月頃、iOSアプリに追加した「みんなの投稿」機能を題材に、この過程と効果を紹介します。
なぜInterface Builderを触ってもらうことにしたのか
「終盤の細かなデザインの調整の際に、修正と確認が細かく発生してしまい、デザイナーとエンジニアの時間を細かく使ってしまう」という問題の解決として、時間を決めてペアプログラミングをする、というのもあります。 これも短い時間で集中して対応することが出来るのでうまくワークします。
とはいえ、この手段もエンジニアが実装をしてデザイナーが指示を出し、というやり方になるので、こだわりきれない点もあるのでは・・と考えていました。
そんな時、夏にあったiOSDCというカンファレンスで「デザイナーにStoryboardをお任せする技術」という話を聞いたことと、一緒に仕事をしているデザイナーさんからInterface Builderを覚えたいという話があったため、トライしてみよう、ということになりました。
みんなの投稿画面
今回対象にした「みんなの投稿」は以下のような画面です。
1つのタブの中身はUITableViewを使ったリストで、リスト中の1セルは高さも固定、表示する要素も条件で出たり消えたりしない、という画面設計になっています。
Interface Builderを使った最初のトライにはこのようなシンプルな画面が適してると考え、これを選択しました。
以下、実際に機能が取り込まれるまでに行ったことを書いていきます。 「デザイナーにStoryboardをお任せする技術」に沿った内容となっています。
1. ViewControllerとView, Autolayoutのことを教える
まずは座学とペアプロでViewController, View, AutoLayoutの事をざっくりと学んでもらいました。Interface Builderはグラフィカルで取っ付き易いツールだと思いますが、
iOSアプリケーションの構造を知らずに触っても、何が起こるのか想像がつかず、混乱するだろうと考えたからです。
事前に資料を渡し、ホワイトボードで図を交えて教え、ペアプログラミングをして実際に動かしてもらいました。
いきなり全部を覚えて貰うのは、新しいことが多すぎるので難しいと考えて、これは２回に分けて行いました。
それぞれを1時間〜1時間半くらいで２日に分けました。
本題に入る前に補足をしますと、座学がたったの2日で合計3時間というのはかなりすんなりと行ったと思っています。 その背景として今回一緒にトライを行ったデザイナーさんは 普段からCookpad本体のRailsアプリケーションのCSSやHTMLに関しては自ら修正してGitHubでPRを投げており、ターミナルでの作業や開発フローに慣れている。 また、その開発を行う関係で「手元にXcodeなどの必要なツールキットも揃っている」というのがあると思います。
ViewControllerとView
初回ではViewControllerとViewについて学んでもらいました。
大事な点は2つあると考えています。
- iOSアプリケーションで、
ViewControllerとViewがどういう役割で、どう見えているのか Interface Builder上ではそれらはどう見えているのか
1つめについては、View Controller Programming Guide for iOSに十分な内容があり、こちらを利用して説明を行いました。
具体的にはiOSのアプリケーションは1つの画面に最低でも1つのViewControllerがあり、複数のViewがViewControllerの持つViewの上に配置されることで、画面を構成している、というような内容です。
2つめについては、1つめの点を踏まえてペアプログラミングをしながら実際に手を動かして学んでもらいました。
題材はMaster-Detail Applicationにしています。初期状態で画面遷移があり、1つの画面に最低でも1つのViewControllerというのが動かしながら見せられるためです。
AutoLayout
次にAutoLayoutについてです。
AutoLayoutは制約をViewに与えることでレイアウトを決める、Appleの機構です。
ここでの大事な点は以下３点だと考えています。
AutoLayoutのレイアウトのための考え方Interface Builder上での設定の仕方Interface Builder上で発生し得るエラーとその対処方法
1つ目のAutoLayoutの考え方については、Auto Layout ガイドのAutolayoutの考え方のページに詳しく書かれています。
ホワイトボードで図や式を書きながら、AutoLayoutの制約に基づいたレイアウトの考え方を教えます。「デザイナーにStoryboardをお任せする技術」でもお話がありますが、数式や図を交えて説明をすると、すんなりと腹落ちをしてくれていました。
2つ目はInterface Builder上での制約の設定の仕方です
急に粒度の細かな話しになりますが、大事だと考えています。Interface Builder上での制約の設定は結構クセがあって混乱の元になるからです。(例えば、8px空けていたところを12pxにしたいと考えて、pinを選択して12と入れると、同じ属性に対する制約が複数出来てエラーになる、というのはありがちでわかりにくいミスだと思います)
ここからは、ペアプログラミングをしながら、実際のツール上で触って設定の仕方を教えています。
3つ目は、Interface Builder上で発生するAutoLayoutに関するエラーがどういうケースで発生するのかとその対応について教えました。
エラーの場合は、AutoLayoutが座標を決められない状態なので、エラーの内容を見て決められるように制約を設定しようとか、ワーニングは単に制約とInterface Builder上の位置がズレているので、制約か配置のどちらかを合わせてあげれば問題ないよ、といった内容です。
Interface Builderで制約を設定する過程でどうしてもエラーが発生する事があり、それぞれの対応方法を教えておくと、デザイナーが作業するときに、エラーに悩まされて不安になることがなく、良いと思います。
2. 実装
座学が終わったので実装に入ってもらいました。
エンジニア側で「あとはInterface Builderでレイアウトの調整をすればmasterにPRが出せる」という状態にまでして、 GitHubのissueにどのファイルを編集する必要があるのか書いて受け渡しています。
ファイルの受け渡しはFeatureブランチを切っておいて、それをpullしてもらう形です。 ファイルの内容の細かなところは口頭やSlackで説明しています。
渡したときには画面はこんな状態でした。
これをSlackや口頭で相談を受けながら整えていってもらいます。
3. PRを送ってもらう
整ったところで、FeatureブランチにPRを投げ貰いました。
xibのレビューも含めて行います。例えば、misplacedが残っていないか、下位互換を考慮すると厳しいものが入っていないか等。 一通りの修正をしてもらい、終わったところで、Featureブランチにマージします。 その後、エンジニアがFeatureブランチからmasterにPRを出し他のエンジニアのレビューも受けてmasterにマージしました。
効果
今まで終盤で起こりがちだった、「iPhone6では良いのだけど、iPhone5や4sではレイアウトを調整をしたほうが良い」というケースがあります。
ここに細かくデザイナーとエンジニアの時間を細かく使ってしまっていました。
しかし、今回はデザイナー自身がシミュレータで確認をしながら調整をしてくれたので、この問題が解消されました。
今回のケースは「iPhone5の場合にサムネイルが大きすぎる」という問題でした。
左のレシピ作者のアイコンを少し小さくする等の調整はAutoLayoutの制約を利用して、デザイナーさん自信が調整をしてくれています。
(※ セルの高さのみコードで調整しています)
| Before | After |
|---|---|
 |  |
感想と振り返り
実施後、KPTを用いて振り返りを行い、以下のことがでてきました。
エンジニア
エンジニアとしては、まず問題が解決出来たことも良かったと考えいます。
また自身のAutoLayoutへの知見も深まりました。leadingとleftの違いや、equal以外の関係性の使い所等。ついコードを書いて解決してしまっていたところを、一緒にAutoLayoutの制約でなんとか出来ないかを考えて解決できたのは、良い経験でした。
デザイナー
みんなの投稿のデザイン調整を行うことができ、Interface Builderを触れるようになりました。 目的が、リソースがいっぱいいっぱいのエンジニアの細かいデザイン調整の時間を減らすことだったのでそれを達成できたのは大きかったです。逐一エンジニアの席にいって「あと数ptずらしてください…あっやっぱり戻してください…」のような時間がかかるコミュニケーションが無くなり自分自身で調整して、シミュレーターで確認できたのは大きかったです。Interface Builderを使いこなせてないので、今後もInterface Builderが使える場面では積極的に触っていこうと思います。
課題
まだ簡単な画面をトライしただけなので「他の画面ではどうなのか」「結局のところデザイン確認がコードレビューに逆転しただけになってしまっているのでは」など、考えられる課題はたくさんありそうです。
また、デザイナーにInterface Builderを触ってもらうのでなく、エンジニアがSketchを受け取ってレイアウトを調整する取り組みもありそうです。 実際にフリルさんでは、その取り組みについて記事が書かれています。(フリルのiOSアプリ開発におけるエンジニアとデザイナーの作業分担について)
Sympliのような、SketchのデータをInterface Builderへいい感じに取り込んでくれるプラグインも出てきており、試してみたいです。
どの手段を取るにせよ、大切なことはエンジニアとデザイナーがお互いを尊重して歩み寄っていく姿勢だと私は考えています。
まとめ
今回のトライでは、目論見通りエンジニアもデザイナーも双方で細かな調整と確認で時間が取られることがなく、終盤の細かなデザインの修正が行えて良かったのではないかと考えています。
アプリを開発をする上での１つの事例として参考になれば幸いです。