本文へ移動

ホーム / App / 第1部 モバイルアプリエンジニアとは

第1部 モバイルアプリエンジニアとは・第1章

モバイルアプリエンジニアとは

★★☆ 重要5トピック・面接 3問

モバイルアプリエンジニアの仕事の範囲と、Web との違いを押さえる。

ひとことで

iPhone・Android のアプリを設計・実装・配信し、端末の機能を生かした体験を作る職種。

モバイルアプリエンジニアは、iPhone・Android の端末で動くアプリを作る職種です。画面を作るだけでなく、通信・端末内の保存・通知・カメラや位置情報などの端末の機能、そしてストアへの配信までを担当します。

作り方は3つ。どれを選んでも共通の土台があるiOSSwift・SwiftUI(UIKit)Mac と Xcode で開発AndroidKotlin・Jetpack ComposeAndroid Studio で開発クロスプラットフォームFlutter・React Native・KMP1つのコードで両方共通:通信・認証・端末の保存・通知・ストアへの配信・クラッシュの監視画面の作り方は OS ごとに違っても、サーバーとの境目の知識はどの道でも同じように使う
iOS・Android をそれぞれ作るか、1つのコードで両方を作るか。どちらでも共通の知識がある

iOS/Android/クロスプラットフォーム

  • iOS:Swift と SwiftUI(古い画面は UIKit)で作ります。開発には Mac と Xcode が必要です。端末の種類が少なく、新しい OS への更新が速いのが特徴です。
  • Android:Kotlin と Jetpack Compose(古い画面は View)で作ります。メーカー・端末・OS の版が多く、その差に対応するのが仕事の一部です。
  • クロスプラットフォーム:Flutter・React Native・Kotlin Multiplatform などで、1つのコードから両方のアプリを作ります。人数が少ないチームで両 OS を出したいときに選ばれます。ただし、通知・課金・端末の機能まわりではネイティブ(各 OS 専用)の知識が結局必要になります。

会社によって「iOS 担当」「Android 担当」と分かれることも、1人が両方を見ることもあります。どちらの場合も、API を作るサーバー側の人と仕様をすり合わせる力が欠かせません。

Flutter・React Native・KMP の比較

面接ではこう答える

モバイルアプリエンジニアは、iPhone や Android の端末で動くアプリを設計・実装し、ストアへの配信と配信後の運用まで担当する職種です。画面を作るだけでなく、通信、端末内のデータの保存、プッシュ通知、カメラや位置情報などの端末の機能を組み合わせて体験を作ります。作り方は iOS と Android をそれぞれネイティブで作るか、Flutter などで1つのコードから作るかがあり、どちらでも OS の仕組みとサーバーとの連携の知識が必要です。

ひとことで

アプリは審査と利用者の更新を経て届くので、不具合をすぐ直せず、古い版も何年も残る。

アプリは、Web と比べて「出したものをすぐ直せない」「古い版が残り続ける」「端末がばらばら」という3つの大きな違いがあります。この違いが、アプリの設計・テスト・リリースのやり方のほとんどを決めています。

観点Webアプリ
配信サーバーに置けばすぐ全員に届くストアの審査を通ってから届く。審査に1〜2日かかることもある
更新古い版は残らない利用者が更新しない限り古い版が動き続ける。何年も前の版から API が呼ばれる
端末ブラウザーの差を吸収すればよい画面の大きさ・OS の版・メモリ・メーカーごとの癖がばらばら
オフラインつながらなければ表示できないのが普通地下鉄や機内でも使われる。保存と同期を設計する
実行の制限タブが開いている間は動く裏に回ると OS に止められたり、終了させられたりする

特に「出したものをすぐ直せない」ことが大きな違いです。不具合のある版が利用者の手元に残るので、リリース前のテスト、段階的リリース、サーバー側から機能を止める仕組み(Feature Flag)を最初から用意しておきます。

