Androidエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

フリーランスのAndroidエンジニアの仕事は、Kotlinで画面と処理を作り、さまざまな端末で動くかを確かめ、Google Playや社内の仕組みでリリースすることの繰り返しです。ただし、運用中のアプリに入るのか、新しく作るのか、移行や要件対応のために入るのか、業務用の端末で動くアプリなのかで、1日の時間の使い方も、話す相手も、残る成果物も大きく変わります。

この記事では、Androidの案件を4つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はAndroidの報酬の記事、求められる技術はAndroidの案件で求められるスキルで扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「アプリの状態」と「端末の種類」で決まる

Androidの案件は、同じ「Androidエンジニア募集」でも働き方がかなり違います。違いを生むのは主に次の2つです。

• アプリの状態：すでに利用者がいて定期的にリリースしているか、これから作るか、古い構成から移している途中か
• 端末の種類：一般の利用者のスマートフォンで動くのか、店舗や倉庫の業務用端末、外部の機器とつながるアプリなのか

この2つを組み合わせると、フリーランスのAndroid案件はおおむね次の4種類に分けられます。

以下では、それぞれの流れを典型的な例として紹介します。時間の配分は案件ごとに違うため、目安として読んでください。

運用中アプリの機能開発の仕事

一般向けのアプリを、定期的なリリースの中で育てていく案件です。Androidの案件の中でも数が多い型です。

1日の流れ（例）

朝は、チームの短い打ち合わせで前日の進み具合と困りごとを共有します。午前中は担当する機能の実装に集中し、ComposeやViewで画面を作り、ViewModelやリポジトリに処理を足します。午後は、ほかのメンバーのプルリクエストのレビュー、デザイナーとの細かな見た目のすり合わせ、iOS担当やサーバー側の担当とのAPIの仕様の確認が入ります。夕方は、クラッシュの報告やストアのレビューに上がった不具合を見て、再現できるかを確かめることもあります。

1か月の流れ（例）

• リリースの周期の始め：次に出す機能の仕様を読み、見積もりと分担を決める
• 周期の途中：実装とレビュー、テストの追加。iOS版と挙動をそろえるための確認
• リリース前：検証端末での確認、QA担当からの指摘の修正、リリースノートの準備
• リリース後：段階的な公開の様子とクラッシュの報告を見て、必要なら修正版を出す

成果物

実装したコードとテスト、プルリクエストの説明、設計の判断を残したメモ、不具合の調査結果などです。ストアへの提出そのものを担うかどうかは、チームによって分かれます。

新規アプリの開発の仕事

発注元のアプリを受託側で作る案件や、事業会社が新しいサービスを立ち上げる案件です。最初の数週間と、その後とで仕事の中身が変わります。

立ち上げの時期

最初は、画面の一覧とデザイン、APIの仕様を読みながら、アーキテクチャ、モジュールの分け方、使うライブラリ、ビルドの種類（開発用・検証用・本番用）を決めます。ここで決めたことが後の作業のしやすさを左右するため、決めた理由を文書に残す時間が多くなります。

実装の時期

画面と通信の実装を並行して進め、発注元への中間の確認会で動くものを見せます。仕様の追加や変更が出やすい時期でもあり、影響の範囲を説明する機会が増えます。

公開の準備

ストアに載せる情報、権限の説明、プライバシーに関する申告などは発注元が判断する事項ですが、技術的な情報を求められることがあります。Google Playでは、新しいアプリの公開にあたってアプリの署名の設定（Play App Signing）が必要です（2026年10月時点のAndroid Developersの案内）。署名の鍵や公開のアカウントを誰が管理するかは、立ち上げの時期に確かめておきます。

成果物

設計の方針書、モジュールの構成図、画面と処理のコード、テスト、ビルドとリリースの手順書、引き継ぎの資料などです。受託の案件では、納品物として何を渡すかが契約で決まっていることが多くあります。

移行・要件対応の仕事

