# iOSDC japan 2020に参加しました

6 min読了の目安(約4000字IDEAアイデア記事

iOSDC japan 2020に参加しました

https://iosdc.jp/2020/

OPENING

スポンサー紹介

今年のiOSDCはリモート開催でした。リモートでの勉強会・カンファレンスとしての知見が詰まった物になっていたと思います。

https://www.hasegawa-tomoki.com/blog/2020/09/23/iosdc-japan-2020/
*長谷川さんの作った収録システム凄すぎる。。

形式

トーク配信は事前に録画したものをニコニコ動画で流しながら(LTについてはライブ感を重視して生配信)、Discordでそれぞれのトークルームを立ててスピーカーと参加者が会話できたりする仕組みを導入していました。
生配信はトラブルが起きやすいので、事前録画の試みはとてもよかったと思います。
ニコニコはコメントがついてライブ感が出るし、弾幕もついたりして懐かしい気持ちになったのもよかったですね(コメントが匿名なので気軽にできるのがよかった)。
これからは配信や動画作成スキルをあげておくに越したことはないなと思いました。

個人的に興味を持ったトーク

面白かったトークや、あとで見返そうと思ったトーク

今日から分かるAVAudioEngineの全て & AVAudioEngineでリアルタイムレンダリング

AVAudioEngineを使った音声処理周りのトーク2つ。今の業務では扱わないテーマだけど、そういうトークを聴くことにこそこういう大規模なカンファレンスの価値があると思う。音声サービス流行ってるしね。

Xcode Preview でUIKitベースのアプリ開発を効率化する

https://speakerdeck.com/kenmaz/xcode-previews-deuikitbesufalseapurikai-fa-woxiao-lu-hua-suru-iosdc-japan-2020

プレビューでデザイン崩れなどをリアルタイムに確認しながら開発できるようになると手戻りが減って効率上がりそうー。すぐにでも導入してみたいと思いました。
短いテキストの場合、長いテキストの場合のレイアウト崩れがないか、一度にチェックできたりするのとか良いですね(SE系端末での崩れとかよくありますね)
iOS13未満もサポートしている場合の対処法なども述べられていてPerfectでした。

エラーアーキテクチャ設計について考える

https://speakerdeck.com/kichiemon/thinking-about-error-architecture-design

エラーを丁寧に列挙していくことで可読性の担保、考慮漏れやバグの混入を防げる良い取り組みだと思いました。
🧑「こういうエラーの時アプリの表示どうなるんだっけ?」
🧑‍🦰「調べます!(コード読む)」
みたいなシーン業務だと割とあるので、網羅されてると恩恵を受ける機会は結構ありそうだなと思いました。

*「優れたアーキテクチャはユースケースを強調し、周辺の関心ごとからユースケースを切り離す」
3つのポイント

新規機能開発からモジュール分割を始めてみる

https://speakerdeck.com/rizumi/xin-gui-ji-neng-kai-fa-karamoziyurufen-ge-woshi-metemiru
ノハナAppでのモジュール分割を始めた話。
うちとはモジュールの切り方が違ったのが面白かったです。
うちの場合は全部テスト書く前提and新規だったので横に切ったけど、縦に切ると共通部分をさらにモジュール化してimportみたいに依存グラフが複雑になりそうなのが気になるところ。
機能ごとのコンフリクトを技術的制約で防ぐか、企画の運用で防ぐかみたいな部分だけ見れば前者の方がかっこよく感じるけどどっちがコスト低いんでしょうか。

iOSリジェクト戦記 ~リジェクトされないための課金ページ~

https://speakerdeck.com/hcrane/iosdc2020-iosriziekutozhan-ji
配信でも飽きさせない作り込まれた発表資料がまず面白い。
丁寧に他社比較なども行っていて実は内容もとても良い。
最後に触れていた
・Apple審査でガイドライン違反でバグ修正が遅れることはなくなる
・次回の申請に問題を持ち越せる
というのが今後の申請で期待。どこまで適用されるかは謎。

テストコードが増えるとバグは減るのだろうか? - 「0% → 60.3%」で見えた世界の話

https://speakerdeck.com/ahiru/does-more-test-code-mean-fewer-bugs
ZOZOでのテスト導入の話。
QAチーム(自動化テスト含む品質担保全般を担当)欲しいですねぇ。メルカリとかにもあるけど、うちだとそれぞれのサービスにつきどれくらいQAチームが存在してるものなのか気になる🤔(フリマBEにはQAチームあります)
*QAチームって役割として、プロダクトのテストだけじゃなくて開発プロセスの向上やフィードバックみたいな部分も場合によってはみるらしく、うちにもちゃんとそういうチームあるといいんじゃないかなぁとかは思いました。

https://speakerdeck.com/ahiru/does-more-test-code-mean-fewer-bugs?slide=33
取り組みとしてチーム内レビュー良さそう。コンフルじゃなくてFigmaとかみんな自由に編集できるツールの方が良いのではと思ったり。

https://speakerdeck.com/ahiru/does-more-test-code-mean-fewer-bugs?slide=75
UIテストはコスパが悪いので個人的には好きではないですが、
DIでモックをさして同じ画面のSnapshotテストを導入しておくのはありだと思った。(テストは未来のために書く、を思い出した)

4年間運用されて表示速度が低下した詳細画面を改善する過程で得た知見

https://speakerdeck.com/martysuzuki/iosdc-japan-2020-day-1-track-b-10-50
AbemaTVの地道な画面表示速度改善。
数値に届いてるかまで聴けるとなおよかったですが、こういう地道な改善もやりたい。
今のフリマがやりそうな雰囲気はないですが、手を付けないとヤフオク化してやばいと思う😇

Flutter移行の苦労と、乗り越えた先に得られたもの

https://www.slideshare.net/KeisukeKiriyama/flutter-238560064
じゃらんでiOS/Androidの一部モジュールにFlutterを導入している話。
地雷を踏みぬいていく覚悟が必要そうですが、工数削減という観点で見ればいいんでしょうか?
なんとなく開発人員やコミュニケーションコストは2/3くらいにはなりそうですよね。(半分にはならなそう)
チームにFlutterやりたいエンジニアが増えれば導入もありなんですかねぇ。

その他感想

https://photos.google.com/share/AF1QipPUjw9gpTsOSc9O2pvQFNvAPfH_lJh3danXT-QGVnzKhuc2z9JCxeh1KUekPcOpNw?key=SDM0OXJNNmc5eVBLdEpoNDQtYnFjZGZCMm9WaV9R

ノベルティグッズが届くと不思議とiosdc今年もしっかり見るぞ!みたいな気持ちになったし、リモートだからこそ気楽に見れる反面視聴のモチベーションも低下しがちなのでモチベ上げる仕組みはちゃんと考えていくのだいじ。

あとパンフレットでスポンサー各社のページがあるんですが、うちは採用のさの字もなかったのが一社員としては非常に気になりました。人足りないってよく聞くけどなぁ?🤔笑

リモート開催ということで東京に来れない遠方の人たちも参加できるようになったのはコミュニティとしてはとても良いことですね。今後もしばらくはこういう形式でのカンファが増えていきそうだなーと思いました。