2020年1月30日にAbema Towersで開催されたサイバーエージェントの勉強会CA.swift #11に参加してきました 。トークも面白かったのですが、パネルディスカッションも面白いなと思って文字起こしをしたので公開します。（何か書けないことがあったり公開できない情報や誤りがあればご連絡ください）

文字起こし

服部(モデレーター)
はい、よろしくお願いします。
AbemaTV所属の服部と申します。AbemaTVでiOSアプリの開発をしていて、もりしの話であった第二世代から第三世代の途中ぐらいまでいました。テーマとして3年後のアプリ設計を考えようというのを大テーマとして話していきます。事前に質問を送って頂いて、みんなが興味あるところをピックアップしてそれをぶつけていこうと思ってます。
軽く下地作りとして、3年後のアプリ設計を考える、難しいお題ですよね、2023年、iOS 16、iPhone 14、または14sだろうと考えてるんですけど、3年後を正確に予言するゲームではなく、当事者としてこういうスタンスで対応していきますというテイストになると思います。
単語を拾って記録に残そうというよりも、文脈を汲み取って頂いた方が楽しいかなと思います。
早速始めていきましょう。

Q.1 RxSwiftやReactiveSwiftからCombineへの移行方法は？RxSwiftはオワコン？

3年後を見据えてRxSwiftを使い続けていいのか？

松舘( @d_date )
皆さんの視線が非常に怖いのでもう少し和やかにやりたいなという気持ちです（笑）ちなみにCombine移行した人います？
(0人)
RxSwift使い続けてるんですよね。多分ReactiveSwiftからCombineへの移行は結構スムーズにいくと思うんですよ。なぜならResultの取り扱いですね。独自のエラー型を定義できるのはReactiveSwiftの特徴で、RxSwiftは基本的に標準のエラー型をキャストして扱っていくので、そこが明確にCombineとは異なりますと。
とはいえ、Swift標準のResult型もエラーをそのままコンファームして使うことができるので、その辺の扱いをどうするかぐらいが懸念。
後のオペレーターは今度try! SwiftにくるShaiっていうCombineとRxSwiftの比較記事を書いている人がいるんですけど、彼の記事を一読すると、RxSwiftのsubscribeがsinkに対応するとか、そういうのが一通りわかるようになっているので、まだCombineを触ってないっていう人はまずそれを読むとCombineとの違いのイメージが湧きやすいのがあります。
Combineの話でいうとBackpressureっていう概念があります。この話もtry! Swiftにくるシャイが喋ってくれるのでそれを聞いてもらうのがいいんですけど、稲見さんが去年のDeNAやったでCombineゴリゴリキャッチアップ会でBackpressureとは何かを喋ってくれているので、その辺を見てキャッチアップすると、まず、CombineとRxSwiftの違いがわかるので、それで置き換えてられていくところを置き換えていくのがいいんじゃないかなぁというのが僕の意見ですが、皆さんいかがでしょうか？

服部(モデレーター)
結構Combine移行に乗り気で、移行手段もあるし、Combineにしかない機能もあるからポジティブに捉えて、折を見て移行していくスタンス？

松舘( @d_date )
そうですね。ただ、今言ったBack Pressureに関してはiOSのユースケースが全く見えてないので、一旦ガン無視して愚直にオペレーターを置き換えていくだけで僕は十分かなと思います。

服部(モデレーター)
一回Combineを使ったAWAの意見とかもしあったら聞きたい

佐々木(AWA)
そうですね。特にこれ以上言うことないなと思ったんですけど（笑）Combine使った感想としては、もともとAWAはRxで、Rxと比べて支障はないかなと、ただ、便利オペレーターみたいのが少ないので、それらを自分で作っていくしかないっていうのが、もう少し充実してくれたらただただ嬉しいなというところなんですけど。まぁ、ちょっとRxも膨らみすぎてる気もするので、最小限で済むみたいなコンセプトなんだったらそれもそれでありかなぁ、でも便利な方が嬉しいなぁ、というところです。

