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

Slide 1

Slide 1 text

タップルのサービス特性に合わせた設計方針を考える 2023/11 CA.swift #18 Kazuma Nagano

Slide 2

Slide 2 text

アウトライン ● アーキテクチャ特性の探しかた ● タップルのアーキテクチャ特性をさがす ○ 事業ドメインからさがす ○ 機能要件からさがす ○ 暗黙特性からさがす ● タップルのアーキテクチャ特性まとめ ● これからの設計方針

Slide 3

Slide 3 text

┃経歴・2019年4月新卒入社　　　　　　（同期に yasui_akio, kazu）・2019年5月タップル iOS ・2023年2月タップル iOSチームリーダー・2023年4月 Cyberagent Next Experts iOS ┃その他・なで肩 → なで・昨日Mac版のバイオハザードヴィレッジをクリアしました👏（2022 WWDCで紹介）永野一馬 / なでながのかずま

Slide 4

Slide 4 text

【宣伝】Cyberagent Developer Experts / Next Experts について参照：https://www.cyberagent.co.jp/way/list/detail/id=29271

Slide 5

Slide 5 text

CA.internal.swift について ● CA.swift の社内限定版やってます ○ 社内で意見をもらったり議論したり ○ そこから社外発表に繋げたり ○ 外では話せないここだけの話をしたり ● 対外的なCA.swiftと並んで、より気軽に事業部横断での技術共有ができる場

Slide 6

Slide 6 text

タップルのアーキテクチャ特性はどこにあるのか

Slide 7

Slide 7 text

アーキテクチャ特性の探しかた

Slide 8

Slide 8 text

アーキテクチャ特性 ISOの公開しているソフトウェア品質特性の例 ISO/IEC 25010: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

Slide 9

Slide 9 text

アーキテクチャ特性『ソフトウェアアーキテクチャの基礎』 4章アーキテクチャ特性 p.60

Slide 10

Slide 10 text

アーキテクチャ特性『ソフトウェアアーキテクチャの基礎』 4章アーキテクチャ特性 p.60

Slide 11

Slide 11 text

アーキテクチャ特性『ソフトウェアアーキテクチャの基礎』 4章アーキテクチャ特性 p.60

Slide 12

Slide 12 text

“アーキテクトは、 ● ドメインの関心事 ● 明示的な要件 ● 暗黙的な特性という、少なくとも 3 つの方向からアーキテクチャ特性を明らかにできる。" アーキテクチャ特性を明らかにする『ソフトウェアアーキテクチャの基礎』 5章アーキテクチャ特性を明らかにする p.67

Slide 13

Slide 13 text

ドメイン特性はドメインの特徴として求められる特性アーキテクチャ特性は変更追加を行う先のドメインによって決まる場合がある例 ● ユーザーの能動アクションを増やすためのフリックなどの快適なUX （= ユーザビリティ / アジリティ / 分析容易性） ● メッセージ機能の重要度が高く、ユーザー数や時間帯による負荷増大に耐える必要（= 可用性 / スケーラビリティ）ドメインの関心事

Slide 14

Slide 14 text

明示的な要件仕様の中の要件として要求される場合がある特性。 PMやデザイナーといったエンジニア以外のロールのメンバーでも認識可能例 ● 複数のサブスクリプションプランをユーザーごとに出し分け可能（= 保守容易性 / 分析容易性） ● ユーザーごとに異なるUIを提供可能（= 保守容易性 / 互換性）

Slide 15

Slide 15 text

要件にはほとんど現れないがプロジェクトの成功には欠かせないもの開発者の目線で、要求がソフトウェアの設計構造に影響を与えると判断できるものも、備えるべきアーキテクチャ特性例 ● チーム規模（保守容易性） ● リリース頻度 / 変更量（アジリティ） ● 扱う情報の種類（セキュリティ）暗黙特性『ソフトウェアアーキテクチャの基礎』 p.58

Slide 16

Slide 16 text

タップルの ● 事業ドメイン ● 特徴的な機能要件 ● 暗黙的な特性の３つから改めて重要度の高い特性を考えるタップルのアーキテクチャ特性について考える『ソフトウェアアーキテクチャの基礎』 5章アーキテクチャ特性を明らかにする p.67

Slide 17

Slide 17 text

タップルの事業ドメイン

Slide 18

Slide 18 text

タップルのいま ● 10年目のサービス ● 業界でも大手 ● 23年9月TVCM放映開始 ● コラボコンテンツ

Slide 19

Slide 19 text

直近の取り組み：初のTVCMを放映「恋を応援する」をテーマに計3本のTVCMを全国配信にて放映中。はじめてマッチングアプリを使う方でも安心して使えるような訴求にしています。参照：https://www.cyberagent.co.jp/news/detail/id=29296

Slide 20

Slide 20 text

直近の取り組み：コラボコンテンツ

Slide 21

Slide 21 text

事業の特徴 ● 事業フェーズ ○ 市場の伸び < 競合との競争 ○ 速度感＝アジリティが優位性に ○ システム投資が回収可能なフェーズ ● 新規参入より大手の寡占市場 ○ 大規模なリデザイン < 機能改修 ● マーケティング連動 ○ CM ○ コラボ機能

Slide 22

Slide 22 text

特徴的な機能要件

Slide 23

Slide 23 text

タップルのシステム特性 ● コンテンツ＝ユーザーの能動的なアクション ○ eg) 新規登録、ユーザー情報入力、フリック ○ アクションを増やすための快適な UXの重要度が高い ● いい人と出会える ○ リコメンデーションロジック ● サービスの信頼性 ○ 安心安全、本人認証 ● 高い可用性が求められる機能が限定的に ○ メッセージ ● 従量 / サブスクリプションの充実 ○ 課金システム

