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

フリーランスのFlutterエンジニアがつまずきやすいのは、「両OS対応」の中身が決まらないまま引き受けること、ストアのアカウントや証明書の扱い、片方のOSだけで確かめて出してしまうこと、パッケージとOS要件の更新への追従、端末の費用や公開後の契約終了です。どれも、ひとつのコードで2つのOSとストアを少人数で受け持つFlutterならではの事情から起きます。

対策の基本は、範囲と権限を参画前に言葉にしておき、現場では両OSでの確認と記録を習慣にすることです。この記事では、契約・現場・技術・お金の順に、Flutterの案件で起きやすい場面と対策を整理します。求められるスキルの全体像はFlutterの案件で求められるスキルで扱っているので、ここでは「実際につまずく場面」に絞ります。

契約でのつまずき

「両OS対応」がどこまでを含むか決まっていない

求人や契約書に「Flutterでのアプリ開発（iOS・Android）」とだけ書かれ、参画してみると、ストアへの申請、審査の差し戻し対応、ネイティブ側のコード、API側の小さな修正まで期待されていた、という食い違いはよく起きます。Flutterは「一人で両方を見られる」ことを前提に募集されやすいため、範囲が広く読まれがちです。

対策：参画前に、自分が担う作業と担わない作業を分けて確かめます。たとえば「Dartの画面と機能の実装、両OSのテスト配布までは担う。ストアへの最終提出とネイティブのSDK組み込みは発注側の担当」のように、作業の単位で言葉にしておきます。参画後に範囲が広がってきたときの扱いは業務範囲が変わったときの記事をご覧ください。

ストアのアカウントや証明書の扱いが決まっていない

App Store ConnectやGoogle Play Consoleのアカウント、署名の鍵、証明書を誰が持ち、フリーランスにどこまでの権限を渡すかが決まっていないと、リリースの直前に作業が止まります。逆に、個人のアカウントで署名や登録をしてしまうと、契約が終わったあとの引き継ぎで困ります。

対策：アカウントは発注側の名義で、必要な権限だけを付与してもらう形を基本にします。署名の鍵の保管場所と、契約終了時に権限を外す手順も、早いうちに窓口と確かめておきます。

受託の請負で「完成」の基準があいまい

受託開発の請負契約では、どの時点で完成とみなすかが報酬に直結します。「ストアの審査を通ること」まで完成に含むのか、「検収用のビルドを渡すこと」で完成なのかがあいまいだと、審査の差し戻しが続いたときに負担が膨らみます。準委任との違いは準委任契約と請負契約の違いで解説しています。

現場でのつまずき

片方のOSだけで確かめて出してしまう

普段使っている端末のOSだけで動作を確かめ、もう一方のOSで表示の崩れや権限の確認画面の違いが見つかる、というつまずきは、Flutterで特に起きやすいものです。ひとつのコードで動くぶん、「片方で動けば大丈夫」と思い込みやすくなります。

対策：変更ごとに、両OSの実機かシミュレーターで確かめる手順を決め、確かめた端末とOSの版をプルリクエストや報告に書きます。OSごとに差が出た点は、報告を分けて書くと、レビューする側も追いやすくなります。

ネイティブ担当やデザイナーとの境目がずれる

ネイティブのエンジニアが別にいる現場では、プラットフォームとのつなぎ込みをどちらが書くかがあいまいになりやすく、双方が手を付けない、あるいは二重に書く、ということが起きます。デザイナーとの間でも、iOSらしい見た目とAndroidらしい見た目のどちらに寄せるかが決まらないまま実装が進むことがあります。

対策：ネイティブ側との境目は「どの機能のどの部分を誰が書くか」を機能単位で決めます。見た目の寄せ方は、最初の画面を作る前にデザイナーと一度すり合わせておくと、作り直しが減ります。

自分の得意な書き方を持ち込みすぎる

状態管理や層の分け方には複数の流儀があります。前の現場で慣れた方式を、参画してすぐに持ち込むと、コードの書き方が混ざり、チームの保守の負担が増えます。

対策：最初は既存の書き方に合わせます。変えたほうがよいと思う点は、理由と影響の範囲を添えて提案し、チームの判断に委ねます。

