Bonfire iOS #4に参加してきました

モバイルアプリエンジニアの山下です。
昨日はヤフー株式会社主催のBonfire iOS #4に参加してきました。

Bonfire iOS #4 - connpass

第4回のテーマは「UI」ということで、デザイナーとの協業の話からARKitのコアな話まで深みのある発表内容でした。
今回は簡潔なレポートと、いちモバイルアプリエンジニアとしての感想を共有したいと思います。

セッション内容

健康なStoryboardを考える　〜 Auto Layout、UIStackViewともっと仲良く！

内容
- Storyboardはごちゃごちゃやってたらできちゃう、もしくは Xcodeがいい感じにしてくれる
- できちゃうから理解が疎かになるが、ツラミが消えないし苦手意識が増える
- Storyboardを綺麗にするにはAutoLayoutをしっかり組むのが大切
- AutoLayoutには設定方法やプロパティが色々あるが意外と知らない人が多い
- AutoLayoutとStackViewを使って、UIの階層を意識して組むのが大切
- Storyboardを組む上でのTips
感想
- Storyboardのツラミからコードレイアウトに切り替える流れをよく聞きますが、参加者の約8割がプロジェクトに導入していて意外と多いと思いました
  - とはいえLCLの高速バス比較もまだStoryboardが捨てきれておらず、約8割のうちの1人に入っているので他の方もそんな感じなのかもしれません
- 個人としては健康的なStoryboardが組めてると思いました
  - デザイナーでなくてもSketchなどでデザインを作ったことがある人は健康的な組み方ができるのではないかと思います
- Storyboardを使えばUIの設計時間が短縮されて、効率が上がるのは頷けるのですが、そのためには厳密なルールと全員が健康的なStoryboardを組める環境が必要だと思っています
- LCLでは以下の理由で廃止に向けてリプレースをしているところですが、高速バス比較のような動的描画が少ないアプリは比較的Storyboardを活用しやすいですね
  - レビューしづらい
  - ダミーViewが発生しがち
  - 修飾を完璧に寄せないと破綻する

デザイナーｘエンジニアの共同UIづくり

内容
- デザイナーとエンジニアの協業
- デザイナー視点
  - UIを組むのが楽しい
  - ビルドやCIのエラー時をすぐに尋ねられる
- エンジニア視点
  - ピクセル単位のようなUIの細かい実装をしなくて済み、ロジックやリファクタに専念できる
  - 振る舞いなどの仕様をすぐに尋ねられる
- 業務の流れ
  - デザイナーがUIの実装をPRで投げる
  - エンジニアがフェッチしてロジックの実装を進める
  - テストは企画・制作・技術全員で確認
- デザイナーも変更しやすいようにStoryboardを使用
- WYSIWYGなStoryboardを心がける
感想
- デザイナーがUIの実装までしてくれるのはいいですね。必然的にViewにはロジックが無くなりそう
- スピード感を保つにはデザイナーが実装できない場面に遭遇した際にどの段階で踏ん切りつけるかが重要そうだと思いました
- 可能な限りStoryboardに寄せて運用しているとのことで、このルールをしっかりと守れば効率は上がりそうですね
- 業務の流れはLCLの夜行バス比較なびの開発の流れが同じですが、この流れをアプリ開発でされているのは珍しいと思いました
  - UI実装だけに特化したアプリエンジニアはいないと思うのでそうですよね

ユーザーインターフェースと非同期性について

内容
- iOS 11のProgressReportingからなぜ非同期にするのかについて
- 他の技術ではどうしているか
  - React
  - Dart
- 宣言的なフレームワークが流行っている
- これらでは非同期を同期的に扱っている
  - コード上は同期的な扱いだが、裏ではうまく非同期的に処理されている
- Marzipanはどうなる？
感想
- 非同期の実装は頭を悩ませるので同期的に扱えるのはいいですね
- Dartのコードは初めてみましたが、ぱっと見だとわかりやすそうな言語だと思いました（でもセミコロンがあるのは..）

ARKit + CoreLocation

内容
- YahooマップのARモードについて
- 開発時期は12月、特性上外でデバッグしなければいけなかった
  - めっちゃ寒い時期に外でバグがみつかるとツライ
- コード書いて、外に出てデバッグして、戻ってコード書くの繰り返し
- 座標の計算方法
- 足跡、看板、けんさくなどのわかりやすさと楽しさを含めたインターフェース
- 標準モード（地図）とARモードをすぐに切り替えられるようにしている
- 3Dオブジェクトの配置にはARKitよりもSceneKitの知識が必要
感想
- ARKitを導入したプロジェクトの話は初見だったのでとても参考になりました
- 位置情報を使う上に、ARとなるとやはりデバッグがツラそうですね
- それでも3Dオブジェクトを立てて空想の看板や、キャラクターを配置できたら楽しそうです
- 高速バス比較では現状導入の予定はないですが、リソースに余裕ができたら追加してみたいです

快適なUIを持つアプリを作るためにやっていること

内容
- 快適なUIを持つアプリを作るためにやっていること
  - 攻め - 高速に動作するUI・安定したUI
  - 守り - 攻めによって実現したUIの品質を継続させる（今回はこちらを中心とした発表）
- 目指すべき品質
  - ユーザにとっての普通はFacebook、Instagramレベルの動作
- InterfaceBuilderは一切使用せずコードレイアウト
- UIの不具合と呼べるもの
  - UIの塊、チラツキ、デザイン崩れ
- 動作確認の怠りから見逃しが発生するのでラクにする仕組みを導入
- Crashlyticsで例外を取得
感想
- 途中にアプリの動作映像がありましたがとてもぬるぬるでした
- "UIの不具合"は高速バス比較でも多く発生してしまっているので早く対応したいと思います
- 動作確認をラクにする仕組みは高速バス比較でも導入済みですが、デバイスサイズまで変えようというのは発想になかったです
- 例外を送る仕組みも同じく対応済みですが、ログの埋め込みが疎かになっていてなかなか活かせていないので改善していこうと思います

エクストリーム・プログラミング開発におけるUIテスト〜ライブコーディングを添えて

内容
- エクストリーム・プログラミングとは
- ペアプロでのライブコーディング TDD
- ペアプロのメリット
  - レビューをしなくて済むので全員が実装に専念できる
  - 隣に人がいるので会話できて楽しい
    - 以前はもくもくとやりたい派だった変わった
- UI実装の際はさらに後ろにデザイナーが立っている
  - Zeplinの透過機能を使って1px単位で確認してくれる
- ペアプロは新人向けというイメージだが、4~5年目の伸び悩んでいる方がやると自分では拾えなかった知識を拾える
  - 他人を知ることは己を知る
感想
- レビューをしなくて済む、テストを書けるというのはいいですね
- 手戻りの時間とハマっている時間が一番もったいない時間なので両方をすぐに解決できるという点ではとても良いと思いました
- 実は以前も別の勉強会で拝見したのですが、実際にやってみようとすると以下の問題がありました
  - いつものままだとタスクの粒度が大きすぎる
  - モバイルアプリエンジニアが現状1人なため、ペアプロの相手がいない
    - XCUnitテストを書くことに慣れていない
      - じゃんけん見積もりできない
  - 全体数が少ないのでペアプロの時間を増やしすぎると業務に支障がでそう
- 最後の点は慣れとバランスの問題だと思いますが、以上が解決できればとても有用な手段だと思いました