Slide 24

Slide 24 text

取り組み：課金システム刷新参照：iOSDC2023 StoreKit2を使ったアプリ内課金のフルリニューアル

Slide 25

Slide 25 text

取り組み：マイクロサービス化 ⇨ BFF 参照：タップルのマイクロサービスアーキテクチャに向けた取り組み

Slide 26

Slide 26 text

取り組み：マイクロサービス化 ⇨ BFF 参照：CABN2022 タップルにおけるBFFとopenAPI導入事例の紹介

Slide 27

Slide 27 text

おさらい）バックエンドを同じシステムと捉えると

Slide 28

Slide 28 text

バックエンドを同じシステムと捉えると App Presentation Logic UseCase Microservice A Mobile App BFF Mobile Team Backend Team Microservice B

Slide 29

Slide 29 text

タップルの暗黙特性

Slide 30

Slide 30 text

チーム規模

Slide 31

Slide 31 text

Trafic 3~4人リアーキテクチャ 1~2人 5~6人 swift化ネイティブモノレポ化

Slide 32

Slide 32 text

コードボリューム ---------------------------------------------------------------------------------------------- Language files blank comment code ---------------------------------------------------------------------------------------------- Swift 2966 41886 28497 237091 ---------------------------------------------------------------------------------------------- SUM: 2966 41886 28497 237091 ----------------------------------------------------------------------------------------------

Slide 33

Slide 33 text

直近のモバイルチームの課題 ● メンバーが半年で倍に（5人 → 10人） ○ ドメイン知識の浸透が不足気味 ○ 新しい技術に対して意欲的なメンバーが多い ● モバイルのワンチーム化 ○ ユーザー数がiOSのが多いが、メンバーは Androidのが層が厚い ● KMP / BFFによる技術の学習コスト増大 ○ Swift / Kotlin / Typescriptの3言語とそれに伴う環境構築が求められる ○ 十分な知識を習得しないまま KMP / BFFを利用し結果的に生産性を落とす場合も ● 検証の大規模化 ○ 半期をかけたタブ単位の検証など、検証対象の規模が拡大 ○ 同時に複数の検証が走るケースなど検証数も増 ● 設計パターンの変更に伴うオーバーヘッド ○ FluxとSwift ConcurrencyやKMPとの相性が悪い ○ KMPとパターン統一をしつつ SwftUI / Swift Concurrencyを活用したコードに

Slide 34

Slide 34 text

アーキテクチャ / KMP

Slide 35

Slide 35 text

Feature Module開発 https://developers.cyberagent.co.jp/blog/archives/33752/

Slide 36

Slide 36 text

取り組み：セグメント最適化

Slide 37

Slide 37 text

取り組み：Firebase Personalization

Slide 38

Slide 38 text

タップルのアーキテクチャ特性まとめ

Slide 39

Slide 39 text

事業ドメイン ● アジリティ（保守容易性 / 拡張性）の事業要求が高い ● 安心安全のためのセキュリティ / 品質特徴的な機能要件 ● モジュール性（機能単位での堅牢性） ● モバイルはユーザー行動を促進させるUXに集中（ユーザビリティ）暗黙的な特性 ● 大規模、複数の検証を容易に（検証容易性） ● 若手が多く開発難易度を下げる必要あり（保守容易性）タップルのアーキテクチャ特性『ソフトウェアアーキテクチャの基礎』 5章アーキテクチャ特性を明らかにする p.67

Slide 40

Slide 40 text

タップルは ● モジュール性を高めてUXを磨いていく ○ マイクロサービス&BFF / Feature Module / 課金システム刷新 ● 開発の難易度を下げて保守を簡単にしていく ○ リアーキテクチャ / SwiftUI / Swift Concurrency ● より大規模な検証を可能にする検証容易性に投資 ○ セグメント最適化 / Personalization タップルのアーキテクチャ特性まとめ

Slide 41

Slide 41 text

これからについて

Slide 42

Slide 42 text

保守容易性 ● KMPの責務限定 ○ Android ⇨ iOS の動きに限定 ○ iOSメンバーの専門性としてはアディショナルにし、若手の必須スキルにはしない ● 主要画面のアーキテクチャスタイル統一 ○ 半年目処で統一していくモジュール性 / カスタマイズ性 ● Server Driven UI の検証 ● 生成AIの推進これから

Slide 43

Slide 43 text

Server Driven UI https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5 ● バックエンドとのIFを画面の識別子とStateに統一することで画面構成の責務をバックエンドに移譲するアーキテクチャスタイル ● AirBnB、Lyft、Expediaなどが推進

Slide 44

Slide 44 text

参考: 当初のBFFの導入背景 by CTO

Slide 45

Slide 45 text

なぜServer Driven UI ？ ● 当初の責務に沿った形でのBFF活用を目指せる ● すでに導入済みのBFFを活用して検証容易性を推進できる ○ リリースなしでのUI変更 ○ 大規模な個別最適化 ● SwiftUIによってState ⇔ UIの変換がなめらかになった ● BFFに責務を集約することで短期的な生成AIの活用を推進できる

Slide 46

Slide 46 text

おさらい）バックエンドを同じシステムと捉えると

Slide 47

Slide 47 text

生成AIの推進 https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5

Slide 48

Slide 48 text

ご清聴ありがとうございました