Web は直せばすぐ届く。アプリは審査と更新を経て届き、古い版も残るWebアプリ修正デプロイ全員にすぐ反映修正ビルド・署名審査多くは1〜2日段階的に配信利用者が更新更新しない人の手元では古い版が動き続け、何年も前の版から API が呼ばれる
Web は直せばすぐ全員に届くが、アプリは審査と利用者の更新を経て届き、古い版も残る

面接ではこう答える

Web との一番の違いは、出したものをすぐには直せないことです。修正版はストアの審査を通り、さらに利用者が更新して初めて届くので、古い版が何年も動き続けます。そのため API は過去のすべての版から呼ばれる前提で後方互換を守り、リリースは段階的に広げ、問題があればサーバーから機能を止められる Feature Flag を用意します。端末や OS の版がばらばらなことと、回線が切れることも前提にして設計します。

アプリエンジニアの仕事は、コードを書く時間だけではありません。企画の段階で「OS の制約でできること・できないこと」を伝え、サーバー側と API をすり合わせ、リリースの後はクラッシュや評価を見て直す、という一連の流れに関わります。

段階アプリエンジニアがすること主に話す相手
企画・仕様OS の制約(通知・裏の処理・権限)を伝え、作る量を見積もるPdM・デザイナー
設計画面の状態、端末の保存、API の形を決めるサーバーのエンジニア
実装・レビュー画面と処理を作り、テストを書き、互いにレビューするチームのエンジニア
テスト・審査テスト配信で確かめ、ストアの審査に出すQA
リリース・運用段階的に公開し、クラッシュ率・評価・問い合わせを見て直すサポート・SRE

特に大事なのは、サーバー側の人と API の約束を早めに決めることです。アプリは古い版が残るので、後から API を変えるのが Web より難しく、最初の約束の質がそのまま運用の楽さに響きます。

アプリエンジニアは多くの職種の間に立つアプリエンジニアPdM何を作るか・優先順位デザイナー画面・操作の仕様サーバーのエンジニアAPI の仕様・変更QAテストの観点・不具合サポート・SRE問い合わせ・障害
企画から運用まで、多くの職種とやり取りしながら進める

アプリの技術は、OS の基礎の上に、設計・通信・配信と運用が積み重なっています。まずは片方の OS の基礎と設計を固め、そのうえで通信と配信を「1本のアプリを出す」経験の中で覚えるのが近道です。

分野最低限できること章
OS の基礎ライフサイクル・状態の消え方・メインスレッドの決まりを説明できるiOS・Android
設計状態の置き場所と、画面・ViewModel・Repository の分け方を決められるアーキテクチャ
データ端末の DB のマイグレーションと、オフラインの同期を設計できる端末のデータ
通信・認証失敗する前提の通信、トークンの保存と更新を作れる通信・認証
配信・運用段階的リリースと、クラッシュ率・起動時間の改善を回せる性能・配信
このサイトの章と、技術の層配信・運用テスト・審査・段階的リリース・クラッシュ率(第5部)通信と連携不安定な回線・API・認証・プッシュ通知・リンク(第4部)アプリの設計状態管理・モジュール分割・端末の DB・オフライン(第3部)OS の基礎ライフサイクル・UI の仕組み・並行処理(第2部)色の付いた層は、どの会社・どのアプリでも必ず聞かれる中心の部分
下の層ほど OS に近い土台、上の層ほど利用者に届けるための知識
ひとことで

細かい操作感や体験にこだわり、OS の変化を追い続けられる人に向く。

向いているのは、手に持って触ったときの気持ちよさにこだわれる人です。ボタンの反応の速さ、スクロールのなめらかさ、片手で届く位置など、細かい差が評価に直結します。加えて、OS の新しい版が毎年出るので、新しい仕組みを追い続けるのが苦にならない人、端末ごとの「なぜかこの機種だけ落ちる」を粘り強く調べられる人も向いています。

キャリアは大きく2つの道があります。

