私の右太ももには「Apus apus」という鳥（「ヨーロッパアマツバメ」として知られる）のタトゥーが彫られています。そう、Appleがロゴに使い、プログラミング言語の名前にもした同じ鳥です。それほどiOS開発は私の仕事とアイデンティティにとって意味深いものなのです。Swiftは私の人生で多くの扉を開いてくれた鍵です。この言語に感情的な愛着があると言えるでしょう。
それなのに、これから読むのは私がReact Nativeへの移行を主導し、全面的に支持した話です。もう一度読み返してみてください。
真実は、私はiOS開発を愛しているということです。しかし、ビジネスニーズに合致した技術スタックを選択することは、好みの問題というよりも、実際にビジネスにとって何が理にかなっているかという問題なのです。
Zenjobでは、それぞれ7年と8年の歴史を持つ別々のネイティブコードベースを維持することが私たちの足かせになっていると判断しました（あなたのチームも同じ状況かもしれません）。この記事は、私たちがリプラットフォーミングの決定をどのように検討し、React Nativeへの移行以来どのようなビジネス成果を経験したかについて書いたものです。
ネイティブエキスパートに依存することの限界
Zenjobでは、ネイティブモバイル開発において成長企業が直面する多くの課題に直面していました。優秀なiOSとAndroid開発者がいたにもかかわらず、スタックのサイロ化された性質によってますます制約を受けていることがわかりました。
日常的にNode.jsやJavaを使っている開発者が、SwiftやKotlinを習得し、さらに全く異なるアーキテクチャやUIの細かな違いまで理解するのは簡単なことではありません。締切が迫ってくるたびに、この痛みを痛感していました。
そのため、フィーチャーチームには通常1人のiOSエンジニアと1人のAndroidエンジニアを組み込んでいました。想像できるように、バスファクターは非常に低い状態でした。さらに、ネイティブ開発者の数は他の開発者に対して1:5や1:6の比率で少なく、バックエンドの観点では準備できている機能の方が、ユーザーに提供できる機能よりも多いという状況でした。
デュアルプラットフォームアプローチは、本質的にすべてを2回構築することを意味していました。コードの重複は非効率なだけでなく、プラットフォーム間で一貫性のないユーザーエクスペリエンスを生み、貴重なエンジニアリング時間を無駄にしていました。シンプルな機能でさえ多くの調整が必要で、出荷能力が低下していました。
実装が分岐した1年後に機能に戻ってきたとき、どちらが正しい実装なのか：iOSかAndroidか？といった理解困難なシナリオも生まれていました。
リリースサイクルも痛みの種でした。高度に最適化されたセットアップがあっても、数週間取り組んできたエキサイティングな新機能や重要なバグ修正を含む新しいバイナリを配信することはほぼ不可能でした（手動レビュープロセスをバイパスすることは選択肢にありませんでした）。さらに段階的ロールアウトも加わると、あらゆる変更に対して非常に長いリードタイムが発生していました。
ステークホルダーも満足せず、エンジニアも満足せず、私も満足していませんでした。これは単に野獣の本性として受け入れるしかないものでした。
私たちはシンプルなユースケースに対してWebビューをアプリに埋め込み、両方のアプリから利用することでこれを克服しようとしましたが、全体的なユーザーエクスペリエンスを損なうだけでなく、さらに別のコードベースが追加されることになりました。
リプラットフォーミングの真の意味
リプラットフォーミングは単に技術を切り替えることではなく、組織がプロダクトを構築する方法を変革することです。私たちにとって、ExpoでReact Nativeに移行することは、慣れ親しんだ技術を使って製品組織全体がモバイル開発に貢献できるようにすることを意味していました。
移行により、開発アプローチを統一することができました。異なる言語とフレームワークで別々のコードベースを維持する代わりに、エンジニアの認知負荷を軽減し、チーム全体の開発速度を向上させる共有基盤を作成しました。
この変化により、モバイルプラットフォームチームの役割が根本的に変わりました。機能を直接出荷する責任を負う代わりに、他のチームを支援する役割に進化しました。現在は、インフラストラクチャ、デザインシステム、ビジョン、ツール、支援、実験に焦点を当てています。この変革により、組織全体のプロダクトチームがモバイル実装を含めて機能をエンドツーエンドで所有できるようになりました。
1つのコードベースへの移行により、以前私たちを遅らせていた作業の重複が排除されました。機能を一度構築してプラットフォーム間にデプロイでき、一貫性を確保しながら開発時間を劇的に短縮できます。このアプローチにより、iOSとAndroid間で真の機能パリティを維持することも容易になりました。
なぜExpoがエンタープライズチームにとってReact Nativeを実用的にするのか
React Nativeは私たちが必要としていたクロスプラットフォーム基盤を提供しますが、Expoこそがビジネスクリティカルなアプリケーションでこのアプローチを実用的にする鍵です。Expoは単なるフレームワークではなく、React Nativeを採用する際にチームが直面する多くの課題に対処するスケール向けに構築された統合プラットフォームです。
Expo CLIと開発ツールによる開発体験は、イテレーション速度を劇的に向上させました。エンジニアはプラットフォーム間で変更を即座に確認でき、開発プロセスがより効率的で楽しいものになりました。この高速フィードバックループは、移行中のモメンタム維持に重要でした。
iOSはSwiftUIプレビューで大きく進歩しましたが、それらは常にアプリ内の単一ビューの静的表現です。Expoで初日から両プラットフォームでホットリロードを使えることは、ゲームチェンジャーです。
運用面では、Expo Application Services（EAS）がEAS Workflowsによる本番グレードのCI/CDを提供し、ビルドとデプロイメントプロセスの複雑さの多くを排除しました。ストア申請と署名（従来モバイル開発の痛みの種だった側面）は、EAS Submitを通じて合理化されます。それだけでなく、iOSに対してExpoはfastlaneのような馴染みのあるツールの上に構築されているため、何か問題が発生した場合、詳しく調べて内部で何が起こっているかを確認できます。
おそらく最も変革的なのは、アプリストアレビューを通さずにアップデートを配信できる能力を得たことです。EAS Updateにより、修正と改善をユーザーに直接配信でき、多くの変更に対する市場投入時間を劇的に短縮できます。この機能だけで、機能開発とバグ修正へのアプローチが変わりました。
Expoは、プリコンパイルされたReact Nativeなどの最適化を通じてパフォーマンスの懸念にも対処し、アプリの応答性と信頼性を確保しています。ネイティブコードで機能を拡張する必要がある場合、Expo Modulesは従来のReact Nativeネイティブモジュールの複雑さなしにクリーンなインターフェースを提供します。これまでカバーされていない非常に特定の変更が必要な場合は、Expo Config Pluginを書いて対処します。
Expoにより、React Nativeの1コードベースの美しさ以上のものを得ました：モバイルDevOpsの最も困難な部分を排除し、インフラストラクチャと格闘するのではなく価値の提供に集中できるチーム最適化プラットフォームを得たのです。
Expoへの移行を評価する方法
リプラットフォーミングの取り組みを検討する際、リーダーシップは当然、タイムライン、ROI、リスク、潜在的な能力損失について懸念を抱きます。移行の評価に対する私たちのアプローチは、これらの懸念に体系的に対処することに焦点を当てました。
最もリスクの高い統合を特に対象とした概念実証から始めました。これにより、完全な移行にコミットする前に、React Nativeが最も複雑な要件を処理できることを検証できました。
初日からプロダクトとデザインチームを巻き込み、移行が単なるエンジニアリングイニシアチブではなく、会社全体の変革であることを確実にしました。彼らの早期参加により、潜在的なUXの課題と機会を特定でき、新しいプラットフォームでより良い全体的な体験につながりました。
プロセスの早い段階で、既存のアプリケーションにReact Nativeを統合するのではなく、グリーンフィールドアプローチを採用することを決定しました。相互運用性の問題を心配することなく、より速く進めることができるため、このルートを選択しました。また、ユーザーにとって本当に重要な機能を優先することもできました（結果的に、移行する価値のないアプリの一部機能を削除しました）。
Expoでの構築によるビジネス成果
リプラットフォーミングの取り組みの結果は、複数の次元で期待を上回りました：
機能のリードタイムが劇的に短縮され、開発サイクルが数週間から数日、時には数時間にまで短縮されました。共有コードベースにより、より高速な実装が可能になり、以前私たちを遅らせていた調整のオーバーヘッドが削減されました。
オーバーザエア更新のおかげで、デプロイメント頻度が桁違いに増加しました。アプリストアレビューを待つ代わりに、改善をユーザーに直接配信でき、はるかに応答性の高い開発プロセスが可能になりました。変更がメインブランチに反映されると、7分以内にユーザーが利用できるようになります。
おそらく最も重要なのは、モバイル開発がボトルネックから会社全体の能力に変革されたことです。プロダクトチームは、すべての変更について専門のモバイルエンジニアに依存することなく、モバイル実装を含めて機能をエンドツーエンドで所有できるようになりました。
共有デザインシステムにより、デザイン負債を削減しながらプラットフォーム間の一貫性が向上しました。一度構築されたコンポーネントはどこでも動作し、iOSとAndroid実装間で発生していた分岐を排除しました。
人材の観点から、ReactとTypeScriptエンジニアのより大きなプールを活用できるため、採用が容易になりました。新しいチームメンバーは、単一のプラットフォームに限定されることなく、スタック全体に貢献できるようになりました。
エンジニアリング満足度が劇的に向上しました。移行以来、モバイル開発について一度も苦情を受けていません。従来モバイル機能に深く関わることを避けていたエンジニアが、今では積極的に構築を試みたがるようになりました。
アプリを現代化するだけでなく、チームを将来に備える
Expoを使ったReact Nativeは、孤立したネイティブ開発の限界に苦しむ組織にとって、モバイル自律性への最速で最もクリーンなパスを提供します。Zenjobでの私たちの経験は、利益が技術的考慮事項をはるかに超えて広がることを実証しています—チームが価値を提供するために協力する方法を根本的に変革するのです。
この移行を行う企業は、生産性、コラボレーション、品質において複合的な利益を見ています。統一されたアプローチはプラットフォーム間のサイロを打破し、より結束力があり効率的なエンジニアリング組織を作り出します。
サイロ化されたネイティブチームと遅いモバイルリリースの痛みを感じているなら、飛躍する時かもしれません。この旅には献身と慎重な計画が必要ですが、ビジネス成果（より高速な配信、品質向上、エンジニアリング満足度の向上）により、投資に十分見合う価値があります。
Swiftのタトゥーを持つ人間でさえ、Expoを使ったReact Nativeのビジネス利益は無視できません。時として最良の技術選択は、個人的なインクの好みの問題ではなく—チームが顧客に例外的な体験を、これまで以上に高速で一貫して提供できるようにすることなのです。