iOSDC2020のday2に参加したセッションの内容と感想

# トークセッション

## [「それ、自動化できますよ」: note を支えるワークフロー大全 by laprasDrum](https://fortee.jp/iosdc-japan-2020/proposal/a6fcae29-405e-4923-aa45-8132a2444e60)
[iOS Dev Workflow Automation for note - Speaker Deck](https://speakerdeck.com/laprasdrum/ios-dev-workflow-automation-for-note)
zapierを使ってCIビルドを自動化した話

**感想**
結構、よくある話だが、実際に運用しているフローと組み込むまでの流れを聞けたのは参考になった
具体的な手順を紹介してくれたので、業務でも取り入れたい

## [XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する by 佐藤剛士](https://fortee.jp/iosdc-japan-2020/proposal/e6c39712-3efa-4f0c-8d9d-ecebdfcae820)
[XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する - Speaker Deck](https://speakerdeck.com/satotakeshi/xcuitestfalseturasawocheng-riyue-ete-iosahuriniuitestwodao-ru-suru)
PageObjectデザインパターンを導入した、UIテストの導入方法を紹介
UIテストを導入する判断基準から、実際にコードを紹介しつつ、実際に導入する手順まで、丁寧に解説

**感想**
実際に業務でUIテストの導入を検討したが、ログイン画面がWebだったので、うまく要素が取れず断念したが、Ask the Speakerで、まさに聞きたいことを質問してくれた人がいたので、非常に為になった。再度、UIテストの導入に挑戦してみたい
自社でもQAリソースが足りないことが多く、サービスがWebメインなのでアプリの優先度も高くないので、導入を前向きに検討するための情報を得られた

**メモ**
>**UIテストのつらさ**
UIは変わりゆくもの

>**UITestを導入した経緯**
UITestの対象、新機能？既存機能？
メルペイでは、既存
リグレッションテストは、２週間ごと
既存機能は安定していることが必要
リグレッションテスト300 自動化対象200項目　CIパス項目40

>**XCUITest入門**
AccessibilityIdentifier
クラス名や要素名を組みあわせる命名規則
Page Object Pattern
テストと画面を分ける考え方　Appniumが提唱するパターン
変更容易性向上　UIが変わっても、Page Object を変更するのみ

**Ask the Speaker**
**Q** WebでのUIテストどうしてますか？
**A** メルペイでは、Webはほとんどランディングページしかないので、UIテストは遷移したかどうかくらいしかチェックしてない
Webをテストする際は、waitは、10秒〜30秒かけた方がいい。結構、読み込みに時間がかかる印象
**Q** パーミッションのテストはどうしてますか？
**A** パーミッションは、XCUIアプリケーションで取れないので、システムアラート取得するようにしてる。トークでは省いたけどスライドに追加しました。

## [ここ数年間のタウンワークiOSアプリのエンジニアのチャレンジ by 石井　潤、元　亨周](https://fortee.jp/iosdc-japan-2020/proposal/3ea8c467-c58a-47a4-8e14-84b3c9653409)
大規模なサービスゆえの、いろいろな制限(制約)の中で、どのように改善していったかの話
デバッグモードの開発で手動テストの効率化をしたり、E2Eテストツール導入、クラッシュ率のモニタリングして99.9%を保つ運用、フルSwift化して品質・コストを改善したり

**感想**
自社の業務では、EdTechゆえいろいろな制約があるので、制約がある中で改善した話は、非常に共感出来て、その運用方法や手法は真似したい

## [組織構造の力学を操作して、アプリ開発プロセスを最大化させる by Masato Ishigaki](https://fortee.jp/iosdc-japan-2020/proposal/b0545970-a264-4f4a-b7de-0c1fc9887fbb)
[組織構造の力学を操作して、アプリ開発プロセスを最大化させる / organizational structure to maximize the development process - Speaker Deck](https://speakerdeck.com/i35_267/organizational-structure-to-maximize-the-development-process)
iOSアプリを開発する中で、生産性のバランス可視化したり意思決定プロセスの構築、開発体制の整備などを行って、新規事業開発で、市場投入までの時間を短縮した話

**感想**
ちょうど、今やってる業務でユーザーストーリーを作成し、その次にどう進めるかというフェーズだったので、非常に興味があり、実際にAsk the Speakerで質問もしてみて、いろいろ参考になった
iOSの話というより、もっと幅広い話になるが、個人的には前職では、そういったプロジェクトに関わることが多く、同じような課題感を持っていたので、過去にうまくいかなかったプロジェクトが、どう進めればよかったのかを改めて振り返ることが出来た
新規開発だと、機能を積み上げるインクリメント型で作りがちだが、ユーザーのストーリーにそったイッテレーティブ型で作るのが重要という話で、頭の中では分かってるが、図にすると非常に分かりやすいと思って、スムーズに理解できた

**メモ**
>リードタイムを最大限短縮する

>ユーザーストーリーマッピング
プロダクトバックログ

>ナラティブフローに沿って、行ってレーティブに作る
インクリメントでは作らない

>カンバンの可視化したほうがいい
WIP制限をかけてたほうがいい

>1番大事なのは、生産性の可視化

**Ask the Speaker**
*（ユーザーストーリーを作成したあとの流れについて知りたかったので）質問してみた*
**Q** ストーリーマッピングの中で、実際にUIデザインをする時にどの程度書き起こすのかと、その後の流れで実際に開発に着手するタイミングを教えてください
**A** ユーザーストーリーマッピングの時点で、がっつりデザインを作っていた。各工程でグラデーションがあって、初期の段階で、デザインも開発も早い段階で着手し、出来るところから初めていく。多少の手戻りはしょうがない。ワイヤーのデザインもガッチリ作っていた。ワイヤーが何のエピックをやっているか、設計のエピックが何をやっているかを、可視化するのが大事

## [実践！「みてね」における自動生成活用例 by 佐藤俊輔](https://fortee.jp/iosdc-japan-2020/proposal/9272d534-6261-4ba9-be62-3be1f4d5cd92)
[実践！「みてね」における自動生成活用例 - Speaker Deck](https://speakerdeck.com/ushisantoasobu/shi-jian-mitene-niokeruzi-dong-sheng-cheng-huo-yong-li)
Sourcery + Stencil を用いて「テストデータ」の自動生成をしたり、「DI」まわりのコードを自動生成した話

**感想**
SourceryとStencilというものを初めて知った
コードの自動生成については、Webのフレームワークではよくあるので、Xcodeでも標準で出来るようになるといいなと思いつつ、将来的にはこういう自動生成が普通になる可能性は高いので、早めにキャッチアップしておいたほうがよさそう
個人的に、印象に残ったのは、「頑張りすぎない。テンプレートを見てわかりやすいように運営する」

## [google/mediapipe で始めるARアプリ開発 by noppe](https://fortee.jp/iosdc-japan-2020/proposal/10e8ee31-d3b9-493f-87a8-4cf6169dad5d)
[google/mediapipe で始めるARアプリ開発/iOSDC2020 - Speaker Deck](https://speakerdeck.com/noppefoxwolf/iosdc2020)
mediapipeで構築したMLパイプライン(Graph)とARKitを連携して、ハンドトラッカーのフレームワークを作り、バーチャルなボタンを作成する話
bezelというビルドツールを使う
Xcodeでもビルドできる「tulsi」というものがある

**感想**
個人開発で、KinectやLeapMotionを使ったトラッキングのサンプルコードや、AR/VRのサンプルコードで遊んでいた時期がありかつ、iOSのVisionフレームワークも触ってみたことがあったので、非常に興味があるセッションでした
内容的には、バーチャルボタンをクリックするというシンプルなものでしたが、近未来を感じさせるようなものなので、とてもワクワクした
前職で、個人でHTC VIVEとHoloLensを買った強者がいたが、HoloLensはバーチャルボタンをクリックする体験が出来たので、これがモバイルデバイスレベルで出来るようになったのを感じるのは、とても嬉しかった

**Ask the Speaker**
きつねのanimojiは、プライベートAPIをハックしてだしたらしい

## [Apple Silicon への長い道 by hak](https://fortee.jp/iosdc-japan-2020/proposal/0188c283-2804-42cc-acb2-0287ec38ca57)
macOS/iOSデバイスのSoCの歴史を、細かに解説

**感想**
自身もmacOSとiOSデバイスを触り始めて、結構な年数立ってるので、興味深いセッションでした
ただ、1時間半あったので、途中、集中力が切れて、居眠りしちゃってた部分もあり、細かくは覚えてない
が、ハードウェアに興味ある方は必見

---
# LTセッション
LLDBはアプリ開発時に使うデバッガーツールだけど、Mac用のアプリであれば自ら作成したアプリでなくともアタッチすることができるそうで、LLDBでMac用アプリのどのような情報にアクセスできるので怖いよという話
## [本当はこわいLLDB by みやし](https://fortee.jp/iosdc-japan-2020/proposal/62a95cf9-1b1b-401a-8a1c-11c0490aad00)
[本当はこわいLLDB - Speaker Deck](https://speakerdeck.com/miyasakakazutoshi/ben-dang-hakowailldb)
Obj-Cだとハックできる
Swiftで書いたコードは、型・シンボルなどの情報はほぼ残らないので、実行中に制御できないが、Objective-Cでは、さわれてしまう

**感想**
iOS開発に携わって長いが、LLDBに関しては、あまり詳しくなかく、デバッグツールとしてはよく使っていたけど、ハックが出来るのは知らなかったので、確かに怖いと思い、よい情報を得られたのでよかった

## [iOS 13における Siri Shortcuts 最小実装+α by 明渡麻衣花](https://fortee.jp/iosdc-japan-2020/proposal/5c2cd2ea-f1dd-4dfa-b19e-1a07035572b8)
[iOS 13におけるSiri Shortcuts 最小実装+α - Speaker Deck](https://speakerdeck.com/myamada04/ios-13niokerusiri-shortcuts-zui-xiao-shi-zhuang-plus-a)
Siri Shortcutsの実装の仕方や考察、Siri Shortcutsの導入判断基準や検証する端末や検証方法などの話

**感想**
Siri Shortcutsについては、意外と使われているんだなと思った
具体的な実装方法を紹介してくれたので、比較的簡単に実装できそうなので、よさそうと思いつつ、シーンなどをイメージして実装しないと、利用されないどころか、逆に余計な機能になりうるなと分かった

## [xcrun Essentials by Yutaro Muta](https://fortee.jp/iosdc-japan-2020/proposal/5a9f8fa1-8c89-470b-b72c-502f3a4a6f66)
[xcrun Essentials - Speaker Deck](https://speakerdeck.com/yutailang0119/xcrun-essentials)
Command Line Tools Packageに付属しているxcrunの活用方法の話

**感想**
xcrunについては、最近ちょうど、CIで利用できるテストシュミレータの確認をするときに使って、その事例紹介だったので、内容には非常に共感でき、もっとコマンドを知りたいなと感じた

**メモ**
>xcrun とはなにか
コマンドラインから、Xcodeの機能を実行できる
>shim（コマンドラッパー）の一つ

>xcrun を使う例
CIで、利用可能なテストデバイスを確認する

## [Swiftで分かるSOLID原則 by 川口 航平](https://fortee.jp/iosdc-japan-2020/proposal/689dc929-5cbf-4ef0-a334-e4ef48aacd7d)
[SwiftでわかるSOLID原則 iOSDC 2020 - Speaker Deck](https://speakerdeck.com/k_koheyi/swifttewakarusolidyuan-ze-iosdc-2020)
SOLID原則とは何かという話から、SOLID原則を意識してソフトウェア開発を行えば，開発者にとって有益という話

**感想**
開発をしているとバグを埋め込む可能性にびくびくしながら何回も見直すことが多く、変更に強く理解しやすいシステムを作りたいというのは、常にあるので、SOLID原則を分かりやすく解説してくれたのはよかった
原則のいくつかは、見たことあるものだが、十分理解出来てない部分も多かったので、よく理解できた
特に、依存性逆転の原則については、最近、悩んでるところでもあったので、分かりやすく説明してくれたので楽しみながら学べた

**メモ**
>SOLID原則　変更に強く理解しやすいシステム

>単一責任原則
したがっていない例
FatVCがよくある例

>リスコフの置換原則
>依存性逆転の原則

## [SwiftUIとFlutter by tamappe](https://fortee.jp/iosdc-japan-2020/proposal/1618ed4e-197c-420b-8ab5-d66d27e3e40b)
[SwiftUIとFlutterを比較する - Speaker Deck](https://speakerdeck.com/tamappe/swiftuitoflutterwobi-jiao-suru)
とりあえず、Flutter最高という話

**感想**
SwiftUIとFlutter、どちらもキャッチアップしようと思って、できていないものであったので、比較しながら、Flutterのよさを確認できたのはよかった
SwiftUIとFlutterどちらを先にキャッチアップしても、損はしないな（もう一方の方の理解がしやすくなりそう）と感じた

## [100人以上の中高大学生にiOSアプリ開発を教えていて感じたこと by とし](https://fortee.jp/iosdc-japan-2020/proposal/14ab7993-c746-4582-8a10-fb61bb2a28a4)
[三年間で100人以上の中高大学生にiOSアプリ開発を教えていて感じたこと - Speaker Deck](https://speakerdeck.com/tosh7/san-nian-jian-de100ren-yi-shang-falsezhong-gao-da-xue-sheng-niiosapurikai-fa-wojiao-eteitegan-zitakoto)
プログラミング初心者にプログラミングを教える上で、注意するべきこと、うまく行ったこと、うまくいかなかったこと、どんな手助けが有効なのかなど、経験を通して学んだ話

**感想**
前職の初期に、開発チームを０から立ち上げ、未経験者5人、経験者は自分1人という経験をしたことがあるので、非常に共感できる内容だった
その時は、あまりうまくいかなかったが、このセッションで、何が悪かったのか

**メモ**
伸びる子、全く伸びない子がいる
↓
アプリが作れる→コードが書ける＋アプリのことがわかっている
↓
アプリらしさが欠如している

## [Feature Flagを適切に分類することでA/Bテストの運用コストを下げる by Takeshi Ihara](https://fortee.jp/iosdc-japan-2020/proposal/cfd5bd01-c940-42e6-b06c-66edf3bef6f8)
[iOSDC20200921: Feature Flagを適切に分類することでA/Bテストの運用コストを下げる - Speaker Deck](https://speakerdeck.com/nonchalant/btesutofalseyun-yong-kosutowoxia-geru)
新機能の表示の切り替えでKPIの変化を検証するためのA/Bテストを、Feature Flagという機能の有効・無効を切り替える機能で運用
それを、検証範囲や検証期間に合わせて、Release、Ops、Permission、Experimentという4分類にして管理コストを削減した運用を紹介

**感想**
A/Bテストが増えるたびに、Feature Flagの数を増やすと管理が大変になるので、4に限定して切り替えを行うというのは、理にかなっていて納得

## [CryptoKitとCoreBluetoothを利用したスマートキー開発 by saiten](https://fortee.jp/iosdc-japan-2020/proposal/184a1285-efd6-4448-bd2d-2ccf97f073bd)
[CryptoKitとCoreBluetoothを利用したスマートキー開発/iOSDC2020 - Speaker Deck](https://speakerdeck.com/saiten/iosdc2020)
リモコンキーのないクルマにArduinoとiPhoneを利用したスマートキーシステムを構築する過程で得た知見の話

**感想**
RxBluetoothKitというRxSwiftベースで作られたライブラリがあるので、それを使うと、簡単に実装できるのが分かった
実際のコード例があるので、実装のイメージが沸いた

**メモ**
>セキュリティ対策はを行わないと、簡単に車のドアを操作できてしまうので注意
その署名も、CryptoKitで簡単

## [Apple Low-Latency HLSを使った超低遅延配信について by meteor](https://fortee.jp/iosdc-japan-2020/proposal/1093b42e-e463-4bd5-ac0e-939669fdf0b1)
[Apple Low-Latency HLSを使った 超低遅延配信について - Speaker Deck](https://speakerdeck.com/yaminoma/apple-low-latency-hlswoshi-tuta-chao-di-chi-yan-pei-xin-nituite)
複雑なAppleのLow-Latency HLSの仕組みを紹介

**感想**
HLSは、一度、前職で動画配信の仕組みを作るときに扱ったことがあり（β実装まででリリースなし）、仕組みは難しくて、あまり理解できてなかったが、分かりやすく紹介していた

**メモ**
>iOS13だと、safariで使えない
iOS14だと、使える
サンプルコードあり

## [着信時氏名表示させたいエンジニア vs 簡単には着信時氏名表示できない電話番号 (iOS13対応版) by 栗山 徹](https://fortee.jp/iosdc-japan-2020/proposal/b3d9b32d-a0c8-4def-b3c5-c065852a6e9e)
CallKitを使って着信表示する際の、iOSの不具合なのか、実装にてこづった後、iOS13以降での注意点の含めて紹介

**感想**
CallKitは使ったことがなかったので、実例と苦労話を交えて聞けたのはよかった

# その他の見たセッションで感想
ここに書いてないセッションの感想を、以下のページに分けて、書きましたので、こちらもどうぞ
[iOSDC2020のday0に参加したセッションの内容と感想 - Qiita](https://qiita.com/yoko-yan/items/edf278db349f9baab179)
[iOSDC2020のday1に参加したセッションの内容と感想 - Qiita](https://qiita.com/yoko-yan/items/fe61fc8d89398f87d3dd)
[iOSDC2020に参加して３日間で36のセッションを見ました - Qiita](https://qiita.com/yoko-yan/items/adb3c55a82ac9c41f4f1)