道深めること活躍しやすい場
スペシャリストiOS か Android のどちらかを深める。描画の性能、OS の新機能、アクセシビリティ、アプリ全体の設計利用者の多いアプリ、OS ごとにチームが分かれた会社
フルスタック寄り両 OS やクロスプラットフォーム、さらに API やサーバー側まで広く扱う小さなチーム、スタートアップ

どちらの道でも、通信・認証・データの同期といった「サーバーとの境目」の知識は共通して役に立ちます。まずは片方の OS で1本のアプリを最初から配信まで経験すると、どちらに進むか決めやすくなります。

面接ではこう答える

モバイルアプリエンジニアに向いているのは、手に持って触ったときの反応の速さやスクロールの滑らかさといった細かい体験にこだわれる人と、毎年変わる OS の新しい仕組みを追い続けられる人です。キャリアは、iOS か Android のどちらかを深めるスペシャリストの道と、両 OS やサーバー側まで広く扱う道があります。どちらでも、通信・認証・同期のようなサーバーとの境目の知識は共通して役に立ちます。

この章のまとめ

🖨 まとめシート(印刷・PDF)
  • iOS・Android・クロスプラットフォームの違いと、アプリならではの難しさ
  • 審査・配信・古いバージョンが残ることを前提にした開発

この章のクイズ

面接ではこう聞かれる

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1アプリ開発で Web と違って難しいと感じる点は?

模範回答

一番大きいのは、出したものをすぐに直せないことです。ストアの審査を通さないと修正版を届けられず、利用者が更新しない限り古い版が動き続けます。そのため API は古い版からも呼ばれる前提で互換性を保ち、致命的な問題に備えて段階的リリースや Feature Flag、最低バージョンの強制アップデートを用意しておきます。

もう一つは端末と環境の多様性です。画面の大きさ、OS の版、メモリの少ない端末、メーカーごとの電池の節約機能などで挙動が変わります。さらに電車の中のように回線が切れたり遅くなったりするので、オフラインでの保存と後からの同期、タイムアウトと再試行を設計する必要があります。Web よりも「リリース前に問題をつぶし、出した後は遠隔で止められるようにする」ことに力を使う点が違うと感じています。

深掘りされたら

  • 古い版のアプリが残ることで、API の設計はどう変わりますか?
  • 端末の多様性に対して、テストはどう工夫していますか?

見られているポイント審査・古いバージョン・端末の多様性・オフライン

Q2この機能はアプリと Web のどちらで作るべきか、と相談されたらどう答えますか?

模範回答

使われ方で決めます。毎日のように開く、通知で呼び戻したい、カメラ・位置情報・生体認証など端末の機能を深く使う、オフラインでも使いたい、という条件がそろうならアプリが向いています。逆に、たまにしか使わない、検索や共有のリンクから初めて来る人が多い、内容を毎日のように変えたい、という場合は Web のほうが届けやすく、直すのも速いです。

アプリにすると、審査・古い版の互換性・両 OS の開発という手間が続くことも伝えます。例えば、まず Web で出して使われ方を確かめ、よく使う人向けにアプリを出す、という段階の踏み方も提案します。

深掘りされたら

  • アプリの中に Web の画面(WebView)を混ぜるのはどんなときですか?
  • アプリを作らないと決めた例はありますか?

見られているポイント使われ方・端末の機能・更新の手間で判断できるか

Q3アプリをリリースから運用まで担当した経験を教えてください。

模範回答

例えば、家計簿アプリの新しい版を担当したとします。開発中は、古い版から API が呼ばれ続けることを前提に、サーバーとの間で項目を足すだけの変更にとどめ、新しい機能は Feature Flag で隠して出しました。

リリースは段階的に行い、最初の数日はクラッシュ率と問い合わせを毎日見ました。ある機種だけで落ちることが分かったので、配信を止め、Flag でその機能を切ってから修正版を審査に出しました。この経験から、出す前に「止める手段」を用意しておくことの大切さを学びました。

深掘りされたら

  • リリースの手順で自動化したことは?
  • 運用で一番大変だったことは?

見られているポイント出した後の監視と、止める手段まで考えているか