モバイルエンジニア転職ガイド

モバイルの求人は、同じ「アプリ開発」でも、担当OS、配布経路、リリース権限が違います。画面を作る仕事と、審査・署名・クラッシュ監視を含む仕事では、面接で聞かれる話が変わります。応募前に、自分が責任を持ちたい配布の単位を決めてください。

iOS

SwiftやObjective-C、Xcode、App Storeの審査と署名、端末差とOS更新への追従が日常に入りやすいです。

Android

KotlinやJava、Gradle、Google Playの配信経路、端末メーカー差、権限モデルの変化が日常に入りやすいです。

Flutter / React Native

共通コードで両OSへ出す選択です。ネイティブモジュール、ビルド、審査、性能問題は共通化できないことがあります。

リリース責任

ストア提出、段階公開、強制更新、ロールバックの可否です。画面実装ができても、提出権限がない求人があります。

「どちらが得か」は、会社のコードベースと、端末機能の使い方で決まります。カメラ、決済、プッシュ、バックグラウンド制限など、OSの制約に触れるほど、共通コードだけでは足りなくなります。希望を書くときは、好きなフレームワーク名より、触ったOS制約を先に出します。

• 共通化の利益

  画面と業務ロジックを一度書いて両OSへ出せること。チームが小さいときの選択肢になります。

• 共通化の限界

  審査文言、権限ダイアログ、バックグラウンド、課金、ウィジェットはOS差が残ります。

• Web経験の活かし方

  コンポーネント設計、状態管理、アクセシビリティの話は転用できます。ストアと端末制約は別に学習します。

• ゲームや特殊端末

  エンジンや組み込み寄りの求人は、通常の業務アプリと評価軸が違います。職種名だけで混ぜないでください。

画面が動くことと、店頭に並び続けることは別です。審査で差し戻されると、修正内容より「何がポリシーに抵触したか」の説明が求められます。クラッシュは、再現端末、OS版、ログ、次回提出までの判断がセットです。ダウンロード数は媒体やダッシュボードの定義が違うため、求人票や公式サイトの最新情報で確認してください。

モバイル求人は、言語名の羅列が多くなります。言語は入口です。見るべきは、新規開発か既存保守か、ストア提出まで含むか、サーバー側も持つかです。

• 配布経路（ストア、社内、両方）が書いてある
• 最低サポートOSや端末方針が分かる、または面談で確認できる
• デザインシステムやWebとの共通化方針が空欄のままになっていない
• 「スマホアプリ全般」だけでOSもゲームも全部、となっていない
• 最新の勤務条件は求人票と公式サイトで確認する

Web出身でも、レスポンシブ、オフライン、プッシュ相当の通知、認証は材料になります。ネイティブ出身でも、状態管理とテストの話は転用できます。ダウンロード数や売上は、分母と期間が言えないなら書かない方が安全です。

1. 01
   配布の単位を1つ書く

   一般公開、企業内、審査中のベータなど、誰がインストールできたかを具体化します。ユーザー数は根拠があるものだけです。

2. 02
   壊れた画面か、壊れた提出かを分ける

   端末上の不具合と、審査や署名の失敗は別の技能です。両方あるなら両方書きますが、混ぜて1行にしないでください。

3. 03
   OS制約を1つ選ぶ

   権限、バックグラウンド、省電力、ファイルアクセス、生体認証など、OSに止められた経験を時系列で話します。

4. 04
   自分で決めた設計と、踏襲した設計を分ける

   モジュール分割、状態の置き場、ナビゲーションのうち、自分が判断した範囲だけを強調します。

Webの即時デプロイと違い、モバイルは審査と端末側キャッシュの影響を受けます。緊急修正ができるかは、ストアの仕組みと社内の提出権限次第です。面接では「すぐ直せる」と断言せず、提出から反映までの経路を確認します。

モバイル専任チーム、Webと兼務、プロダクト横断のクライアントチームでは、評価される成果が違います。画面の追加速度なのか、ストアを止めない安定なのかを、組織の話として聞いてください。

• 専任モバイル

  OS更新と端末差の追従が仕事の中心になりやすいです。深いネイティブ知識が評価されやすいです。

