Androidエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのAndroidエンジニアがつまずきやすいのは、リリース作業や公開アカウントの扱いがあいまいなまま始まる契約、特定の端末でだけ起きる不具合の抱え込み、毎年のストアの要件への対応の見積もり違い、検証用の端末やPCの費用です。どれも、アプリが「作って終わり」ではなく、OSとストアと端末に合わせて動き続けることから起きます。

対策の基本は、範囲と環境を参画前の取り決めで小さくしておき、現場では再現の記録と早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、Androidならではの場面と対策を整理します。独立までの準備はAndroidエンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

「Android開発」の範囲にリリース作業が入っているか分からない

契約書には「Androidアプリの開発業務」とだけ書かれ、現場ではストアへの公開申請、審査で差し戻されたときの対応、ストアの掲載情報の更新まで期待されていた、という食い違いはよく起きます。リリースの作業は、終わりが審査の結果に左右されるため、時間が読みにくい部分です。

対策：参画前に、自分が担う作業（実装、テスト、ビルドの作成など）と、担わない作業（公開申請、ストアの掲載文の作成など）を言葉で確かめます。範囲の外の依頼が来たときの扱いは作業範囲が広がったときの記事と追加の依頼の断り方をご覧ください。

公開アカウントや署名の鍵を自分が持ってしまう

小さな発注元では、「アカウントの準備もお願いしたい」と頼まれることがあります。自分のデベロッパーアカウントでアプリを公開したり、署名の鍵を自分だけが持っていたりすると、契約が終わった後の更新や引き継ぎで問題になります。

対策：公開アカウントと署名の鍵は、発注元が持つのが基本です。誰のアカウントで公開し、鍵を誰が管理するかを参画前に確かめ、必要なら発注元のアカウントに招待してもらう形にします。成果物の権利の考え方は成果物の著作権の記事で解説しています。

指揮命令の形が社員と変わらなくなる

社内のモバイルチームに入り、勤務時間や作業の手順まで細かく指示されるようになると、準委任の契約と実態がずれてきます。考え方は偽装請負の記事で解説しています。

現場でのつまずき

検証の環境がそろうまで動けない

Androidの案件では、貸与PCの準備、リポジトリや署名の設定、検証用の端末の手配、社内の配布の仕組みへの登録など、作業を始めるまでの準備が多くあります。どれかが遅れると、最初の数日を何もできずに過ごすことになります。

対策：開始日までに、PCと端末を誰が用意するか、ビルドに必要な権限の申請先はどこかを窓口と確かめておきます。貸与PCの扱いは貸与PCを使うときの注意点、初月の進め方はAndroidエンジニアの参画初月にやることで整理しています。

特定の端末でだけ起きる不具合を一人で抱え込む

「特定のメーカーの端末でだけ落ちる」「あるOSの版でだけ通知が来ない」といった不具合は、手元の端末で再現できないことがあります。外部の立場だと「解決するまで報告しにくい」と考え、時間だけが過ぎていきがちです。

対策：再現できない不具合は、調べた範囲（試した端末とOSの版、ログ、クラッシュの報告の内容）と、次に試すことを添えて、早めに共有します。「まだ直っていない」ではなく「ここまで絞れた」と伝えると、追加の端末の手配や優先度の判断を相手がしやすくなります。

iOSチームやサーバー側との仕様のずれ

AndroidとiOSを別のチームで作る現場では、画面の動きやエラーの出し方がOSごとに少しずつずれていきます。気づかずに実装を進めると、リリース前に片方だけ作り直すことになります。

対策：仕様があいまいな点は、実装の前にiOS側とサーバー側の担当にまとめて確かめ、決まった内容をチケットや議事録に残します。

既存の作りを早く変えすぎる

前の現場でうまくいった設計やライブラリを、参画してすぐに持ち込むと、チームの反発を招きやすくなります。JavaとKotlin、ViewとComposeが混ざった状態には、それなりの経緯があることが多いからです。

対策：最初は既存の作りに合わせて実装し、困っている点が見えてから、変える理由と範囲を添えて提案します。

技術でのつまずき

