Flutterエンジニアのフリーランス案件の選び方｜契約前に確かめたいこと

Flutterエンジニアのフリーランス案件を選ぶときは、報酬や稼働日数に加えて、アプリの段階、Flutterの担当人数、ネイティブ連携の範囲、ストア申請とアカウントの担当、コードの状態と版上げの状況、開発環境と端末、契約の形と成果物の7点を契約前に確かめておくことが大切です。同じ「Flutterエンジニア募集」でも、この7点の違いで負担と責任が大きく変わります。

特に見落としやすいのは、担当が自分一人になるか、申請やアカウントの管理まで任されるかです。案件票には画面の実装しか書かれていなくても、参画すると両OSのリリース全体を背負う現場があります。この記事では、Flutter案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

Flutter案件の選び方で差が出る理由

Flutterは一つのコードで両OSのアプリを作れるため、少人数のチームで選ばれやすい技術です。その分、案件票には「Flutterでのアプリ開発」とだけ書かれ、実際に担う範囲が読み取りにくくなりがちです。参画後によくあるずれは次のようなものです。

• 画面の実装の募集だったが、Flutterの担当は自分だけで、設計からリリースまで任された
• ネイティブの経験は不要と聞いていたが、決済や通知の連携でSwiftやKotlinを書く必要が出た
• 長く版を上げていないアプリで、機能追加より先に版上げとパッケージの入れ替えが必要だった
• ストアの権限がなく、申請のたびに社員の手が空くのを待つことになった

こうしたずれの多くは、面談と条件の確認の段階で聞き方を工夫すれば防げます。案件の種類ごとの働き方はFlutterの仕事内容の記事で整理しています。

契約前に確かめたい7つの点

1. アプリの段階：新規か、運用中か、置き換えか

最初に確かめたいのは、アプリがどの段階にあるかです。新規の立ち上げなら決める範囲が広く、運用中のアプリなら既存のコードに合わせて壊さずに変える仕事が中心になります。ネイティブのアプリにFlutterを部分的に入れる案件では、Flutterの部分をモジュールとして取り込む構成（add-to-app）になり、ネイティブ側のビルドの設定にも関わります（2026年10月時点、Flutterの公式ドキュメントによる）。

面談では「参画後の最初の1か月で、最も期待されている成果は何か」を聞くと、段階と役割が見えやすくなります。

2. Flutterの担当人数と、自分の位置

• Flutterの担当は何人か。自分が唯一の担当になるか
• 設計や状態管理の方針を決めるのは誰か
• コードのレビューをする人はいるか
• デザイナーやAPI担当はいるか、社内か外部か

担当が一人の現場では、設計の判断からリリース、問い合わせの調査まで集まりやすくなります。決める範囲が広いことを前提に、稼働の見込みと報酬を考える必要があります。報酬の考え方はFlutterの報酬の記事をご覧ください。

3. ネイティブ連携の範囲

決済、地図、カメラ、プッシュ通知、ログインなど、OSの機能とつなぐ部分をどこまで担うかを確かめます。パッケージで足りるのか、SwiftやKotlinでネイティブのコードを書く必要があるのか、ネイティブ担当がいるのかで、必要な経験が変わります。自分の経験が届かない部分があるなら、契約前に伝えておくと、参画後の行き違いを防げます。

4. ストア申請と、アカウントの権限

App StoreとGoogle Playへの申請を誰が行うか、自分にどの権限が付くかを確かめます。App Store Connectでは、アカウントの所有者のほか、管理者、アプリの管理、開発といった役割ごとに行える操作が分かれています。Google PlayのPlay Consoleでも、所有者や管理者がユーザーを招待し、アカウント全体か特定のアプリに限って権限を付ける仕組みです（いずれも2026年10月時点、各公式ヘルプによる）。

• 申請や審査の対応まで業務に含まれるか
• 自分に付く権限の範囲と、権限がない作業を誰に頼むか
• 証明書や署名の鍵を誰が管理するか
• 開発者アカウントは発注元の名義か