松舘( @d_date )
それで言うと一個多分不便に感じるところはですね、RxSwiftを使うメリットの一つはRxCocoaの存在なんですよ。UIとReactive Programmingの取り扱いはRxCocoaで実現されているんですけど、それに対応するものは今のところCombineには無いので、CombineをUIKitに入れるとなると結構大変だと思います。
ただ、SwiftUIとはかなりのインテグレーションが進んでいるので、SwiftUIと合わせて使うのならCombine一択になるかなって感じですね。

服部(モデレーター)
なるほど。わかりました。AWAとかiOS 9サポートってさっき聞いてびっくりしたけど、Watchの方でだいぶ冒険をしたプロジェクトだったんだなぁと思いました。
実際に何個かオペレーターをカスタムで実装したっていうことですか？

佐々木(AWA)
そうですね。ちょっと今は何を実装したかすぐには思い出せないんですけど、足りないものは結構あったので。後、あるけど名前が全然違うくて全然見つけられなかったっていうのも後から見つかったりしています。
すごく不便に感じることはないけど、あれがあれば便利なのになーが無いといった感じです。

服部(モデレーター)
なるほど。了解です。AbemaTVとかで開発10人いて、Combineをどう取り入れようとか、話題が出たりしていますか？

森下(AbemaTV)
今のところ検討に上がってはいないですね。AbemaTVはまだiOS 11以降をサポートしているので、結構先になるかなと思っています。
ただ、iOS 13以降サポートになった場合に、Combineが使えるといいなという風には思っていますね。

服部(モデレーター)
なるほど。了解です。次のトピックいきましょう。

Q2. 技術構造の決め方や設計を決める過程を学びたい

服部(モデレーター)
これはおそらく二つあると思っていて、これまで開発を続けていて新しい技術が出てきた場合と、スクラッチでやる場合と二つあると思うんですけど。
Amebaのリファクタの過程で、何をどう見て決めたらいいんじゃっていうのが自分でも疑問なんですよ。
銀の弾丸は無いって皆いうけどとはいえ決めなきゃいけないじゃ無いですか。

三木(Ameba)
人それぞれ決め方はあると思うんですけど、僕とかだったらサービス特性に一番合っているアーキテクチャでっていう軸で見てっていう感じにしますかね。
例えば、MVCとかも全然いいアーキテクチャだと思ってて、別に作り方次第で悪い構成にはならないかなと思ってます。
どちらかというとサービスの仕様とか機能が膨らみ上がったことによってModelとViewとControllerだけの構成ではなかなかうまくいかないところとか（状態をすごく持ったり）という背景を元に色々生まれてきてると思うんで、自分たちのサービスがどのアーキテクチャを選定したら良さそうかっていう軸で見るのがいいかなぁと思います。

服部(モデレーター)
決める過程で実際三木さんは周りを巻き込んだ感じでしたか？

三木(Ameba)
そうですね。僕一人で決めるっていうよりはチームを巻き込んだっていう形になります。
活発に議論して、設計に対してちゃんと向き合ってる人がある程度いるようなところで経験を積むっていうのが一番いいかなと思います。
自分の考えを話した上で、相手がどういう風にそれを捉えてくれて、それに対してどういう風に反応がもらえて、じゃあここはどうしていかなきゃいけないかっていうのを考えるっていうのが一番いいかなと思っています。個人的にはですね。

服部(モデレーター)
なるほど。わかりました。ちょっと色々個人的に聞きたいなと思ったことを突っ込んでいこうと思うんですが、松舘さんがComposable Architectureを組んだというところで、これは新規ですか？それとも既存のリプレースですか？

松舘( @d_date )
新規ですね。

服部(モデレーター)
どう考えてどう決めたみたいなのがありました？

松舘( @d_date )
まずは、SwiftUI・Combineの到来が決まってるというのはもう既に認知されている状態で、将来どこかで置き換える、もしくは部分的に使うことがあるだろうなというのを見据えて、その辺でも生き残っていけそうなものを探していたのと、シングルストアでは使えるものに倒しておいた方が、ずっと自分でメンテしやすいなというのと、他の3人が話したようなアーキテクチャのぶっ壊しみたいなことは多分起こらんだろうというのを見据えていたので、まぁまさにこれがぴったりはまったなという感じですね。

