Dartのシステム開発の発注/外注/依頼/委託方法について

Dartのシステムを発注・外注するなら、Flutterで画面を共通化することだけでなく、既存基幹との連携、現場端末、データ移行、保守まで含めて方式と委託先を決めることが重要です。

「Dartなら安く作れそう」「一つのコードで全部の端末に対応できそう」と考えて相談を始める企業は少なくありません。しかし、発注前の要件整理が不足すると、オフライン入力やバーコード、帳票、権限管理などが後から追加され、納期と費用が膨らみます。この記事では、Dartのシステム開発を外注する際の発注形態の選び方、RFPの作り方、契約形態、費用相場、委託先の見極め方、見積書の比較ポイントを順番に解説します。

▼全体ガイドの記事
・Dartのシステム開発の完全ガイド

Dartのシステムを発注する前に押さえる全体像

Dartのシステムという言葉は、Dart言語で動くサーバーだけを指すとは限りません。実務では、Dartを使うFlutterでスマートフォンアプリ、Web管理画面、WindowsやmacOS向けのアプリを作り、Firebaseや既存のJava・C#・GoなどのAPIと組み合わせる構成も含まれます。発注時は「Dartで作るか」だけでなく、「どの利用者が、どの端末で、どのデータを、どの業務ルールに従って扱うか」を先に決める必要があります。

Dartはプログラミング言語で、FlutterはDartを使って画面やアプリを作るフレームワークです。たとえば、現場担当者がスマートフォンで写真と位置情報を登録し、管理者がブラウザで承認する業務では、Flutterのモバイル画面とWeb画面を共通の設計思想で作れます。一方、会計仕訳や在庫引当のように厳密なトランザクションが必要な処理は、既存基幹のAPIを活用する方が安全な場合があります。DartのServerpod、Dart Frog、shelf、Firebase Functionsなどでサーバー側まで統一する方法もありますが、既存資産、運用担当者、障害対応の体制を比較して選ぶことが大切です。

FlutterはiOSとAndroid、さらにWebやデスクトップへ展開しやすい点が強みです。ただし、専用スキャナ、Bluetooth機器、決済、印刷、MDM、端末のカメラ制御などは、OSごとの実装やプラグインの検証が必要になります。共通UIの割合が高くても、API、認証、データ移行、実機テスト、ストア審査、運用設計は別に工数が発生します。発注先から「100％同じコードで対応できます」と説明されたときは、共通化の意味が画面だけなのか、業務ロジックやテストまで含むのかを確認します。

発注形態はPoC、段階発注、一括開発から選びます

発注形態は、予算だけでなく、要件の確かさ、社内に業務知識を持つ人がいるか、リリース後の保守を誰が担うかで決まります。まだ現場の使い方が固まっていない場合は小さく検証し、業務ルールが明確で納期も決まっている場合は範囲を定義して開発を委託します。最初から全機能を一括発注することが、常に効率的とは限りません。

カメラ撮影、オフライン一時保存、バーコード読み取り、既存API連携など、実現できるか不安な要素がある場合は、PoC（概念実証）を先に発注します。PoCでは、ログイン、主要な登録画面、検索、1本のAPI連携、現場端末での操作確認に絞り、技術的な可否と使い勝手を検証します。業務アプリの公開相場では、画面10以下の小規模開発が100万〜300万円、1〜3か月という目安が掲載されていますが、これは一般的なFlutterアプリの公開情報であり、Dartのシステム全体にそのまま当てはまる金額ではありません（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。PoCの見積では、検証後に本開発へ進まない場合の成果物と、再利用できるソースコードの範囲も確認します。

PoCで実現性が確認できたら、次は「点検報告だけ」「在庫入出庫だけ」のように業務単位で段階発注します。第1段階では、利用者、対象拠点、入力項目、承認者、出力帳票を限定し、入力時間、差戻し率、紙の削減枚数などのKPIを計測します。現場で使われない原因は、画面の見た目よりも、電波が弱い場所で保存できない、入力項目が多すぎる、既存の業務ルールと合わないといった運用面にあります。段階ごとに受入条件を決めると、次の発注を続けるか、仕様を見直すかを冷静に判断できます。

販売管理、在庫、顧客、会計、複数拠点の権限を一度に刷新する場合は、一括開発が適することもあります。ただし、発注時点で要件が曖昧なまま機能一覧だけを渡すと、開発中の変更が増えます。一括発注を選ぶなら、要件定義、基本設計、詳細設計、開発、テスト、データ移行、教育、リリース後の保守を工程として分け、各工程の完了条件を契約書と見積書に記載します。社内の意思決定者、現場代表、情報システム担当、委託先のプロジェクト責任者を明確にし、変更要求を承認するルートも先に決めておきます。

RFPと要件整理は現場の業務を起点に作ります

