Flutterエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

フリーランスのFlutterエンジニアの仕事は、Dartで画面と機能を作り、iOSとAndroidの両方で動くことを確かめ、ストアに出し続けることが軸です。ただ、新しいアプリを立ち上げるのか、公開済みのアプリを育てるのか、ネイティブのアプリを置き換えるのかで、1日の時間の使い方も、話す相手も、手元に残る成果物も大きく変わります。

この記事では、Flutterの案件を4つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。求められるスキルはFlutterの案件で求められるスキル、独立の進め方はFlutterエンジニアがフリーランスになるにはで扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「アプリの段階」と「チームの人数」で決まる

Flutterは一つのコードから両方のOSのアプリを作れるため、少人数のチームで選ばれることが多い技術です。そのため、同じ「Flutterエンジニア」の募集でも、次の2つで仕事の中身が変わります。

• アプリの段階：これから作るのか、公開済みで利用者がいるのか、ネイティブから移す途中なのか
• チームの人数：Flutterの担当が自分一人なのか、複数人で画面を分けて作るのか

この2つを掛け合わせると、フリーランスのFlutter案件はおおむね次の4種類に分けられます。

以下の1日と1か月の流れは典型的な例です。会議の数やリリースの間隔はチームによって違うため、目安として読んでください。

新規アプリの立ち上げ案件

1日の流れ（例）

朝はチャットで、デザイナーやAPI担当からの更新を確かめます。午前はプロダクトの責任者との短い打ち合わせで、その日に作る画面の優先順位と仕様の不明点をそろえます。午後は実装の時間が中心です。画面を作りながら、APIの形が決まっていない部分はAPI担当と相談し、仮のデータで先に進めます。夕方は、iOSとAndroidの実機やシミュレーターで動きを確かめ、気になった差をメモに残します。

立ち上げでは、まだ決まっていないことを決めながら作る時間が長くなります。状態管理の方法、フォルダの分け方、使うパッケージなど、後から変えにくい判断を自分が担うことも少なくありません。

1か月の流れ（例）

• 最初の週：画面の一覧とデザインを見て、層の分け方と状態管理の方法を決め、ひな形を作る
• 毎週：決めた画面を作り、社内向けのテスト配布で関係者に触ってもらい、意見を反映する
• 月の後半：ログインや決済、プッシュ通知など、ネイティブ側の設定が要る機能に取りかかる
• 公開の前後：両ストアの申請に必要な情報をそろえ、審査の指摘に対応する

成果物

アプリのソースコード、設計の方針をまとめた文書、画面の部品の一覧、テスト配布の手順、ストア申請に使う情報の整理などです。立ち上げの案件では、次に入る人が読める設計のメモも成果物として求められやすくなります。

運用中アプリの改善案件

1日の流れ（例）

朝は、前日の不具合の報告やクラッシュの記録、問い合わせの内容を確かめます。午前は、担当している機能の追加や修正を進めます。既存のコードの書き方に合わせることが前提になるため、似た画面のコードを読む時間も含まれます。午後は、プルリクエストのレビューを受けたり、他の人のレビューをしたりします。QAの担当者から確認結果が届けば、その対応も入ります。

1か月の流れ（例）

• 月初：その月に出すリリースの範囲を、プロダクトの責任者と確かめる
• 毎週：機能の追加と不具合の修正を進め、テスト配布で確認する
• 随時：OSの新しい版やストアの要件の変更、Flutter本体やパッケージの更新に合わせて、版上げの作業を計画する
• リリースの週：両ストアに提出し、公開後のクラッシュや問い合わせの増え方を見る

運用中のアプリでは、利用者がいる状態で壊さずに変えることが中心です。新しい機能より、既存の動きを守るための確認に時間を使う日もあります。

成果物

機能追加や修正のソースコード、テストコード、リリースノート、版上げの影響の調査メモ、不具合の原因と対策の記録などです。新規開発と保守の働き方の違いは新規開発と保守運用の案件の違いでも解説しています。

ネイティブからの置き換え・部分導入の案件