開発者アカウントや署名の鍵を個人の名義で用意するよう頼まれた場合は、契約終了後の引き継ぎで問題になりやすいため、慎重に判断しましょう。

5. コードの状態と、版上げの状況

運用中のアプリでは、コードの状態で作業の重さが大きく変わります。

• Flutter本体とパッケージを最後に上げた時期
• メンテナンスが止まったパッケージを使っていないか
• テストがどの程度あるか
• 前任者がいた場合、引き継ぎの資料や期間があるか

長く版を上げていないアプリでは、機能追加の前に版上げが必要になり、見積もりや稼働の見込みが崩れることがあります。版上げが業務に含まれるか、優先順位をどう付けるかを確かめておきましょう。

6. 開発環境、端末、リモートの条件

iOSのビルドにはMacが要るため、端末を貸与されるのか自分で用意するのかを確かめます。両OSの検証用の端末、テスト配布の仕組み、社内のネットワークへの接続の要否も合わせて確認しましょう。自分のMacを使う場合は、案件ごとの情報の分け方や、契約終了時のデータの消し方の取り決めも大切です。リモートの条件はFlutterのリモート案件の記事で解説しています。

7. 契約の形、成果物、権利の扱い

多くのFlutter案件は準委任契約で参画しますが、受託開発会社の案件などでは、アプリの完成を約束する請負に近い形のこともあります。

• 準委任か請負か。完成やリリースの期日を約束する書き方になっていないか
• 成果物が求められる場合、その範囲（ソースコード、設計書、テストの結果など）
• 作ったコードの著作権の扱いと、自分が以前から使っている部品の扱い
• 使うパッケージのライセンスを誰が確認するか

契約の形の違いは準委任契約と請負契約の違い、権利の扱いは業務委託の著作権の記事、パッケージのライセンスはOSSライセンスの記事で解説しています。

確かめた内容を書面と照らし合わせる

面談や事前の確認で聞いた内容は、契約の前に書面と照らし合わせます。フリーランス法では、発注する事業者は業務を委託したら直ちに、業務の内容、報酬の額、支払期日などの取引条件を、書面またはメールなどの電磁的方法で明示することとされています（2026年10月時点、公正取引委員会の案内による）。明示される事項の内容はフリーランス法で明示される取引条件をご覧ください。

Flutterの案件では、特に次の点が書面に反映されているかを確かめます。

1. 業務の内容に、担う範囲（画面の実装、設計、ネイティブ連携、版上げ、ストア申請など）が書かれているか
2. 完成やリリースの期日を約束する書き方になっていないか（準委任の場合）
3. 稼働の幅と、超えたときの精算方法
4. 貸与される端末やアカウント、契約終了時の返却や消去の扱い
5. 契約期間と更新の時期

面談で聞いておくとよい質問はFlutterの面談でよく聞かれる質問と答え方の逆質問の項目でも紹介しています。一般的な逆質問の考え方は面談で聞いておくべき逆質問をご覧ください。

よくある質問

Flutterの担当が自分一人の案件は避けたほうがよいですか？

避ける必要はありません。設計からリリースまでを一人で担った経験は、次の案件で評価されやすい経験です。ただし、レビューする人がいない分、判断の責任が重くなるため、担う範囲、相談できる相手、稼働の見込みを参画前に確かめてから受けることをおすすめします。

面談でコードの状態や版上げの状況を聞いても失礼になりませんか？

作業の見通しを立てるための確認として聞けば、失礼にはあたりません。「最初に取り組むべきことを把握したい」という目的を添えると、相手も答えやすくなります。答えられない場合は無理に聞き出さず、ほかの確認点で判断しましょう。

個人の開発者アカウントでアプリを公開してほしいと頼まれました。どうすればよいですか？

アプリの持ち主が誰になるか、契約が終わったときにアプリをどう移すかで問題になりやすい依頼です。発注元の名義でアカウントを用意してもらえないかを確かめ、個人の名義で行う場合は、移管の手順や費用の負担を契約で取り決めておくことをおすすめします。判断に迷う場合は専門家にご相談ください。