RFP（提案依頼書）は、開発会社に「良いシステムを作ってください」と依頼する文書ではありません。目的、対象業務、利用者、制約、希望時期、予算の考え方、提案してほしい範囲を同じ条件で伝え、各社から比較可能な提案を得るための文書です。Dartのシステムでは、技術名を先に固定するより、必要な端末と業務結果を示したうえで、Flutter、既存API、Firebase、Dartサーバーの組み合わせを提案してもらう方が適切な構成になりやすいです。

最初に、紙、Excel、メール、電話、FAXなどを含めた現状の業務フローを描きます。誰が、いつ、何を入力し、誰が確認し、どのデータを次の工程へ渡しているかを整理します。特に、通常処理だけでなく、返品、差戻し、欠品、通信断、担当者の交代、月末締めなどの例外を記載することが重要です。理想の画面を先に描くと、現場の例外が抜けて作り直しになりやすいため、まず業務の流れと判断ルールを固めます。

機能要件には、ログイン、組織・拠点・ロール管理、顧客や商品などのマスタ、登録・検索・CSV入出力、申請・承認・通知、写真・位置情報・バーコード、集計・帳票、外部API連携を記載します。非機能要件には、利用者数、同時アクセス数、対応OS、通信断時の動作、表示速度、バックアップ、監査ログ、障害通知、個人情報の保存期間、権限分離を含めます。さらに、既存データの件数と形式、移行対象、移行リハーサルの回数、教育対象者、運用開始後の問い合わせ窓口まで書くと、見積の抜けを比較しやすくなります。

「使いやすい」「十分に速い」といった表現だけでは、完成後に判断が分かれます。たとえば、現場担当者が電波のない場所で点検を保存し、通信復旧後に二重登録なく同期できること、管理者が申請を承認すると担当者へ通知されること、権限のない拠点のデータを閲覧できないことを受入シナリオにします。画面単位ではなく、業務の開始から完了までを通したテストケースにすると、Flutterの画面とバックエンド、通知、監査ログのつながりを検証できます。受入テストの実施者、証跡の形式、未達時の再テスト条件もRFPに含めます。

契約形態は要件の確度と変更の多さで使い分けます

Dartのシステム開発では、請負契約、準委任契約、企画や要件定義だけを先に委託する分割契約が候補になります。契約形態の名称だけでなく、成果物の定義、完成責任、作業時間の管理、仕様変更の扱い、知的財産権、再委託、検収、瑕疵や不具合への対応、保守への移行条件を確認する必要があります。社内法務や顧問弁護士の確認も受けながら、実態に合う契約を選びます。

請負契約は、定めた成果物を完成させ、発注者が検収する形に向きます。画面一覧、API仕様、データベース定義、テスト結果、移行手順、マニュアル、ソースコード、ビルド・CI/CD設定などを成果物として列挙し、検収期限と不具合の修正条件を定めます。要件が固まっていないのに全工程を請負で固定すると、変更のたびに追加見積や納期延長が発生します。要件定義やPoCを準委任で行い、仕様が固まった開発部分だけ請負に切り替える方法もあります。

準委任契約は、委託先が一定の業務を遂行し、発注者と優先順位を調整しながら進める形です。現場からのフィードバックを受けて画面や業務フローを短いサイクルで改善する場合、アジャイル開発と組み合わせやすい契約です。一方で、作業時間や体制に対して費用を支払うため、完成機能や予算の上限が自動的に保証されるわけではありません。月次の成果、消化工数、残課題、次月の計画、追加作業の承認方法を定例会で確認し、発注者側にも意思決定できる担当者を置きます。

納品時にソースコードを受け取っても、ビルド環境や秘密情報の管理方法が分からなければ、別会社へ引き継げません。リポジトリ、CI/CD設定、クラウドアカウントの名義、証明書、パッケージ一覧、ライセンス、API仕様、データベース定義、監視設定、障害対応手順を誰が管理するかを契約書に記載します。委託先が利用するOSSや有料SDKのライセンス費、第三者サービスのアカウントを発注者名義にするかも確認します。引き継ぎ期間と有償・無償の範囲を決めておくと、担当会社の変更や内製化にも備えられます。

Dartのシステム開発にかかる費用相場と内訳

Dart専用の業務システム統計は多くないため、公開されているFlutterアプリの相場と、業務システムで発生する要件定義・基幹連携・移行・保守の費用を分けて考えます。目安は、単純な社内入力アプリやPoCで100万〜300万円、中規模の業務アプリで300万〜800万円、複数拠点・外部連携・管理画面を含む案件で800万〜1,500万円程度です。基幹システムをまたぐスクラッチ開発は1,000万円を超え、数千万円から数億円規模まで広がる可能性があります。いずれも機能と体制によって変動する推定レンジであり、Dartを選べば自動的にこの金額になるわけではありません。

