Share
Embed
Transcript
55 slides
-
Copyright Kanmu, Inc. All right reserved. 2 伊藤 友気 Kanmu,
Inc. @mururu @mururururu 自己紹介 -
Copyright Kanmu, Inc. All right reserved. 3 会社とプロダクト カンム と
React Native の歴史 バンドルカードの現在 構成・運用 カンム と React Native のこれから 1 2 3 アジェンダ 4 -
Copyright Kanmu, Inc. All right reserved. 4 React Native を採用しそれなりの期間を運用してきた一例につい
てその背景から示すことにより、React Native 採用の判断や運用 について少しでも参考になったらうれしいです -
6 Copyright Kanmu, Inc. All right reserved. カンムが目指すこと 心理的unbankedをソフトウェアで解決する 世界には金融サービスを利用することができないというunbanked層が存在します。
日本ではunbanked層は少ないのですが、面倒、難しい、怖い、不安という気持ちから 様々な金融サービスから距離をとっている心理的unbanked層が多いと感じています。 そんな心理的unbankedを解決するソフトウェアを開発します。 -
10 Copyright Kanmu, Inc. All right reserved. リターンやリスクがわかりやすい 投資を始められない大きな理由の1つに 「損失が怖い」が挙げられます。
Pool ではリターンやリスクを わかりやすくする機能を目指しています。 手元の資産としても使える Pool では投資資産が付帯の クレジットカードの支払いにも充てられ、 投資のリターンとカード決済の1% キャッシュバックで幅広い人が資産形成に 活用できるような機能を目指しています。 Pool が目指していること - 預金から投資へ -
Copyright Kanmu, Inc. All right reserved. 13 バンドルカード以前(約8年前) 購買データ カードの明細ページに
クーポンを配信 カード会社 カンム カードの明細ページ -
Copyright Kanmu, Inc. All right reserved. 14 バンドルカード以前(約8年前) • 提携先のカード会社/加盟店を広げていくことのハードルがあま
りにも高すぎた ◦ 実績のないスタートアップ ◦ 当時は FinTech という言葉も定着していない時代 • 自分たちにコントロールできることが少ない ◦ そもそもカードのWeb明細を頻繁に見る人は少ない -
Copyright Kanmu, Inc. All right reserved. 16 当時の状況 • エンジニア2名、デザイナ1名
◦ Swift や Java を書いたことのあるメンバーはいない ◦ React の経験はあった ◦ アプリの開発に避けるリソースはエンジニア1人 + デザイナ 0.5 人分 -
Copyright Kanmu, Inc. All right reserved. 17 当時の選択肢 • ネイティブ
◦ 妥当な選択肢 • PhoneGap などのクロスプラットフォーム開発環境 ◦ それまでの経験でパフォーマンスに厳しい印象があった • React Native ◦ 約半年前(2015/03)に Facebook がオープンソース化したと ころだった ◦ 当時のチームのスキルセットにあっていそうに見えた -
Copyright Kanmu, Inc. All right reserved. 18 当時の選択肢 • ネイティブ(Swift/Java)
◦ 妥当な選択肢 • PhoneGap などのクロスプラットフォーム開発環境 ◦ それまでの経験でパフォーマンスに厳しい印象があった • React Native ◦ 約半年前(2015/03)に Facebook がオープンソース化したと ころだった ◦ 当時のチームのスキルセットにあっていそうに見えた ◦ まずこの検証から始めていく -
Copyright Kanmu, Inc. All right reserved. 19 検証の結果 • プロトタイピングを始めたのが
0.11 ◦ Android がサポートされ始めたバージョン ◦ Android ビルドはまともに動かかなかったので iOS のみ • 当時のPhoneGapと比べると圧倒的に体験が良かった ◦ アニメーションが自然でふつうのネイティブアプリと遜色なくて びっくりした ◦ スタイリングがHTML/CSSでないことに不安があったがすぐ に慣れた (むしろ楽になった) • これまでのスキルセットの延長で必要な品質のアプリケーション が作成できそう -
Copyright Kanmu, Inc. All right reserved. 20 React Native 採用理由のまとめ
• とても少人数かつネイティブ開発経験がないWeb開発経験者の みのチームであったこと • とにかく素早くリリースして仮説を検証したかったこと • 検証の結果 iOS に関しては十分な品質のものを素早くリリース できるであろうことが確認できたこと ◦ Android に関する判断は後回し -
Copyright Kanmu, Inc. All right reserved. 22 • ターゲットは iOS
のみ • React Native のバージョンは v0.15.0 ◦ ここからリリースまでに v0.32.0 まで進む ◦ 常に最新版を追従していた ◦ 毎月軽いBreaking Changesが入る感じだったが大きくはつ まずかなかった 開発のはじまり(2015/12) -
Copyright Kanmu, Inc. All right reserved. 23 当時の設計 • redux,
redux-thunk • src 直下に actions, reducers, components などが並ぶフラット な構成 • このころは見本どおりのオーソドックスでシンプルな作りだった -
Copyright Kanmu, Inc. All right reserved. 25 Android版リリース(2016/12) 開発初期は iOS
のみでとりあえず実装してリリースし、Android 版 もそこまで大きな変更は必要ないと見込んでいた 実際にはアニメーション系などいくつかクラッシュする部分の発生 や、Android 対応を謳っているものの Android で動作しないライブ ラリも多く存在していた 一旦別ブランチでのリリースを決定 このタイミングで iOS 版は 0.35 Android 版は 0.39 -
Copyright Kanmu, Inc. All right reserved. 26 iOS/Androidブランチ統合(2017/01) ここで一旦 React
Native で iOS/Android 版を実装するというゴー ルは達成できた -
Copyright Kanmu, Inc. All right reserved. 27 粛々とプロダクト改善期間 • React
Native のアップデートがつらいものがたまにある ◦ 0.57 -> 0.60での64bit / AutoLinkingなど • それにともなう Flow のアップデートもつらい • 機能追加によるコードベース増加に伴い、構成変更の実験をし 始める -
Copyright Kanmu, Inc. All right reserved. 28 大幅な仕様変更 • サービスの仕様に大きく変更が入った
◦ 一人のユーザーが複数種類のカードを所持するようになった ◦ 会員登録後に発行するカードを選べるようになった ◦ 提携カードとして展開していくため、カード毎の機能を柔軟に 切り替えられるようになった • 当然アプリのUI/仕様も大きな変更が必要だった -
Copyright Kanmu, Inc. All right reserved. 29 Web版リリース (2017/09) •
Web での提供を決定 • 当時はまだ React Native for Web などもこなれていないので 別のアプリケーションとして開発をすすめる • ただしドメインモデルなど一部をアプリ、Webで共通化しようと試 みる ◦ この部分を大幅仕様変更と同時に進めてしまった ◦ これが結局うまく行かず中途半端な負債として残ることに -
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対応版/非対応版を別ブ ランチで管理 -
Copyright Kanmu, Inc. All right reserved. 31 課題: デザイン連携 •
デザイナー不在の時期、デザイナーがいきなり実装していた時 代などがあり、実装とデザインファイルの一致してない部分が発 生していた • 新しいエンジニア/デザイナーが入社してもうまく乗れてないとこ ろがあった • 一致しているところにしてもコンポーネントに一貫したルールがな く自由闊達だった -
Copyright Kanmu, Inc. All right reserved. 32 課題: デザイン連携 •
まず画面の洗い出し(100ページ以上)からはじめ、愚直にデザ インファイルと同期していこうとした ◦ コードを先行して改修しあとでデザインリソースを見直す方針 にしていたが、期間が長引き乖離が発生 • 機能改修にあわせて漸進的に同期していく方式に変更、より高 頻度でルールを擦り合わせ、デザイナー主導でコードとデザイン リソースを同時に改修していくようにした • デザイナーもStorybook にて実際のコンポーネントの実装状況 を確認できる状況を用意した -
Copyright Kanmu, Inc. All right reserved. 34 現在の構成 • React
Native, JavaScript, Flow, Redux, Storybook, Firebase など • 日常のほとんどの開発が React の世界のエコシステムの範囲ですんでい る • Expo は使っていない • リリースサイクルはおよそ週1 -
Copyright Kanmu, Inc. All right reserved. 35 ビルド/リリース周り • 基本的にビルド/リリースはfastlaneで完結させ、CIはBitriseにの
せている • lint やテストなどは社内の別のプロジェクトと共通で CircleCI 利 用 • 開発版の社内への配布は DeployGate を利用 -
Copyright Kanmu, Inc. All right reserved. 37 API 連携 •
JSON Hyper-Schema からAPIクライアントの実 装を自動生成している • バックエンドのAPIサーバーも同じスキーマからリ クエスト/レスポンスの構造体やバリデーション実 装を自動生成している -
Copyright Kanmu, Inc. All right reserved. 38 テスト • ロジック部分のテスト:
Jest • コンポーネントのテスト: snapshot testing • E2E テストはない -
Copyright Kanmu, Inc. All right reserved. 39 デバッグ • react-native-debugger
• Flipper に移行予定 ◦ 過去に導入を試みた際にビルドがとても遅くなった ことがあり、一旦移行していないが再度試したい -
Copyright Kanmu, Inc. All right reserved. 40 Storybook • いわゆるUIコンポーネントカタログ的な使い方
• それに加えてほぼ全てのコンポーネント/ページを Storybook化している ◦ Storyshots で Snapshot testing を行うことで影響範囲 を把握できるように -
Copyright Kanmu, Inc. All right reserved. 41 エラートラッカー/クラッシュレポート • Sentry
◦ 当初よりエラートラッキングに利用 ◦ 定期的にトリアージして issue に転記して対応 • Firebase Crashlytics ◦ クラッシュレポート ◦ Firebase で記録しているイベント紐付けられるので 便利 ◦ あくまでも Sentry の補助的な役割 -
Copyright Kanmu, Inc. All right reserved. 42 Firebase の他の機能 •
Analytics ◦ 行動ログは Firebase Analytics で収集 ◦ react-navigation の遷移イベントをフックに ページ遷移のトラッキングなども • Remote Config ◦ 任意のタイミングで表示を切り替えたい場合 (ex. アドホックな文言の変更 ◦ A/B テスト -
Copyright Kanmu, Inc. All right reserved. • だれがやっても同じになるように ◦ PRで不毛なやり取りが行われたらdangerのルールとして定
義や見直し ◦ Contribution Guidelinesを用意 ◦ 新規ファイル作成用のジェネレータを用意して定期的に更新 して参考実装的に使っている ◦ 使ってないファイルをCIで警告 • React Native のアップデートはマイナーバージョンは常に確認し ており、大きめの変更やセキュリティアップデートがありそうなら アップデートする ◦ アップデートにともなう Flow の修正が大変 43 細かい運用話 -
Copyright Kanmu, Inc. All right reserved. 44 Expo は? •
開発を始めたタイミングで Expo という選択肢はほぼないに等し かった • 現在は Expo のモジュールを適宜利用 -
Copyright Kanmu, Inc. All right reserved. 45 Native Module は?
• 小さな2つだけ自分たちで管理している ◦ スクリーンショットの制御周り ◦ ローカル認証の制御 -
Copyright Kanmu, Inc. All right reserved. 47 課題①: TypeScript 化
• 当初から Flow + Javascript • そろそろ Flow をサポートしないライブラリも出てきているので、 身動きが取れなくなる前に TypeScript に移行したい • 新しく入ってくるメンバーもだいたい TypeScript に慣れている -
Copyright Kanmu, Inc. All right reserved. 48 課題2: デザイン連携の効率化 •
先程述べたようにデザイナーとの連携、コンポーネントの整理を 進めているがこれを完遂し、継続的に維持できる状況にしなけ ればならない -
Copyright Kanmu, Inc. All right reserved. 49 pool について •
新規プロダクトにおいても React Native を採用している • なぜ React Native を採用したか ◦ 人もノウハウも社内に十分な蓄積がある ◦ React Native 自体が衰退しているような状況ではない ◦ React Native で問題がないようなアプリケーションであ る ▪ ネイティブモジュールを書かなければ行けない場面 は少なそう ▪ 複雑なインタラクションのないシンプルなクライアント アプリである -
Copyright Kanmu, Inc. All right reserved. 50 pool について •
バンドルカードで得ている課題感、できていないことを解消した状態で 進めている ◦ TypeScript の採用 ▪ Flow のアップデートつらい ◦ Redux Toolkit の採用 ▪ ボイラープレートの削減 ◦ コンポーネントもデザイナーと最初から一貫した基準を共有しなが ら目線を合わせて進められている ◦ Hermes の導入 -
Copyright Kanmu, Inc. All right reserved. 52 今後 • 既存のアプリケーションにおいてはまだ
React Native を使い続けるつもりである • 新しいアプリケーションにおいても React Native の 恩恵が受けられるものである限りは React Native を採用すると思う -
Copyright Kanmu, Inc. All right reserved. 53 React Native を採用してよかったか
• あのタイミングでは間違いなくよい選択をしたと思う • 今後もまだ React Native を中心に据えていくだろうと 思う