17 ポイント 投稿者 ahnheejong 2021-05-15 | 2件のコメント | WhatsAppで共有

最近、Coinbaseの開発者が新しいCoinbaseアプリがRNで書かれていることをTwitterで共有し、ちょっとした話題になっていました(https://twitter.com/htormey/status/…

以下、原文内容の要約訳です。

  • すでにiOS、Androidのネイティブアプリがある状況で、RNへ移行。移行の過程では200以上の画面規模に及ぶ巨大なネイティブアプリを再実装する必要があり、30人以上の既存ネイティブエンジニア向けに、移行のための社内RN講座も提供。

  • 多大な努力の末、ネイティブ時代と比べてパフォーマンス指標、ビジネス指標、アプリ評価、7 day crash freeユーザー率、Cold Startにかかる時間、タブ切り替え時間などの主要指標はすべて維持または改善。

  • 最初のアプリが2013年にリリースされ、2017年ごろにはAndroid/iOSそれぞれに小規模なチームがあったが、Web開発者に比べて採用があまりに難しく、Webプラットフォーム技術の進化速度がもたらす生産性にネイティブプラットフォーム技術が追いついていないと感じていた。何度かの試行錯誤の末、2018年にはモバイルプラットフォームのイテレーション速度と成長率の改善が必要であることが明白になった。

  • Coinbaseが製品をどう作るかをゼロから見直すことにした。主要機能は機能別組織として、バックエンド2人+各プラットフォーム(Web、Android、iOS)ごとにクライアント2人という体制で、1つのバーティカルのために多すぎる人員が必要だった。1つの機能チームの最小開発者数を8人から5人程度に減らし、クライアント開発者が複数プラットフォームをカバーできないかと考えるようになった。

  • これによりチーム編成の最小要件が緩和され、より効率的な開発が可能になり、クライアント開発者同士の接点が増えることを期待した。もちろん効率だけでは不十分で、その過程で顧客が感じる性能と品質も改善されてはじめて、その投資は正当化できると考えた。

  • 当時すでにReactベースのかなり成熟したWebプラットフォームチームが存在していた。複数のクロスプラットフォーム案を検討した結果、既存で使っている馴染みのある技術に基づき、Webとモバイルの統合への道筋が明確に見えたRNを選択。すでに稼働中のネイティブアプリも移行しなければならなかったため、段階的でショックの少ない移行を実現するために、数か月にわたる事前技術検証と戦略策定の期間を設けた。

  • まずはRNとネイティブの連携が不要なgreenfieldから始めるのがよいと考えた。Coinbase内でも複雑で、リアルタイム価格チャートやdepth chartなど性能が重要な機能が多く、当時モバイル提供していなかったProというWeb製品を先にアプリ化することを決定。ProをRNでうまく作れれば、他の(より複雑さが低く、性能要件もそこまで厳しくない)機能も無理なく移行できるだろうと仮定した。

  • 次に、Proと既存アプリで共有するオンボーディングフローをRNで実装し、それを既存のネイティブアプリに組み込んでみた。サービス提供地域が多様なため、オンボーディング部分はアプリの中でも最も複雑な部類に入り、従来は手を入れるのが非常に難しい箇所だった。Proで新しく作ることで、既存アプリのリファクタリングも兼ねられることを期待した。

  • 最後に、前の2つの工程で得た経験と知見をもとに、既存ネイティブアプリをRNで再実装。計画時点ではfull rewriteになるのか、ネイティブアプリに段階的にRN比率を増やしていく形になるのかは未定で、先行する2段階の結果を見て決めることにしていた。

  • 戦略を定め、2019年10月にProモバイルアプリをリリース。結果は期待以上だった。ビジネス成果も良く、性能上の課題となる箇所とその解決策について学べたほか、RNがもたらす生産性に非常に満足し、短期間でWebエンジニアがRNでも生産性を発揮できることも確認できた。

  • 勢いに乗ってオンボーディングフローの再実装も開始し、同様にビジネス面・アプリ品質面の両方で目標を達成。

オンボーディングフロー再実装自体の結果は良好だったが、既存アプリにRNを組み込むことの難しさを痛感した。

Web専業またはネイティブ専業の場合に比べて生産性も良くなく、両陣営から「それならなぜRNを使うのか」と感じるエンジニアが出てきた。(Airbnbの事例と非常によく似ており、実際にAirbnbのエンジニアと話しながら多くを学んだ)

  • 結果として、こうした教訓からネイティブとRNを併用するbrownfieldアプローチがあらゆる問題の根源だと判断し、既存アプリ全体をRNで再実装することを決定。

  • 2つのプラットフォームのうちAndroidアプリの移行のほうが、性能、パフォーマンス、生産性などの面でより難しいと考え、Androidを先に再実装の対象にした。これまでの経験からfull rewriteには6か月程度かかると見積もったが、得られる利益はコストを上回ると見込んだ。

  • 2020年3月にAndroidアプリの再実装を開始し、実際に6か月ほどかかった。その後に続いたiOSの再実装も2021年1月に完了。両プラットフォームで主要指標は良好な成果を示した。

  • 2020年半ばの時点で、Coinbaseには18人のiOSエンジニアと7人のAndroidエンジニアがいた。2021年5月現在、CoinbaseのRNリポジトリには113人のコントリビューターがいて、その中にはそれまでモバイルに貢献できなかったWebエンジニアも多数含まれている。

  • ネイティブエンジニアからRNエンジニアへの転換のためのトレーニングは大きな摩擦なく進み、従来ネイティブバックグラウンドだったエンジニアたちは現在RNアプリで高い成果を上げている。まだ完璧ではないが、当初期待していたとおり、各機能別組織では1つの「クライアントチーム」がすべてのクライアントプラットフォームをカバーする形になりつつある。

  • 3つ(React、iOS、Android)あったプラットフォームは2つ(React、RN)になったが、次のステップとしてそれを1.5個まで減らそうとしている。WebとRNで共有するデザインシステム、GraphQLベースの共通データレイヤー、インフラ系ツーリングなどの共有を計画中。1人のエンジニアが最小限のコンテキストスイッチだけでWebとモバイルの全プラットフォームに機能をデプロイできる姿を目指している。

  • 今後、技術的な難所やその過程で得た経験など、RNに関するさらに多くの記事を共有する予定。

2件のコメント

 
budlebee 2021-05-15

ラフテルのRN導入記を思い出しますね。

https://ridicorp.com/story/react-native-1year-review/

 
xguru 2021-05-15

日本国内の企業にもとても参考になりそうな記事ですね。要約翻訳ありがとうございます!