カンムと React Native / Kanmu React Native

by mururu

Slide 1

Slide 1 text

カンムと React Native Yuki Ito React Native Matsuri 2021

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

会社とプロダクト 1

Slide 6

Slide 6 text

6 Copyright Kanmu, Inc. All right reserved. カンムが目指すこと心理的unbankedをソフトウェアで解決する世界には金融サービスを利用することができないというunbanked層が存在します。日本ではunbanked層は少ないのですが、面倒、難しい、怖い、不安という気持ちから様々な金融サービスから距離をとっている心理的unbanked層が多いと感じています。そんな心理的unbankedを解決するソフトウェアを開発します。

Slide 7

Slide 7 text

誰でも作れるVisaプリペイドカード手元の資産形成に活用できるクレジットカード New

Slide 8

Slide 8 text

誰でも作れるVisaプリペイドカード

Slide 9

Slide 9 text

手元の資産形成に活用できるクレジットカード

Slide 10

Slide 10 text

10 Copyright Kanmu, Inc. All right reserved. リターンやリスクがわかりやすい投資を始められない大きな理由の1つに「損失が怖い」が挙げられます。 Pool ではリターンやリスクをわかりやすくする機能を目指しています。手元の資産としても使える Pool では投資資産が付帯のクレジットカードの支払いにも充てられ、投資のリターンとカード決済の1% キャッシュバックで幅広い人が資産形成に活用できるような機能を目指しています。 Pool が目指していること - 預金から投資へ

Slide 11

Slide 11 text

Slide 12

Slide 12 text

カンムと React Native の歴史 1

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Copyright Kanmu, Inc. All right reserved. 20 React Native 採用理由のまとめ ● とても少人数かつネイティブ開発経験がないWeb開発経験者のみのチームであったこと ● とにかく素早くリリースして仮説を検証したかったこと ● 検証の結果 iOS に関しては十分な品質のものを素早くリリースできるであろうことが確認できたこと ○ Android に関する判断は後回し

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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対応版/非対応版を別ブランチで管理

Slide 31

Slide 31 text

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

バンドルカードの現在構成・運用 3

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Copyright Kanmu, Inc. All right reserved. 42 Firebase の他の機能 ● Analytics ○ 行動ログは Firebase Analytics で収集 ○ react-navigation の遷移イベントをフックにページ遷移のトラッキングなども ● Remote Config ○ 任意のタイミングで表示を切り替えたい場合 (ex. アドホックな文言の変更 ○ A/B テスト

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

カンムと React Native のこれから 3

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Copyright Kanmu, Inc. All right reserved. 50 pool について ● バンドルカードで得ている課題感、できていないことを解消した状態で進めている ○ TypeScript の採用 ■ Flow のアップデートつらい ○ Redux Toolkit の採用 ■ ボイラープレートの削減 ○ コンポーネントもデザイナーと最初から一貫した基準を共有しながら目線を合わせて進められている ○ Hermes の導入