技術でのつまずき

パッケージの更新が止まり、身動きがとれなくなる

Flutterのアプリは多くのパッケージに支えられています。更新を後回しにしていると、Flutter本体の版を上げようとした段階で、依存の衝突や、更新が止まったパッケージが見つかり、作業が一気に膨らみます。Flutterの公式ドキュメントでは、flutter pub outdated で古くなった依存を洗い出す方法が案内されています（2026年10月時点）。

対策：参画して早いうちに依存の一覧を確かめ、更新が止まっているパッケージや、版を大きく上げる必要があるものを洗い出して共有します。更新は一度にまとめず、小さく分けて進めます。

OS側の要件の変更に気づくのが遅れる

ストアの要件は定期的に変わります。たとえばGoogle Playでは、2026年8月31日から、新規アプリとアプリの更新はAndroid 16（APIレベル36）以上を対象にすることが求められています（Android Developersの案内、2026年10月時点）。こうした変更に気づくのが遅れると、機能の追加より先に対応が必要になり、計画が崩れます。

対策：AppleとGoogleの公式の告知を定期的に読む習慣を持ち、影響がありそうな変更は早めにチームに伝えます。Flutter側の対応状況もあわせて確かめておくと、作業の見積もりがしやすくなります。

Flutterの外側のビルド設定で詰まる

Dartのコードは問題なく書けても、iOS側のビルド設定やライブラリの管理、Android側のビルドの設定で詰まることがあります。Flutterから開発を始めた人ほど、この部分に慣れていないことが多い傾向があります。

対策：エラーが出たときに、FlutterとOS側のどちらで起きているかを切り分ける手順を身につけます。両OSのビルド設定を一度自分で読み、どこで何が決まっているかを把握しておくと、詰まったときの時間が短くなります。

お金でのつまずき

端末やMac、開発者アカウントの費用を誰が持つか決まっていない

Flutterの開発には、iOSのビルドのためのMacや、両OSの検証端末が必要です。手持ちの機材を使うのか、貸与されるのか、費用の精算があるのかが決まっていないと、思わぬ出費になります。経費の扱いは業務委託の交通費・経費は誰が負担する？、貸与の機材を使う場合の注意点は貸与PCを使うときの注意点をご覧ください。

審査の差し戻しやリリース前後で稼働が膨らむ

審査の差し戻しが続いたり、公開直後に不具合が見つかったりすると、稼働が延びます。超えた分の扱いを決めていないと、報酬に反映されないまま負担だけが残ります。

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

アプリの公開を節目に契約が終わる

新規アプリの公開や、ネイティブからの置き換えの完了を節目に、開発の体制が小さくなることがあります。フリーランス法では、6か月以上の業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。ただ、6か月に満たない契約もあり、予告があっても空白の期間がなくなるわけではありません。

対策：公開の時期が見えてきたら、更新の見込みを早めに確かめ、次の案件の相談を始めます。更新の仕組みは契約更新の仕組みで整理しています。

よくある質問

Flutterの案件で、ネイティブのコードを書くよう頼まれたら引き受けるべきですか？

経験があり、契約の範囲に含まれるなら引き受けてよいでしょう。範囲に含まれていない場合や経験が浅い場合は、作業の量と期限、品質の責任をどこまで持てるかを伝えたうえで、窓口と扱いを決めてください。黙って引き受けると、範囲外の作業が当たり前になりやすくなります。

個人のApple Developerアカウントでアプリを登録してよいですか？

発注側のアプリは、発注側の名義のアカウントで登録するのが基本です。個人のアカウントで登録すると、契約終了後の引き継ぎや、アプリの権利の扱いで問題になりやすくなります。判断に迷う場合は、参画前に窓口と取り決めておいてください。

前任者が残したパッケージが古く、更新すると壊れそうです。どうすればよいですか？

すぐに全部を更新しようとせず、古くなった依存の一覧と、更新した場合の影響の見立てをまとめて共有します。OSの要件に関わるものから優先し、小さく分けて進める計画を出すと、発注側も判断しやすくなります。