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

.NET MAUIのシステム発注は、業務と成功条件の整理から始まります。そのうえでPoCにより実機を検証し、要件を定めて委託先を選ぶ流れで進めると、現場で使われる仕組みに近づけやすくなります。

発注前の全体像は、.NET MAUIのシステム開発の完全ガイドでも確かめられます。

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

.NET MAUIのシステムを発注する前に知るべき全体像

アプリの外側にも、設計と委託範囲の確認が広がります。

.NET MAUIはC#とXAMLを中心とするフレームワークで、iOS、Android、Windows、Mac Catalystなどのアプリを共通コードで開発できます。一方で、多くの案件では、MAUIアプリにASP.NET Coreなどの業務API、データベース、既存のCRMや販売管理システムを組み合わせて、営業管理の機能を実現します。

.NET MAUIのシステムで委託する範囲

発注時は、アプリだけでなく利用者や端末も含めて整理します。範囲には、業務データや連携先、管理画面を入れます。そのうえで、認証や通知、ログ、運用窓口まで決めておきます。

営業業務：顧客検索、案件更新、訪問記録、写真添付、次回アクション、上長承認。
オフライン：通信が不安定な現場では、入力を一時保存して、復旧後にAPIへ同期します。

既存のSalesforceやHubSpot、Dynamics 365、ERPなどと連携する場合は、画面数よりもデータ連携の設計が見積に影響します。

APIの利用制限や同期項目、名寄せ、更新競合、失敗時の再送方法は、開発の前に発注側と開発会社で決めておきます。決めずに始めると、後半で追加費用が生じやすくなります。

MAUIで共通化できるのは、主に画面や業務ロジックの一部です。一方で、API、データ移行、端末固有の機能は、MAUIを使っても自動的に共通化されません。

技術選定より先に業務と成功条件を決める理由

営業アプリでは、納品そのものよりも、訪問後の入力を短くし、案件情報を正確に更新して、次の行動を漏れなく実行できる状態を作ることが目的です。

利用状況：月間利用者数や訪問記録の登録率を定めます。
操作と通信：入力時間やオフライン時の許容時間を、決めておきます。
業務成果：案件更新の締切を決め、完成後に達成度を測ります。

利用率や入力率を測れなければ、完成後に使われない原因を突き止められません。

Microsoft Learnの企業向けガイドでは、表示、表示ロジック、エンティティ、APIクライアント、データやキャッシュの層を分ける構成が示されています（出典: Microsoft Learn「Introduction to .NET MAUI」、2024年以降参照）。

発注者は、実装を細かく指定しなくて構いません。そのかわり、変更のしやすさ、テスト、障害調査、納品後の運用担当は、RFPで確認しておきます。

ポイント

アプリの外側にあるAPIや連携先、運用窓口まで委託範囲に含まれているかを、見積を比べる前に見直します。範囲が曖昧なままだと、後半の追加費用が生じやすくなります。

.NET MAUIのシステム発注・外注の進め方

実機や業務上の不確実性を前半で確かめる流れです。

発注は、自社の業務と制約を整理するところから始めます。技術会社を探すのは、その後です。

小さな検証の後は、要件定義、設計・開発、受入テスト、運用引き継ぎへと進みます。工程ごとに成果物と意思決定者を決めておくと、委託先との認識違いを抑えやすくなります。

1. 現行業務と発注目的の整理

最初に、誰がどこで、どの端末を使い、何を入力・参照しているかを洗い出します。たとえば営業日報なら、顧客検索から面談記録、写真添付、上長報告、案件更新までの流れをたどります。

現場担当者、営業管理者、システム管理者の三者には、別々に話を聞きます。あわせて、Excelや紙の帳票も集めておきます。

初回に必要：顧客検索や活動登録、オフライン対応、同期状況の確認を、MVPに含めます。
後回しにできる：AIスコアリングや複雑な分析は、初回リリースでの優先度を見極めて判断します。

