どんなチームがReact Nativeによる開発に向いているか

はじめに

最近はアプリ開発にReact Native（以下RN）を使用するケースも増えてきているようですが、RNはネイティブアプリを開発する最強のライブラリというわけではありません。 メリットをうまく利用すればとても良いアプリができると思いますが、失敗すると、さらに倍の時間をかけてSwift、Javaで作りなおし、、、といったことも発生するかもしれません。 特徴や他社事例をよく調査し、チームの状況に応じて、採用するかどうか判断することがとても大事です。 この記事では、どういった状況に置かれたチームが、RNで開発するのに適しているか、僕なりの考えを書きますので、参考にしていただければと思います。 RNがどういったものであるかの説明や、実装方法については書きません。

目次

  1. なるべく早くリリースしたいチーム
  2. iOS/Androidで仕様・見た目を揃えたいチーム
  3. WEBのエンジニアは足りているけど、ネイティブのエンジニアが十分にはいないチーム
  4. アプリのデザイン経験が無いデザイナが多いチーム
  5. アプリの改善サイクルをなるべく早く回したいチーム
  6. WEBとアプリの見た目を合わせたいチーム

  7. 最速・最高を求めないチーム

  8. なるべく早くリリースしたいチーム RNはiOS/Androidのソースを一括で記述／管理することが可能です。 また、ホットリロードが可能なので、修正後のビルドの時間も短くてすみます。 そのため、なるべく早くiOS/Androidアプリを開発したいというチームには適しているかと思います。 また、記述するのは主にJSなので、エディタやIDEも好みのものを使えます。 そのため、開発がより進むこともあるかもしれません。

  9. iOS/Androidで仕様・見た目を揃えたいチーム iOS、Androidを別の人が実装すると、仕様や認識のズレが発生したり、OS固有の理由により、出来る出来ないが発生したりするというのが、アプリ開発におけるあるあるかと思います。 RNで1ソースで管理すれば、そういったことも少なくなるでしょう。 また、もちろん、OSによって適したデザインがあると思いますが、それでも見た目を揃えたい箇所がある場合、実装が1箇所になるので目的は果たされるかと思います。 ただ、1箇所にまとめたコードの中で、あえてiOS/Androidそれぞれで処理を分岐させる箇所が多くなってくると、「一括でソースを管理しているのはなんでだっけ？」となるくらい、分岐が多く、読みづらいコードになる可能性もあります。 そういった場合には、*.ios.js 、 *.android.js などとファイルごと分けてしまうなど、設計を考える必要があるかと思います。

  10. WEBのエンジニアは足りているけど、ネイティブのエンジニアが十分にはいないチーム アプリの需要は依然として高く、ネイティブのエンジニアは売り手市場です。 基本的にどのチームもネイティブのエンジニアは足りていないと思います。 ただ、アプリ以外のエンジニアにも目を向けてみると、WEBのエンジニアであればJSを書いたことが無い人はあまりいないかと思うので、どうしても手が足りない場合には、少し（？）Reactを勉強してもらって、開発に携わってもらうこともできるかと思います。 ただ、リリースの際にXcodeを使うなど、iOS、Androidの知識は少なからず必要なので、ネイティブのエンジニアが全くいない状態でJSだけで書けるからとRNを採用するのはおすすめしません。 （その状態ではSwift、Android Javaでもアプリが作れるかというとわかりませんが。。。） まとめると、ネイティブの知識はゼロでは無く、少しは必要。ただ、WEBのエンジニアに手伝ってもらえる可能性もある、ということです。

  11. アプリのデザイン経験が無いデザイナが多いチーム RNの見た目の部分はcssライクに書くことができます。 また、見た目もネイティブよりかは自由度があります。 なので、アプリの経験がなくても、開発時には対応できるかと思います。 ただ、やはりアプリらしいデザインや、それぞれのOSに適したデザインがあるので、それは常に勉強して、改善していくのがいいかと思います。

  12. アプリの改善サイクルをなるべく早く回したいチーム RNを利用する大きなメリットとして、CodePushが利用可能であることがあげられます。 そのため、デリバリーの高速化が可能です。 ネイティブのデメリットとして、特にiOSですが、実装してもリリースまで時間がかかる、リリースしてもユーザーがアップデートしないと使ってもらえない/バグが直らない、というのがあります。 CodePushを使えば、実装したものをすぐに届けられるので、細かなバグ修正や、見た目の修正、ABテストもやりやすくなるのかなと思います。

  13. WEBとアプリの見た目を合わせたいチーム React Native for Webというものがあります。 最初は名前に少し違和感があるかと思いますが、スマホのブラウザから見た場合のWEBのHTMLをRNのようにコンポーネントでラップして開発できると考えるといいかもしれません。 こういったものを利用すれば、WEBとアプリの見た目を揃えたり、コンポーネントを共通化させて開発速度を上げることができるかもしれません。 少し難易度は高そうですが、細部から少しずつ挑戦してみるといいと思います。

  14. 最初から最速・最高を求めないチーム RNは一度JSを経由するため、ネイティブ実装に速度でまさることは出来ません。 また、ネイティブをちゃんと実装できるエンジニアがいて、時間も十分ある場合、（codepushを除いては）RNを利用するメリットはありません。 アプリ開発において、それに越したことはないです。 ただ、最初のリリースは品質は2の次でとにかく早く出したい、ユーザーの意見を聞いて早く改善していきたい、という場合には適しています。 それでサービスがスケールしたら、ネイティブのエンジニアを採用して、ネイティブで書き直すのがいいと思います。

まとめ

上にも書いたように、RNはアプリ開発における最適解ではありません。 ただ、適した場所で使用すればとてもメリットがあると思います。 上に書いたような環境に置かれた時に、開発の選択肢を増やす意味でも、RNを勉強しておくのがよいと思います。