TUNAGモバイルアプリでコア機能『タイムライン』をSwiftUI / Jetpack Compose化しました

こんにちは！プロダクト開発部のおしん(@38Punkd)です。

スタメンは、組織改善クラウドサービス「TUNAG」を提供しています。そのコア機能である『タイムライン』を、モバイルアプリでWebViewからSwiftUI / Jetpack Composeにリプレイスしました。今回は、その背景と技術選定、そして実現までの道のりをご紹介します。

リプレイスの背景

スタメンの主幹サービスである「TUNAG」は、『人と組織に働きがいを』提供することをミッションに掲げ、コミュニケーションの活性化、情報共有の促進、ビジョン浸透、人材定着、そして業務効率化をメインに、お客様の組織課題を解決するサービスです。

TUNAGにはWebアプリ版とモバイルアプリ版があり、ファーストリリースはWeb版が先行し、モバイルアプリ版もそれに追従する形でリリースされました。当時の組織のケイパビリティがWeb技術に寄っていたこともあり、モバイルアプリは、いわゆるガワネイティブの形式で開発を進めていました。

しかし、TUNAGをご利用いただくユーザー層が多様化するにつれて、アプリのパフォーマンス改善を求める声が次第に増えてきました。例えば、地下街のレストランや工場で働かれる方、あるいは社用端末を一律で配布され、最低限のスペックと弱い通信環境でTUNAGをご利用されているお客様も少なくありません。

私たちは、こういった方々のユーザー体験の課題を解決するため、モバイルアプリのパフォーマンス改善を真剣に検討し、技術選定の見直しを行うことになりました。

技術選定の見直し

モバイルアプリ開発における様々なアプローチ方法の、一般的なメリット・デメリットを整理しました。

開発アプローチ	メリット	デメリット
1. SwiftUI / Jetpack Compose	高いパフォーマンスとUX: OSのUIコンポーネントを使用するため、高速でスムーズな動作。各プラットフォームのガイドラインに準拠したUI/UXを提供可。フル機能へのアクセス: カメラやGPS等端末の全ての機能に直接アクセスでき、OSの最新機能やAPIにいち早く対応可。	開発コスト: iOS, Androidそれぞれ別の開発が必要になる。
2. Flutter / React Native	開発コスト削減: 一つのコードベースでiOS, Androidの両方に対応可。ネイティブに近いパフォーマンスとUI: Flutterは独自のレンダリングエンジンを持ち、React NativeはOSのUIコンポーネントにブリッジするため、Swift / Kotlinに近いパフォーマンスとUI。	OS機能へのアクセス制限やライブラリ依存: 一部のOS機能には別途ブリッジ実装やサードパーティ製ライブラリへの依存が必要となる場合がある。
3. KMP / CMP	(KMP/CMP)ビジネスロジックの共有による効率化: 共通のビジネスロジックをKotlinで記述し、iOS, Androidで共有可。 OSのUIの活用と柔軟性: UIは各OSのUIで実装するため、ガイドラインに準拠したUIとパフォーマンス。	(KMP)プレゼンテーション層の開発が二重になる可能性: UI層はiOS, Androidでそれぞれ開発する必要があるため、接続部分の工数は削減されない。 (CMP)成熟度とコミュニティの規模: 比較的新しい技術なため、利用可能なライブラリやツールが発展途上なことも。
4. WebView	開発コスト削減: 既存のWebコンテンツを流用でき、Web開発の知識を用いて開発可。迅速なデプロイ: App StoreやGoogle Playの審査を通さずにコンテンツ更新可。	パフォーマンスの限界: WebコンテンツをWebView内で表示するため、複雑なUIやアニメーションでもたつきやカクつきが発生しやすい。 OS機能への制限とUXの低下: アクセスが制限されたり、ブリッジが必要な場合も。また、ストアの審査基準で単なるWebサイトの表示では却下の可能性も。

私たちの場合、

社内にSwift / Kotlinの経験者はそれぞれ複数名在籍しているが、FlutterやReact Nativeの経験者は不在だったこと
クライアント側にそこまで複雑なロジックが多くないこと
パフォーマンス課題が大きいため、UIの作り込みがしやすい技術が必要なこと

という理由から、コア機能である『タイムライン』を、WebViewからSwiftUI / Jetpack Componseへリプレイスすることに踏み切りました。

ゴールと、その策定背景

実は、これまでもコア機能である『タイムライン』をネイティブ化しようという試みは、社内で何度か話題に上がっていました。

しかし、優先度の高い新機能開発や、モバイルエンジニアのリソース不足の問題で、残念ながら保留になってきた経緯があります。仮にネイティブ化に再チャレンジするとしても、中途半端にタイムラインのWebViewの一部コンポーネントだけをネイティブ化していては、かえって技術負債につながりかねません。

そこで私たちは、画面単位でいち早く刷新しリリースすることを今回のプロジェクトのゴールとしました。

ゴール達成に向けた戦略

この大きな目標を達成するために、私たちは2つの戦略を立てました。

1. 社内からの共感を得る

タイムラインは、20種類以上の項目の組み合わせからなる投稿の一覧が並ぶ、非常に複雑な仕様です。そのため、エンジニアサイドのQAだけでは、不具合を発見しきれないと懸念していました。なので、より多くの人に触ってもらう社内リリースでの不具合の早期発見が重要と考えました。

エンジニアが長期間、技術刷新に時間を割くことの意味は、エンジニア同士なら理解しやすいかもしれません。しかし、エンジニアではない社員からは中々想像がつきにく、想像しにくいものに対しては興味や関心を持ってもらいにくいと考え、「そもそもネイティブ化とは何か」そして特に、「ネイティブ化したら何が嬉しいのか」の2点に絞って、全社への共有を徹底しました。そうしてプロジェクトへの理解と協力を得ることに努めました。

実際にプロジェクト開始前よりも多くの社員から、社内リリースされたアプリに対して、チャットでリアクションをもらったり、気づいたことを指摘したりしてくれるようになりました。