タップルのサービス特性に合わせた設計方針を考える

2023/11 CA.swift #18
https://cyberagent.connpass.com/event/294204/

Transcript

1. タップルのサービス特性に合わせた 設計方針を考える 2023/11 CA.swift #18 Kazuma Nagano
2. アウトライン • アーキテクチャ特性の探しかた • タップルのアーキテクチャ特性をさがす ◦ 事業ドメインからさがす ◦ 機能要件からさがす ◦ 暗黙特性からさがす • タップルのアーキテクチャ特性まとめ • これからの設計方針
3. ┃経歴 ・2019年4月 新卒入社 　　　　　　（同期に yasui_akio, kazu） ・2019年5月 タップル iOS ・2023年2月 タップル iOSチーム リーダー ・2023年4月 Cyberagent Next Experts iOS ┃その他 ・なで肩 → なで ・昨日Mac版のバイオハザード ヴィレッジを クリアしました👏（2022 WWDCで紹介） 永野 一馬 / なで ながの かずま
4. 【宣伝】Cyberagent Developer Experts / Next Experts について 参照：https://www.cyberagent.co.jp/way/list/detail/id=29271
5. CA.internal.swift について • CA.swift の社内限定版やってます ◦ 社内で意見をもらったり議論したり ◦ そこから社外発表に繋げたり ◦ 外では話せないここだけの話をしたり • 対外的なCA.swiftと並んで、より気軽に事業部横断での 技術共有ができる場
6. タップルのアーキテクチャ特性はどこにあるのか
7. アーキテクチャ特性の探しかた
8. アーキテクチャ特性 ISOの公開しているソフトウェア品質特性の例 ISO/IEC 25010: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
9. アーキテクチャ特性 『ソフトウェアアーキテクチャの基礎』 4章 アーキテクチャ特性 p.60
10. アーキテクチャ特性 『ソフトウェアアーキテクチャの基礎』 4章 アーキテクチャ特性 p.60
11. アーキテクチャ特性 『ソフトウェアアーキテクチャの基礎』 4章 アーキテクチャ特性 p.60
12. “アーキテクトは、 • ドメインの関心事 • 明示的な要件 • 暗黙的な特性 という、少なくとも 3 つの方向からアーキテクチャ特性を明らかにできる。" アーキテクチャ特性を明らかにする 『ソフトウェアアーキテクチャの基礎』 5章 アーキテクチャ特性を明らかにする p.67
13. ドメイン特性はドメインの特徴として求められる特性 アーキテクチャ特性は変更追加を行う先のドメインによって決まる場合がある 例 • ユーザーの能動アクションを増やすためのフリックなどの快適なUX （= ユーザビリティ / アジリティ / 分析容易性 ） • メッセージ機能の重要度が高く、ユーザー数や時間帯による負荷増大に 耐える必要（= 可用性 / スケーラビリティ） ドメインの関心事
14. 明示的な要件 仕様の中の要件として要求される場合がある特性。 PMやデザイナーといったエンジニア以外のロールのメンバーでも認識可能 例 • 複数のサブスクリプションプランをユーザーごとに出し分け可能 （= 保守容易性 / 分析容易性 ） • ユーザーごとに異なるUIを提供可能 （= 保守容易性 / 互換性）
15. 要件にはほとんど現れないがプロジェクトの成功には欠かせないもの 開発者の目線で、要求がソフトウェアの設計構造に影響を与えると判断できるものも、 備えるべきアーキテクチャ特性 例 • チーム規模（保守容易性） • リリース頻度 / 変更量 （アジリティ） • 扱う情報の種類（セキュリティ） 暗黙特性 『ソフトウェアアーキテクチャの基礎』 p.58
16. タップルの • 事業ドメイン • 特徴的な機能要件 • 暗黙的な特性 の３つから改めて重要度の高い特性を考える タップルのアーキテクチャ特性について考える 『ソフトウェアアーキテクチャの基礎』 5章 アーキテクチャ特性を明らかにする p.67
17. タップルの事業ドメイン
18. タップルのいま • 10年目のサービス • 業界でも大手 • 23年9月TVCM放映開始 • コラボコンテンツ
19. 直近の取り組み：初のTVCMを放映 「恋を応援する」をテーマに計3本のTVCMを全国配信にて放映中。 はじめてマッチングアプリを使う方でも 安心して使えるような訴求にしています。 参照：https://www.cyberagent.co.jp/news/detail/id=29296
20. 直近の取り組み：コラボコンテンツ
21. 事業の特徴 • 事業フェーズ ◦ 市場の伸び < 競合との競争 ◦ 速度感＝アジリティが優位性に ◦ システム投資が回収可能なフェーズ • 新規参入より大手の寡占市場 ◦ 大規模なリデザイン < 機能改修 • マーケティング連動 ◦ CM ◦ コラボ機能
22. 特徴的な機能要件
23. タップルのシステム特性 • コンテンツ ＝ ユーザーの能動的なアクション ◦ eg) 新規登録、ユーザー情報入力、フリック ◦ アクションを増やすための快適な UXの重要度が高い • いい人と出会える ◦ リコメンデーションロジック • サービスの信頼性 ◦ 安心安全、本人認証 • 高い可用性が求められる機能が限定的に ◦ メッセージ • 従量 / サブスクリプションの充実 ◦ 課金システム
24. 取り組み：課金システム刷新 参照：iOSDC2023 StoreKit2を使ったアプリ内課金のフルリニューアル
25. 取り組み：マイクロサービス化 ⇨ BFF 参照：タップルのマイクロサービスアーキテクチャに向けた取り組み
26. 取り組み：マイクロサービス化 ⇨ BFF 参照：CABN2022 タップルにおけるBFFとopenAPI導入事例の紹介
27. おさらい）バックエンドを同じシステムと捉えると
28. バックエンドを同じシステムと捉えると App Presentation Logic UseCase Microservice A Mobile App BFF Mobile Team Backend Team Microservice B
29. タップルの暗黙特性
30. チーム規模
31. Trafic 3~4人 リアーキテクチャ 1~2人 5~6人 swift化 ネイティブ モノレポ化
32. コードボリューム ---------------------------------------------------------------------------------------------- Language files blank comment code ---------------------------------------------------------------------------------------------- Swift 2966 41886 28497 237091 ---------------------------------------------------------------------------------------------- SUM: 2966 41886 28497 237091 ----------------------------------------------------------------------------------------------
33. 直近のモバイルチームの課題 • メンバーが半年で倍に（5人 → 10人） ◦ ドメイン知識の浸透が不足気味 ◦ 新しい技術に対して意欲的なメンバーが多い • モバイルのワンチーム化 ◦ ユーザー数がiOSのが多いが、メンバーは Androidのが層が厚い • KMP / BFFによる技術の学習コスト増大 ◦ Swift / Kotlin / Typescriptの3言語とそれに伴う環境構築が求められる ◦ 十分な知識を習得しないまま KMP / BFFを利用し結果的に生産性を落とす場合も • 検証の大規模化 ◦ 半期をかけたタブ単位の検証など、検証対象の規模が拡大 ◦ 同時に複数の検証が走るケースなど検証数も増 • 設計パターンの変更に伴うオーバーヘッド ◦ FluxとSwift ConcurrencyやKMPとの相性が悪い ◦ KMPとパターン統一をしつつ SwftUI / Swift Concurrencyを活用したコードに
34. アーキテクチャ / KMP
35. Feature Module開発 https://developers.cyberagent.co.jp/blog/archives/33752/
36. 取り組み：セグメント最適化
37. 取り組み：Firebase Personalization
38. タップルのアーキテクチャ特性まとめ
39. 事業ドメイン • アジリティ（保守容易性 / 拡張性）の事業要求が高い • 安心安全のためのセキュリティ / 品質 特徴的な機能要件 • モジュール性（機能単位での堅牢性） • モバイルはユーザー行動を促進させるUXに集中（ユーザビリティ） 暗黙的な特性 • 大規模、複数の検証を容易に（検証容易性） • 若手が多く開発難易度を下げる必要あり（保守容易性） タップルのアーキテクチャ特性 『ソフトウェアアーキテクチャの基礎』 5章 アーキテクチャ特性を明らかにする p.67
40. タップルは • モジュール性を高めてUXを磨いていく ◦ マイクロサービス&BFF / Feature Module / 課金システム刷新 • 開発の難易度を下げて保守を簡単にしていく ◦ リアーキテクチャ / SwiftUI / Swift Concurrency • より大規模な検証を可能にする検証容易性に投資 ◦ セグメント最適化 / Personalization タップルのアーキテクチャ特性まとめ
41. これからについて
42. 保守容易性 • KMPの責務限定 ◦ Android ⇨ iOS の動きに限定 ◦ iOSメンバーの専門性としてはアディショナルにし、若手の必須スキルにはしない • 主要画面のアーキテクチャスタイル統一 ◦ 半年目処で統一していく モジュール性 / カスタマイズ性 • Server Driven UI の検証 • 生成AIの推進 これから
43. Server Driven UI https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5 • バックエンドとのIFを画面の識別子とStateに統一することで画面構成の責務をバッ クエンドに移譲するアーキテクチャスタイル • AirBnB、Lyft、Expediaなどが推進
44. 参考: 当初のBFFの導入背景 by CTO
45. なぜServer Driven UI ？ • 当初の責務に沿った形でのBFF活用を目指せる • すでに導入済みのBFFを活用して検証容易性を推進できる ◦ リリースなしでのUI変更 ◦ 大規模な個別最適化 • SwiftUIによってState ⇔ UIの変換がなめらかになった • BFFに責務を集約することで短期的な生成AIの活用を推進できる
46. おさらい）バックエンドを同じシステムと捉えると
47. 生成AIの推進 https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5
48. ご清聴ありがとうございました