既存Webサービスのモバイルアプリ版を 1週間でリリースし、進化させてきた話 2022/10/19【カケハシ/Ubie/ゆめみ】“変化に強いシステム”を実現するためにテックリードが行った取捨選択 Yuku Kotani (@yukukotani)

2 自己紹介 小谷 優空 (@yukukotani) ● Software Engineer @ Ubie Discovery (2019/05~) ○ プロダクト開発 (~2022/06) ○ 技術戦略、設計、認証基盤 (~現在) ● Student @ Univ. Tsukuba (2019/04~) ○ 情報科学類 ● Hobby Guitarist (2020/06~) 2

3 目次 症状検索エンジン「ユビー」の紹介 モバイルアプリ開発の背景 モバイルアプリ開発における意思決定 意思決定の振り返り これからの展望 まとめ

4 症状検索エンジン「ユビー」の紹介 ● 自分の症状を答えると、関連する病名や 診療科、近隣医療機関がわかるサービス ● 2020年5月に正式公開、現在700万MAU ● TypeScript+Next.js / Kotlin+Spring Boot / GraphQL / Capacitor https://ubie.app

5 目次 症状検索エンジン「ユビー」の紹介 モバイルアプリ開発の背景 モバイルアプリ開発における意思決定 意思決定の振り返り これからの展望 まとめ

6 背景 ● ユビーは Web アプリケーションとしてサービス提供してきた ○ Next.js で実装されている ● 自然流入・広告によるユーザーが増えてきて、リテンションが欲しくなってくる ● より生活に根差した、医療体験の起点となるプロダクトになっていきたい → せや！モバイルアプリや！

7 背景 でも... ● 既存の資産はすべて Web 技術 ● 歴史的経緯でフロントエンド側に実装が寄っていて、移植が大変 ● モバイルアプリ開発自体に不確実性があり、まずは大きなコストをかけずに検証したい ○ ストアの審査に問題なく通るか ○ モバイルアプリのリターンはどれくらいか ● 不確実性がクリアできたら、そのままサービス提供していきたい ○ ブラウザ版の機能開発に追従する必要がある

8 目次 症状検索エンジン「ユビー」の紹介 モバイルアプリ開発の背景 モバイルアプリ開発における意思決定 意思決定の振り返り これからの展望 まとめ

9 Capacitor の採用 決定その1

10 Capacitor とは Capacitor の採用 ● クロスプラットフォームアプリのフレームワーク ● Web技術 (HTML5, CSS, JavaScript) で開発する ● WebView に描画され、JavaScript API でネイティブ機能を呼び出せる プッシュ通知を送る例

11 他の選択肢との比較 Capacitor の採用 Capacitor Flutter React Native Kotlin / Swift 既存資産の流用 ◯ × △ △ 機能開発コスト ◯ △ △ × 人材獲得 ◯ × △ △ ユーザー体験 × △ △ ◯ ● ブラウザ版の資産をそのまま動かせる部分が多く、素早い立ち上げが可能 ● 今後の機能開発も大部分を共通化できる ● 一方で、いわゆるネイティブっぽい体験は提供しにくい

12 なぜ Capacitor か Capacitor の採用 ● サービスの性質上、リッチアニメーションのような描画コストの高い UI がない ● まだ新規機能開発が活発なフェーズであり、完全に独立してモバイルアプリ開発をするのは大変 ● OTAアップデートによってブラウザ版と同様に高速デプロイができる

13 ブラウザ版と共通のコードベースで実装 決定その2

14 アーキテクチャ ブラウザ版と共通のコードベースで実装 Browser Native App (Capacitor) Next.js Next.js GraphQL BFF Micro Services コードベースは同じだが、 ビルドを分けて 別インスタンスで配信

15 ビルド時に挙動を決定 ブラウザ版と共通のコードベースで実装 ● 環境変数でブラウザ版とモバイルアプリ版の挙動を分岐 ● ビルド時に定数置換と Dead Code Elimination、 Tree Shaking が効く ○ モバイルアプリ向けの実装やライブラリが ブラウザ版のバンドルサイズ(≒SEO)を毀損しない 定数置換 Dead Code Elimination ランタイムではなく ビルドタイムで ここまで最適化

16 WebViewからリモートサーバーにアクセス ブラウザ版と共通のコードベースで実装 ● Capacitor の WebView からリモートサーバーの Next.js にアクセスする ● ブラウザと同じ感覚でシンプルにOTAアップデートを実現できる ● Capacitor ではリモートサーバーからの配信を推奨していないが、 メンテナの意見など一次情報を収集し、問題ないと判断 ○ 今の所インターネット接続なしに提供できる機能がほぼないため、オフライン対応不要 ○ 現在のストア規約では、リモート配信が明示的に許可されている (リンク) ionic-team/capacitor#4122

17 目次 症状検索エンジン「ユビー」の紹介 モバイルアプリ開発の背景 モバイルアプリ開発における意思決定 意思決定の振り返り これからの展望 まとめ

18 良かったこと・気になっていること 意思決定の振り返り Good ● トップページ等から徐々にモバイルアプリ版を最適化できている ● 新規機能もブラウザ版に追従して提供できている ● 動き出しから1週間でリリースし、すぐに不確実性検証できた ○ リテンション率の計測、リテンションユーザーへのインタビュー Bad ● ユーザー体験にはまだまだ全く満足できていない ● ブラウザ版とモバイルアプリ版の分岐が複雑化 ● ネイティブアプリ側と JavaScript 側の Capacitor バージョン差異に気を使う必要がある

19 学び 意思決定の振り返り ● 第一想起の Flutter, React Native だけでなく、Capacitor も検討に入れることができた ○ 広く浅いインデックス的知識によって選択肢が広がる ● ビルドプロセスについての知識があったおかげで、SEO についての懸念を解消できた ○ 自社のビジネスインパクトが大きいポイントを考えて、 関連分野に専門性を持っておくと思わぬところで応用が効きやすい ● ユーザー体験を妥協することで、高速にリリースして不確実性を潰せた ○ 作り手として直感的には悔しいが、中長期で提供価値を最大化し、 最短距離でミッション達成を目指す目線を持つ

20 目次 症状検索エンジン「ユビー」の紹介 モバイルアプリ開発の背景 モバイルアプリ開発における意思決定 意思決定の振り返り これからの展望 まとめ

21 コードベースの分離 これからの展望 ● ブラウザ版とモバイルアプリ版の分岐が増えて複雑化してきた ○ 提供したい体験の差分が大きくなってきている ● うまくコンポーネントを共通化しつつ、大元のコードベースは分離して整理する方向性 ● まずは共通化できるコンポーネントの切り出しからやっていく

22 ユーザー体験の改善 これからの展望 ● コードベースを分離すると、より抜本的な体験改善をしやすくなる ○ アニメーション等によるページ遷移の視認性・操作性向上 ○ タブごとの履歴管理の改善 ○ サービスワーカーによるオフライン対応

23 目次 症状検索エンジン「ユビー」の紹介 モバイルアプリ開発の背景 モバイルアプリ開発における意思決定 意思決定の振り返り これからの展望 まとめ

24 まとめ ● Capacitor をうまく使うことでモバイルアプリを短期間にリリースできた ● インデックス的知識をベースに、専門性をスケールさせる ● 非連続な大きい変化ではなく、いかに現実的で連続的な進化を描くかがテックリード業の肝

25 採用 まずはお話させてください！！！ https://meety.net/matches/ivWSVUlcTGtZ Meety 採用サイト