Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2App, 1Repository
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
n-seki
February 15, 2026
Programming
18
0
Share
2App, 1Repository
n-seki
February 15, 2026
More Decks by n-seki
See All by n-seki
10年もののバグを退治した話
n_seki
0
250
永続化、なに使おう?
n_seki
0
320
OS間でBluetooth処理を(一部)共通化している話
n_seki
0
110
やってみようMaven!
n_seki
0
370
Try Android Health Connect
n_seki
0
96
Other Decks in Programming
See All in Programming
GNU Makeの使い方 / How to use GNU Make
kaityo256
PRO
16
5.6k
AI-DLC Deep Dive
yuukiyo
9
4.6k
Coding at the Speed of Thought: The New Era of Symfony Docker
dunglas
0
5k
AI時代のPhpStorm最新事情 #phpcon_odawara
yusuke
0
190
〜バイブコーディングを超えて〜 チームで実験し続けたAI駆動開発
tigertora7571
0
140
UIの境界線をデザインする | React Tokyo #15 メイントーク
sasagar
2
370
Running Swift without an OS
kishikawakatsumi
0
850
ローカルで稼働するAI エージェントを超えて / beyond-local-ai-agents
gawa
3
280
AIエージェントで業務改善してみた
taku271
0
540
Going Multiplatform with Your Android App (Android Makers 2026)
zsmb
2
440
ハンズオンで学ぶクラウドネイティブ
tatsukiminami
0
130
t *testing.T は どこからやってくるの?
otakakot
1
700
Featured
See All Featured
The Cult of Friendly URLs
andyhume
79
6.8k
The SEO Collaboration Effect
kristinabergwall1
1
420
Agile that works and the tools we love
rasmusluckow
331
21k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
For a Future-Friendly Web
brad_frost
183
10k
How to make the Groovebox
asonas
2
2.1k
Prompt Engineering for Job Search
mfonobong
0
270
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
180
Technical Leadership for Architectural Decision Making
baasie
3
330
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
100
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
140
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1.2k
Transcript
STORES 株式会社 ~ 設計と実装の振り返り ~ 2025.12.09 Ebisu mobile #12 Naoto
Uwaseki 2つのアプリ、1つのリポジトリ
自己紹介 2 • Naoto Uwaseki ◦ n-seki • 決済一筋8年目 ✌
• アイコンはモルモットです→
これまでの決済Androidアプリ 3 • 普通のAndroidアプリ ◦ Google Play で配信中! • 機能
◦ 決済、返金、決済履歴、入金 ◦ スタッフ管理、お知らせ...etc • 外部機器との接続 ◦ 決済端末(Bluetooth接続) ◦ プリンター(Bluetooth接続) • Phone/Tablet向けのUI実装
これまでの決済Androidアプリ 4 • Gradleマルチモジュール構成 • appモジュールをビルドすること で.apkが得られる • 決済SDKとの共通モジュールが あったり
• View/Compose + ViewModel + UseCase + Repository . ├── app // 決済アプリ ├── core ├── hoge └── huga
• 決済端末2もAndroid! • 技術検証によって、既存アプ リと同じところ/違うところ が見えてきた......! • 要件検討も本格化し、どのよ うな機能が必要そうか見えて きた......!
決済端末2 で動作する決済アプリを作る......! 5
既存アプリと専用アプリの共通点 6 1. どちらもAndroidアプリである! → ☺☺☺ 2. 決済端末との接続処理の流れや決済処理のフローにはほとんど 差分がない! →
決済のコアな処理には決済端末も深く関わっており、アプ リと決済端末でデータのやり取りが必要です。 コネクションの確立、決済処理などのプロトコルについて、 決済端末と決済端末2では(ほぼ)違いがない、ということ。
既存アプリと専用アプリの共通点 7 3. サポートする決済手段も同じ! 4. 決済以外の機能にも大きな差分はなし! a. 既存アプリにある機能のいくつかを落とした形になりそう
• 決済端末2のディスプレイは小さい!(480 x 800) ◦ 既存アプリのUI/UXそのままでは使いにくい画面も ◦ デバイスのカラーに合わせたデザインを取り入れたい → UIは新しく実装してあげる必要がありそう
😼 既存アプリと専用アプリの相違点 8
• 接続方式が異なる! ◦ 既存アプリはBluetoothで決済端末と接続している ◦ 決済端末2上で動作するアプリはローカルソケット通信で カードリーダーとやり取りする • GMSが利用できない......! ◦
(さきほどの発表の通り) 既存アプリと専用アプリの相違点 9
共通点と相違点 10 共通点 相違点 • Androidアプリ • コアなロジック • 決済手段
• 決済以外の機能 • ディスプレイサイズ • 決済端末との通信方式 • GMS
考えられる戦略 11 1. 新規で0からアプリを作成する a. 既存アプリとは完全分離 2. 既存アプリの資産を最大限活かす a. うまいこと処理を抽象化すればできそう......?
考えられる戦略 12 1. 新規で0からアプリを作成する a. 既存アプリとは完全分離 2. 既存アプリの資産を最大限活かす a. うまいこと処理を抽象化すればできそう......?
→ 技術検証を重ね、 「既存アプリの資産を活かして開発する」ことに 🔥
2つのアプリ、1つのリポジトリ 13 • 既存の資産を活用した方が、品質が高いアプリをより短期間で 実装できそう • どのレイヤーを既存アプリと共通化するかも併せて検討
2つのアプリ、1つのリポジトリ 14 • 本格実装前のリファクタリング ◦ Bluetooth/ローカルソケットの接続方式を抽象化 ◦ 既存アプリと共通して利用したいコードたちを、新しい Gradleモジュールにお引越し ▪
Daggerが壊れたりしたので修正...... 😌 ◦ 2024/12 前後くらい • GMSが使えないので実装を変更 ◦ (さきほどの発表の通り)
2つのアプリ、1つのリポジトリ 15 • 既存のViewModel/UiStateを利用する形で Full Composeでアプリ実装 ◦ 必要があればリファクタリング . ├──
app // 既存アプリ ├── appCommon // 既存アプリとの共通モジュール ├── core ├── hoge ├── huga └── stores-payments-2-app // 決済端末2向けアプリ sp2-app app appCommon core
良かったこと/改善できそうなこと 16 • 👍 既存コードの多くを共通化できた ◦ 開発スピード、品質に寄与 • 👍 0からUI実装できた(Full
Compose) • ✊ 共通コードの中に既存アプリ or 決済端末2 の分岐が生まれ てしまった • ✊ 既存設計に引っ張られてしまう場合があった ◦ ロジックが複雑になってしまったり ◦ 既存アプリと同じロジックだと問題があることが後々判明 したり
まとめ 17 • 改善の余地はありつつ、当初の設計どおりに実装できて、年内 リリースが完遂できたことは素直に喜ばしい • これから運用していく中でも課題がでてくると思うので、適宜 見直しをしながらコードベースを育てていきたい