Sansan Androidアプリ開発におけるマルチモジュール化の進め方 / Approaches to multi-module development in Sansan Android app

Sansan Androidアプリ開発における
マルチモジュール化の進め方
i O S / A n d r o i d アプリ開発のマルチモジュール化
【アンドパッド｜クックパッド｜ S a n s a n 】
Sansan株式会社技術本部
Mobile Applicationグループ
赤城史哉

View Slide

前職ではAndroidアプリの受託開発に従事。
2019年にSansan入社後、Sansan Android アプリの開発・運用を担当。
赤城史哉
Sansan 株式会社
技術本部 Mobile Applicationグループ
1

View Slide

2

View Slide

Sansan株式会社とは
名刺管理から、営業を強くする
名刺でつながる、
ビジネスのためのSNS
請求書受領から、
月次決算を加速する
設立年 2007年6月
拠点表参道本社
Sansan One
Sansan パラシオ
関西支店
福岡支店
名古屋支店
資本金 63億33百万円
（2021年8月31日時点）
代表者寺田親弘（代表取締役社長）
事業働き方を変えるDXサービス
（クラウド名刺管理サービス等）の
企画・開発・販売
グループ会社 Sansan Global Pte. Ltd.
（シンガポール）
Sansan Corporation
（アメリカ）
ログミー株式会社
東京証券取引所市場第一部
上場証券取引所
従業員数 979名（2021年8月31日時点）
3

View Slide

Sansan – 働き方を変えるDX –
4
新世代エントリーフォーム新世代パンフレット
全文書き起こしメディア
名寄せエンジン
Sansan Data Hub
ピアボーナスサービス
契約書データ化サービス
クラウド請求書受領サービス
スマート受付
無人名刺受付システム
名刺作成サービス
セミナー管理システム
クラウド名刺管理サービス
スマート署名取り込み
AI名刺管理オンライン名刺
同僚コラボレーション
メール配信
イベント・セミナー
請求書
名刺
契約書
組織コミュニケーション
名刺印刷・発注データ活用
反社チェックオプション
powered by Refinitiv/KYCC
契約管理オプション
for クラウドサイン
商談管理オプション
for Salesforce
アンケートオプション
powered by CREATIVE SURVEY
powered by MotionBoard
名刺分析オプション
業務連携

View Slide

本発表のゴール
- マルチモジュール導入の具体的な事例を知る
- 各々の開発現場での技術的な意思決定の材料とする
5

View Slide

Agenda
- Sansan Androidアプリのマルチモジュール化の現状
- マルチモジュール化の計画
- マルチモジュール化で困ったこと
- 様々な規模の開発現場におけるマルチモジュール化との向き合い方
6

View Slide

Sansan Androidアプリの
マルチモジュール化の現状

View Slide

- 名刺管理
- スマホのカメラを使って名刺登録
- 登録した名刺に関連する企業のニュースを確認
- 商談メモや議事録 (コンタクト機能)
- 社内チャット
- 企業情報の閲覧
- 同僚一覧を閲覧
アプリの主な機能
8

View Slide

- ファイル数
- Kotlin : 約3000ファイル
- Xml : 約1000ファイル
- コード行数（Kotlin）
- Kotlin : 約16万行
- Xml : 約5万行
- モジュール数：80モジュール
- エンジニア数：7名
- アーキテクチャ：Flux + Clean Architecture
Sansanアプリ開発の現状
9

View Slide

すごく便利！！！
おかげで、快適な開発が出来ている。
Gradleさんありがとう！！！！
マルチモジュール化の恩恵（1エンジニアの感想）

View Slide

- 開発の大規模化
- 複数人での並列的な機能開発による諸問題
> コンフリクトの増加
> アーキテクチャのルールが守られなくなる懸念
- コードの肥大化による諸問題
> ビルド時間の増加
> コードの読みづらさ
> 改修・調査するファイルの見つけづらさ
アプリ開発における課題
11

View Slide

- ビルド時間の短縮
- レイヤー間の依存関係の強制
- 各モジュールの関心事を小さくできる
- packageではクラスのグルーピングしか出来ないが、レイアウトファイルや
resource等も含めたグルーピングが可能
マルチモジュール化のメリット
12

View Slide

- 差分ビルドの時間が約半分に
- legacyを触るときはまだ遅い
- string.xmlやlayoutファイル、Android Manifest等の情報が
機能単位に集約され、見やすい
- ノイズが少なく、担当している機能に集中できる
- internal修飾子による、モノリスより柔軟な可視性の制御
- モジュール追加のタイミングで、アーキテクチャのレイヤーが
守られる事を担保
マルチモジュール化の恩恵
13

View Slide

Sansanアプリ開発の現状：マルチモジュールの構造
14
:app
:legacy
:repository
:data:repository_impl
:data:local
:data:network
:resources
:xx_util
:router
:domain
:feature:bizcard
:feature
:company
:feature
:company_common

View Slide