株式会社LASSICの公開情報では、Flutterアプリの目安として、小規模が100万〜300万円で1〜3か月、中規模が300万〜800万円で3〜6か月、大規模が800万〜1,500万円で6か月〜1年と整理されています（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。この区分は、画面数やAPI、通知などを含む一般的なアプリの相場です。業務システムでは、現場ヒアリング、複雑な権限、既存データのクレンジング、移行リハーサル、教育、帳票、監査ログが加わるため、同じ画面数でも高くなることがあります。見積書で要件定義、設計、実装、単体テスト、結合・総合テスト、移行、教育、リリース支援が別項目になっているかを確認します。

人件費はDartのシステム開発費の大きな部分を占めます。公開情報では、Flutterエンジニアの月額単価は経験やスキルにより70万〜90万円帯が多く、上位人材では100万〜145万円に達する例もあります（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。また、リサーチノートで参照したエン・ジャパンの2025年2月の月額平均単価レポートでは、Flutter案件の平均は83.0万円でした。仮にエンジニア2名を4か月配置すると、83万円×2名×4か月で約664万円ですが、これは人件費だけの単純計算です。PM、UI設計、QA、インフラ、管理費、リスク対応を加えた総額で比較します。

リリース後は、OS更新、Flutter SDK更新、脆弱性対応、不具合修正、監視、バックアップ、問い合わせ、ストア審査、機能追加が発生します。公開相場では、年間保守費用を初期開発費の15％程度、機能追加や運用委託まで含める場合は20％程度とする目安があります（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。初期開発費300万円なら年45万〜60万円、1,000万円なら年150万〜200万円という計算になりますが、サポート時間やSLAによって変わります。Firebaseなどの従量課金、クラウド、監視ツール、端末、AppleとGoogleの開発者登録費、証明書更新費を別建てで確認し、3年から5年のTCOで比較します。

委託先の選定と見積比較で見るべきポイント

委託先を選ぶときは、Dartの経験年数やFlutterの制作件数だけで判断しません。業務要件を聞き取る担当者と実装責任者が同じ方向を向いているか、既存システムと連携した実績があるか、実機テストと自動テストを行うか、公開後のSDK更新に対応できるかを確認します。候補会社には同じRFPを渡し、金額の総額だけでなく、前提条件、含まれない作業、体制、工程、成果物、追加費用の条件を横並びにします。

候補会社の実績を見るときは、単に「Flutterアプリを何件作ったか」ではなく、販売管理、在庫、点検、施工、営業報告など、自社に近い業務を扱ったかを確認します。画面の制作実績が豊富でも、会計や在庫の整合性、複数拠点の権限、データ移行を経験していない場合があります。逆に、既存基幹とのAPI連携に強い会社が、Flutter部分を適切なパートナーと分担する提案もあります。提案時には、担当予定者の経歴、過去案件での役割、再委託の有無、発注者と直接話す窓口を質問します。

見積比較では、まず要件定義費、UI・UX設計費、Flutterアプリ費、Web管理画面費、API・データベース費、外部連携費、テスト費、移行費、教育費、リリース費、保守費を分けます。次に、対応する画面数、API数、対象OS、実機台数、オフラインの有無、通知や帳票の範囲を確認します。最安の提案にテストや移行が含まれていないと、後から追加費用が発生します。反対に高い提案でも、監査ログ、負荷試験、教育、運用設計、SDK更新の費用まで含まれていれば、TCOでは妥当な場合があります。差額の理由を説明できる会社を選びます。

個人情報や取引データを扱うDartのシステムでは、認証だけでなく、組織・拠点・ロールごとの認可、通信の暗号化、端末紛失時のセッション失効、管理者操作の監査ログ、バックアップと復元テストを確認します。Firebaseを使う場合は、Firestore Security Rules、App Check、サーバー側のIAMやAPI認可を分けて設計します。サーバーSDKからのアクセスはクライアント側のルールだけでは守れないため、発注先の説明を聞きます。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」を基に、利用目的、保存期間、委託先、国外移転、削除手順を社内で整理してからRFPに記載します（出典：個人情報保護委員会、2026年確認）。

2026年時点のDartの動向を発注判断に反映します

発注時点の最新バージョンを確認することは大切ですが、新機能を採用すること自体を目的にしてはいけません。Dart公式ブログでは、2026年5月のDart 3.12でプライベートな名前付きパラメータ、実験段階のプライマリコンストラクタ、Genkit Dartのプレビュー、Firebase Cloud FunctionsのDart対応に関する実験的サポート、AIエージェントと連携するAgentic Hot Reloadが紹介されています（出典：Dart公式ブログ「Announcing Dart 3.12」、2026年5月）。実験的機能は将来性がある一方、本番システムでは安定版の範囲、サポート期間、代替手段、アップデート費用を確認して採否を決めます。

