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

.NET MAUIのシステムを発注する際は、アプリ画面の開発費だけでなく、既存CRMとの連携、オフライン同期、実機テスト、OS更新、保守まで含めて委託範囲と費用を決めることが重要です。

営業担当者が外出先で顧客情報や案件を確認したり、訪問記録を登録したりする業務アプリでは、iOSとAndroidを別々に開発するか、.NET MAUIで共通化するかが発注時の大きな検討事項になります。この記事では、発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の選定、見積書の比較方法を順番に解説します。

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

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

.NET MAUIは、C#とXAMLを中心に、iOS、Android、Windows、Mac Catalystなどのアプリを共通コードベースで開発できるフレームワークです。ただし、CRMや営業管理が完成したパッケージではありません。多くの案件では、.NET MAUIのクライアントアプリに、ASP.NET Coreなどの業務API、データベース、既存CRMや販売管理システムを組み合わせます。

発注時は「アプリを作ってください」と伝えるだけでは不十分です。利用者、端末、業務データ、連携先、管理者向け画面、認証、通知、ログ、運用窓口を一つのシステムとして整理します。たとえば営業向けなら、顧客検索、案件のステージ更新、訪問記録、写真添付、次回アクション、上長承認までが対象になります。現場の通信が不安定なら、入力内容を端末に一時保存し、通信復旧後にAPIへ同期する処理も要件に含めます。

既存のSalesforce、HubSpot、Dynamics 365、ERPなどとつなぐ場合は、画面数よりもデータ連携の設計が見積に影響します。APIの利用制限、同期する項目、名寄せルール、更新競合の扱い、失敗時の再送方法を決めないまま開発を始めると、後半で追加費用が発生しやすくなります。MAUIの共通化は主に画面や業務ロジックの一部を対象にするもので、API、データ移行、端末固有機能まで自動的に共通化されるわけではありません。

営業アプリの目的は、アプリを納品することではなく、訪問後の入力時間を短くし、案件情報を正確に更新し、次のアクションを漏れなく実行できる状態を作ることです。したがって、要件の初期段階で「月間の利用者数」「訪問記録の登録率」「入力にかかる時間」「オフライン時の許容時間」「案件更新の締切」を決めます。利用率や入力率を測定できなければ、完成後に使われない原因を発見できません。

Microsoft Learnの企業向け.NET MAUIガイドでも、表示部分、表示ロジック、エンティティ、APIクライアント、データやキャッシュの層を分け、変更しやすくテストしやすい構成が示されています（出典: Microsoft Learn「Introduction to .NET MAUI」、2024年以降参照）。発注者は実装方法を細かく指定する必要はありませんが、変更可能性、テスト方法、障害時の調査方法、納品後の運用担当をRFPで確認することが大切です。

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

発注プロジェクトは、技術会社を探すところから始めるのではなく、自社の業務と制約を整理するところから始めます。次に小さな検証を行い、要件定義、設計・開発、受入テスト、運用引き継ぎへ進みます。各工程の成果物と意思決定者を先に決めておくと、委託先との認識違いを抑えられます。

最初に、誰が、どの場所で、どの端末を使い、どの情報を入力・参照するのかを整理します。営業日報を例にすると、訪問先で顧客情報を検索する、面談結果を入力する、写真を添付する、上長へ報告する、案件ステージを更新するという流れがあります。現場担当者、営業管理者、システム管理者に別々にヒアリングし、Excelや紙帳票も集めます。

ここで「絶対に必要な機能」「あれば便利な機能」「後回しにできる機能」を分けます。初回リリースからAIスコアリングや複雑な分析を詰め込むより、顧客検索、活動登録、オフライン対応、同期状況の確認など、利用率に直結する機能をMVPに含める方が検証しやすくなります。業務の例外をすべてアプリに再現するのではなく、標準化できる手順を先に決めることも発注者の役割です。

いきなり全機能を作るのではなく、代表画面を数本使ったPoCを発注します。ログイン、顧客検索、写真や位置情報の取得、API接続、通信が切れた場合の保存と復帰後の同期を実機で確認します。エミュレーターだけでは、カメラ、GPS、通知、低速回線、端末のスリープ復帰などの問題を見落とす可能性があります。

