Dartのシステム発注は、業務要件を整理し、発注形態と契約を選び、保守まで比べる順に進めます。この順で進めると、変更と予算のリスクを抑えられます。
発注形態、RFP、契約、費用、委託先の順に、発注側が決めておきたい点を並べます。
▼全体ガイドの記事
・Dartのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
Dartのシステムを発注する前に押さえる全体像
Dartのシステムは、Dart言語で動くサーバーだけを指すとは限りません。Flutterを使えば、スマートフォン、Web管理画面、WindowsやmacOS向けアプリを作れます。また、FirebaseやJava・C#・Goなどの既存APIと組み合わせる構成もあります。
発注時は、利用者と端末、扱うデータを先に決め、そのうえで業務ルールを整理します。「Dartで作るか」を決めた段階では、必要な構成はまだ判断できません。
DartとFlutter、バックエンドの役割分担
DartとFlutter、バックエンドは担う処理が異なるため、役割を分けて整理します。
- DartとFlutter：Dartはプログラミング言語で、FlutterはDartで画面やアプリを作るフレームワークです。
- 画面の共通化：現場担当者がスマートフォンで写真と位置情報を登録し、管理者がブラウザで承認する業務なら、モバイル画面とWeb画面を共通の設計で作れます。
- バックエンド：会計仕訳や在庫引当のように厳密なトランザクションが必要な処理は、既存基幹のAPIを使うほうが安全な場合があります。
- Dartサーバー：Serverpod、Dart Frog、shelf、Firebase Functionsで統一する案も、既存資産や運用体制と比べます。
業務システムにおける共通化の範囲
FlutterはiOSとAndroidに加え、WebやデスクトップへAppが展開しやすい点が強みです。一方で、専用スキャナやBluetooth機器、決済には、OSごとの実装やプラグイン検証が必要です。印刷、MDM、カメラ制御でも、OSごとの対応が求められます。
共通UIの割合が高くても、APIや認証、データ移行には別の工数がかかります。実機テストやストア審査、運用設計も、工数を分けて見る必要があります。そのため、「100％同じコード」の範囲が、画面、業務ロジック、テストのどこまでかを確認します。
PoC、段階発注、一括開発の発注形態
発注形態は予算だけでなく、要件がどれだけ確かか、社内に業務知識を持つ人がいるか、リリース後の保守を誰が担うかで決まります。
使い方が固まっていなければ小さく検証し、業務ルールが明確で納期も決まっていれば範囲を定めて委託します。ただし、最初から全機能を一括で発注するのが、いつも効率的とは限りません。
PoC・MVP発注による技術と現場の不確実性への対応
現場の端末や通信環境が関わる機能は、PoCで検証対象と範囲を分けて確かめます。
- 検証対象：カメラ撮影、オフライン一時保存、バーコード読み取り、既存API連携。
- 検証範囲：ログイン、主要な登録画面、検索、1本のAPI連携、現場端末での操作確認。
範囲を絞っておくと、技術的な可否と現場での使い勝手を分けて確かめられます。
公開相場には、画面10以下の小規模開発で100万〜300万円、1〜3か月という目安があります。ただし、これは一般的なFlutterアプリの情報で、Dartのシステム全体の価格ではありません（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。見積では、検証後に本開発へ進まない場合に何が手元に残るかと、再利用できるソースコードの範囲を確認します。
業務単位で区切る段階発注
PoCで実現性を確認したら、「点検報告だけ」「在庫入出庫だけ」のように業務単位で発注します。第1段階では、利用者や拠点、入力項目を絞り込み、承認者と帳票も限定します。そのうえで、入力時間、差戻し率、紙の削減枚数などを測ります。
現場で使われない原因は、画面の見た目よりも運用面にあります。たとえば、電波の弱い場所で保存できない、入力項目が多すぎる、既存の業務ルールと合わない、といった点です。
段階ごとに受入条件を定めておけば、次の発注を続けるか、仕様を見直すかを決められます。
一括発注の前に固める要件と担当範囲
販売管理や在庫、会計などの業務を一度に刷新する場合は、一括開発が適することもあります。ただし、要件が曖昧なまま機能一覧だけを渡すと、開発中の変更が増えます。
工程は、要件定義、基本設計、詳細設計、開発に分けます。そのうえで、テスト、データ移行、教育、リリース後の保守も工程に加え、工程ごとの完了条件を契約書と見積書に記載します。
まず、意思決定者や現場代表、情報システム担当、委託先のプロジェクト責任者を決めます。次に、変更要求を承認するルートを定めます。
現場業務を起点にしたRFPと要件整理
RFP（提案依頼書）は、目的や対象業務、利用者、制約を各社に同じ条件で伝える文書です。希望時期、予算の考え方、提案範囲も書き添えます。
比較しやすい提案を得るため、技術名は先に固定せず、必要な端末と業務結果を示します。そのうえで、Flutter、既存API、Firebase、Dartサーバーの組み合わせを、各社に提案してもらいます。
現状業務と理想業務の図解
現状の業務フローは、紙やExcel、メール、電話、FAXを含めて描きます。そのうえで、誰がいつ何を入力し、誰が確認し、どのデータを次工程へ渡すかを整理します。
通常処理に加え、返品や差戻し、欠品などの例外も記載します。さらに、通信断や担当者の交代、月末締めも書き出します。
理想の画面から描くと例外が抜け落ち、作り直しになります。そのため、業務の流れと判断ルールを先に固めます。
RFPに入れる機能・非機能・データ・運用の条件
機能要件は、見積の漏れを防ぐため、業務機能とシステム条件に分けて記載します。
- 機能：ログイン、組織・拠点・ロール、顧客・商品のマスタ、登録・検索・CSV入出力、申請・承認・通知、写真・位置情報・バーコード、集計・帳票、外部API連携。
- 非機能：利用者数、同時アクセス数、対応OS、通信断時の動作、表示速度、バックアップ、監査ログ、障害通知、個人情報の保存期間、権限分離。
- データと運用：既存データの件数・形式、移行対象、移行リハーサルの回数、教育対象者、運用開始後の問い合わせ窓口。
各社が同じ範囲で見積もれるよう、要件ごとの前提と対象範囲を明示します。
数値と業務シナリオで定める受入条件
「使いやすい」や「十分に速い」といった言葉は、完成後に人によって判断が分かれます。そこで、通信のない場所で点検を保存し、復旧後に二重登録なく同期できることなどを、受入シナリオとして定めます。
管理者の承認後に通知されることや、権限のない拠点のデータを閲覧できないことも、条件に含めます。業務の開始から完了までを通してテストし、Flutter画面、バックエンド、通知、監査ログの連携を検証します。
受入テストの実施者、証跡の形式、未達時の再テスト条件も、RFPに含めます。
要件の確度と変更の多さで使い分ける契約形態
候補には請負、準委任、企画や要件定義だけを先に委託する分割契約があります。
契約では、成果物と完成責任、作業時間、仕様変更の扱いを確認します。さらに、知的財産権、再委託、検収、瑕疵や不具合への対応、保守への移行条件も確かめます。
契約の中身は、社内法務や顧問弁護士にも確認したうえで、実態に合うものを選びます。
請負契約の完成範囲と検収
請負契約は、定めた成果物を完成させ、発注者が検収する形に向きます。成果物には、画面一覧、API仕様、DB定義、テスト結果を含めます。さらに、移行手順、マニュアル、ソースコード、ビルド・CI/CD設定も列挙します。
また、検収期限と不具合修正の条件も定めます。要件が固まらないまま全工程を請負にすると、変更のたびに追加見積や納期延長が生じます。
要件定義やPoCは準委任で行い、仕様が固まった開発部分だけを請負に切り替える進め方もあります。
伴走型開発と変更対応の準委任契約
準委任では、契約の進め方と費用管理の条件を確認します。
- 契約の進め方：委託先が一定の業務を遂行し、発注者と優先順位を調整する形です。
- 向く場面：現場の意見で画面や業務フローを短期間で改善する場合、アジャイル開発とも組み合わせやすい契約です。
- 費用の注意：作業時間や体制に対して支払うため、完成機能や予算上限が自動的に保証されるわけではありません。
- 定例会：月次の成果、消化工数、残課題、次月の計画、追加作業の承認方法を、毎月の場で確かめます。
- 発注者側の体制：意思決定できる担当者を、自社側に置いておきます。
契約に入れるソースコードと運用資産の帰属
納品後の運用や委託先の変更に備えて、管理者と引き継ぎ条件を契約で決めておきます。
- 引き継ぎ：ソースコードのほか、ビルド環境や秘密情報の管理方法も必要になります。
- 開発資産：リポジトリ、CI/CD設定、証明書、パッケージ一覧、ライセンス、API仕様、データベース定義。
- 運用資産：クラウドアカウントの名義、監視設定、障害対応の手順と管理者を取り決めます。
- 外部サービス：OSSや有料SDKのライセンス費、第三者サービスのアカウントを発注者名義にするかどうか。
- 引き継ぎ条件：期間と有償・無償の範囲を決めておくと、担当会社の変更や内製化に備えられます。
Dartのシステム開発にかかる費用相場と内訳
Dart専用の業務システムの統計は多くないため、Flutterアプリの公開相場と、要件定義、基幹連携、移行、保守の費用を分けて考えます。
たとえば、単純な社内入力アプリやPoCは100万〜300万円、中規模の業務アプリは300万〜800万円が目安です。複数拠点や外部連携、管理画面を含む案件は、800万〜1,500万円程度です。
一方で、基幹をまたぐスクラッチ開発は1,000万円を超え、数千万円から数億円規模まで広がる可能性があります。これらはいずれも機能と体制による推定で、Dartを選んだことで決まる金額ではありません。
規模別の費用レンジと含まれる工程
株式会社LASSICの公開情報では、Flutterアプリの目安として、規模別の費用と期間が整理されています（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。
- 小規模：100万〜300万円、1〜3か月。
- 中規模：300万〜800万円、3〜6か月。
- 大規模：800万〜1,500万円、6か月〜1年。
この区分は、画面数やAPI、通知などを含む一般的なアプリの相場です。
業務システムでは、現場ヒアリングや複雑な権限、既存データのクレンジングが工数に加わります。さらに、移行リハーサル、教育、帳票、監査ログも含まれるため、同じ画面数でも高くなることがあります。
見積では、要件定義、設計、実装、単体・結合・総合テストが別項目になっているかを確認します。移行や教育、リリース支援も、別の項目かどうかを見ます。
人月単価と体制による見積の検算
見積の人件費は、人月単価と配置人数、期間を照らして検算します。
- 単価の目安：月額70万〜90万円帯が多く、上位人材では100万〜145万円の例もあります。
- 配置試算：2名を4か月配置すると、83万円×2名×4か月で約664万円です。
- 総額の確認：人件費にPM、UI設計、QA、インフラ、管理費、リスク対応を加えて比較します。
この単価帯は公開情報の目安です（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。
なお、エン・ジャパンの2025年2月の月額平均単価レポートでは、Flutter案件の平均は83.0万円でした。この配置試算は、人件費だけの単純計算です。
初期見積と分けて考える保守費用とクラウド費用
OSやSDKの更新、クラウド利用で続く費用は、初期開発費と分けて整理します。
- 保守作業：OS・Flutter SDK更新、脆弱性や不具合の対応、監視、バックアップ、問い合わせ、ストア審査、機能追加。
- 年間保守費：初期開発費の15％程度、機能追加や運用委託込みでは20％程度が目安です。
- 費用例：初期費用300万円なら年45万〜60万円、1,000万円なら年150万〜200万円です。
- 運用費：Firebaseなどの従量課金、クラウド、監視ツール、端末、Apple・Googleの開発者登録費、証明書更新費。
この保守費の割合は公開相場に基づきます（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。ただし、保守費の実額はサポート時間やSLAで変わります。そのため、初期費用と運用費を合わせ、3年から5年のTCO（総所有コスト）で比べます。
委託先の選定と見積比較で見るべきポイント
委託先の力量は、Dartの経験年数やFlutterの制作件数に加えて、業務要件を聞き取る担当者と実装責任者が同じ方向を向いているかで判断します。さらに、既存システム連携、実機・自動テスト、公開後のSDK更新への対応も確認します。
同じRFPを渡したうえで、総額だけでなく、前提条件、対象外作業、体制、工程、成果物、追加費用の条件を横並びにします。
業務理解とDart・Flutterの実績の切り分け
「Flutterアプリを何件作ったか」より、販売管理、在庫、点検、施工、営業報告など自社に近い業務の実績を確認します。画面制作の実績が豊富でも、会計や在庫の整合性、複数拠点の権限、データ移行は経験していない場合があります。
既存基幹とのAPI連携に強い会社が、Flutter部分をパートナーと分担する案もあります。その場合は、担当者の経歴や過去案件での役割、再委託、発注者との窓口を質問します。
工程・前提条件・追加費用を並べた見積比較
見積の項目と対象範囲を揃えると、金額差の理由を把握できます。
- 工程費：要件定義、UI・UX、Flutter、Web管理画面、API・DBの開発、外部連携、テスト・移行・教育、リリースと保守。
- 前提条件：画面数やAPI数、対象OS、実機台数、オフライン対応、通知と帳票の範囲。
- 追加費用：テストや移行の有無、監査ログ、負荷試験、教育、運用設計、SDK更新の扱い。
最安案にテストや移行が含まれていないと、あとから追加費用が生じます。一方で、高い案でも運用設計まで含んでいれば、TCOで見て妥当な場合があります。そこで、差額を説明できる会社を選びます。
提案評価に含めるセキュリティと引き継ぎ
提案評価では、セキュリティ対策と個人情報の取り扱い、運用引き継ぎに必要な条件を確認します。
- アクセスと端末：組織・拠点・ロールごとの認可、通信暗号化、紛失端末のセッション失効。
- 監査と復旧：管理者操作の監査ログ、バックアップ、復元テスト。
- Firebaseの保護：Firestore Security Rules、App Check、サーバー側のIAMやAPI認可を、それぞれ分けて設計します。
- 個人情報：利用目的や保存期間、委託先、国外移転、削除手順を、RFPに記載します。
個人情報の取り扱いは、「個人情報の保護に関する法律についてのガイドライン（通則編）」を基にします。社内で整理してRFPに記載します（出典：個人情報保護委員会、2026年確認）。
サーバーSDKのアクセスは、クライアント側のルールだけでは守れません。そのため、委託先の説明を確認し、管理方針と引き継ぎ条件も提案に含めてもらいます。
2026年時点のDartの動向と発注判断
最新バージョンは確認しますが、新機能の採用そのものを目的にはしません。Dart公式ブログは、Dart 3.12（2026年5月）の機能を紹介しています。
紹介されたのは、プライベートな名前付きパラメータ、実験段階のプライマリコンストラクタ、Genkit Dartのプレビューです。さらに、同ブログはFirebase Cloud FunctionsのDart対応に関する実験的サポートも紹介しています。
また、AIエージェントと連携するAgentic Hot Reloadも挙げています（出典：Dart公式ブログ「Announcing Dart 3.12」、2026年5月）。実験的な機能は将来性がある一方で、本番では安定版の範囲、サポート期間、代替手段、アップデート費用を確認し、採否を決めます。
契約前に確認するSDKとプラグインの更新方針
SDKの機能やリリース内容を押さえ、更新後の対応条件を契約前に確認します。
- Dart 3.8：Webのホットリロードやクロスコンパイルが示されました。
- ネイティブ連携：早期アクセスも示されました（出典：Dart公式ブログ「Announcing Dart 3.8」、2025年5月）。
- Flutter 3.32.0：Web、Android、iOS、Windows、Linux、テストやツールが更新されています。
- 更新時の対応：OSやSDKの更新時に、何を試験し、誰が修正し、どの費用で対応するかを決めておきます。
- プラグイン：最終更新日、対応OS、ライセンス、代替プラグイン、ネイティブコードの有無を、一覧にして整理します。
新技術の採用より継続運用できる体制
提案の時点では、Dartの新機能と合わせて、運用や引き継ぎの体制も確認します。
- 技術動向：2026年はAI連携やフルスタック開発の選択肢が広がっています。
- 評価軸：業務システムでは、技術の新しさよりも、継続運用できる体制を重く見ます。
- 運用機能：障害を追えるログ、権限を変更できる管理画面、復元できるバックアップ。
- 引き継ぎ：担当者が退職しても引き継げる文書と、SDK更新を計画に含める保守契約です。
- 採用判断：「本番利用」「検証利用」「採用しない」のいずれかに分け、理由と将来の見直し条件を示してもらいます。
運用や引き継ぎの体制を提案の段階で確かめておけば、流行の技術を採用した後に運用で困るリスクを抑えられます。
よくある質問（FAQ）
費用、技術の選び方、委託後の運用について答えます。利用者数や既存システム、端末、データの機密性に当てはめて検討します。
Dartのシステム開発は最低いくらから発注できますか？
単純な社内入力アプリや技術検証では、Flutterの公開相場として100万〜300万円、1〜3か月程度が参考になります。ただし、これは一般的な小規模アプリの目安で、Dartシステムの一律価格ではありません。
費用は、要件定義やAPI、認証、実機テスト、データ移行、保守の有無で変わります。そのため、検証内容と成果物、本開発で再利用できる範囲を確認します。
Dartだけでバックエンドまで作るべきですか？
バックエンドをDartに統一するかどうかは、案件ごとに判断します。小規模な新規サービスで、データモデルや検証を共有するなら、DartサーバーやFirebase Functionsが候補になります。
会計や在庫などの既存APIが安定しているなら、Flutterから利用するほうが移行リスクを抑えられます。統一案と既存活用案、段階的な置換案を比べ、運用担当者が保守できる構成を選びます。
Flutterで作ればiOSとAndroidの費用は必ず安くなりますか？
Flutterで共通化した場合の削減幅は、OS固有の機能や運用の範囲を含めて判断します。
- 削減幅：共通開発は、ネイティブの個別開発より30〜40％減の例もあります（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。
- OS固有機能：カメラ、センサー、専用スキャナ、印刷が多いほど、効果は小さくなります。
- 比較範囲：初期費用に加え、実機検証、プラグインとOSの更新、保守体制も含めて判断します。
外注先にはどのような資料を渡せばよいですか？
外注先には、現状業務と課題、利用者・拠点、業務フローをRFPにまとめて渡します。機能、端末、既存システムとAPIも、この資料に含めます。データの件数や形式、セキュリティも記載します。希望時期、予算の考え方、受入条件も、あわせて書き添えます。
画面案に加えて、例外処理と業務ルールも記載します。同じ資料を各社に渡し、対象外作業、前提、体制、再委託、保守、ソースコードの権利を確認すると、公平に比べられます。
まとめ
Dartのシステム発注では、技術を選ぶ前に、業務、端末、既存基幹との役割分担、移行、セキュリティ、保守を計画します。
要件が固まっていなければ、PoCや段階発注から始め、請負と準委任を工程ごとに使い分けます。これにより、変更と予算を管理しやすくなります。
発注前に決める項目
発注前に決める内容は、形態、技術の境界、要件、契約、TCO、委託先の体制に分けられます。
- 発注形態：PoC・段階発注・一括開発から選ぶ。
- 技術と要件：Flutterと既存API・Dartサーバーの境界、機能・非機能・移行・受入条件を定める。
- 契約と費用：請負と準委任で担当範囲を分け、初期費用・保守・クラウドを含むTCOを比べる。
- 委託先：実績、テスト、SDK更新、引き継ぎ体制を確認する。
価格の安さに加えて、同じ条件で比べられ、将来の運用まで説明できる委託先を選ぶことが、システムの定着につながります。
最初の相談で伝える業務課題と検証したいこと
初回相談では、技術名に加えて、現場の課題、対象端末、既存システム、データ、検証したい機能、希望時期を共有します。
委託先が質問を返し、リスクや代替案を説明し、工程別の費用を示せるかを見ると、発注後の進め方が想像できます。共通化の利点を活かし、自社業務に必要な部分へ投資します。
▼全体ガイドの記事
・Dartのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。