• Web兼務

  同じ機能を複数クライアントへ出す話が増えます。共通化の判断と、切り捨てるOS機能の説明が要ります。

• 受託・制作

  案件ごとのストアアカウントと期限が制約です。契約範囲と保守の切れ目を確認します。

• ゲーム・特殊

  エンジン、リアルタイム、審査ポリシーが業務アプリと違います。関連記事のゲーム領域とは希望を分けて書いてください。

次の一手は、必ずしもフルスタックではありません。アクセシビリティ、性能、決済、オフライン、プラットフォームAPIなど、クライアント側で専門性を深める道もあります。2年後に責任を持ちたい範囲を話せるようにします。

モバイル求人は、事業会社、受託、ゲーム、社内向け端末に分散します。1社の提案だけで「モバイル市場」を判断しない方が安全です。OSに詳しい相談と、プロダクト役割がはっきりした相談を併用すると、ネイティブとクロスの差が見えます。

• IT・Web領域に詳しいサービスで技術スタックを確認する
• 同じ求人の重複応募が起きないよう一覧を作る
• 最新の募集条件は各公式サイトと面談で確認する

• 言語名だけで比較する

  SwiftもKotlinも、審査とクラッシュの話が無いと仕事内容が伝わりません。

• ダウンロード数を成果にする

  マーケや既存ユーザーの影響が大きく、分母が言えない数字は外します。

• 両OS完璧を装う

  主担当と、読める・直せる範囲を分けた方が信頼されます。

• Webと同じデプロイ感覚で話す

  審査と端末反映の遅れを無視すると、運用面で不安に見えます。

失敗は能力不足の証明ではありません。差し戻しや重大クラッシュを、非難ではなく時系列で話せる人が、モバイルでは早く信頼されます。確認できない市場規模や満足度は使わないでください。

新しい画面を足した話より、古いOSを切るか残すか、特定端末だけ落ちるかを判断した話の方が、モバイルらしいです。切り方にはサポート期限と検証コストが絡みます。利用率の数字は根拠があるものだけ使い、分からなければ未確認と面談で聞いてください。ダウンロード数や審査通過率は求人票や公式サイトの最新情報で確認してください。

クロスプラットフォームを使っていても、審査文言、課金、バックグラウンドはOS差が残ります。共通化した範囲と、ネイティブモジュールで吸収した範囲を分けて書いてください。両OS完結と書かない方が安全です。

モバイルの経歴は、言語名の列挙より先に配布経路を置きます。一般公開なのか社内配布なのか、提出権限があったのかが分からないと、面接の質問が画面実装に偏ります。ダウンロード数はダッシュボード定義が違うため、分母と期間が言えないなら書きません。

1. 01
   1本のリリースを時系列にする

   実装、ビルド、提出、差し戻し、再提出、公開、監視を行に分けます。自分が承認者でない工程は「他人」と書きます。

2. 02
   もう片方のOSは正直に書く

   読める、直せる、未経験を分けます。両方完璧を装うより、主担当の深さを示した方が信頼されます。

3. 03
   公開成果物の範囲を決める

   勤務先アプリの画面や鍵は載せません。個人開発でもストアの申告内容と実装がずれていないかを確認します。

1. 01
   画面からストアまでの経路を1枚にする

   実装、ビルド、署名、提出、公開、監視を矢印で描きます。権限が自分にない工程は「他人」と書きます。

2. 02
   不具合を1件だけ深掘りする

   端末、OS、ログ、修正、再提出を各3行で書きます。ユーザー数は根拠がなければ書きません。

3. 03
   希望する主OSを選ぶ

   iOS、Android、クロスから、今の希望を1つに絞ります。もう片方は学習中または読める、と添えます。

4. 04
   公開してよい成果物だけ残す

   勤務先アプリの非公開画面や内部APIをポートフォリオに入れないでください。迷ったら出さないでください。

5. 05
   相談先を2系統用意する

   技術職に強い相談と、役割定義の相談を分けます。条件の最終確認は公式サイトで最新情報をご確認ください。

モバイルエンジニア転職は、華やかなUIより提出と監視の話で差がつきます。誰の端末で動き、店頭に並び、壊れたら誰が止めるか。この3点を自分の言葉で説明できると、求人比較も面接も具体になります。内定や年収の保証はありません。