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

カンム と React Native / Kanmu React Native

mururu
October 02, 2021

カンム と React Native / Kanmu React Native

React Native Matsuri 2021

mururu

October 02, 2021
Tweet

More Decks by mururu

Other Decks in Programming

Transcript

  1. Copyright Kanmu, Inc. All right reserved. 3 会社とプロダクト カンム と

    React Native の歴史 バンドルカードの現在 構成・運用 カンム と React Native のこれから 1 2 3 アジェンダ 4
  2. Copyright Kanmu, Inc. All right reserved. 4 React Native を採用しそれなりの期間を運用してきた一例につい

    てその背景から示すことにより、React Native 採用の判断や運用 について少しでも参考になったらうれしいです
  3. 6 Copyright Kanmu, Inc. All right reserved. カンムが目指すこと 心理的unbankedをソフトウェアで解決する 世界には金融サービスを利用することができないというunbanked層が存在します。

    日本ではunbanked層は少ないのですが、面倒、難しい、怖い、不安という気持ちから 様々な金融サービスから距離をとっている心理的unbanked層が多いと感じています。 そんな心理的unbankedを解決するソフトウェアを開発します。
  4. 10 Copyright Kanmu, Inc. All right reserved. リターンやリスクがわかりやすい 投資を始められない大きな理由の1つに 「損失が怖い」が挙げられます。

    Pool ではリターンやリスクを わかりやすくする機能を目指しています。 手元の資産としても使える Pool では投資資産が付帯の クレジットカードの支払いにも充てられ、 投資のリターンとカード決済の1% キャッシュバックで幅広い人が資産形成に 活用できるような機能を目指しています。 Pool が目指していること - 預金から投資へ
  5. Copyright Kanmu, Inc. All right reserved. 14 バンドルカード以前(約8年前) • 提携先のカード会社/加盟店を広げていくことのハードルがあま

    りにも高すぎた ◦ 実績のないスタートアップ ◦ 当時は FinTech という言葉も定着していない時代 • 自分たちにコントロールできることが少ない ◦ そもそもカードのWeb明細を頻繁に見る人は少ない
  6. Copyright Kanmu, Inc. All right reserved. 16 当時の状況 • エンジニア2名、デザイナ1名

    ◦ Swift や Java を書いたことのあるメンバーはいない ◦ React の経験はあった ◦ アプリの開発に避けるリソースはエンジニア1人 + デザイナ 0.5 人分
  7. Copyright Kanmu, Inc. All right reserved. 17 当時の選択肢 • ネイティブ

    ◦ 妥当な選択肢 • PhoneGap などのクロスプラットフォーム開発環境 ◦ それまでの経験でパフォーマンスに厳しい印象があった • React Native ◦ 約半年前(2015/03)に Facebook がオープンソース化したと ころだった ◦ 当時のチームのスキルセットにあっていそうに見えた
  8. Copyright Kanmu, Inc. All right reserved. 18 当時の選択肢 • ネイティブ(Swift/Java)

    ◦ 妥当な選択肢 • PhoneGap などのクロスプラットフォーム開発環境 ◦ それまでの経験でパフォーマンスに厳しい印象があった • React Native ◦ 約半年前(2015/03)に Facebook がオープンソース化したと ころだった ◦ 当時のチームのスキルセットにあっていそうに見えた ◦ まずこの検証から始めていく
  9. Copyright Kanmu, Inc. All right reserved. 19 検証の結果 • プロトタイピングを始めたのが

    0.11 ◦ Android がサポートされ始めたバージョン ◦ Android ビルドはまともに動かかなかったので iOS のみ • 当時のPhoneGapと比べると圧倒的に体験が良かった ◦ アニメーションが自然でふつうのネイティブアプリと遜色なくて びっくりした ◦ スタイリングがHTML/CSSでないことに不安があったがすぐ に慣れた (むしろ楽になった) • これまでのスキルセットの延長で必要な品質のアプリケーション が作成できそう
  10. Copyright Kanmu, Inc. All right reserved. 20 React Native 採用理由のまとめ

    • とても少人数かつネイティブ開発経験がないWeb開発経験者の みのチームであったこと • とにかく素早くリリースして仮説を検証したかったこと • 検証の結果 iOS に関しては十分な品質のものを素早くリリース できるであろうことが確認できたこと ◦ Android に関する判断は後回し
  11. Copyright Kanmu, Inc. All right reserved. 22 • ターゲットは iOS

    のみ • React Native のバージョンは v0.15.0 ◦ ここからリリースまでに v0.32.0 まで進む ◦ 常に最新版を追従していた ◦ 毎月軽いBreaking Changesが入る感じだったが大きくはつ まずかなかった 開発のはじまり(2015/12)
  12. Copyright Kanmu, Inc. All right reserved. 23 当時の設計 • redux,

    redux-thunk • src 直下に actions, reducers, components などが並ぶフラット な構成 • このころは見本どおりのオーソドックスでシンプルな作りだった
  13. Copyright Kanmu, Inc. All right reserved. 25 Android版リリース(2016/12) 開発初期は iOS

    のみでとりあえず実装してリリースし、Android 版 もそこまで大きな変更は必要ないと見込んでいた 実際にはアニメーション系などいくつかクラッシュする部分の発生 や、Android 対応を謳っているものの Android で動作しないライブ ラリも多く存在していた 一旦別ブランチでのリリースを決定 このタイミングで iOS 版は 0.35 Android 版は 0.39
  14. Copyright Kanmu, Inc. All right reserved. 26 iOS/Androidブランチ統合(2017/01) ここで一旦 React

    Native で iOS/Android 版を実装するというゴー ルは達成できた
  15. Copyright Kanmu, Inc. All right reserved. 27 粛々とプロダクト改善期間 • React

    Native のアップデートがつらいものがたまにある ◦ 0.57 -> 0.60での64bit / AutoLinkingなど • それにともなう Flow のアップデートもつらい • 機能追加によるコードベース増加に伴い、構成変更の実験をし 始める
  16. Copyright Kanmu, Inc. All right reserved. 28 大幅な仕様変更 • サービスの仕様に大きく変更が入った

    ◦ 一人のユーザーが複数種類のカードを所持するようになった ◦ 会員登録後に発行するカードを選べるようになった ◦ 提携カードとして展開していくため、カード毎の機能を柔軟に 切り替えられるようになった • 当然アプリのUI/仕様も大きな変更が必要だった
  17. Copyright Kanmu, Inc. All right reserved. 29 Web版リリース (2017/09) •

    Web での提供を決定 • 当時はまだ React Native for Web などもこなれていないので 別のアプリケーションとして開発をすすめる • ただしドメインモデルなど一部をアプリ、Webで共通化しようと試 みる ◦ この部分を大幅仕様変更と同時に進めてしまった ◦ これが結局うまく行かず中途半端な負債として残ることに
  18. Copyright Kanmu, Inc. All right reserved. 30 大変だったこと: Android4.4 対応

    もともと Android 4.4 系で原因特定が難しいクラッシュが発生しが ちであった Android の 64bit 対応のため React Native 0.60 へのアップデー トを試みた所、Android 4.4 系でのクラッシュが爆増し断念 → 4.4 系のサポート終了を決定 終了までの間 Multiple APK にして 64bit対応版/非対応版を別ブ ランチで管理
  19. Copyright Kanmu, Inc. All right reserved. 31 課題: デザイン連携 •

    デザイナー不在の時期、デザイナーがいきなり実装していた時 代などがあり、実装とデザインファイルの一致してない部分が発 生していた • 新しいエンジニア/デザイナーが入社してもうまく乗れてないとこ ろがあった • 一致しているところにしてもコンポーネントに一貫したルールがな く自由闊達だった
  20. Copyright Kanmu, Inc. All right reserved. 32 課題: デザイン連携 •

    まず画面の洗い出し(100ページ以上)からはじめ、愚直にデザ インファイルと同期していこうとした ◦ コードを先行して改修しあとでデザインリソースを見直す方針 にしていたが、期間が長引き乖離が発生 • 機能改修にあわせて漸進的に同期していく方式に変更、より高 頻度でルールを擦り合わせ、デザイナー主導でコードとデザイン リソースを同時に改修していくようにした • デザイナーもStorybook にて実際のコンポーネントの実装状況 を確認できる状況を用意した
  21. Copyright Kanmu, Inc. All right reserved. 34 現在の構成 • React

    Native, JavaScript, Flow, Redux, Storybook, Firebase など • 日常のほとんどの開発が React の世界のエコシステムの範囲ですんでい る • Expo は使っていない • リリースサイクルはおよそ週1
  22. Copyright Kanmu, Inc. All right reserved. 35 ビルド/リリース周り • 基本的にビルド/リリースはfastlaneで完結させ、CIはBitriseにの

    せている • lint やテストなどは社内の別のプロジェクトと共通で CircleCI 利 用 • 開発版の社内への配布は DeployGate を利用
  23. Copyright Kanmu, Inc. All right reserved. 37 API 連携 •

    JSON Hyper-Schema からAPIクライアントの実 装を自動生成している • バックエンドのAPIサーバーも同じスキーマからリ クエスト/レスポンスの構造体やバリデーション実 装を自動生成している
  24. Copyright Kanmu, Inc. All right reserved. 38 テスト • ロジック部分のテスト:

    Jest • コンポーネントのテスト: snapshot testing • E2E テストはない
  25. Copyright Kanmu, Inc. All right reserved. 39 デバッグ • react-native-debugger

    • Flipper に移行予定 ◦ 過去に導入を試みた際にビルドがとても遅くなった ことがあり、一旦移行していないが再度試したい
  26. Copyright Kanmu, Inc. All right reserved. 40 Storybook • いわゆるUIコンポーネントカタログ的な使い方

    • それに加えてほぼ全てのコンポーネント/ページを Storybook化している ◦ Storyshots で Snapshot testing を行うことで影響範囲 を把握できるように
  27. Copyright Kanmu, Inc. All right reserved. 41 エラートラッカー/クラッシュレポート • Sentry

    ◦ 当初よりエラートラッキングに利用 ◦ 定期的にトリアージして issue に転記して対応 • Firebase Crashlytics ◦ クラッシュレポート ◦ Firebase で記録しているイベント紐付けられるので 便利 ◦ あくまでも Sentry の補助的な役割
  28. Copyright Kanmu, Inc. All right reserved. 42 Firebase の他の機能 •

    Analytics ◦ 行動ログは Firebase Analytics で収集 ◦ react-navigation の遷移イベントをフックに ページ遷移のトラッキングなども • Remote Config ◦ 任意のタイミングで表示を切り替えたい場合 (ex. アドホックな文言の変更 ◦ A/B テスト
  29. Copyright Kanmu, Inc. All right reserved. • だれがやっても同じになるように ◦ PRで不毛なやり取りが行われたらdangerのルールとして定

    義や見直し ◦ Contribution Guidelinesを用意 ◦ 新規ファイル作成用のジェネレータを用意して定期的に更新 して参考実装的に使っている ◦ 使ってないファイルをCIで警告 • React Native のアップデートはマイナーバージョンは常に確認し ており、大きめの変更やセキュリティアップデートがありそうなら アップデートする ◦ アップデートにともなう Flow の修正が大変 43 細かい運用話
  30. Copyright Kanmu, Inc. All right reserved. 44 Expo は? •

    開発を始めたタイミングで Expo という選択肢はほぼないに等し かった • 現在は Expo のモジュールを適宜利用
  31. Copyright Kanmu, Inc. All right reserved. 45 Native Module は?

    • 小さな2つだけ自分たちで管理している ◦ スクリーンショットの制御周り ◦ ローカル認証の制御
  32. Copyright Kanmu, Inc. All right reserved. 47 課題①: TypeScript 化

    • 当初から Flow + Javascript • そろそろ Flow をサポートしないライブラリも出てきているので、 身動きが取れなくなる前に TypeScript に移行したい • 新しく入ってくるメンバーもだいたい TypeScript に慣れている
  33. Copyright Kanmu, Inc. All right reserved. 48 課題2: デザイン連携の効率化 •

    先程述べたようにデザイナーとの連携、コンポーネントの整理を 進めているがこれを完遂し、継続的に維持できる状況にしなけ ればならない
  34. Copyright Kanmu, Inc. All right reserved. 49 pool について •

    新規プロダクトにおいても React Native を採用している • なぜ React Native を採用したか ◦ 人もノウハウも社内に十分な蓄積がある ◦ React Native 自体が衰退しているような状況ではない ◦ React Native で問題がないようなアプリケーションであ る ▪ ネイティブモジュールを書かなければ行けない場面 は少なそう ▪ 複雑なインタラクションのないシンプルなクライアント アプリである
  35. Copyright Kanmu, Inc. All right reserved. 50 pool について •

    バンドルカードで得ている課題感、できていないことを解消した状態で 進めている ◦ TypeScript の採用 ▪ Flow のアップデートつらい ◦ Redux Toolkit の採用 ▪ ボイラープレートの削減 ◦ コンポーネントもデザイナーと最初から一貫した基準を共有しなが ら目線を合わせて進められている ◦ Hermes の導入
  36. Copyright Kanmu, Inc. All right reserved. 52 今後 • 既存のアプリケーションにおいてはまだ

    React Native を使い続けるつもりである • 新しいアプリケーションにおいても React Native の 恩恵が受けられるものである限りは React Native を採用すると思う
  37. Copyright Kanmu, Inc. All right reserved. 53 React Native を採用してよかったか

    • あのタイミングでは間違いなくよい選択をしたと思う • 今後もまだ React Native を中心に据えていくだろうと 思う