From Swift tattoo to React Native migration lead: a business-first approach to mobile development
Users • React Native • September 30, 2025 • 12 minutes read
ゲスト寄稿：Leo Picado
Berlin拠点のStaff EngineerであるLeo Picadoによる寄稿記事です。デザイン、フルスタック開発、教育の経験を持ち、JavaScriptでの開発と開発者体験を向上させるツール作りに情熱を注いでいます。
はじめに — なぜこの話をするのか
私の右腿には「Apus apus」（通称 Common Swift）のタトゥーがあります。Appleのロゴや言語名と同じ鳥で、iOS開発が私の仕事やアイデンティティにどれだけ深く関わっているかを象徴しています。Swiftは私にとって多くの扉を開いてくれた鍵であり、感情的なつながりすらあります。
それでも、私はZenjobでReact Nativeへの移行を主導し、全面的にサポートしました。ここで語るのは、なぜその決断をし、どのように進め、そしてどんなビジネス成果を得たのか、というストーリーです。
ネイティブに頼ることの限界
Zenjobでは、ネイティブモバイル開発に関して多くの成長企業が直面する問題にぶつかりました。優秀なiOS／Androidエンジニアがいたにも関わらず、スタックがサイロ化していることで制約を受けていました。Day-to-dayで使うのがNode.jsやJavaのチームにとって、SwiftやKotlin、それぞれのアーキテクチャ、UIの細かな差異をキャッチアップするのは簡単ではありません。
その結果、以下のような問題が起きていました：
- Featureチームには通常iOSエンジニア1人、Androidエンジニア1人が組み込まれており、bus factorが低かった。
- ネイティブ開発者比率が1:5〜1:6になることもあり、バックエンド側で準備できている機能がユーザーに届けられない状況が発生した。
- 二重プラットフォーム戦略は基本的に“すべてを2回作る”ことを意味し、コードの重複、プラットフォーム間での一貫性の欠如、貴重なエンジニア時間の浪費を招いた。
- リリースサイクルが長く、ストア審査や段階的ロールアウトのためにリードタイムが非常に長くなった。
- 単純な機能でも高い調整コストがかかり、1年後に実装が乖離してどちらが正しい実装か判断が難しくなるようなケース（iOS版かAndroid版か）も発生した。
一時的な対策としてWeb Viewを埋め込むことも試しましたが、UXを損ない、さらに別のコードベースを増やすだけでした。
リプラットフォーム（replatforming）が意味するもの
リプラットフォームは単なる技術の切り替えではなく、組織がプロダクトを作る方法そのものを変えるプロセスです。Zenjobでは、Expoを使ったReact Nativeへの移行によって、プロダクト組織全体が馴染みのある技術でモバイル開発に貢献できるようになりました。
主な変化は次のとおりです：
- 別々のコードベースを維持する代わりに、共通の基盤を作ることでエンジニアの認知的負荷を下げ、チーム全体のベロシティを向上させた。
- Mobile Platformチームの役割が変わり、直接機能を出す担当から、インフラ、デザインシステム、ビジョン、ツーリング、エンパワーメント、実験を支援する「イネーブラー」へと進化した。
- プロダクトチームがモバイル実装を含む機能をエンドツーエンドで所有できるようになり、重複開発が排除された。
- iOSとAndroidの真の機能パリティ（feature parity）の維持が容易になった。
なぜExpoがエンタープライズにとって有効なのか
React Native自体がクロスプラットフォームの基盤を提供しますが、Expoはこれをビジネスクリティカルなアプリで実用可能にする鍵になります。Expoは単なるフレームワークではなく、スケールを前提とした統合プラットフォームで、採用時の多くの課題に対処します。
- 開発体験：Expo CLIと各種dev toolsによってイテレーション速度が劇的に改善しました。変更は両プラットフォームで瞬時に確認できるため、開発が効率的かつ快適になった。
- ホットリロード：iOSのSwiftUI previewsは進化していますが、単一ビューの静的プレビューに留まります。Expoのホットリロードは両プラットフォームで即時のフィードバックを提供し、移行期の勢いを維持するうえで非常に重要でした。
- オペレーション：Expo Application Services（EAS）はEAS Workflowsによる本番レベルのCI/CDを提供し、ビルドやデプロイの複雑さを大幅に削減しました。ストア提出や署名（従来は手間のかかる領域）はEAS Submitで合理化できます。iOS側ではfastlaneのような慣れたツールの上に構築されているため、問題があれば内部を掘ることも可能です。
- OTAアップデート：EAS Updateを使えば、ストア審査を経ずに更新をユーザーに配信でき、多くの変更でタイム・トゥ・マーケットを劇的に短縮できました。
- パフォーマンスと拡張性：precompiled React Nativeなどの最適化によりアプリの応答性と信頼性を維持できます。ネイティブ機能の追加が必要な場合は、Expo Modulesが従来のnative moduleよりシンプルなインターフェースを提供します。特定の変更が既存でカバーされていない場合は、Expo Config Pluginを書いて対処します。
要するに、ExpoはReact Nativeの“1コードベース”という利点に加え、Mobile DevOpsの最も難しい部分を取り除くチーム最適化されたプラットフォームを提供してくれます。
Expoへの移行を評価する方法
経営陣が懸念するのは、タイムライン、ROI、リスク、機能喪失の可能性などです。私たちの評価アプローチはこれらを体系的に扱うことに集中しました。
- ハイリスクな統合を標的にしたProof of Concept（PoC）から始め、React Nativeが複雑要件を満たせるかを検証した。
- プロダクトとデザインチームを初日から巻き込み、移行がエンジニアリングだけのイニシアチブではなく会社全体の変革であることを保証した。これによりUX上の問題点や改善機会を早期に見つけられた。
- 既存アプリにReact Nativeを統合するのではなく、グリーンフィールドで新規に構築することを選んだ。これにより相互運用性の問題に悩まされずにスピードを出せ、ユーザーにとって本当に重要な機能に優先順位を付けられた（移行に値しない機能は思い切って削った）。
Expoで構築したことによるビジネス成果
リプラットフォームの結果は多方面で期待を超えました：
- Featureのリードタイムは劇的に短縮され、開発サイクルは数週間から数日、場合によっては数時間になった。
- 共通コードベースにより実装が速くなり、これまで必要だった調整コストが削減された。
- OTAアップデートによってデプロイ頻度が桁違いに増加。ストア審査を待つ必要がなくなり、mainブランチに変更が入るとユーザーに7分以内で届くようになった。
- モバイル開発はボトルネックではなく会社横断の能力へと変わった。プロダクトチームがモバイル実装を含めて機能をエンドツーエンドで所有できるようになった。
- 共通のデザインシステムによりプラットフォーム間の一貫性が改善され、デザイン負債が減少した。1度作ったコンポーネントがどこでも動くことでiOSとAndroid間の乖離がなくなった。
- タレント面ではReactとTypeScriptエンジニアというより大きな人材プールを活用できるようになり、採用が容易になった。新しいメンバーは単一プラットフォームに限定されずスタック全体に貢献できる。
- エンジニアの満足度も劇的に向上し、移行以降モバイル開発に関する不満はほとんど聞かれなくなった。かつてモバイルに手を出すことを避けていたエンジニアも積極的に取り組むようになった。
結論 — 技術選択は個人的嗜好ではない
React Native + Expoは、分断されたネイティブ開発に悩む組織にとって、最も速く、最も明快なモバイル自律化への道筋を提供します。Zenjobの経験は、利点が単なる技術面を超え、チームの働き方そのものを根本的に変えることを示しています。生産性、コラボレーション、品質において複利的な効果が生まれます。
ネイティブチームのサイロ化や遅いモバイルリリースに悩んでいるなら、移行を検討する価値は高いです。旅路はコミットメントと慎重な計画を必要としますが、得られるビジネス成果（より速いデリバリー、改善された品質、向上したエンジニア満足度）は投資に見合うものです。
そして、Swiftのタトゥーを持つ者であっても、React Native + Expoのビジネス上の利点を無視することはできません。時には最良の技術選択は個人的な“インクの好み”ではなく、チームがより速く、より一貫して優れた体験を顧客に届けることを可能にするかどうかで決まります。
この記事はLeo Picadoによるゲスト寄稿です。