:legacy
:repository
:data:local
:data:network
:resources
:xx_util
:router
:domain
:feature:bizcard
:feature
:company
:feature
:company_common
15
:app
全てのモジュールに依存
Daggerによる依存性の解決を行う

View Slide

:app
:legacy
:repository
:data:local
:data:network
:resources
:xx_util
:router
:domain
:feature:bizcard
:feature
:company
:feature
:company_common
16
:legacy
:feature:bizcard
:feature
:company
:feature
:company_common
Presentationレイヤー
Activity, Flux etc…
Featureは画面・機能に切り分け

View Slide

:legacy
:repository
:data:local
:data:network
:resources
:xx_util
:router
:domain
:feature:bizcard
:feature
:company
:feature
:company_common
:app
17
Domainレイヤー
その他各featureモジュール
が共通して使うクラス
:repository
:resources
:xx_util
:router
:domain

View Slide

:legacy
:repository
:data:local
:data:network
:resources
:xx_util
:router
:domain
:feature:bizcard
:feature
:company
:feature
:company_common
:app
18
Dataレイヤー
SharedPreference, Retrofit など
を取り扱う実装
Presentationレイヤーから
直接依存されない
:data:local
:data:network

View Slide

:legacy
:repository
:data:local
:data:network
:resources
:xx_util
:router
:domain
:feature:bizcard
:feature
:company
:feature
:company_common
:app
19
実態は、featureがdataレイヤーを参照していたり、
その他のモジュールも存在していて複雑。こちらは基本的なコンセプト。
このコンセプトにそう実態になるよう、日々改修している。

View Slide

マルチモジュール化の計画と実行

View Slide

- STEP 1 : domainのみを分離
- STEP 2 : data関連のモジュールを分離
- STEP 3 : UI関連のコードをlegacyに移動
- STEP 4 : Repository, Routerのinterfaceを切る
- STEP 5 : UIのコードを機能ごとに分割
マルチモジュール化の5ステップ
21

View Slide

STEP1 : domainのみを分離
22
:app

View Slide

STEP1 : domainのみを分離
23
:resources
:xx_util
:domain
:app

View Slide

STEP2 : data関連のモジュールを分離
:app
:data:local
:data:network
:resources
:xx_util
:domain
24

View Slide

STEP3 : UI関連のコードをlegacyに移動
:app
:legacy
25
:data:local
:data:network
:resources
:xx_util
:domain

View Slide

STEP4 : Repository, Routerのinterfaceを切る
:app
:legacy
26
:data:local
:data:network
:resources
:xx_util
:domain
:router
:repository :data:repository_impl

View Slide

STEP5 : UIのコードを機能ごとに分割
:app
:legacy
27
:data:local
:data:network
:resources
:xx_util
:domain
:router
:feature
:bizcard_common
:feature
:company
:feature:bizcard

View Slide

STEP5 : UIのコードを機能ごとに分割（完成形）
:app
28
:data:local
:data:network
:resources
:xx_util
:domain
:router
:feature
:company_common
:feature
:company
:feature:bizcard
:feature:piyo
:feature:hoge
:feature:fuga

View Slide

マルチモジュール化で困ったこと

View Slide

- モジュール化の認識をチームで合わせる必要性
- 共通化されたクラスを使いたい時、循環依存を回避するのが難しい
- 意図せずデグレしてしまう事がある
困ったことのカテゴリ
30

View Slide

- モジュールの切り方が分からない
- 作成方法のドキュメントを用意しておく
- モジュールの切る粒度
- 都度議論して方向修正していく
- 新規開発でのモジュールの切り方、モジュール名の付け方
- 開発時に、詳細設計レビューを実施している。
その際にモジュール設計もレビューする
モジュール化の認識をチームで合わせる必要性
31

View Slide

循環依存を考慮した設計をする必要がある
会社詳細画面のモジュールに、新しく名刺の一覧画面を作ることになり
既存の名刺レイアウトを流用したい場合
32
:feature:会社詳細
(new)
会社に紐づく名刺一覧画面
:feature:名刺詳細
名刺レイアウト.xml

View Slide

会社詳細画面のモジュールに、新しく名刺の一覧画面を作ることになり
既存の名刺レイアウトを流用したい場合
33
(new)
implementation project(”:feature:名刺詳細”)

View Slide

名刺詳細でも、会社詳細に依存したいケースが出てきてしまうと…
34
(new)
implementation project(”:feature:会社詳細”)

View Slide

35
名刺詳細でも、会社詳細に依存したいケースが出てきてしまうと…
(new)
implementation project(”:feature:会社詳細”)
コンパイルエラーになってしまう

View Slide

Sansan Androidでは、feature_commonモジュールを作り解決
36
:feature:名刺_common
(new)

View Slide

- シングルモジュールのアプリではコンパイルできた依存関係でも、
マルチモジュールに移行するとエラーになってしまう
- 注意しながら依存関係を設計しないと、すぐに複雑なモジュール間の
依存関係が作り出されてしまい、負債となる
37

