皆様こんにちは。スパイダープラス株式会社のプロダクトグループ技術推進部に所属する谷黒と申します。
GWが終わり梅雨に近づいてきました。新入社員の皆様は会社の空気に慣れてきた頃でしょうか。
さて、スパイダープラス株式会社では現場向けの「iOS/Androidアプリ」としてS+Partner（以下、SPP）のサービスを運用しております。このたびSPPのpush通知のサービスをFirebaseに移行いたしました。その件について今回お話させていただければと存じます。
モバイルpush通知のサービスの移行を検討している方に少しでもお役に足ればと思います。
背景
SPPは、主に建設現場での危険予知活動（KY）などに活用されているサービスで、ユーザー同士のコミュニケーションを強化するためにプッシュ通知機能を提供しています。
これまでプッシュ通知の実現には、ニフクラ mobile backend（ncmb）というサービスを使用してきました。しかし、ncmbのサービスが終了するとのことから、新たなサービスへの移行が必要となりました。
検討の結果、新しいプッシュ通知のプラットフォームとして、Firebase Cloud Messaging（FCM）を選びました。
なぜFCMを選定したか
Firebaseはプッシュ通知やアナリティクス、データベース、認証サービスなど多機能を一つのプラットフォームで提供しております。
また、Googleのインフラを利用し、アプリの成長に応じてスケール調整が可能であることや、iOS、Androidに対応し、Google Analytics統合による高度な分析機能も備え、広範なコミュニティと充実したサポートが利用可能など様々なメリットが期待できます。
以上の理由から移行先のサービスとしてFCMを採用いたしました。
どう移行したか 移行に際しての注意点
移行前の通知の流れ
SPPではMonacaというモバイルアプリ開発のプラットフォーム上で開発を行っています。
push通知では通知するデバイスを特定するために、Monaca上でユニークなトークンを発行する必要があります。ncmbではこれをinstallation_idとしています。
SPPはログイン後の処理をWebViewでWeb側の画面に表示しています。Web側でのPush通知処理のために、発行したinstallation_idをデバイスのLocalStorageに保存し、Web側はこの保存したトークンを取得してPush通知処理を行います。
今回のFCMへの移行ではアプリケーション側（Monaca）はNCMBプラグインからFCMプラグインへと変更しました。同時に、Web側にも新たにFCMのプッシュ通知処理を追加しました。
移行に際しての注意点
S+Partnerは稼働中のサービスで、その運用を中断することなく、ユーザビリティを維持しつつ移行を行うことが大切です。移行後、アプリを更新しないとPush通知ができなかったり、すぐに使用できないといった状態はユーザーにストレスを与え、サービスへの信頼性に影響するのでとても重要な要素となります。
そのため、ncmbのサービスが終了する1ヶ月前からは、新旧のサービスが共存する期間を設置しました。この期間を通じて、アプリを更新したユーザーも、更新していないユーザーも、どちらもサービスを利用し続けられるよう配慮しました。そして、この期間中にユーザーに対してアプリの更新をお知らせし、ncmbのサービスが終了するまでに全てのユーザーが新サービスにスムーズに移行できるように取り組みました。 このように、ユーザーの皆様にとってストレスを感じることなくサービスの移行を実現することを心がけました。
既存フローを洗い出す
移行期間中は、移行前と移行後のサービスの両方でプッシュ通知が利用可能でなければなりません。このためにまず、現行のプッシュ通知のフローを詳細に洗い出しました。 その結果をUMLなどを用いて図式化すると、一目で理解しやすくなります。図式化のメリットは視覚的に処理を理解でき、打ち合わせ時にフロー図を見ながらチーム内で意見を交換し、設計を進めることができる点にあります。
新処理を洗い出す
ncmbとFCMでは発行するデバイス固有のトークンが異なります。ncmbではinstallation_idでしたがFCMではdeviceTokenとなります。
アプリをFCMにアップデートしたらweb側にはdevice_tokenが渡されますが、web側ではinstallation_idかdevice_tokenかを判断できません。device_tokenとあわせてアプリが新しくなったかどうかを判定するis_newをweb側に渡し、is_newをもとにFCMのpush通知とncmbのプッシュ通知の処理を分岐させました。
新処理を既存フローに組み込む
旧サービスのフローにFCMのpush通知処理を組み込みます。
既存機能と新機能で共通化できる部分や全く別の処理を行うところを整理し、図式化した既存処理に対して分岐する処理を加えます。
既存フローを黒色で示したのに対して、新規Push通知処理を赤で示しました。このように新たに追加した処理と既存処理を色分けすると見やすくなります。
実装を行う前に既存フローと新処理を図式化することで処理の流れがわかりやすくなります。
実装～テスト
エラーを潰し、不具合を調整する
上記のように準備してから実装を行ってもPush通知の確認では予期せぬエラーがいくつも生じました。
細かいところまで挙げるときりがありませんが、これらエラーや不具合をfirebasePluginやcordvaPruginなどの公式リポジトリのドキュメントや未改善不具合状況を隅々まで読解しつつ、１つ１つ潰していく作業を行いました。この作業が一番大変な作業でした。 実装前に以上の課題に気付くことができず多くの時間をここに使う必要がありました。
膨れ上がるテスト
移行期間中のユースケースは旧アプリと新アプリの両方を考慮する必要があります。その為、通常時のユースケースよりも多くの観点でテストを行う必要がありました。また、通知確認した段階で考慮していなかったことも、後からテストケーステストケースに追加しテストケースが膨れ上がっていきました。
その結果、当初の想定よりも多くのテストを限られた時間内でこなす必要がありました。結局、当初は移行期間を2か月程度見込んでいたのですが、新バージョンのリリースが後ろ倒しになり移行期間が短くなる結果となってしまいました。
この経験を通じて、ユーザビリティを考慮したサービスの移行は難易度が高いことがわかりました。想定していない不具合やエラーに遭遇し、それらをプロジェクトの初期段階で見積もることは難しかったです。
当初から想定外の出来事を見込んで余裕を持ったスケジュールを組むことができればよかったと思いました。（二フクラからのサービス終了の通知が昨年の12月末だったので、そもそも取れる期間が短かったということもありますが…）
最後に
プッシュ通知のサービス移行における重要な点は、ユーザビリティを損なわないために既存のプッシュ通知と新しいPush通知の両方が使用可能な期間を設けることです。 これを実現するためには、
- 既存の処理の洗い出し
- 新しい処理の洗い出し
- 既存処理と新処理の統合の図式化
等を行い、適切に準備すると良いでしょう。 また、どんなに十分な準備を行っても予期しないエラーが生じることがあります。
等、事前に十分なバッファを見込んだ工数を設定してから走り始めることをお勧めします。また、プラグインの不具合なども起こることもありますので、サポート体制やサービス提供の継続性等も考慮し技術選定を行うことをおすすめします。
スパイダープラスでは仲間を募集中です。 スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。
最後までご覧くださり、ありがとうございます。
