NOT A HOTELアプリのチャット機能リプレースの裏側

はじめに

NOT A HOTELでAndroidエンジニアをしている松尾です。2025年1月に入社した3人目のAndroidエンジニアです。

今年の8月頃にNOT A HOTELのチャット機能をリプレースするという大きめの開発を担当しました。Androidの実装は私が担当、他にはiOSエンジニア、バックエンドエンジニア、PdMという4人チームで進めてきました。

チャット機能について

NOT A HOTELアプリにはコンシェルジュという機能があります。これは、お客様からの様々な質問やリクエストにお応えしたり、運営スタッフからお客様への連絡事項を伝達したりする、NOT A HOTELアプリの中でも主要な機能の一つです。

リプレースの背景

コンシェルジュ機能の中でもチャットでメッセージを送受信する部分は、サードパーティ製ライブラリの画面実装に大部分を依存した作りになっていました。部分的にUIを差し替えたりカスタマイズしていたのですが、ライブラリが公開しているAPIだけでは十分なカスタマイズができず、findViewByIdを駆使して無理やりViewを差し替えたり、XMLリソースIDを上書きしてスタイルを変更したりと、少々無理のある方法を取らざるを得ませんでした。また、チャットライブラリが提供するUIはFragmentのため、他の画面は全てComposeで作られているのに対し、チャット画面だけはAndroidViewやFragmentを使ったイレギュラーな形を取る必要がありました。

こういった事情により、ライブラリを更新することによって機能が壊れてしまったり、一見うまく動いているように見えるのに特定条件下で再現性が低い事象が散発し、継続的な保守性に課題がありました。

そもそも、「今動いているから」といって古いライブラリを使い続けること自体にも問題があります。AndroidやiOSは定期的にOSが新しいバージョンに更新されるため、その時にライブラリも新しいOSに対応したものに更新する必要があります。これができないと、いつか動作しなくなるかもしれないというリスクがあります。

とはいえ、ライブラリを撤廃して自前実装に置き換えるというのも大変な作業です。他にもやるべき開発項目はたくさんありましたから…こうした事情から、いつかチャットライブラリをリプレースしたいという声はありつつなかなか実現できない状況が続いていたのですが、この度ついに自前実装へのリプレースをすることを決断しました。

※ここから先は、自前実装の新しいチャットのことを「新チャット」、従来から使われていた外部SDK依存のチャットのことを「従来チャット」と表記します。

リプレースの計画

大きな機能を丸ごと一気にリリースするのは大きなリスクを伴います。何か少しでも不具合があったらシステム全体が止まってしまうかもしれないし、最悪の場合は古いシステムにロールバックしないといけなくなったりします。（ロールバックできればまだマシで、本当に最悪なのはシステムが復旧不能な状態になってしまうことです…）

チャットはNOT A HOTELの滞在体験に大きな影響を及ぼす機能です。そのため、チャットのメッセージが送れない・返事が来ないといった障害が発生するリスクは最小限に抑え、万が一障害が起きてもすぐに復旧できるようにしておく必要があります。

そのため、従来チャットを一度に全てリプレースするのではなく、段階的に新しいシステムへ移行していくことにしました。最終的にはバックエンドとフロントエンド3種（Web・Android・iOSアプリ）の移行が必要なのですが、最初の移行対象はAndroidとiOSのアプリにしました。バックエンドはモバイルアプリの移行に最低限必要な対応と、今後の本格的な移行を見据えた新チャットの基盤を作るところまでを行います。

モバイルアプリから従来チャットのライブラリを完全に取り除き、自前実装の新チャットに置き換えることで、前述したメンテナンス性の問題が解消されます。さらに、Android・iOS間の微妙な挙動差や低頻度事象の原因切り分けが容易になり、開発者・ユーザー双方にとってメリットが大きいと判断しました。

今回の記事でお話するのは最初のステップであるモバイルアプリ側のチャットリプレースの話になります。

仕様の検討

新チャットを開発する際にまず行ったのは、従来チャットの機能の把握です。元々サードパーティライブラリの機能をそのまま使っていたこともあり、NOT A HOTELアプリ上でのチャット機能のうち、ライブラリによって実装されている必要な機能を整理する必要がありました。そのため、実際にアプリのチャットを触りながら様々なメッセージ送信を試したり、サードパーティライブラリが公開しているAPI仕様を調査したりしながら、何種類のUIが存在するのか、どういう条件でそれらが表示されるか、などを明らかにしていきました。

そして、この調査結果を基に新チャットの仕様を決定します。移行によってユーザーが混乱しないように気を付けながら、新たに設計し直しました。従来チャットの機能の中でもあまり重要でない機能（の割に実装が大変なもの）は思い切って削除したり、簡略化した仕様に変更したり、AndroidとiOSで微妙に動作が違っていた部分を共通の仕様に揃えたりしました。

実装

新チャットの仕様が固まったとはいえ、本当に細かい部分に関しては実装してみないとわからないことも結構ありました。そのため、
とりあえずUIを実装→FigmaやNotionにも明記されていないパターンを見つけたら確認する→仕様をアップデートするというサイクルをスピーディーに回しながら開発を進めました。

クライアント側の途中まで出来上がった状態をすぐに確認できるようにするため、FeatureFlagを活用して製品ビルドでの従来チャットの動作は変えないまま開発ビルドでのみ新チャットを動かせるようにしました。開発版ビルドを使えばいつでも新チャットの動作確認ができるため、細かい仕様の考慮漏れにもすぐ気付くことができたり、デザインと実装の乖離がないか確認できたり、スピーディーな開発を進めることができました。

リリース

実装とQAを終え、いよいよリリースの時期を迎えました。Androidの方がiOSより一足先に実装完了していたため、Androidから先行リリースすることになりました。翌月にはiOSの新チャットもリリースでき、モバイルアプリに関しては新チャットへの移行を完了することができました！🎉

チャットの改善はこれからも続く

モバイルアプリ側のチャットが新しくなったことで、今後はチャット機能に関する様々な改善ができるようになっていくと思います。チャットのリプレースプロジェクトはまだ始まったばかりです。今後のチャット・コンシェルジュ機能のさらなる改善にご期待ください。

自分たちで使ってみる

新チャットを作りきって一安心…といったところですが、
作った機能が本当にサービスの役に立っているのか？
思ったとおりに動いていないところはないか？
使い勝手はどうか？
など、開発しているだけでは気付けないことがたくさんあります。そういったことにき付けるようにするためには自分たちがユーザーとなってアプリを使ってみるのが手っ取り早いです。

そこで、9月中旬にソフトウェアチームのエンジニア・プロダクトマネージャー数名の有志でNOT A HOTEL MINAKAMI TOJIに宿泊してきました。
新チャットを使ってみて、うっかり誤操作をしてしまったり現地のモバイル回線が繋がりにくいエリアがあることに気付いたり、まだまだ改善ポイントがあるなと思いました。今後のアップデートを頑張ります！
なお、この時の宿泊の様子は後日の連載記事でもレポートされる予定ですので、お楽しみに！