View Slide

意図せずデグレしてしまう事がある
strings.xml strings.xml
38

View Slide

39
string.xmlなどのresource idがコンフリクトすると、
片方のresourceが上書きされてしまう

View Slide

40
マルチモジュール環境では、resource id はユニークにする必要がある

View Slide

resource prefix機能を使うと、そのモジュールの中のresource id にprefixを
設定できる。
41

View Slide

様々な規模の開発現場における
マルチモジュール化との向き合い方

View Slide

- 今までのセクションは、あくまでSansan Androidアプリ固有の話
- 様々な開発現場のシチュエーションを想像して、マルチモジュール機能を
どのように使うか、考えてみましょう！
- Twitterで #ANDPAD_cookpad_Sansan タグをつけて @ginyolith_tech の
アカウントでツイートするので、同じくタグを付けて、お題に対する回答
を引用リツイートお願いします！
- 経験豊富な方は初心者時代の自分と同じような人を助ける気持ちで、
マルチモジュール初心者の方は自分で考えるトレーニングとして、
ぜひツイートしてください！
このセクションについて
43

View Slide

- エンジニアの人数：１人（あなた）
- アプリ開発のアイデアがあり、これから作っていく
技術選定のフェーズ
- とにかく早くリリースをして欲しいという社長からの要望
開発現場１創業したてベンチャー企業で1人エンジニア
44

View Slide

- マルチモジュール化には向き合わなくて良い
- とにかくリソースが無いことが想像できる
- マルチモジュール化は詰まりどころが多い
- コードベースが小さいのであれば、ビルド速度は問題にならない
- 余裕があれば、packageでの最低限のレイヤー分けが出来ていると良い
- ViewModel, Repository等
- 補足：
初心者の場合は、他の技術（coroutineやcompose等）を優先して学習すべき
開発現場１自分の考え
45

View Slide

- エンジニアの人数：2~3人（あなた + 中堅エンジニア２, 3人）
- 半年程度でアプリを完成させ納品する契約
- 要件やデザインは決まっており、これから技術選定する段階
- 納期には多少余裕がありそう
- 納品した後は大きなアップデートの予定は無い
バグ修正程度の依頼がちょくちょく来る想定
開発現場２中規模な受託開発案件
46

View Slide

- レイヤー分けレベルのマルチモジュール化はした方が良い
- 納期間際でのバグ修正や仕様変更に対応したい
- アーキテクチャをある程度守らないとバグになりやすい規模感
- 機能単位のモジュール化は余裕があればしてもよさそう
- コンパイルが通らなくなったり、循環依存の問題が出やすいので注意
開発現場２自分の考え
47

View Slide

- エンジニアの人数：4人（あなた + ベテラン、中堅、ジュニア各1）
- 技術的負債が大きく、新機能の開発に工数がかかるのを解消したい
- コードベースが大きくなっており、ビルド時間がかかるのがストレス
- 最近はアーキテクチャを導入してきれいなコードになっているが、
一部の昔のコードはFat Activityなどつらいコードが存在する
- 定期的に新機能の開発を行っている
- アーキテクチャやライブラリなどを刷新する計画が立っている。
その技術選定を考えるフェーズ
開発現場３中規模な事業会社でのリアーキテクチャ
48

View Slide

- 計画的にマルチモジュール化に向き合ったほうが良い
- アーキテクチャを考え直すのとセットで向き合うと良い
- モノリス -> モジュール化は工数が結構かかるので注意
- featureモジュールも作ったほうが良い
- 機能開発と並行してモジュール化をする場合
- ビルド速度に関しては、即時の対応としてマシンスペックを上げるのも手
> M1Macだと大分変わる
開発現場３自分の考え
49

View Slide

まとめ
- マルチモジュール機能は大規模な開発現場における協力な味方
- 一方で、もちろん銀の弾丸ではない
メリットデメリットを正しく検討して導入しよう
- 巨大なモノリスからのモジュール化は計画をきちんと建てて行うと良い
50

View Slide

エンジニア情報サイト「Sansan Engineering」
51
・Sansanエンジニアのミッション
・プロダクト、テクノロジー概要
・エンジニアインタビュー
・技術スタック
・働く環境、社内制度
・募集職種
・Blog
・イベント情報 ... and more
Sansan Engineering
Sansanのプロダクトやテクノロジー、カルチャー、採用情報など、エンジニアリングに関するあらゆる情報を掲載
https://jp.corp-sansan.com/engineering/

View Slide

※ 登録の際、紹介コードの欄に「0 1 1 2 勉強会」と入力ください。

View Slide

View Slide

Sansan Androidアプリ開発におけるマルチモジュール化の進め方 / Approaches to multi-module development in Sansan Android app

Sansan Androidアプリ開発におけるマルチモジュール化の進め方 / Approaches to multi-module development in Sansan Android app

Sansan

More Decks by Sansan

Other Decks in Technology

Featured

Transcript