服部(モデレーター)
なるほど。自分の裁量があって、周りを見渡して、これなら決断のタイミングを遅らせられるというか、負債が無いみたいな観点で決めた？

松舘( @d_date )
一番の理由は僕が今一人でやっているので、自分の好きなものを使えるというのが一番強いです。ぶっちゃけ設計は自分の好きな通りにやるというのが一番いいので、僕はそれで選んだという感じです。

服部(モデレーター)
なるほど、了解です。Abemaとかで三段会変遷してますけど、どういう過程でしたか？

森下(AbemaTV)
僕が入ったのは二世代目からで、Unioを導入した経緯のところまでしか分からないのですが、経緯でいうと基盤チームという（Abemaは人数が多いので）本質的な技術課題を解決するためのチームがいまして、そこで課題について議論し、優先度が高いものに対して解を出してきた。

服部(モデレーター)
そうなんですよね。Abemaは10人いるから、2人ぐらいはそういう改善を専門にできるんですよね。

森下(AbemaTV)
そうなんですよね。そこで出された解を全体に共有してコンセンサスをとって導入した経緯があります。

服部(モデレーター)
そうですね。自分も思い出してきました。プロトタイプを説明する会が催されて、このような課題を解決して、価値があるというのを皆で理解して、導入進んでいくという経緯を思い出しました。
AWAのところでフルスクラッチのところですごく自由度が高いのでどう決めたかと思って後で聞こうと思っていたが、割とスライドの中で説明していて、6種類ぐらいの中から最終的にFluxに決めたというような過程も説明してもらいましたけど。
Reduxとか結構メリットがあるけど、ここが合わなかったというところをもう一段階聞きたいなと思ったりしたんですけど。

佐々木(AWA)
合わなかったというほどReduxに詳しくなれていないというのが結構デカくて、Reduxをしっかり理解していればできたんだろうなとは思っています。
ただ、全員がReactive初めてで、プロダクションレベルのコードを書いていくみたいなところで、ハードル高すぎてしまったら逆にアーキテクチャが壊れてしまうんじゃ無いかという懸念があったので、なるべくMVCから近目な方がいいかなというのがありました。
MVVMも検討したんですけど、やっぱり単方向のデータフローを作りたいよねという話が出たので、間を取ってFluxとか。
ちょうどView Fluxを使ったっていう話をしたんですけど、作者が社内にいたので、知見を色々聞いて、これだったら使ってみようかという結論に至っています。

服部(モデレーター)
なるほど、わかりました。ありがとうございます。そろそろ次のトピックに行ってみましょうかね。

Q3. FlutterやReact Nativeなどの開発環境とiOS単体での開発での設計方針は将来どのように変わってくると思いますか？

結構重めの質問ですね。Flutter最近話題になってますけど、どういう風に捉えているかっていうのを聞いてみたいなと思っていて、
AbemaでFlutter、React Nativeの話とか具体的に何か出たりしてますか？

森下(AbemaTV)
マルチプラットフォームという観点でいいんですかね？Kotlin Nativeでコードの共通化を検討したことはありますね。
ただ、Abemaでいうと結構出来上がってきたプロダクトなのでマルチプラットフォーム前提の設計じゃ無いところで、なかなかコードを共通化したところでメリットが弱いなという結論に至り、導入は今のところ予定は無いですね。

服部(モデレーター)
割とガチで検討して見送ったという感じ？

森下(AbemaTV)
そうですね。活躍する場面が今のところ無さそうといったところで、頑張って使うところも無いかなぁという話になりました。

服部(モデレーター)
わかりました。松舘さんFlutter、React Nativeの辺りはどのように捉えていますか？
（技術顧問をされていていろんな話を聞いたりということもあると思うが）いろんな側面から聞いてみたいと思います。

