Upgrade to Pro — share decks privately, control downloads, hide ads and more …

既存Webサービスのモバイルアプリ版を 1週間でリリースし、進化させてきた話

Yuku Kotani
October 19, 2022

既存Webサービスのモバイルアプリ版を 1週間でリリースし、進化させてきた話

【カケハシ/Ubie/ゆめみ】“変化に強いシステム”を実現するためにテックリードが行った取捨選択 –意思決定ポイント、苦労したことと乗り越え方-
https://techplay.jp/event/874532

Yuku Kotani

October 19, 2022
Tweet

More Decks by Yuku Kotani

Other Decks in Technology

Transcript

  1. 2 自己紹介 小谷 優空 (@yukukotani) • Software Engineer @ Ubie

    Discovery (2019/05~) ◦ プロダクト開発 (~2022/06) ◦ 技術戦略、設計、認証基盤 (~現在) • Student @ Univ. Tsukuba (2019/04~) ◦ 情報科学類 • Hobby Guitarist (2020/06~) 2
  2. 6 背景 • ユビーは Web アプリケーションとしてサービス提供してきた ◦ Next.js で実装されている •

    自然流入・広告によるユーザーが増えてきて、リテンションが欲しくなってくる • より生活に根差した、医療体験の起点となるプロダクトになっていきたい → せや!モバイルアプリや!
  3. 7 背景 でも... • 既存の資産はすべて Web 技術 • 歴史的経緯でフロントエンド側に実装が寄っていて、移植が大変 •

    モバイルアプリ開発自体に不確実性があり、まずは大きなコストをかけずに検証したい ◦ ストアの審査に問題なく通るか ◦ モバイルアプリのリターンはどれくらいか • 不確実性がクリアできたら、そのままサービス提供していきたい ◦ ブラウザ版の機能開発に追従する必要がある
  4. 10 Capacitor とは Capacitor の採用 • クロスプラットフォームアプリのフレームワーク • Web技術 (HTML5,

    CSS, JavaScript) で開発する • WebView に描画され、JavaScript API でネイティブ機能を呼び出せる プッシュ通知を送る例
  5. 11 他の選択肢との比較 Capacitor の採用 Capacitor Flutter React Native Kotlin /

    Swift 既存資産の流用 ◯ × △ △ 機能開発コスト ◯ △ △ × 人材獲得 ◯ × △ △ ユーザー体験 × △ △ ◯ • ブラウザ版の資産をそのまま動かせる部分が多く、素早い立ち上げが可能 • 今後の機能開発も大部分を共通化できる • 一方で、いわゆるネイティブっぽい体験は提供しにくい
  6. 12 なぜ Capacitor か Capacitor の採用 • サービスの性質上、リッチアニメーションのような描画コストの高い UI がない

    • まだ新規機能開発が活発なフェーズであり、完全に独立してモバイルアプリ開発をするのは大変 • OTAアップデートによってブラウザ版と同様に高速デプロイができる
  7. 14 アーキテクチャ ブラウザ版と共通のコードベースで実装 Browser Native App (Capacitor) Next.js Next.js GraphQL

    BFF Micro Services コードベースは同じだが、 ビルドを分けて 別インスタンスで配信
  8. 15 ビルド時に挙動を決定 ブラウザ版と共通のコードベースで実装 • 環境変数でブラウザ版とモバイルアプリ版の挙動を分岐 • ビルド時に定数置換と Dead Code Elimination、

    Tree Shaking が効く ◦ モバイルアプリ向けの実装やライブラリが ブラウザ版のバンドルサイズ(≒SEO)を毀損しない 定数置換 Dead Code Elimination ランタイムではなく ビルドタイムで ここまで最適化
  9. 16 WebViewからリモートサーバーにアクセス ブラウザ版と共通のコードベースで実装 • Capacitor の WebView からリモートサーバーの Next.js にアクセスする

    • ブラウザと同じ感覚でシンプルにOTAアップデートを実現できる • Capacitor ではリモートサーバーからの配信を推奨していないが、 メンテナの意見など一次情報を収集し、問題ないと判断 ◦ 今の所インターネット接続なしに提供できる機能がほぼないため、オフライン対応不要 ◦ 現在のストア規約では、リモート配信が明示的に許可されている (リンク) ionic-team/capacitor#4122
  10. 18 良かったこと・気になっていること 意思決定の振り返り Good • トップページ等から徐々にモバイルアプリ版を最適化できている • 新規機能もブラウザ版に追従して提供できている • 動き出しから1週間でリリースし、すぐに不確実性検証できた

    ◦ リテンション率の計測、リテンションユーザーへのインタビュー Bad • ユーザー体験にはまだまだ全く満足できていない • ブラウザ版とモバイルアプリ版の分岐が複雑化 • ネイティブアプリ側と JavaScript 側の Capacitor バージョン差異に気を使う必要がある
  11. 19 学び 意思決定の振り返り • 第一想起の Flutter, React Native だけでなく、Capacitor も検討に入れることができた

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