PoCの結果を踏まえて、RFPには画面一覧、業務フロー、データ項目、権限、連携先、対応OS、対象端末、性能目標、監査ログ、セキュリティ条件、テスト環境、納品物を記載します。要件定義の成果物には、機能要件だけでなく、電波がない場合の動作、同じ顧客を複数人が更新した場合の競合解決、失敗した同期の再実行、端末紛失時の対応も含めます。

開発中は、要件定義、基本設計、画面プロトタイプ、API仕様、実装、結合テスト、総合テストの節目ごとにレビューを設定します。発注者側の業務責任者が画面を確認し、現場担当者が入力操作を確認し、情報システム部門が権限や運用を確認するというように、レビューする人を分けると見落としを減らせます。

受入テストでは、正常系だけでなく、通信断、APIのタイムアウト、重複送信、権限不足、古いアプリの利用、OSアップデート後の表示崩れ、端末の紛失を想定します。合格条件を「動くこと」ではなく、「訪問記録を一定時間以内に登録できる」「同期エラーを利用者が把握できる」「管理者が監査ログを確認できる」など、業務結果で定義すると判断しやすくなります。

発注形態と契約形態はどのように選びますか？

発注形態は、完成品を納めてもらうのか、開発チームに継続参加してもらうのか、企画や要件定義だけを支援してもらうのかで選びます。契約形態も、要件が固まっているか、改善を繰り返すか、成果物をどこまで明確にできるかによって適した方法が変わります。おすすめは、要件の不確実性が高い部分と、納品物が明確な部分を分けて契約する考え方です。

一括請負は、合意した仕様と成果物をもとに完成品を納めてもらう形態です。要件や受入条件が明確で、画面数や連携仕様を固定しやすい案件に向いています。一方、要件変更が多い状態で一括請負にすると、変更管理や追加見積が頻発し、発注者と受託者の双方が疲弊しやすくなります。

準委任は、一定期間・一定の体制で設計や開発を進める形態です。現場ヒアリングを続けながら画面を改善したい場合や、既存CRMの仕様を調査しながら連携方法を決めたい場合に適しています。ラボ型は、専任または半専任のチームを中長期で確保し、優先順位を変えながら開発する方式です。どの方式でも、作業時間だけでなく、成果物、レビュー方法、品質基準、知的財産権、引き継ぎを契約書に明記します。

契約書や個別契約では、設計書、画面仕様、API仕様、データ移行仕様、テスト仕様書、ソースコード、ビルド手順、ストア申請資料、操作マニュアル、運用手順書の納品有無を確認します。ソースコードを受け取っても、ビルド環境や証明書、CI/CD設定が受け取れなければ、別会社へ保守を移せないことがあります。リポジトリの所有者、クラウドアカウントの名義、外部ライブラリのライセンスも発注者側で把握します。

責任分界では、端末の調達、AppleやGoogleの開発者アカウント、CRM側のAPI契約、クラウド費用、データクレンジング、利用者教育、ストア審査、障害一次受付を誰が担うかを決めます。個人情報を扱う場合は、再委託、保管場所、アクセス権、ログ保存期間、事故発生時の報告手順も確認します。仕様書に書かれていない作業を「当然含まれる」と考えると、納品直前に追加費用の原因になります。

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

.NET MAUIの発注費用は、MAUIを採用するだけで決まるものではありません。画面数、APIや管理画面の有無、既存システムとの連携本数、データ移行、オフライン同期、端末固有機能、セキュリティ、テスト対象端末、リリース後の保守によって大きく変わります。公開定価ではなく、2026年時点で要件整理に使える推定レンジとして確認してください。

小規模PoCや営業日報アプリは、初期開発費300万円〜800万円程度、期間2〜4か月が一つの目安です。ログイン、10〜20画面程度の入力・検索、簡易API、写真添付、iOSとAndroidの実機確認を想定したレンジです。既存APIが使えず、新たに認証や管理画面を作る場合は上振れします。

顧客・案件・活動履歴、権限、通知、オフライン同期、管理画面、CRM連携を含む中規模システムは、800万円〜2,000万円程度、期間4〜8か月が目安です。複数拠点、ERPやMAとの連携、データ移行、厳格な監査ログ、BI連携まで含む大規模な営業基盤は、2,000万円〜5,000万円以上、期間8〜18か月に及ぶ可能性があります。これらはリサーチノートに基づく編集用の推定であり、特定会社の価格を示すものではありません。

