こんにちは。株式会社JMDC　インシュアランス本部　ソリューション部に所属しているモバイルアプリエンジニアの高野です。

今年、JMDCではアドベントカレンダーに参加しています。

本記事は、JMDC Advent Calendar 2023 10日目の記事です。

はじめに、私の部署で取り組んでいるビジネス、プロダクトについて簡単に紹介させてください。

私の部署は主に、保険会社様を顧客としたプロダクトの開発・保守運用をしています。一方で一部、自社プロダクトも開発・保守運用をしています。

▼ぜひこちらのブログもご参考ください

今回は自社プロダクト開発・保守運用で遭遇したケースに関して、お話しさせていただきます。

私が携わっているプロダクトの一つに、Flutterで開発しているスマートフォンのPHR（Personal Health Record）アプリがあります。こちらは今年の3月にリリースを行い、改修・機能追加を行いながら運用しています。

本題

前述のプロダクトは初回リリース後、軽微な改修・リリースを何度か行っていたのですが、実は私は今年の夏にJMDCにJOINしており、その時点で次の開発の佳境を迎えており、終盤の開発・試験から参画することになりました。

さて、モバイルアプリは自分たちのタイミングでリリースできるWebアプリと異なり、各プラットフォームのストアに審査を受けて、リリースを行う必要があります。

そして、ストア審査に提出するアプリは改修を施したアプリで、バックエンドのサーバもストア審査に合わせたバージョンをリリースする必要があります。
（かなり当たり前のことを書いてしまっていますが…）

今回の開発では、一部APIのレスポンスを変更する必要があり、そのままの状態では審査期間中に現在リリース中のアプリで不具合が生じることがわかりました。

不具合が起きている箇所はモバイルアプリ側だったのですが、下記3点の理由から今回はバックエンドに現在リリース中のバージョンも対応するための処理を追加することにしました。

また、今後互換性の対応が継続的に発生することを踏まえて、バージョン対応をアプリ側で実装するか、バックエンド側で実装するか、ケースバイケースで対応するか等の議論を行なっていきました。

対応方法

メリット

デメリット

アプリで対応する

・バックエンドの交換ができないようなPJでは有用（そうせざるを得ない）

・実装の仕方によってはバージョンの条件分岐がかなり煩わしいことになりそう

・前述のストア審査がある通り、いざという時にスピーディな対応が難しくなる

バックエンドで対応する

・自分たちのタイミングでリリースをすることができる

・見通しの悪いコードになっても比較的メンテナンスがしやすい、APIであればユニットテストで分岐の対応もできる

・他のアプリでも使用されているようなバックエンドアプリの場合、影響が都度生じる

前職ではモバイルアプリ専任で開発することが多く、相手先の規模次第でアプリで対応することのほうが多かったので、どう対応するかという議論をすること自体、個人的には新鮮でした。

議論の結果、リリースのしやすさを最優先し、今後互換性はバックエンドで考慮していくことになりました。

設計や要件定義の中で互換性について検討し、吸収できるようにするのがより良いと個人的には考えますが、今後の戦略を決めておいたことで個人的にはこの部分の気持ちが楽になりました。また、モバイルアプリを中心に考えていた自分の経験において、システム全体での選択・決定をできることが個人的には新鮮でした。

おわりに

ストア審査における互換性の考慮は、長くプロダクト開発を続けているプロダクト、プロジェクトであれば既に仕組みがあることや、そこを踏み抜かないように進められていますが、実際は不具合の温床にもなりやすいものだと個人的には考えています。

今回、自分が携わった若いプロダクトでは初めてハマったので、そこを今までの経験ベースではなくチームで開発戦略まで考えて決定できたことがよかったです。

明日11日目は、八杉さんです！お楽しみに♪

JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。

まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。

★最新記事のお知らせはぜひ X（Twitter）をご覧ください！