年次のtargetSdk対応を軽く見積もる

Android Developersの案内では、2026年8月31日以降、新しいアプリとアプリの更新はAndroid 16（APIレベル36）以上を対象にする必要があり、延長を申請すると2026年11月1日まで猶予を得られるとされています（2026年10月時点）。targetSdkを上げると、権限、通知、バックグラウンドの処理などの挙動が変わることがあります。

数字を一つ変えるだけに見えて、実際には挙動の変更の調査、組み込んでいるライブラリの対応待ち、複数のOSの版での確認が重なり、作業が膨らみます。

対策：見積もりは、調査、修正、検証の3つに分けて出し、ライブラリの対応待ちのように自分では進められない部分を別にして伝えます。期限の前に終わらない場合の扱いも、早めに発注側と話しておきます。

ネイティブのライブラリの対応を見落とす

Android Developersの案内では、Android 15（APIレベル35）以上を対象とするアプリは、64ビットの端末で16KBのメモリページサイズに対応する必要があり、2027年2月1日以降は対応していない更新をリリースできなくなるとされています（2026年10月時点）。KotlinやJavaだけで書かれたアプリは対応済みとされますが、C/C++のコードや、それを含むSDKを組み込んでいると作業が発生します。

対策：参画の初期に、組み込んでいるSDKとライブラリの一覧を作り、ネイティブのコードを含むものと、その提供元の対応状況を確かめておきます。ライブラリの利用条件の考え方はOSSのライセンスの記事も参考になります。

経験の浅い技術を引き受けすぎる

「Composeもできますよね」「Kotlin Multiplatformもお願いしたい」と、面談で話した範囲を超える依頼が来ることがあります。引き受けたものの手が止まると、信頼を損ないます。

対策：経験した範囲と、調べながらなら進められる範囲を分けて伝えます。調べながら進める場合は、最初の数日で小さく試し、見通しを報告してから本格的に進めます。

お金でのつまずき

検証用の端末やPCの費用を見込んでいない

自分で端末を用意する案件では、OSの版やメーカーの違う端末をそろえる費用がかかります。報酬の額だけで案件を選ぶと、手元に残る額が想定より少なくなります。

対策：端末やPCを貸与してもらえるか、自分で用意するかを参画前に確かめます。事業で使う機器は経費として扱える場合があるため、経費にできるものの記事もご覧ください。

リリース前後の稼働の超過が精算されない

リリースの直前や審査の差し戻しが続いたときは、稼働が精算幅を超えることがあります。超えた分の扱いを決めていないと、負担だけが増えます。

対策：稼働を日々記録し、精算幅を超えそうな段階で窓口に伝えます。精算の仕組みは精算幅の記事で解説しています。

作業の山が終わると契約も終わる

移行や年次対応のために参画した場合、作業が終わった時点で契約が更新されないことがあります。フリーランス法では、6か月以上の業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。

対策：契約期間と作業の終わりの見込みを並べて見ておき、更新の見込みを早めに尋ねます。次の案件の相談は、契約の終わりの1〜2か月前には始めると決めておくと、空白の期間を短くしやすくなります。

よくある質問

参画してから、聞いていた作業と違うと気づきました。どうすればよいですか？

まずは、何が違うのかを具体的に書き出し、契約で決めた業務範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に早めに伝えてください。我慢して続けると、範囲外の作業が当たり前になり、後から戻しにくくなります。

リリース後に重大な不具合が見つかったら、責任を問われますか？

準委任契約では、成果そのものではなく、専門家として通常求められる注意を払って業務を行うことが約束の中身です。ただし、契約の内容や、作業の進め方に落ち度があったかどうかで判断が変わることがあります。不安がある場合は、契約書の損害賠償の条項を読み、弁護士などの専門家にご相談ください。

手元にない端末での不具合を直すように頼まれたら、どうすればよいですか？

再現できる環境がないまま推測で直すと、別の不具合を生むことがあります。端末の貸与や検証の仕組みの利用を発注側に相談し、それが難しい場合は、ログやクラッシュの報告から分かる範囲と、確かめられない点を分けて伝えてください。