予算配分のたたき台として、要件定義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年）。これはアプリ開発費ではなく、採用する部品の追加ライセンス費です。

保守・OS対応・脆弱性修正は、スクラッチ開発では初期開発費の年10〜20%程度を目安に別計上します。ただし、24時間監視や緊急対応を含むか、問い合わせ対応だけかで金額は変わります。見積書では、月次の作業時間、対応時間帯、障害の優先度、OSアップデートの検証回数、MAUIやSDKのメジャーアップデート対応を分けて記載してもらいます。

Microsoft公式のサポートポリシーでは、.NET MAUI 10は2025年11月11日にリリースされ、2026年7月時点のサポート終了日は2027年5月11日です（出典: Microsoft「The official .NET MAUI support policy」、2026年7月23日更新）。.NET 10本体のサポート期限と.NET MAUIの期限は同じとは限らないため、発注時に採用バージョン、更新計画、更新費用、旧バージョンを使い続ける場合のリスクを確認します。

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

相見積もりでは、合計金額の安さだけでなく、同じ前提条件で比較できているかを確認します。会社ごとに画面数、APIの本数、対応端末、テスト範囲、移行データ、保守期間の定義が違うと、見積金額を並べても判断できません。RFPには「含むもの」と「含まないもの」を記載し、提案書では前提条件とリスクを明示してもらいます。

RFPには、背景と目的、対象利用者、対応OSと端末、現行業務、対象範囲、画面・帳票、データ項目、外部連携、権限、認証、オフライン要件、性能、可用性、ログ、バックアップ、監査、移行、教育、運用、納品物、希望スケジュール、予算の考え方を記載します。画面一覧には、参照だけか登録・更新も行うか、必須入力は何か、写真や位置情報を使うかを書きます。

特に.NET MAUI案件では、端末固有機能と実機検証の条件を具体化します。カメラやバーコード、GPS、プッシュ通知、ファイル添付、電子署名を使う場合、対象機種、権限拒否時の動作、オフライン時の制限、OSアップデート後の再検証を要件に含めます。Androidについては、Google Playが2025年11月1日から、Android 15以降を対象とする新規アプリや更新に16KBページサイズ対応を求めています（出典: Google Android Developers「Support 16 KB page sizes」、2026年7月13日更新）。外部SDKやネイティブライブラリを使う場合は、委託先に対応状況と検証結果を提出してもらいます。

委託先は「.NETに詳しい」という説明だけでなく、.NET MAUIを使った公開実績、対応OS、対象端末、オフラインや同期の実装経験、CRM・ERPとの連携経験、実機QA、ストア公開、保守体制を確認します。営業支援やフィールドサービスの実績があれば、利用者の移動、通信不安定、写真・位置情報、短時間入力といった業務上の制約を理解している可能性があります。公開事例が少ない場合は、NDA締結後に匿名化した設計範囲やテスト計画を確認します。

提案時には、プロジェクト責任者、要件定義担当、MAUI開発者、バックエンド担当、QA担当、保守担当が誰かを確認します。営業担当だけでなく、実際に設計・テストを担うメンバーと会い、懸念点を質問してください。「一つのコードで全て対応できます」と断言する会社より、共有できる部分、iOS・Android固有の実装、将来の更新負担を説明できる会社の方が、発注後の期待値を合わせやすくなります。

見積書は、要件定義、UI・UX、MAUIアプリ、API・バックエンド、管理画面、連携、データ移行、テスト、リリース、教育、保守に分けて確認します。各項目に人月だけでなく、対象成果物、担当範囲、前提、除外事項、検収条件を記載してもらいます。たとえば「テスト一式」では、対応するOSバージョン、端末台数、通信断や権限拒否のテストを含むかが分かりません。

金額差がある場合は、単価の差より先に、作業範囲の差を確認します。安い見積もりに要件定義や実機テストが含まれていない、移行を発注者作業としている、リリース後のOS対応が別契約になっているというケースがあります。反対に、高い見積もりでも、PoC、設計レビュー、監視、教育、引き継ぎまで含むなら、単純な値引き比較は適切ではありません。質問への回答の速さやリスクの開示姿勢も、長期委託先を選ぶ評価軸です。

