UIデザイナーがSwiftを学んでUIを実装したら生産性が爆上がりした
まいど〜。dely株式会社（レシピ動画アプリ「クラシル」を作っている会社）でUIデザイナーをしているうっくんです。
この記事は毎年恒例の「dely #1 Advent Calendar 2020」の10日目の記事です。やっていくぜ！ウェイウェイ！（今年入社したので、まだノリがわかっていない）
昨日はnozaさんの良いレシピ検索体験とは？"選ばれた"を考えた話でした！
nozaさんはAndroidやiOS、Webフロント・バックエンドなどなんでもこなせるマルチなエンジニアさんです。現在は、検索機能の改善を担当するチームでPdM(プロダクトマネージャー)として、技術面のみならずユーザー目線でプロダクト開発を引っ張っていく役割を担っています！
このように、delyでは職種や職能を超えて、ユーザーのためであればなんでもチャレンジできる環境があるなと思います。
もう一つの記事はCXOのtsubotaxが開発体制をSquad化してきてわかってきたコツと課題を書いてくれました！
特定の課題解決に特化したスモールチーム（=Squad）を組織して、流動的にチーム編成を組み替える手法を採用しています。
ユーザーを置いてけぼりにした個人プレーや政治のための議論が起こりにくく、一つのゴールに向かってチームプレーで協力しやすくなるので、この方法はメリットが大きいと思っています。
delyの他の記事は以下のリンクからから見れますので、よろしくお願いします。
さて今回は、UIデザイナーがSwiftを学んでiOSアプリの開発にコミットできるようになったらチームの生産性が爆上がりした話を紹介してみたいと思います。デザイナーがコードを書けるようになることで様々なメリットがありますが、実際にどこから始めればいいかわからない人は多いですよね。そういった方に少しでも参考になれば幸いです。
作っているもの
レシピ動画アプリであるクラシルのネットスーパー機能のデザインを担当しています。
レシピに必要な食材をオンラインで購入して自宅に届けることができる。イオンネットスーパーとの連携で実現した機能。
この機能ですが、先日ついに公開することができました。今は、iPhoneのみのサポートとなっていますが、ぜひ使ってみてください。
コードを書き始める前のスペック
本格的にSwiftのコードを書き始めたのは、5ヶ月前ぐらいです。Apple公式のチュートリアルなどはやったことがあったので一応Xcodeは触ったことがある程度でした。
現在は、画面レイアウト、スタイル（色やフォントサイズ）、テキスト（文言）など、アプリの中でも特にロジックが絡まないフロント寄りの部分をコードを書いて実装したり、変更ができるようになりました。
プロジェクトが始まる前のスペックはこんな感じでした。
職業：UIデザイナー
プログラミングスキル：HTML/CSSはできる。JSもチョーットだけ分かる。SwiftとかReactとかチュートリアルぐらいはやったことあるけど、仕事では使ったことがない。以前delyで開発していたWebのプロジェクトでERB（Rubyが使えるHTMLみたいなやつ）を少し触っていました。その時にGitも覚えました。
コードを書き始めて生産性が爆上がりした
コードを書いて実際に製品にコミットできるようになったことで、以下のようないいことがありました。
1. デザイン的な調整をいちいち依頼しなくて良くなった
「ここのマージンもう少しでかくできますか？」みたいなやりとりに時間を使う必要がなくなって、見た目上の調整を自分でできるようになりました。
Before
デザイナー「せや、UIカイゼンしたろ。」
（Figmaを更新）
デザイナー「でけた。エンジニアに共有せな。」
（エンジニアに説明）
エンジニア「👨💻ここのマージン、左右でずれてますけど、どっちが正解ですか？」
デザイナー「うぅ・・・」
（Figmaからやり直し）
After
デザイナー「せや、UIカイゼンしたろ」
（Xcodeポチポチ）
デザイナー「プルリク書いといたで！」
エンジニア「ヨシ😸！！」
まあ、例は少し盛ってます（Beforeみたいに雰囲気は悪くないです笑）が今までは、まずエンジニアとのコミュニケーションだったり、優先度の相談からスタートしていたのが
カイゼンアイデア→実装する→気が向いたらFigmaに反映する
というシンプルなフローになりました。
2. エンジニア陣が、より高度な実装に時間を使えるようになた
エンジニアがデザイン周りの実装をあまり気にしなくてよくなったことで、ロジックやアーキテクチャ部分などより深いところに時間を使えるようになりました。
3. クライアントサイド（iOS）内での分業ができるようになった
ロジックや画面遷移ができたら、見た目の調整はUIデザイナーの僕にバトンタッチするようなクライアントサイド内での分業もできるようになりました。
4. サーバーサイドエンジニアもクライアントサイドに手を出しやすくなった
クライアントサイドの分業が可能になったことにより、「Swiftもかけるけど、レイアウト調整とかUIの実装は得意じゃない」というサーバーサイドのエンジニアの方もiOSの開発をサポートできるようになりました。
5. UXの磨き込みが可能になった
限られたリソースの中では新機能やバグ潰しが優先されて、ボタンがアニメーションしたり、ハプティックフィードバックを仕込んだり、キーボードショートカットに対応するなどの使い心地に影響するような細かいカイゼンは後回しになりがちでした。そのような細いUXの磨きこみをデザイナーができるようになりました。
このように、デザイナーがほんの少しでもコードが書けるだけで、チーム全体としてのアウトプットが明らかに上がったと感じています。僕が一人で作れるものはたかが知れていますが、他のメンバーとの相乗効果が出るため、初心者プログラマーが1人加入しただけではない変化があったと言えます。
勉強したこと
そうは言っても、コードが書けるようになるまでに覚えなければいけないことも多かったです。その中で特にポイントとなった部分を紹介します。
Git
GitはSwiftを書き始める前に覚えたのですが、業務としてコードを書く上で最初に難しいと思ったポイントでした。
アプリ内の文言を修正するだけなら全文検索をかけて、それらしきテキストを書き換えれば一見誰だってできそうですが、実際はGitがあるのでそうはいかない。
ほとんどのソフトウェア開発プロジェクトではGitなどのソースコード管理をしているので、まずこれを覚えないことにはプロジェクトに参加することすらできないです。
しかもこれが結構むずい😂
僕は早々にコマンドラインからGitを使うのを諦めました。SourceTreeというGitをGUIで操作するクライアントを使っています。
それを使ってもむずいので、Gitはめちゃくちゃむずい。
特に、ソースコードを落としてくる（＝クローン）一番最初のところが既にむずい。SSHキーみたいなのが必要なのですが、それの認証に失敗したり、いきなりつまずく。結局僕はエンジニアさんたちに助けてもらって何とかソースコードをローカル環境に引っ張ってこれるようになりました。みなさんもエンジニアさんに助けてもらいましょう。
Swift
Swiftの文法は何となくしか勉強していません。Gitという最大の壁をクリアしたら、あとは実際のコードを見ながら、分かるところからやってみるというのが一番の近道かも。細かい文法を頭に叩き込んでも、実際の現場ではNSLayoutConstraintsだとかview.layer.opacityのようにiOSのライブラリやAPIを覚えることの方が重要だったりします。
この辺はエンジニアさんにめちゃくちゃ聞きまくりました。Appleのドキュメンテーションを読んでも例文がなさすぎて使い方がよくわからない・・・。
俺「これをこう変更したいんだけど、ここのコードですよね？（😙簡単そうやなwww）」
エンジニア「👨💻違います。」
俺「えっ？」
そんなことを何度も繰り返しました。
iOS開発の場合、UIのデバッグビューが結構便利で、それをうまく使えばどこのコードを見るべきか分かったりします。
無駄にかっこいいXcodeのUIデバッグビュー
ViewControllerとView
iOSのUIを触る前は、なんとなく「HTML・CSSみたいなノリでパーツ並べたり、レイアウト変更したりできるんでしょ？」と思っていたのですが、全然違いました。
Swift（というかUIKit）の世界では、ViewControllerというウェブの世界とは全く異なる概念があって、これを理解しないと話が始まりません。
ViewControllerは1つのViewを管理している小っさいおっさんです。
ViewControllerは1つのViewを持っていて、そのView中に描画したいボタンやテキストなどのオブジェクト（これをSubviewという）を配置していくことでUIを実装していきます。画面遷移をするときはこのおっさんの代わりに新しいおっさんが乱入してきて、そいつを抜擢すると画面が変わるっていうイメージ。
AddSubview
ViewにSubviewを追加するメソッドがAddSubviewです。
Subviewは初期値では左上の0,0点に配置されるところはHTMLとも似ていますが、普通にSubviewをどんどん追加していくと、すでにあるSubviewの上に新しいSubviewが重なるように描画されるのが大きく違うところです。下に積んだり横に積んだりするためにはStackViewやAuto Layoutという仕組みを使います。
StackView
StackViewはFigmaのAuto Layoutのような物で、オブジェクトを縦や横に積んでいくためのViewです。少しクセがありますが、CSSのFlexやFigmaのAuto Layoutに近いのでデザイナーとしてはなじみやすいかもしれません。
AutoLayout（コードで）
僕が担当しているプロジェクトでは、UIを全てコードで記述する開発方法を採用しています。XcodeではInterfaceBuilderと言って、GUIでUI部品を配置して、コードとつなげる開発方法もあるのですが、こちらは採用していません。
となると、コードでボタンの配置を記述しなければいけないのですが、このために必要なのがAutoLayoutです。考え方としては、FigmaのConstraintsと似ていて、「どのViewのどのエッジに対して整列するかというConstraint（制約）」を記述していって、その条件が満たされるところにボタンなどのViewが配置されるという仕組み。
Auto Layoutをコードで書いたときの見本はこのようになります。
NSLayoutConstraint.activate([
titleLabel.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
titleLabel.leadingAnchor.constraint(equalTo: view.leadingAnchor),
titleLabel.trailingAnchor.constraint(equalTo: view.trailingAnchor),
actionButton.centerYAnchor.constraint(equalTo: view.centerYAnchor),
actionButton.centerXAnchor.constraint(equalTo: view.centerXAnchor)
])titleLabelというラベルと、actionButtonというボタンがあって、それぞれViewのこの辺りに整列しといてや〜
というような意味になっています。
アニメーション
Swiftでアニメーションを書くのはとても楽しいです。ProtoPie、Keynote、AfterEffects、Motionなどのプロトタイピングツールやモーショングラフィックソフトを使ったことがある人ならコードを読んでなんとなく理解できると思います。
僕のZennブログでサンプルのソースコードを公開しているので興味があれば覗いてください。デザイナーの方でもXcodeさえ使えれば動かすことができると思います。
まだできないこと
いろいろできるようになったことや、良くなったことを書きましたが、逆にまだまだできないことも多いです。
ロジックの実装
条件分岐があるような画面の表示はまだ難しいです。状態をどこで管理するのかとか、データを永続化するのであればどこでやるべきなのか、など。
データの実装
CollectionViewなど、データをUIにマッピングするのがむずいです。
ボチボチ勉強しつつ、こう言ったこともできるようになれば良さそうですが、もっと得意なエンジニアさんがいるので、彼らがこう言った部分を担当して僕でもできることは僕がやる、というスタンスで開発できるようになっただけでも生産性やモチベーションの向上につながると思っています。
集まれ！エンジニア＆デザイナー！
delyではエンジニア・デザイナーの採用活動をゴリゴリに行っているみたいです。採用ページや、開発チームのメンバーが技術的な話をするTechTalkというオンラインイベントも開催しています。delyの開発チームにご興味がある方はぜひご覧ください。
ほなまた〜！
いいなと思ったら応援しよう！