Dart公式のDart 3.8では、Webのホットリロード、クロスコンパイル、ネイティブ相互運用の早期アクセスなどが示されました（出典：Dart公式ブログ「Announcing Dart 3.8」、2025年5月）。Flutter公式の3.32.0リリースノートでも、Web、Android、iOS、Windows、Linux、テストやツールの更新が継続しています。つまり、納品日に動けば終わりではなく、OSやSDKが更新されたときに何を試験し、誰が修正し、どの費用で対応するかを発注時に決める必要があります。利用しているプラグインの最終更新日、対応OS、ライセンス、代替プラグイン、ネイティブコードの有無を一覧化して納品物に含めます。

2026年のDartは、AI連携やフルスタック開発の選択肢が広がっています。しかし、企業の業務システムに必要なのは、技術の新しさだけではありません。障害時に原因を追えるログ、権限を変更できる管理画面、データを復元できるバックアップ、担当者が退職しても引き継げるドキュメント、SDK更新を計画する保守契約が必要です。提案書では、採用する機能を「本番利用」「検証利用」「採用しない」に分類し、理由と将来の見直し条件を書いてもらいます。これにより、流行の技術を採用した後に運用で困るリスクを抑えられます。

よくある質問（FAQ）

Dartのシステムを発注する際によくある疑問を、費用、技術選択、委託後の運用の観点から回答します。自社の利用者数や既存システム、端末、データの機密性を当てはめて検討します。

単純な社内入力アプリや技術検証であれば、公開されているFlutterの相場として100万〜300万円、1〜3か月程度からのレンジが参考になります。ただし、これは一般的な小規模アプリの目安であり、要件定義、API、認証、実機テスト、データ移行、保守を含むかで変わります。金額だけでなく、何を検証し、どの成果物を受け取り、本開発へ進むときに再利用できるかを確認します。

必ずしもDartだけに統一する必要はありません。新規の小規模サービスでデータモデルやバリデーションを共有したい場合はDartサーバーやFirebase Functionsが候補になりますが、会計・在庫など既存の基幹APIが安定しているなら、Flutterクライアントから既存APIを利用する方が移行リスクを抑えられます。発注先には、Dartで統一する案、既存バックエンドを活用する案、将来段階的に置き換える案を比較してもらい、運用担当者が保守できる構成を選びます。

必ず安くなるわけではありません。公開情報では、iOSとAndroidを共通コードで開発することで、ネイティブ個別開発より30〜40％削減できる場合があるとされていますが、カメラ、センサー、専用スキャナ、印刷などOS固有機能が多いほど削減幅は小さくなります（出典：株式会社LASSIC「Flutterアプリ開発費用の相場」、2026年確認）。共通化による初期費用だけでなく、実機検証、プラグイン更新、OSアップデート、保守の体制を含めて判断します。

現状業務と課題、利用者と拠点、業務フロー、必要な機能、対象端末、既存システムとAPI、データ件数と形式、セキュリティ要件、希望時期、予算の考え方、受入条件をまとめたRFPを渡します。画面イメージがあれば添付しますが、画面だけでなく例外処理と業務ルールも記載します。候補会社には同じ資料を渡し、提案に含まれない作業、前提条件、体制、再委託、保守範囲、ソースコードの権利を質問すると、見積を公平に比べやすくなります。

まとめ

Dartのシステムを発注・外注するときは、DartやFlutterの採用を先に決めるのではなく、現場の業務、利用端末、既存基幹との役割分担、データ移行、セキュリティ、保守までを一つの計画にします。要件が固まっていない案件はPoCや段階発注から始め、請負と準委任を工程ごとに使い分けると、変更リスクと予算を管理しやすくなります。

最終的には、(1)PoC・段階発注・一括開発のどれが適するか、(2)Flutterと既存APIやDartサーバーの境界、(3)RFPに書く機能・非機能・移行・受入条件、(4)請負・準委任の責任分界、(5)初期費用と保守・クラウドを含めたTCO、(6)実績・テスト・SDK更新・引き継ぎの体制を確認します。見積書の安さだけでなく、同じ条件で比較でき、将来の運用まで説明できる委託先を選ぶことが、Dartのシステムを定着させる近道です。

初回相談の段階で、技術名だけを伝えるのではなく、現場の困りごと、対象端末、既存システム、データの扱い、検証したい機能、希望時期を共有します。委託先から質問が返ってくるか、リスクや代替案を説明できるか、費用を工程別に示せるかを見れば、発注後のコミュニケーションも想像しやすくなります。Dartのシステムは共通化の利点を活かしながら、自社の業務に必要な部分へ投資することが成功のポイントです。

▼全体ガイドの記事
・Dartのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。