Androidエンジニアのフリーランス案件で求められるスキルと経験

Androidのフリーランス案件では、Kotlinのコルーチンとフローで非同期処理と画面の状態を扱えること、Jetpack Composeで画面を作れること、Googleが示す推奨アーキテクチャに沿って層を分けられること、Google Playの技術要件に合わせてアプリを直せることが中心に見られます。案件側は機能の数より、「長く運用されるアプリを、設計を崩さずに育てられるか」を確かめようとします。

この記事では、Androidの案件で求められるスキルを分野ごとに整理し、スキルシートや面談での示し方を解説します。Kotlinファーストの方針やtargetSdkの要件、独立までの準備はAndroidエンジニアがフリーランスになるにはで扱っているため、ここでは「何ができると評価されるか」に絞ります。

Androidの案件で見られるスキルの全体像

Kotlinのコルーチンとフロー

Kotlinで書けることは前提として見られます。差がつくのは、非同期処理と画面の状態をどう流しているかです。

• 通信やデータベースの処理を、適切なスコープのコルーチンで実行し、画面が破棄されたときに取り消されるようにした
• データの変化をFlowで流し、画面はその流れを受け取るだけにした
• StateFlowとSharedFlowを使い分け、一度だけ表示するメッセージと、画面の状態を区別した
• 例外がどこで捕まるかを把握し、失敗したときの表示まで設計した

コールバックやRxJavaで書かれた既存の処理を、コルーチンへ移した経験があれば、どの範囲をどの順で移したかを整理しておきましょう。

Jetpack Composeで画面を作る力

Android Developersのドキュメントでは、Jetpack ComposeはAndroidのUIを作るための現代的なツールキットとされ、さまざまな画面サイズに合わせたアプリを作りやすくすると説明されています。Viewを使った従来の作り方とは違う、宣言的な考え方で画面を組み立てます。

案件で見られやすいのは、書けることに加えて次の点です。

• 状態を親に持たせて子は表示だけを担う形（状態の巻き上げ）で、部品を再利用しやすくした
• 不要な再描画（再コンポーズ）が起きる原因を調べ、表示の重さを改善した
• タブレットや折りたたみ端末など、画面サイズの違いに合わせた配置を作った
• XMLのViewの画面とComposeの画面を同じアプリで共存させ、段階的に移した

ViewからComposeへの移行は独立の記事でも触れていますが、スキルとしては「移した結果、何が楽になったか」まで話せると評価につながります。

公式の推奨アーキテクチャに沿った設計

Android Developersのアプリ アーキテクチャ ガイドでは、アプリを少なくとも2つの層（UI層とデータ層）に分け、必要に応じてその間にドメイン層を置く構成が推奨されています。主な考え方は次のとおりです。

既存のアプリは、このガイドどおりに作られているとは限りません。Activityに処理が集まったコードを、ViewModelとリポジトリに分けていった経験や、オフラインでも動くようにデータベースを情報源にした経験は、運用中のアプリに入る案件で具体的に話しやすい実績です。

Google Playの技術要件に追従する力

Google Playでは、毎年のように技術的な要件が加わります。対象とするAPIレベル（targetSdk）の要件については独立の記事で扱っているため、ここではもう一つの要件を紹介します。

Android Developersの案内では、Android 15（APIレベル35）以上を対象とするアプリは、64ビットの端末で16KBのメモリページサイズに対応する必要があるとされています。2027年2月1日以降は、対応していないアプリの更新をリリースできなくなると案内されています（2026年10月時点）。

この対応は、Kotlinだけで書かれたアプリより、C/C++のネイティブコードや、ネイティブのライブラリを含むSDKを使っているアプリで作業が発生しやすい部分です。組み込んでいるライブラリの対応状況を調べ、更新や置き換えを進めた経験は、運用中のアプリで頼りにされる経験です。要件は変わるため、最新の内容は公式の案内でご確認ください。

バックグラウンド処理・権限・ビルド

ほかにも、Androidの案件でよく求められるスキルがあります。

• バックグラウンド処理：WorkManagerなどでの定期処理、OSの制約の中での動かし方
• 権限：通知、位置情報、カメラなどの権限を、必要な場面で求める設計
• ビルド：Gradleの設定、ビルドの種類（開発用・本番用）の分け方、コードの縮小と難読化
• テスト：ViewModelやリポジトリのユニットテスト、ComposeのUIテスト
• 品質の監視：クラッシュ報告からの原因の特定、特定の端末でだけ起きる不具合の調査

古いJavaのコードを扱う案件もあるため、Javaのスキルの見られ方はJavaの案件で求められるスキルも参考になります。

スキルシートと面談での示し方

Androidのスキルシートでは、アプリごとに次の点を書くと、経験の中身が伝わります。

• アプリの種類と規模（利用者の規模は伏せられる範囲で）
• KotlinとJavaの比率、ComposeとViewの比率
• 設計の方針（層の分け方、依存関係の注入の方法）
• 非同期処理の書き方（コルーチン、Flow、RxJavaなど）
• 対応したストアやOSの要件、品質を上げた取り組み

iOSやFlutterの案件とあわせて検討している方は、iOSの案件で求められるスキルやFlutterの案件で求められるスキルと比べてみてください。書き方の詳細はAndroidのスキルシートの書き方、面談の準備は面談でよく聞かれる質問で解説しています。

よくある質問

RxJavaの経験しかありませんが、評価されますか？

RxJavaで非同期処理やデータの流れを設計した経験は、考え方の土台として評価されます。ただ、新しいコードはコルーチンとFlowで書く現場が多いため、両方の違いを説明できるようにしておくと安心です。RxJavaからの移行を担える人が求められる案件もあります。

推奨アーキテクチャどおりに作った経験がないと不利ですか？

ガイドどおりに作られたアプリばかりではないため、経験がなくても参画できる案件は多くあります。大切なのは、層を分ける目的を理解し、既存のコードをどう整えるかを考えられることです。小さなアプリでガイドの構成を試しておくと、面談で説明しやすくなります。

業務用端末のアプリの経験は、一般向けアプリの案件で生かせますか？

Kotlinでの開発や、端末の違いへの対応、バックグラウンド処理の経験は生かせます。一方、一般向けのアプリでは、ストアでの公開や画面の使いやすさ、利用者の多さに伴う品質の監視が重く見られます。応募する案件の性質に合わせて、近い経験から示しましょう。