松舘( @d_date )
React Nativeを採用したい動機って我々ネイティブの話ではなくて、Web（普段Reactを触っている）を普段やっている人が、ネイティブに入る障壁を下げたいという側面の方が強いと思っていて、そこで使える技術要素をそのまま生かすというところがReact Nativeには少なくともありますと。
Flutterに関しては、言語がDartというFlutterでしか使ってないような言語を使って、iOSもAndroidも両方やっていこうというところで、これも日本で流行りすぎてるなという印象を持っているんですけど、それも日本のネイティブ人材がちょっと足りないところから起因してるのかなと個人的には思っています。
キャッチアップする分にはやってもいいと思うんですけど、iOSをネイティブでSwiftで書けているうちは、個人的な印象としては今わざわざ使わなくていいんじゃ無いの？と思っています。

服部(モデレーター)
設計方針まで話を踏み込むと、ネイティブオンリーで考える設計方針と、多少マルチプラットフォームに対応可能なものを入れ込む場合と、設計方針という意味で変わってくるかと思うか否かという点ではどうですか？

松舘( @d_date )
設計方針で話をすると、まずはそれぞれのプラットフォームのベストプラクティスに則るというのがまずは一番いいと思うんですけど、FlutterでいうとBlocだし、iOSのベストプラクティスってなんだって話でいうと色々あると思うんですけど、流行的にReactのVirtualDOMみたいな概念を用いたアーキテクチャみたいなものが、SwiftUIがまさにそれだと思ってるんですけど、その辺の流行りを押さえつつ、iOSで何をやっていくべきかっていうのを考えるというのがいいんじゃ無いかなぁと。

服部(モデレーター)
設計っていう観点だとネイティブをきっちり理解した上で、何をやりたいかを判断というのがあるだろうと。

松舘( @d_date )
どちらにせよクロスプラットフォームの歴史を追ってくると、必ずネイティブの知識を要求される場面はどこからしらであって、それをReact NativeとかFlutterのライブラリ側で解決するのか、ネイティブの方で解決するのか、どちらにせよネイティブの知識がいる話なので、ネイティブを知らない人がその辺をキャッチアップをするのは結構大変だと思うんですけど、逆に我々はFlutterになろうが、React Natvieになろうが、新しい何かが出てこようが、そんなにキャッチアップは大変じゃ無いと思います。

服部(モデレーター)
残り1分になってしまったので最後のトピック行ってみましょうか。

Q4. UIKitとSwiftUIが混合になることもあると思いますがその上での設計とはどうあるべきか

服部(モデレーター)
AWA実際に使ってみて、watchで使ったと思いますが今後どう混ぜていこうとかディスカッションありましたら

佐々木(AWA)
混ざる時点でUIKit使ってるからSwiftUIと混ぜるという感じだと思うんですけど、今回のApple Watchに関してはそもそも全部がSwiftUIなので混合になる想定は特にしてなかったというのが一つあります。
iOSの方はしっかりUIKitなんですが、iOS 9をまだサポートしてるぐらいなので、これにたどり着けるまでには後何年かかるんだろうね？という話でまだ止まっています。
個人的にはSwiftUIの作りは好きなので、UIKitの実装をSwiftUIに寄せて行って、移行するタイミングでコストがかかりにくいような構造にしたらいいじゃ無いかなと思ってるぐらいです。

服部(モデレーター)
ぶつ切り感がありますが、一旦ここのパネルディスカッションとしては切りたいと思います。懇親会にいると思うので、話の続きを聞きたいとかあれば是非登壇者の方達を捕まえて聞いてください。

まとめ

　SwiftUIやCombineが出てきて今後もRxSwiftやReactiveSwiftなどを使い続けるのか、移行していくのかが過渡期にあるなと感じている中でのイベントだったので他社でどういう風に捉えているのかをキャッチアップできる良い機会でした。まだすぐにはプロダクト導入は厳しいが今後iOS 13以降のみをサポートできるようになったら積極的に導入していきたいという雰囲気を感じました。中でFlutterやReact Nativeの話題が出てきましたが、既に大規模にネイティブだけで開発している中では立ち入る隙は無さそうですね。こういった他社でどういう風に考えているかが聞けるようなイベントが色々あると良いなと感じました。楽しかったです。