機能は、「絶対に必要」「あれば便利」「後回しにできる」の三つに分けておきます。なかでも、利用率に直結する機能から作る方が、検証の対象がはっきりします。

業務の例外をすべて再現しようとせず、標準化できる手順を先に決めることも、発注者の役割です。

2. PoCと要件定義による技術的な不確実性の削減

全機能を作る前に、代表画面を数本使ったPoCを発注します。このPoCの実機検証では、主要な端末機能と通信時の動きを確かめます。

接続と保存：ログイン、顧客検索、API接続、通信断時の保存と復旧後の同期。
端末機能：写真や位置情報の取得、カメラ、GPS、通知の動作。
実機条件：低速回線やスリープ復帰も確かめ、エミュレーターでは見えにくい問題を探します。

RFPには、画面一覧、業務フロー、データ項目、権限を書きます。連携先、対応OS、対象端末、性能目標も記載します。さらに、監査ログ、セキュリティ、テスト環境、納品物も含めます。

要件定義では、圏外時の動作と、複数人が同時に更新したときの競合解決を決めます。加えて、同期が失敗した場合の再実行や、端末紛失時の対応も書き込みます。

3. 段階開発と受入テストによる現場定着の確認

開発では、節目ごとにレビューを置きます。節目は、要件定義、基本設計、画面試作の三段階と、API仕様、実装、結合・総合テストの三段階です。

業務責任者：画面が業務の流れに合っているかを見ます。
現場担当者：実際の入力操作を試します。
情報システム部門：権限や運用の妥当性。

レビュー担当を立場ごとに分けると、見落としを減らせます。

受入テストでは、正常な操作に加えて、異常な場面も想定します。想定する場面は、通信断、APIタイムアウト、重複送信、権限不足の四つです。さらに、古いアプリやOS更新後の表示崩れ、端末紛失も含めます。

合格条件は、動くことではなく、業務の結果で定めます。たとえば、訪問記録を一定時間以内に登録できることが条件になります。

また、同期エラーを利用者が把握できることや、管理者が監査ログを確認できることも、条件に含めます。

ポイント

業務の整理、PoC、段階開発の各段階で、実機の結果と業務側の判断がそろってから次の工程へ進むかどうかを決めるのが目安です。

発注形態と契約形態の選び方

発注形態は、完成品を納めてもらうのか、チームに継続して参加してもらうのか、企画や要件定義を支援してもらうのかで選びます。

契約は、要件の確度や改善の頻度、成果物の明確さによって、向いている形が変わります。要件が不確実な部分と、納品物が明確な部分を分けて契約する方法もあります。

一括請負・準委任・ラボ型の違い

三つの方式は、要件の確度や開発中の変更頻度によって、向き不向きが分かれます。

一括請負：合意した仕様と成果物を納める方式で、要件や受入条件が明確な案件に向きます。
準委任：一定期間と一定体制で進める方式で、現場ヒアリングやCRM調査を続ける場合に使えます。
ラボ型：専任または半専任のチームを中長期で確保し、優先順位を変えながら開発する方式。

変更が多い段階で一括請負を選ぶと、変更管理や追加見積が頻発し、発注側と開発会社の双方の負担が重くなります。

どの方式でも、契約書には作業時間だけでなく、成果物やレビュー、品質基準、知的財産権、引き継ぎを明記しておきます。

契約前に決める成果物と責任分界

納品物と担当範囲は、契約の前に確かめておきます。設計書や仕様書、コード、ビルド環境などは、受領後の保守移管にも関わります。

設計・開発資料：設計書、画面・API・データ移行・テスト仕様、ソースコード。
運用資料：ビルド手順、証明書、CI/CD設定、ストア申請資料、操作・運用手順書。
所有・権利：リポジトリ、クラウドアカウント、外部ライブラリのライセンス。

端末の調達や、Apple・Googleの開発者アカウント、CRMのAPI契約、クラウド費用の担当も決めます。さらに、データ整備や利用者教育、ストア審査、障害受付の担当も、発注側と委託先で分けておきます。

