リクルートがB2Bのスマホアプリ開発でReact Nativeを採用した理由：Webフロントエンドエンジニアだけでスマホアプリ開発（1）

リクルートテクノロジーズが開発している、B2Bのスマホアプリ『Airシフト メッセージ用アプリ』。Webフロントエンドエンジニアだけで行っている開発の裏側を明かす連載。初回は、React Nativeを採用した背景などについて。

[辻健人，リクルートテクノロジーズ]

　こんにちは、リクルートテクノロジーズで『Airシフト』のフロントエンドの開発を担当している辻です。これから、連載で、『Airシフト メッセージ用アプリ』を開発した背景、さまざまな側面で工夫した点などを紹介していく予定です。楽しみにしていただけると幸いです。

『Airシフト』とは

　『Airシフト』は、シフト管理サービスです。シフト表の作成はもちろん、スタッフとのやりとりや細かな調整業務をラクにするための機能があります。直感的に操作できることを目指したシンプルな画面で、シフト表を作成できます。シフト表と一体となったチャット機能を使ってスタッフとのやりとりができるため、シフト表を作成しながら、急なシフト調整や連絡を取り合うことも可能です。

　最初に開発したWeb版の技術スタックとしては、React／Reduxをはじめ、チャット機能にWebSocketやSSR（Server Side Rendering）を、ユーザー認証やファイルダウンロードにBFF（Backends For Frontends）アーキテクチャを採用しています。

『Airシフト』Web版でReactを採用した背景

　『Airシフト』のメイン機能はシフト管理であるため、要件定義の段階当初から、UI（ユーザーインタフェース）が複雑になることが想定されました。

　実情として、複雑な表計算ソフトでシフトを管理している店舗は多く、そのソフト上できていたことをWebのUIでも再現する必要があったからです。加えて、ドラッグ＆ドロップでシフトの作成や調整ができたり、シフト表を操作しながらチャットができたりするなど、従来のWebアプリと比べて非常に多機能かつ複雑になることが予想できました。

　これらの要件から、「Single Page Application（以下、SPA）として実現する必要がある」と判断し、その中でも実装開始当初の時点でSSRの実績がある、WebフロントエンドのライブラリとしてReactを採用しました。

　またReduxの採用理由は、Fluxアーキテクチャを実現する最もポピュラーなライブラリであること、Viewを実現するライブラリと完全に切り離して扱うことができることなどです。

『Airシフト』におけるスマホアプリのニーズ

　『Airシフト』は当初、Web版しか提供しておらず、チャット機能において「通知に気付かない」「気軽にメッセージのやりとりができない」といった課題が見えてきました。

　そこで、チャット機能に焦点を当ててその課題を考えたときに、より手軽にチャットができて通知も受け取りやすいスマートフォン（スマホ）アプリ版を実装すれば、それらの課題を解決できるのではないかという仮説を立てました。その仮説を検証するためには、機能をチャットに絞ったスマホアプリ版を、高速で開発するための技術を選定する必要がありました。

React Nativeを選んだ理由

　結論から述べると、「チャット機能に絞ってスマホアプリ版を高速に開発」という条件を踏まえて、Reactをベースとしたクロスプラットフォームの開発フレームワーク「React Native」を採用しました。

　その背景には、そもそも『Airシフト』の開発チームには、スマホ開発経験のあるエンジニアが少ない上に、フロントエンドエンジニアが非常に多かったことがあります。また、フロントエンドエンジニアには「redux-pluto」というリクルート標準のボイラープレートを用いたReact／Reduxの開発経験があり、保有する技術のスキルセットが一貫していました。

　このような背景により、Web版と似たような構成にすることで、学習コストを最低限に抑えつつビジネスロジックなども再利用しながら、高速にスマホアプリ版を開発できるのではないかという期待を持つことができたのです。

