「アプリをつくる仕組み」の構築 / build-system-for-STORES-Branded-Apps

2022/10/13に行われたSTORESとMGReの共同勉強会で登壇した時の資料です。
https://hey.connpass.com/event/261576/

Transcript

1. ヘイ株式会社 「アプリをつ る仕組み」の構築 STORES株式会社 iOSエンジニア 長谷川 将司（@marcy731） 2022/10/13 STORES x MGRe 「最近チャレンジしたことをまとめてみた」
2. アジェンダ 2 1. STORES ブランドアプリ の概要 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 4. STORES ブランドアプリ のシステムアーキテクチャ（未来編） 5. まとめ
3. 1. STORES ブランドアプリ の概要
4. 1. STORES ブランドアプリ の概要 4 2022年12月、ショップフォース株式会社がヘイ株式会社にジョイン。 2022年7月7日、既存サービスを「STORES ブランドアプリ」としてリブランディングしリリース。
5. 1. STORES ブランドアプリ の概要 5 - 複数の 店のスタンプカードをまとめて管理 - ロイヤリティプログラムの提供 - スタンプやポイントに応じた - クーポンの発行 - 特別な 知らせ　など - CRM機能 - DB: Database - 顧客情報の管理 - BI: Business Intelligence - 顧客情報と購買情報等を紐付け、分析 - MA: Marketing Automation - クーポン発行や 知らせの自動化など
6. 1. STORES ブランドアプリ の概要 6 一方で、 客様のニーズとして「 店独自のアプリを作ってブランドを表現したい！」 Stampsの基本機能をベースに、 客様独自のアプリを提供（= STORES ブランドアプリ）
7. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編）
8. App 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 9 Server ・ブランドアプリ事業の立ち上げ期に ける、GitHubのリポジトリ構成の遷移
9. Original Apps Original Apps App 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 10 Server ・ブランドアプリ事業の立ち上げ期に ける、GitHubのリポジトリ構成の遷移 Server Appmaker Data layer StampsのData層を切り離し、API資産を最大限活用
10. Original Apps Original Apps App 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 11 Server ・ブランドアプリ事業の立ち上げ期に ける、GitHubのリポジトリ構成の遷移 Server Appmaker Data layer Server Original Apps Original Apps Appmaker Data layer Appmaker Template UI layer ブランドアプリのUI層を抽象化
11. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 12 Server Original Apps Original Apps Appmaker Data layer Appmaker Template UI layer ・ブランドアプリ事業の立ち上げ期に ける、GitHubのリポジトリ構成の遷移
12. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 13 Server Original Apps Original Apps Appmaker Data layer Appmaker Template UI layer ・ブランドアプリ事業の立ち上げ期に ける、GitHubのリポジトリ構成の遷移 リポジトリ 多す て色々大変… 　 ⇨ メンテナンスコスト 大 ⇨ 新規アプリ作成 よび更新・リリースコスト 大 ⇨ スケーラビリティ なし
13. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 14 ・ブランドアプリ作成〜機能追加〜ストアへのアップロードの流れ　　　　　
14. アプリ新規作成 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 15 ・ブランドアプリ作成〜機能追加〜ストアへのアップロードの流れ　　　　　 App Store App Store Original Apps Original Apps App Store ビルド ＆ アップロード ・リポジトリ作成 ・プロジェクト作成 ・ライブラリのインポート ・必要な設定やリソースを追加 アプリ機能追加 ・ライブラリの更新
15. アプリ新規作成 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 16 ・ブランドアプリ作成〜機能追加〜ストアへのアップロードの流れ　　　　　 App Store App Store Original Apps Original Apps App Store ビルド ＆ アップロード ・リポジトリ作成 ・プロジェクト作成 ・ライブラリのインポート ・必要な設定やリソースを追加 アプリ機能追加 ・ライブラリの更新 これら全てをアプリごとに手動で行う必要あり 　 ⇨ メンテナンスコスト大 ⇨ 新規アプリ作成 よび更新・リリースコスト大 ⇨ スケーラビリティなし
16. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 17 聞 だけで大変そうですよね… > 課題はあるのはわ ってる 、 > エンジニアリソースもな 自動化にも手 回らないし… > まだクライアント様の数もそこまで多 ない… > 今はギリギリなんと なっている… という状況でした
17. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 18 聞 だけで大変そうですよね… > 課題はあるのはわ ってる 、 > エンジニアリソースもな 自動化にも手 回らないし… > まだクライアント様の数もそこまで多 ない… > 今はギリギリなんと なっている… という状況でした 当時のモバイルエンジニアは iOS/Android兼任で1名(業務委託)
18. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 19 そんな中、状況に変化あり 1. STORESとの合流 2. モバイルエンジニアリソース増 a. iOS/Android兼任1名(業務委託) -> iOS/Androidそれぞれ1名(共に正社員）
19. 2. STORES ブランドアプリ のシステムアーキテクチャ（過去編） 20 そんな中、状況に変化あり 1. STORESとの合流 2. モバイルエンジニアリソース増 a. iOS/Android兼任1名(業務委託) -> iOS/Androidそれぞれ1名(共に正社員） ⇨　将来を見据え、 「より拡張性の高いシステムアーキテクチャにしてい ぞ！」 という機運 高まった！！
20. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編）
21. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 22 <課題> 1. リポジトリ多す 問題 2. 手作業多す 問題
22. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 23 <施策> 1. リポジトリ多す 問題　→　ブランドアプリのリポジトリを一つに統合 2. 手作業多す 問題　　　→　CI/CDを導入して可能な限り自動化
23. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 24 <施策> 1. リポジトリ多す 問題　→　ブランドアプリのリポジトリを一つに統合 2. 手作業多す 問題　　　→　CI/CDを導入して可能な限り自動化 「やるべ 」ことを「当たり前」にやる
24. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 25 a. CI/CDを用いた自動化
25. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 26 a. CI/CDを用いた自動化 ×
26. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 27 a. CI/CDを用いた自動化 アプリ新規作成 App Store App Store Original Apps Original Apps App Store ビルド ＆ アップロード アプリ機能追加 ・ライブラリの更新 ・リポジトリ作成 ・プロジェクト作成 ・ライブラリのインポート ・必要な設定やリソースを追加
27. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 28 a. CI/CDを用いた自動化 アプリ新規作成 App Store App Store Original Apps Original Apps App Store ビルド ＆ アップロード ・リポジトリ作成 ・プロジェクト作成 ・ライブラリのインポート ・必要な設定やリソースを追加 ・fastlane + bitriseの設定 アプリ機能追加 ・ライブラリの更新 自動化 マージをトリガーにCI 動作し、アップロードまで自動で行う 一部のみ
28. ・リポジトリ作成 ・プロジェクト作成 ・ライブラリのインポート ・必要な設定やリソースを追加 ・fastlane + bitriseの設定 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 29 a. CI/CDを用いた自動化 アプリ新規作成 App Store App Store Original Apps Original Apps App Store ビルド ＆ アップロード アプリ機能追加 ・ライブラリの更新 自動化 手作業のまま　→　リポジトリ統合に期待…！ マージをトリガーにCI 動作し、アップロードまで自動で行う 一部のみ
29. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 30 b. リポジトリ統合
30. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 31 b. リポジトリ統合 Server Original Apps Original Apps Appmaker Date layer Appmaker Template UI layer
31. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 32 b. リポジトリ統合 Server Original Apps Original Apps Appmaker Data layer Appmaker Template UI layer Server Appmaker Data layer Appmaker Template UI layer
32. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 33 b. リポジトリ統合 Original Apps Original Apps リポジトリ統合
33. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 34 b. リポジトリ統合 Original Apps Original Apps リポジトリ統合 ＝ 「複数のアプリを動的に生成する仕組みを構築する」
34. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 35 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） iOSアプリ 　⇨　専用のプロジェクトファイル(.xcodeproj)をXcodeでビルドすることで生成
35. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 36 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） iOSアプリ 　⇨　専用のプロジェクトファイル(.xcodeproj)をXcodeでビルドすることで生成 　⇨　.xcodeprojをアプリごとに動的に変更もし は生成したい
36. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 37 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） iOSアプリ 　⇨　専用のプロジェクトファイル(.xcodeproj)をXcodeでビルドすることで生成 　⇨　.xcodeprojをアプリごとに動的に変更もし は生成したい XcodeGenを利用 プロジェクトファイル(.xcodeproj)を定義ファイル(project.yml) ら生成するツール
37. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 38 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） iOSアプリ 　⇨　専用のプロジェクトファイル(.xcodeproj)をXcodeでビルドすることで生成 　⇨　.xcodeprojをアプリごとに動的に変更もし は生成したい XcodeGenを利用 プロジェクトファイル(.xcodeproj)を定義ファイル(project.yml) ら生成するツール ⇨　yamlのような簡易なテキストファイル ら.xcodeproj 生成で る
38. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 39 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） iOSアプリ 　⇨　専用のプロジェクトファイル(.xcodeproj)をXcodeでビルドすることで生成 　⇨　.xcodeprojをアプリごとに動的に変更もし は生成したい XcodeGenを利用 プロジェクトファイル(.xcodeproj)を定義ファイル(project.yml) ら生成するツール ⇨　yamlのような簡易なテキストファイル ら.xcodeproj 生成で る ⇨　project.ymlに環境変数を用いることで動的に変更
39. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 40 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） iOSアプリ 　⇨　専用のプロジェクトファイル(.xcodeproj)をXcodeでビルドすることで生成 　⇨　.xcodeprojをアプリごとに動的に変更もし は生成したい XcodeGenを利用 プロジェクトファイル(.xcodeproj)を定義ファイル(project.yml) ら生成するツール ⇨　yamlのような簡易なテキストファイル ら.xcodeproj 生成で る ⇨　project.ymlに環境変数を用いることで動的に変更 ⇨　アプリごとの.xcodeproj 生成で る！
40. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 41 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） XcodeGen 環境変数 env.yml App.xcodeproj project.yml ビルド Script iOS App
41. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 42 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） ＜Point＞ ・アプリ毎の設定値をenv.ymlに記述 ・env.ymlを元に環境変数を生成し、XcodeGenを用いて動的に.xcodeprojを生成 ・ビルドまでの一連の流れをScript化し、1コマンドに （例えば APP_NAME="demo” のように任意のアプリを指定して実行） XcodeGen 環境変数 env.yml App.xcodeproj project.yml ビルド Script iOS App
42. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 43 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） XcodeGen 環境変数 env.yml App.xcodeproj project.yml ビルド Script iOS App
43. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 44 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） XcodeGen 環境変数 env.yml App.xcodeproj project.yml ビルド Script iOS App Assets.xcassets
44. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 45 b. リポジトリ統合 = 複数のアプリを動的に生成する仕組みの構築（iOS） XcodeGen 環境変数 env.yml App.xcodeproj project.yml ビルド Script iOS App ＋ common_env.yml Assets.xcassets Source Code
45. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 46 c. 自動化とリポジトリ統合を組み合わせると
46. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 47 c. 自動化とリポジトリ統合を組み合わせると env.yml App.xcodeproj project.yml ビルド Script iOS App App Store App Store App Store アップロード env.yml Assets.xcassets マージをトリガーにCI 動作し、アップロードまで自動で行う 新規アプリ追加時 追加
47. common_env.yml 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 48 c. 自動化とリポジトリ統合を組み合わせると env.yml App.xcodeproj project.yml ビルド Script iOS App App Store App Store App Store アップロード env.yml Assets.xcassets マージをトリガーにCI 動作し、アップロードまで自動で行う 新規アプリ追加時 アプリ更新時（ライブラリ更新など） 追加 編集
48. common_env.yml 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 49 c. 自動化とリポジトリ統合を組み合わせると env.yml App.xcodeproj project.yml ビルド Script iOS App App Store App Store App Store アップロード env.yml Assets.xcassets 新規アプリ追加時 アプリ更新時（ライブラリ更新など） 追加 編集 Build Pipelinesという仕組みを用い、 アプリごとのビルドを並列で実行 ⇨　1アプリ分の時間で完了！！ マージをトリガーにCI 動作し、アップロードまで自動で行う
49. 3. STORES ブランドアプリ のシステムアーキテクチャ（現在編） 50 c. 自動化とリポジトリ統合を組み合わせると ＜結果＞ 　・メンテナンスコスト　↓ 　・新規アプリ作成 よび更新・リリースコスト　↓ 　・スケーラビリティ　↑ 何より、新機能開発に集中で るようになった！！！
50. 4. STORES ブランドアプリ のシステムアーキテクチャ（未来編）
51. 52 将来的な理想は 1. 設定値をサーバー側に持たる - 「受注 -> 管理画面で必要な設定を行う -> 設定値を動的に取得しアプリを作成 -> ストアへアッ プロード」といった感じで、アプリエンジニアへ依頼することな 、アプリ作成 クライアント もし はCSの稼働のみで完結で る状況をつ る 4. STORES ブランドアプリ のシステムアーキテクチャ（未来編）
52. 5. まとめ
53. 5. まとめ 54 ・　歴史的経緯によりシステムアーキテクチャに拡張性 な った ・　「アプリをつ る仕組み」 を構築することでビジネススケールに対応した ・　モバイルエンジニアとして、 - 通常のアプリ開発だけではな 、「アプリをつ る仕組み」=「自動化を駆使した ビルドシステムの構築」という一般的なモバイルエンジニア 経験しないことを経 験で た！！(している最中) - やり い ある！！！楽しい！！！
54. 最後に 55 STORES ブランドアプリ は iOS / Android 各1名で通常の機能開発に加え、 「アプリをつ る仕組み」作りまで開発しています 一般的なアプリ開発以上の挑戦をして、課題解決をしてい たい方！ ぜひ一緒に改善してい ましょう！ 絶賛エンジニア募集中ですー！！！！