個人情報を扱う場合は、再委託や保管場所、アクセス権、ログ保存期間、事故時の報告手順を確かめます。

仕様に書かれていない作業を当然含まれると考えていると、納品直前に追加費用が生じる原因になります。

ポイント

要件が確定しているか、開発中に変更が多いかで、一括請負と準委任のどちらが合うかを分けて考えるのが目安です。どの形でも、成果物と担当範囲は契約書に書き込みます。

.NET MAUIのシステム発注費用相場とコストの内訳

規模が上がるほど、想定する費用帯も広がります。

発注費用は、MAUIを採用するかどうかだけで決まるものではありません。画面数やAPI、管理画面、連携本数、データ移行、オフライン同期によって変わります。端末機能やセキュリティ、テスト端末、保守も、費用に影響します。

ここで示す金額は、公開定価ではなく、2026年時点で要件整理に使う推定レンジです。

規模別の初期開発費と期間の目安

小規模PoCから大規模営業基盤まで、機能の範囲によって初期費用と開発期間の目安は変わります。

小規模PoC・営業日報：300万円〜800万円程度、2〜4か月。
中規模システム：800万円〜2,000万円程度、4〜8か月。
大規模営業基盤：2,000万円〜5,000万円以上、8〜18か月に及ぶ可能性があります。

小規模の想定は、ログイン、10〜20画面程度の入力と検索、簡易API、写真添付、両OSの実機確認です。既存のAPIがなく、認証や管理画面を新設する場合は、金額が上振れします。

中規模では、顧客や案件、活動履歴の管理に加えて、権限や通知、オフライン同期を含みます。さらに、管理画面とCRM連携も入ります。

大規模では、複数拠点やERP・MA連携、データ移行、厳格な監査ログ、BI連携を含む場合です。

この金額と期間は、リサーチノートに基づく編集用の推定です。特定の会社の価格を示すものではありません。

見積に含める工程と追加費用

工程ごとの配分は、見積項目の抜けを確かめるための目安として使います。

要件定義：10〜15%。
基本設計・詳細設計：それぞれ15〜20%、10〜15%。
開発・結合総合テスト：それぞれ30〜40%、15〜20%。
移行・教育：5〜10%程度。

これは標準の配分ではありません。要件定義や実機QA、移行、教育、リリース作業が別費用になっている場合は、工程ごとの割合ではなく総額で比べます。

初期費用のほかに、クラウドやApple・Googleのアカウント、監視、ログ、外部APIの費用も発生します。

地図や通知、UI部品、端末も費用の対象です。脆弱性診断やOS更新、ストア対応、問い合わせ窓口も、対象に含まれます。

メシウスのComponentOne 2024J v2では、Enterprise開発ライセンスの価格例として、初回22万円、更新11万円が示されています（出典: メシウス株式会社の製品資料、2025年）。なお、これはアプリ開発費ではなく、部品の追加ライセンス費です。

保守費用とバージョン更新の扱い

保守費用は、対応範囲と更新頻度を分けて見積もります。費用項目を整理するときは、次の条件を確認します。

年間費用：スクラッチ開発では、初期開発費の年10〜20%程度を別に計上します。
対応範囲：24時間監視や緊急対応まで含むのか、問い合わせ対応だけかで金額が変わります。
見積条件：月次作業時間、対応時間帯、障害優先度、OS検証回数、MAUI・SDK更新対応ごとに分けて示します。
リリース：.NET MAUI 10は2025年11月11日にリリース。
サポート終了：2026年7月時点で2027年5月11日です。

この日付は、Microsoft公式のサポートポリシーに基づいています（出典: Microsoft「The official .NET MAUI support policy」、2026年7月23日更新）。

.NET 10本体とMAUIのサポート期限は、同じとは限りません。そのため、採用するバージョンや更新計画と費用、旧版を使い続けるリスクを確かめます。

ポイント