顧客情報を扱うシステムでは、認証と画面のログインだけでなく、API側の認可、ロール別の参照範囲、MFA、トークンの失効、端末内データの保護、監査ログ、バックアップ、端末紛失時の遠隔失効を確認します。.NET MAUIのSecureStorageは小さな秘密情報を安全に保存するための機能であり、顧客一覧や案件データを大量に保存する場所とは分けて設計します。

OWASP MASVSは、モバイルアプリのストレージ、認証・認可、ネットワーク、プライバシーなどを検証領域として整理しています（出典: OWASP「MASVS」、2026年参照）。委託先には、脆弱性診断の実施有無、依存ライブラリの管理、ログに個人情報を出さない設計、事故時の連絡体制を確認します。また、既存CRMの顧客名や会社名に表記揺れがある場合、移行前に発注者側で名寄せ方針を決めます。汚れたマスタをそのまま移行すると、検索や重複排除の品質が下がり、MAUIの画面を改善しても現場で使いにくい状態が残ります。

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

.NET MAUIの外注では、共通化による開発効率だけでなく、業務要件、データ、端末、保守の責任分界を確認することが重要です。ここでは、発注前に多く寄せられる疑問へ直接回答します。

必ず半額になるわけではありません。画面や業務ロジックの一部を共有できても、API、データ基盤、端末固有機能、実機テスト、ストア対応、保守は必要です。共通化できる範囲と固有実装の量をPoCで確かめ、iOS・Androidそれぞれのテスト費用を含めて見積もります。

顧客・案件・活動管理が標準機能で足り、端末固有機能や複雑なオフライン要件がなければ、SaaSの標準アプリを先に検討します。独自の営業フロー、既存基幹との深い連携、現場のカメラ・GPS・バーコード、通信断からの同期が競争力になる場合は、.NET MAUIで専用アプリを外注する選択肢があります。初期費用だけでなく、月額ライセンス、カスタマイズ、運用変更、データ所有権まで比較します。

相談できますが、業務の目的、利用者、対象端末、現行の帳票やExcel、連携先、困っている場面だけでも整理してから相談すると、提案の精度が上がります。RFP作成そのものを要件定義フェーズとして委託し、成果物と費用を分けて契約する方法もあります。最初から全機能の確定を目指すのではなく、業務ヒアリングとPoCの範囲を明確にして依頼します。

契約前に、発注者、開発会社、クラウドや外部サービスの提供会社の責任分界を決めます。MAUI、.NET、Xcode、Android SDK、外部ライブラリ、iOS・Androidの更新を誰が監視し、どの頻度で実機検証し、どの条件で追加費用になるかを保守契約に記載します。公開後に更新を放置すると、ストア審査や新しい端末で問題が起きるため、初期費用と保守費用を分けて予算化します。

まとめ

.NET MAUIのシステムを発注・外注するときは、開発技術の比較から始めず、現場業務、利用端末、既存CRMとの連携、オフライン同期、セキュリティ、運用までを一つの要件として整理します。発注形態は、一括請負、準委任、ラボ型の特徴を踏まえ、不確実な要件定義と確定した成果物を分けて考えます。

第一に、顧客・案件・活動などの対象業務と、利用率や入力時間などの成功条件を決めます。第二に、PoCでAPI連携、オフライン、カメラや通知などを実機検証します。第三に、RFPで画面、データ、権限、端末、テスト、移行、納品物を同じ基準にそろえます。第四に、開発費だけでなく、クラウド、部品、端末、ストア、保守、OS更新を含む総額で比較します。第五に、ソースコード、設計書、アカウント、データ、再委託、障害対応の責任分界を契約に残します。

まずは、現行業務の流れ、利用者と端末、必須画面、連携先、困っている場面、希望する導入時期を1〜2枚にまとめます。その資料をもとに、.NET MAUIの実績と営業・CRM・フィールド業務の理解がある会社へ相談し、要件定義やPoCの見積から比較してください。要件と見積の前提がそろえば、納品後も現場で使われ続けるシステムに近づけられます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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