　ところがReact Nativeは、高速に開発が行えるにもかかわらず、特に不自由なくスマホアプリが開発できるかというと、そうではなく、むしろ苦手とする部分もあります。苦手とする理由には大きく2点あります。

　1点目は、iOSが標準で提供しているようなアニメーションを含んだコンポーネントがReact Nativeの標準コンポーネントにはないことです。2点目は、React NativeとiOSのネイティブコードとでやりとりを行う「Bridge」という機能を使わなければ、プッシュ通知をはじめとしたデバイスを扱うのが難しいという点です。

　こうした点を踏まえビジネス要件から考えても、Bridgeを使わなければならないような機能は少ないということで、ここまでの条件から「最も早いリリースを実現できるツール」としてReact Nativeが最有力候補となりました。

　次に、このアプリに必要な機能がReact Nativeで実現できるのかどうかを検証することにしました。

　そもそも、React Nativeを使った開発で「通知に気付くことができない」「気軽にメッセージのやりとりができない」という課題が解決できるのかどうか。運用するに当たって必要なエラートラッキングや、デプロイ回りなど、その他の非機能要件を含めて問題がないのかどうか――それらを確かめるために、技術を検証することにしたわけです。

　検証対象は以下の通りです。

• 認証
• CI/CD（継続的インテグレーション／継続的デプロイ）
• クラッシュレポート
• アクセス解析
• プッシュ通知
• ストア申請
• β（社内実機）テスト
• Hot Code Push

　高速なリリースを実現するために、非機能要件については、Firebaseをなるべく活用する方針を採り、Firebaseの機能を中心に検証しました。

　また、アプリのリリースについては、手作業だとコストが大きく、ミスも生じやすいため、「Visual Studio App Center」で、ビルドや限定公開、リリースを実現できるかどうかも検証しています。

　検証の結果、機能要件、非機能要件ともにやりたいことができそうな見込みが立ったので、React Nativeを活用したスマホアプリ開発を行うに至りました。

プッシュ通知におけるExpoの検討

　なお、React Nativeアプリのビルド、デプロイにおいて便利なツール「Expo」の採用も検討しました。プッシュ通知においてExpoの機能を使えるかどうかを検討したのです。

　Expoには、「Expo SDK」というSDKが用意されています。Expo SDKのBridge機能は制約がありますが、ネイティブコードとのやりとりが可能です。ネイティブレベルの機能は全てExpo SDKとして隠蔽（いんぺい）されているため、よりWebフロントエンドの知識だけでモバイルアプリを実装できます。一方で、Expo SDKで提供されていないネイティブレベルの機能に関しては諦めるしかありません。

　もちろん、React Nativeではもともと、Bridge機能を利用することで、ネイティブレベルの機能をJavaScriptコードから活用することが可能です。機能としてできることの幅はExpoに比べて大きく、制約が厳しくないことから、安易にたくさんのBridgeを導入できてしまいます。それにより、運用コストは大幅に上がることになりかねません。

　こうした検討の結果、『Airシフト メッセージ用アプリ』ではプッシュ通知の要件を鑑み、「Expo Backend」に依存した通知システムであるExpoの採用を見送る方針に決定しました。

　とはいえ、前述のように考えなしでBridgeの導入を行うと、安定したアプリの運用が難しく安定性を維持できなくなってしまうため、そこに制約を設けながら開発を進めていくことにしています。

次回予告

　次回は、『Airシフト メッセージ用アプリ』の開発計画や、顧客の要望を引き出すための工夫について、同じく開発メンバーの髙橋から紹介する予定です。

筆者紹介

辻 健人（つじ けんと）

リクルートテクノロジーズ

ライフイベント領域エンジニアリング1部 APソリューショングループ所属

2018年4月、リクルートテクノロジーズに新卒入社。

現在は、店舗向けシフト管理サービス『Airシフト』の開発に従事。

機能を作るだけではなく、非機能要件を日々向上させるための取り組みも行っている。

趣味はうどん作り、うどんを食べること。