見積の総額を比べるときは、開発費だけでなく、部品や端末、保守、OS更新の費用まで含まれているかを基準にするのが目安です。

RFP・要件整理と委託先選定、見積比較のポイント

相見積もりでは、合計金額だけでなく、同じ前提条件で比べられるかを確かめます。画面数やAPI数、端末、テスト範囲、移行データ、保守期間が異なると、比較ができません。

RFPには、含む作業と含まない作業を書きます。そのうえで、提案書には前提条件とリスクを明示してもらいます。

RFPに入れるべき項目

RFPには、背景や目的、利用者、OS・端末、現行業務を記載します。対象範囲や画面・帳票、データ、連携も書きます。

権限、認証、オフライン、性能、可用性についても、RFPに書いておきます。また、ログやバックアップ、監査、移行、教育、運用の条件も、同じ書類に含めます。さらに、納品物、時期、予算も書きます。

画面一覧には、参照だけか登録や更新も行うのか、必須入力、写真や位置情報の利用有無を書きます。

端末機能：カメラ、バーコード、GPS、通知、添付、電子署名の対象機種。
例外時の動作：権限拒否やオフライン時の制限の扱い。
継続検証：OS更新後の再検証と、外部SDKの対応状況を見ておきます。

Google Playは2025年11月1日から、Android 15以降を対象とする新規アプリや更新に対し、16KBページサイズへの対応を求めています（出典: Google Android Developers「Support 16 KB page sizes」、2026年7月13日更新）。

外部SDKやネイティブライブラリを使う場合は、対応状況と検証結果を委託先に提出してもらいます。

委託先の実績と開発体制の確認

委託先には、.NETの知識だけでなく、MAUIの公開実績や対応OS・端末、オフラインや同期の実装経験があるかを確かめます。また、CRMやERPとの連携、実機QA、ストア公開、保守の経験も見ておきます。

営業支援やフィールドサービスの実績があれば、移動や通信の不安定さ、写真や位置情報、短時間の入力といった制約を理解している可能性があります。

公開事例が少ない場合は、NDAを結んだ後に、匿名化した設計範囲やテスト計画を確認します。

役割：責任者、要件定義、MAUI、バックエンド、QA、保守の担当者。
実担当との対話：設計やテストを担うメンバーに、懸念を質問します。
説明の具体性：共通化の範囲、OS固有の実装、将来の更新負担を説明できるかを見ます。

「一つのコードで全て対応できる」と断言する会社よりも、共通部分と固有実装を説明できる会社の方が、期待値を合わせやすくなります。

見積書の基準をそろえた比較

見積は人月だけでなく、工程ごとの成果物や担当範囲、前提、除外事項、検収条件を確かめます。

「テスト一式」とだけ書かれていると、対象OSや端末台数、通信断や権限拒否の扱いが分かりません。

開発工程：要件定義、UI・UX、MAUI、API・バックエンド、管理画面、連携。
導入工程：データ移行、テスト、リリース、利用者教育。
運用工程：保守、OS対応、監視、引き継ぎの範囲。

金額に差があるときは、単価よりも先に作業範囲を見ます。安い見積では、要件定義や実機テストが含まれず、移行は発注者の作業になっている場合があります。

リリース後のOS対応が、別契約になっているケースもあります。一方で、高い見積でも、PoCや設計レビュー、監視、教育、引き継ぎを含むなら、単純な値引き比較は適切ではありません。

質問への回答の速さや、リスクを開示する姿勢も、長く任せる委託先を選ぶときの評価軸になります。

セキュリティとデータ移行の選定条件

顧客情報を扱う場合は、認証だけでなく、API認可やロール別の参照範囲、MFAを確かめます。さらに、トークン失効や端末内データ、監査ログ、バックアップ、遠隔失効も確認します。

.NET MAUIのSecureStorageは、小さな秘密情報を安全に保存する機能です。一方で、顧客一覧や案件データを大量に保存する場所とは、分けて考えます。

