「スタディサプリ」が React Native から卒業するまで、あるいは技術的負債への感謝と敬意

こんにちは、Quipper iOS エンジニアの @manicmaniac です。現在スタディサプリ iOS アプリ開発チームのエンジニアリングマネージャをしています。

今回はスタディサプリで長らく使われていた React Native のコードを Swift に書き換えた話をします。実は React Native から Swift への置き換え自体は半年ほど前に完了していたのですが、ブログに記すのに時間がかかってしまいました。

スタディサプリにおける React Native の利用

Quipper では 2017年ごろから React Native を iOS / Android アプリ開発に利用し始め、スタディサプリでは 2018年3月ごろから徐々に React Native を iOS アプリケーション開発に導入していました。

iOS 版スタディサプリの、git から取り出した Swift / TypeScript の行数は以下のように推移しています。

当時の記事には React Native 導入の経緯や目的、苦労がまとまっているのでそちらに解説を譲り、要約をご説明します。

まず、React Native 導入によって解決したかった課題は以下のようなものでした。

モバイルエンジニア不足の解消
開発とリリースの高速化
Web フロントエンドとの設計の統一、コードの共用

またスタディサプリでは React Native の部分的な導入を進めていました。 React Native を削除するプロジェクトが開始した時点では、3つの機能が React Native で実装されていました。それぞれの機能の規模としては中程度で、例を挙げると、このうちの1つであるプロフィール機能では最終的に追加された行数は8800行程度となっていました。

なぜやめるか

ひとことで言うと、導入の目的の多くがすでに別の手段で解消されており、継続していくメリットが乏しくなったことが原因です。具体的には、以下の要因が挙げられます。

エンジニア組織の拡大
- Swift 経験豊富な iOS エンジニアが十分な数確保でき、開発リソースの乏しさが解消した
  - React Native の学習コストを支払うより Swift で書いた方が開発スピードが稼げるようになった
- Web とモバイルの分業が進み、 Web エンジニアがモバイル開発することが難しくなってきた
  - Web フロントエンドとの設計・実装の共通化はメンテナンスされなくなっていった
プロダクトの成長に伴う要件の変化
- ユーザー数が増え、素早くリリースする必要よりも長期的に安定的な品質を確保する必要性が大きくなった

一方で、React Native を継続することによるデメリットも大きくなってきました。

React Native に詳しいエンジニアの不足
- React Native に詳しいエンジニアが退職した
- React Native を強みとするエンジニアは転職市場に少なく、新規採用が難しい
当時使っていた React Native バージョンが審査通過しなくなる見込みだった
- UIWebView の API が使われていたが、これは 2021年からは審査通過しなくなるというアナウンスがあった
- バージョンアップを試行したが、相当の工数がかかる

これらの課題を解決するため、React Native 実装部分の Swift 化に腰を据えて取り組むことを決定しました。

どうやってやめたか

定常的な開発と脱 React Native を同時に進めるため、あらかじめ PM の @shunsuke-nishimura と相談しプロダクト開発のロードマップに載せてもらいました。 React Native 継続によって今後の開発スピードが低下する可能性があることや品質面でのリスクなどを説明し、2020年の上期から本格的に実装に取り掛かりました。

開発にあたっては、当時スタディサプリの開発を担当していた iOS エンジニア 3名でそれぞれの機能を担当しましたが、以下のような点に気をつけていました。

実装知識のサイロ化が進まないよう相互にレビューを行い、適宜ペアプログラミングを取り入れること
実装 issue と PR を分割することで全体の進捗を見える化し、レビューを容易にすること
機能のリリース時期をずらして、他の開発にリソースを確保し、ビッグバンリリースが生まれないようにすること

やめてどうだったか

2020年末ごろにすべての機能のリリースが完了し、脱 React Native をすることに成功しました。心配されていた不具合も致命的なものはほとんどなく、現在まで安定して稼働しています。

Swift 化によって当初の課題は解決され、さらに実装に参加したメンバーが各機能のドメイン知識を得られるという副次的な効果も得られました。

導入は失敗だったのか

私たちは一度導入した React Native を再度外す決断をし、それを実行しました。では React Native の導入は誤りだったのでしょうか。私はそうは思いません。

Quipper における React Native の導入は本来の意味での技術的負債でした。

2017年頃に立ち戻ると、スタディサプリは今ほど市場での支持を得られておらず、どんどん新しいことを試していかなければならない場面でした。しかし、やりたいことに対してモバイルの開発力は恒常的に不足している状況でした。

React Native の導入はこの課題を鮮やかに解決しました。比較的余裕のあった Web エンジニアのリソースを使ってモバイルアプリケーションの開発を加速することができたからです。この判断がなければ、開発速度の低下したスタディサプリは市場での競争力を失い、現在のように多くの生徒・学生に使ってもらうことはできなくなっていたでしょう。すなわち、React Native 導入という一時的な「借金」をしたおかげで現在の成功があると考えています。

この数年で、スタディサプリというプロダクトは大きくなり、これを取り巻く環境は大きく変化しました。組織も大きくなる中で React Native 導入当初の課題は解決され、より長期的に安定したプロダクトを作っていく要求が高まってきました。 React Native がもたらす「利息」の影響は我々にとって足枷になってきましたが、おかげでプロダクトは大きく成長し、課題自体を陳腐化するほどになりました。そのような状況を作ることができたことこそ、当初の導入の判断が誤っていなかったという証左だと思っています。

まとめ

Quipper における React Native の歩みについてご説明しました。初回のリリースから数年にわたって開発されて続けてきたスタディサプリにはこれ以外にも様々な技術的負債があります。私たちのビジョンである「世界の果てまで最高の学びを届ける」ために、必要があれば新たな借り入れをし、計画的な返済をしていこうと思っています。