JavaからKotlinへ、XMLのViewからJetpack Composeへ、といった移行や、Google Playの対象APIレベル（targetSdk）の引き上げに合わせた対応を担う案件です。Android Developersの案内では、2026年8月31日以降、新しいアプリとアプリの更新はAndroid 16（APIレベル36）以上を対象にする必要があるとされています（スマートフォン向けの場合。2026年10月時点）。この要件は毎年のように引き上げられてきたため、運用中のアプリでは毎年この種の作業が生まれます。

1日・1か月の流れ（例）

最初の時期は、直すより調べるのが仕事です。OSの版ごとの挙動の変更点を読み、権限、通知、バックグラウンドの処理、画面の表示など、どこに影響が出るかを洗い出します。組み込んでいるライブラリやSDKが新しい版に対応しているかも調べます。

調査が終わると、影響の大きいところから少しずつ直し、そのたびに検証端末で確かめます。移行の案件では、画面単位やモジュール単位で区切り、リリースを止めずに置き換える進め方が一般的です。月の単位では、「どこまで移したか」「残りはどこか」をテックリードやリリースの責任者に報告します。

成果物

影響の調査結果、移行の計画と進み具合の一覧、置き換えたコード、確認した端末とOSの版の記録などです。要件対応の作業は、調べた内容を記録に残しておくと、翌年の対応でそのまま使えます。

業務用端末・機器連携の仕事

倉庫や店舗、工場、医療や物流の現場で使う業務用の端末のアプリや、Bluetoothなどで外部の機器とつながるアプリの案件です。

1日・1か月の流れ（例）

1日の中で、実機を使った確認の比重が大きくなります。バーコードの読み取り、専用のボタン、機器との接続と切断、通信が不安定な場所での動きなど、エミュレーターでは確かめにくい点を一つずつ試します。業務部門や現場の担当者と、操作の手順や画面の流れを決める打ち合わせも入ります。

1か月の単位では、機器のメーカーや担当者との仕様の確認、端末の入れ替えの計画、社内での配布の方法の確認などが加わります。現場への導入の時期は、出社や現地での作業が増えることがあります。リモートとの相性はAndroidのリモート案件の記事で整理しています。

成果物

アプリのコードに加えて、機器との通信の仕様をまとめた資料、端末ごとの確認の結果、現場向けの操作の手順、配布と更新の手順書などです。一般向けのアプリより、文書で残すものが多くなる傾向があります。

どの案件にも共通する仕事

種類が違っても、次の仕事はほとんどのAndroid案件にあります。

1. 端末の差の確認：画面サイズ、OSの版、メーカーごとの挙動の違いを前提に、どの範囲を確かめるかを決める
2. 他のOSとのすり合わせ：iOS版がある場合、仕様や挙動の違いをそろえる
3. ビルドとリリースの運用：ビルドの種類、署名の設定、配布の手順を守る
4. 記録：判断の理由や調査の結果を残し、後から来た人も追えるようにする

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。月の稼働時間に幅を決めて精算する契約が多いため、リリース前や不具合の調査で時間が延びたときも、日々記録しておく必要があります。精算の仕組みは精算幅の記事をご覧ください。

関わる相手と、その相手に出すもの

iOS版を別の人が担当する案件では、相手の進み具合に合わせて作業の順番を組み替えることもあります。iOS側から見た働き方はiOSエンジニアの仕事内容、一つのコードで両方を作る働き方はFlutterエンジニアの仕事内容で解説しています。

よくある質問

フリーランスのAndroidエンジニアは、実装だけをしていればよいですか？

実装が中心の案件もありますが、レビュー、端末での確認、iOS担当やサーバー側とのすり合わせは多くの案件で求められます。どこまでを担う想定かは、参画前に確かめておくと、稼働の見込みとのずれを防げます。

会議はどのくらいありますか？

運用中アプリのチームでは、短い朝の打ち合わせと、リリースの周期ごとの計画や振り返りが中心です。新規開発の立ち上げや業務用端末の案件では、発注元や業務部門との打ち合わせが増えます。案件によって差が大きいため、面談で会議の頻度を聞いておくと安心です。

参画して最初の1か月は何をすることが多いですか？

開発環境とビルドの準備、コードの構成とリリースの流れの把握、検証端末の受け取りから始めるのが一般的です。初月の進め方はAndroidの参画初月にやることで詳しく解説します。