SwiftやKotlinで作られたアプリをFlutterに移す案件や、既存のアプリの一部の画面だけをFlutterで作る案件です。Flutterの公式ドキュメントでは、既存のアプリにFlutterを組み込む方法（add-to-app）が案内されており、iOSとAndroidではFlutterの部分をモジュールとして取り込む形になります（2026年10月時点）。

1日・1か月の流れ（例）

置き換えの案件では、ネイティブ担当との話し合いが1日の中で大きな比重を占めます。どの画面からFlutterに移すか、ログイン状態や設定値をネイティブとFlutterの間でどう受け渡すか、ビルドの設定をどう変えるかを、ネイティブ担当と決めながら進めます。

1か月の単位では、移す画面を決めて実装し、ネイティブの画面と混ざった状態でリリースし、問題がないかを見てから次の画面に進む、という小さな区切りを繰り返すことが多くなります。

成果物

移行の計画と順番、ネイティブとFlutterの間の受け渡しの取り決め、ビルド設定の変更の記録、移した画面のソースコードなどです。ネイティブのコードを読めるかどうかで、任される範囲が変わります。ネイティブ側の働き方はiOSエンジニアの仕事内容とAndroidエンジニアの仕事内容も参考になります。

受託開発会社でのアプリ開発

受託開発会社のチームに入り、発注元のアプリを作る案件です。複数のアプリを並行して作る会社もあり、案件ごとに仕様書の形やデザインの渡し方が違います。

1日・1か月の流れ（例）

1日の多くは、仕様書とデザインに沿った実装です。受託先のPMやディレクターとの打ち合わせで仕様の不明点を確かめ、発注元に確認が必要なことはPM経由で上げます。1か月の単位では、決められた納期に向けて実装を進め、受託先の社内での確認、発注元の受け入れ確認、修正の順に進みます。工数の見積もりに協力を求められることもあります。

成果物

仕様どおりに動くアプリ、テストの結果、発注元に渡すための手順書などです。どこまで直せば完了とみなすかは発注元との約束で決まるため、仕様の変更が入ったときの扱いを、受託先のPMと早めにそろえておくと進めやすくなります。

どの案件にも共通する仕事

種類が違っても、Flutterの案件には次の仕事がほぼ共通してあります。

1. 両OSでの確認：同じコードでも、画面の見え方や権限の聞き方、通知の届き方がOSごとに違う。両方で確かめて差を報告する
2. テスト配布とリリース：社内向けのテスト配布、ストアへの提出、審査の指摘への対応
3. 版上げ：Flutter本体、パッケージ、Xcode、Androidの設定の更新に追従する
4. 記録：設計の判断、OSごとの差、ネイティブ側の変更の理由を残す

フリーランスならではの仕事として、稼働の記録と報告もあります。審査の待ちや版上げの調査など、見えにくい作業に使った時間も日々つけておくと、精算のときに説明しやすくなります。

関わる相手と、その相手に出すもの

Flutterエンジニアの1日は、誰と何をやり取りするかで組み立てられています。

デザイナーやAPI担当がいない小さなチームでは、画面の細部の判断やAPIの仕様の相談相手がプロダクトの責任者一人になり、決める範囲がさらに広がります。働く場所の傾向はFlutterのリモート案件の記事をご覧ください。

よくある質問

Flutterの案件では、SwiftやKotlinのコードを書くこともありますか？

ネイティブの機能とつなぐ部分や、ビルドの設定で書くことがあります。置き換えや部分導入の案件では特に多くなります。どこまで書く想定かは、参画前に確かめておくと稼働の見込みとのずれを防げます。

ストアへの申請はフリーランスが担当しますか？

案件によって違います。申請まで任される案件もあれば、アカウントを持つ社員が提出し、フリーランスは必要な情報とビルドを用意するだけの案件もあります。業務範囲に含まれるかを契約前に確かめましょう。確かめ方はFlutter案件の選び方で整理しています。

参画して最初の1か月は何をすることが多いですか？

開発環境の準備、両OSでのビルドの確認、既存のコードと設計の読み込み、リリースの流れの把握から始めるのが一般的です。初月の進め方はFlutterエンジニアの参画初月にやることで詳しく解説します。