OWASP MASVSは、モバイルアプリのストレージや認証・認可、ネットワーク、プライバシーなどを、検証の領域として整理しています（出典: OWASP「MASVS」、2026年参照）。

開発管理：脆弱性診断、依存ライブラリ、個人情報をログに出さない設計。
事故対応：事故時の連絡体制と端末紛失時の対応。
データ品質：CRMの表記揺れを整理する名寄せ方針。

整理されていない顧客マスタをそのまま移行すると、検索や重複排除の品質が下がります。画面だけを改善しても、現場で使いにくい状態は残ります。

ポイント

相見積もりでは、同じ前提条件で比べられるかをまず見ます。前提がそろわない見積は、金額だけで判断しないのが目安です。

.NET MAUIのシステム発注に関するよくある質問

外注では、共通化による効率だけでなく、業務要件やデータ、端末、保守について、どこまでを誰が受け持つかも確かめる必要があります。

.NET MAUIならiOSとAndroidの開発費は必ず半額になりますか？

必ず半額になるわけではありません。画面や業務ロジックの一部を共有できても、APIやデータ基盤、端末機能、実機テスト、ストア対応、保守は必要です。

共通化できる範囲と固有の実装は、PoCで確かめます。そのうえで、iOSとAndroidそれぞれのテスト費用も含めて見積もります。

SaaSの標準アプリと.NET MAUIの外注はどちらがよいですか？

顧客や案件、活動の管理が標準機能で足りて、端末機能や複雑なオフライン要件もないなら、SaaSの標準アプリを先に検討します。

独自の営業フローや基幹との深い連携、カメラ・GPS・バーコード、通信断からの同期が競争力になる場合は、専用アプリを外注する選択肢があります。

初期費用だけでなく、月額ライセンスやカスタマイズ、運用の変更、データの所有権まで比べます。

RFPを作れない状態でも開発会社へ相談できますか？

相談できます。まず、業務の目的や利用者、端末を整理します。そのうえで、現行の帳票やExcel、連携先、困っている場面をまとめてから相談すると、提案の精度が上がります。

RFPの作成そのものを要件定義として委託し、成果物と費用を分けて契約する方法もあります。その場合は、業務ヒアリングとPoCの範囲を明確にして依頼します。

発注後のMAUIやOSのアップデートは誰が担当しますか？

発注者と開発会社、クラウドや外部サービスの提供者が、それぞれどこまで担うかを、契約前に決めておきます。MAUIや.NET、Xcode、Android SDK、外部ライブラリについては、更新を監視する担当も確認します。

実機検証の頻度と追加費用の条件は、保守契約に記載します。更新を放置すると、ストア審査や新しい端末で問題が起こるため、初期費用と保守費用を分けて予算化します。

まとめ

.NET MAUIの発注では、現場業務や端末、CRM連携、オフライン同期、セキュリティ、運用を、一つの要件としてまとめます。

一括請負、準委任、ラボ型の特徴を踏まえて、不確実な要件定義と、確定している成果物を分けて考えます。

発注前に確認する5つの要点

発注範囲と納品後の運用を見通すために、業務、検証、見積、契約の順で確かめます。

対象業務と利用率、入力時間などの成功条件を決めます。
PoCでAPI、オフライン、カメラ、通知を実機検証します。
RFPで画面、データ、権限、端末、テスト、移行、納品物をそろえます。
開発費にクラウド、部品、端末、ストア、保守、OS更新を加えて比較します。
コード、設計書、アカウント、データ、再委託、障害対応の責任を契約に残します。

最初に作るべき資料

最初の資料は、現行業務や利用者と端末、必須画面、連携先、困っている場面、希望時期を、1〜2枚にまとめたものです。

資料をもとに、MAUIと営業・CRM・フィールド業務に詳しい会社へ相談します。
要件定義やPoCの見積を比べます。

要件と見積の前提をそろえておくと、納品後も現場で使われ続けるシステムに近づけられます。

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

▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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