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

フリーランスのReact Nativeエンジニアがつまずきやすいのは、ストア公開や署名の責任があいまいなまま始まる契約、版上げの見積もりの甘さ、ストア外の更新の誤配信、Macや実機など道具の負担です。どれも、Reactで画面を作る仕事の外側、つまりJavaScriptの外で起きることを、外部の立場で一人で抱えるところから生まれます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくし、現場では手順の文書化と早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、React Nativeならではの場面と対策を整理します。独立前に積んでおきたい経験はReact Nativeエンジニアがフリーランスになるにはで扱っているので、ここでは「参画してから起きやすい場面」に絞ります。

契約でのつまずき

「アプリ開発」とだけ書かれ、公開と運用の範囲があいまい

契約書に「モバイルアプリの開発」とだけ書かれていると、ストアへの申請、審査の差し戻しへの対応、公開後の不具合対応まで、すべて含まれていると受け取られることがあります。React Nativeの案件は少人数で両OSを担うことが多く、範囲が広がりやすい職種です。

対策は、画面の開発、ネイティブ側の設定、ストア申請と審査対応、公開後の保守を分けて、どこまでが自分の担当かを契約前に確かめておくことです。フリーランス法では、発注側は業務の内容や報酬、支払期日などを書面や電磁的方法で示す必要があります（公正取引委員会の特設サイト、2026年10月時点）。明示される項目は取引条件の明示の記事で解説しています。範囲が途中で広がったときの扱いは業務範囲が変わったときの記事をご覧ください。

署名の鍵とストアのアカウントの持ち主が決まっていない

立ち上げの案件では、ストアの開発者アカウントや署名の鍵を誰が作り、誰が持つかが決まらないまま進むことがあります。フリーランスが自分のアカウントで公開してしまうと、契約が終わったあとの引き渡しで揉める原因になります。

アカウントと鍵は発注側の名義で作ってもらい、自分は権限を付けてもらう形にするのが基本です。鍵を預かる場合は、保管の方法と、契約終了時の返し方を書面で決めておきます。

「固定の期間で版上げ」を請け負ってしまう

古い版のまま止まっていたアプリの版上げを、期間と金額を固定して引き受けると、依存ライブラリの置き換えが想定より膨らんだときに、自分が抱えることになります。版上げは、始めてみないと詰まりどころが分からない作業です。

対策は、最初に調査の期間を取り、その結果をもとに計画と見積もりを出し直す二段階の進め方を提案することです。成果物の完成を約束する契約か、作業の時間に対して報酬が払われる契約かでも、負う責任が変わります。

現場でのつまずき

iOSとAndroidの片方でしか確かめていない

手元の環境の都合で、片方のOSだけで動作を確かめ、もう片方で不具合が見つかることがあります。とくに、権限の扱い、通知、キーボードや画面の端の表示などは、OSごとに違いが出やすい部分です。

確認の手順を参画の初期に決め、どの機能をどのOSのどの端末で確かめたかを報告に残すようにすると、抜けが減ります。手元に実機がない端末は、発注側に貸し出しを相談するか、確認の範囲から外すことを明らかにしておきます。

ネイティブの担当者との境目があいまい

SwiftやKotlinの担当者がいる現場では、ネイティブモジュールの不具合がどちらの担当か分からず、問題が宙に浮くことがあります。JavaScript側から見える症状と、ネイティブ側で起きている原因を切り分けて伝えられると、話が進みやすくなります。境目の担当を、参画の初期に窓口と確かめておくことが出発点です。

自分のやり方を早く持ち込みすぎる

状態管理のライブラリや、Expoの使い方には、人によって好みがあります。前の現場でうまくいった構成を、参画してすぐに提案すると、既存のメンバーには負担に映ることがあります。まずは今の構成に合わせて動き、困りごとが見えてから、理由とともに一部ずつ提案するほうが受け入れられやすくなります。

技術でのつまずき

ストア外の更新で、出してはいけないものを出す

Expoの仕組みを使うと、JavaScriptや画像などはストアの審査を通さずに配信できます。一方、ネイティブのコードや依存関係、権限、ExpoのSDKの版を変える場合は、新しいアプリのビルドが要ります（Expo公式ドキュメント、2026年10月時点）。この区別を誤ると、古いビルドのアプリに合わない更新が届き、起動しなくなるおそれがあります。

対策は、ストア外の更新で出してよい変更の基準と、配信の手順を文書にして、発注側と合意しておくことです。本番への配信は、確認用の環境で確かめてから行う、と決めておくと安心です。ストアの規約との関係はReact Nativeの案件で求められるスキルで触れています。

版上げを後回しにして、負債を引き受ける

機能の追加を優先し続けると、版上げが後回しになります。React Nativeは公式の予定表で2か月ほどの間隔で版が出ており、保守されるのは最新の3つのマイナー系列です（2026年10月時点のReleases Overview）。追従が遅れると、ライブラリの更新やストアの要件への対応が一度に押し寄せます。

対策は、版上げの必要性と、遅らせた場合の影響を、発注側が判断できる形で早めに伝えることです。版上げをやるかどうかを決めるのは発注側ですが、判断の材料を出すのはエンジニアの役目です。

再現しない不具合を、時間をかけて一人で追う

特定の端末やOSの版でしか起きない不具合を、一人で何日も追い続けてしまうことがあります。一定の時間を決め、それを過ぎたら状況と仮説を共有し、優先度の判断を仰ぐようにすると、稼働が膨らみすぎるのを防げます。

お金でのつまずき

Macや実機の費用を見込んでいない

iOSのビルドや確認にはMacが要り、両OSの実機もそろえる必要があります。フリーランスになると、こうした道具は自分で用意することが多くなります。発注側が貸し出す案件もあるため、契約前に確かめておきます。貸与のパソコンで作業する場合の注意は貸与パソコンの記事で整理しています。

リリース前の稼働の膨らみが精算されない

公開日が決まっている案件では、審査の差し戻しや直前の不具合で、稼働が想定を超えることがあります。精算の幅を超えた分の扱いは、契約で決めておかないと後から話しにくくなります。考え方は精算幅の記事をご覧ください。

公開が済んだところで契約が終わる

立ち上げの案件は、公開を区切りに契約が終わることがあります。6か月以上続く契約を解除したり更新しなかったりする場合、発注側は原則として30日前までに予告する必要があります（公正取引委員会の特設サイト、2026年10月時点）。詳しくは中途解除の予告の記事で解説しています。公開日が見えてきたら、次の案件を探し始めておくのが現実的です。

よくある質問

参画してから、ストア申請まで担当だと言われました。どうすればよいですか？

まずは契約書や発注書に書かれた業務の内容を確かめてください。含まれていない場合は、担当に加えるかどうか、加えるなら報酬や稼働をどうするかを、窓口と話し合う必要があります。その場で引き受ける前に、紹介を受けたエージェントに相談するのも一つの方法です。

ストア外の更新で不具合を出してしまったら、損害賠償を求められますか？

契約の形や内容によって変わります。成果物の完成を約束する契約か、作業に対して報酬が払われる契約かでも責任の範囲が違います。万一に備えて、配信の手順と承認の流れを事前に決めておくことが大切です。個別の判断が要る場合は、弁護士など専門家にご相談ください。

版上げをしたいのに、発注側が機能追加を優先します。

版上げを決めるのは発注側です。そのうえで、遅らせた場合にどのような作業が一度に必要になるか、ストアの要件にいつ影響しそうかを、判断できる形で伝えてください。小さな版上げを機能追加の合間に挟む進め方を提案するのも有効です。