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

2026年にXamarinのシステムを発注・外注するなら、新規開発をXamarinで進めるのではなく、既存資産の保守、.NET MAUIへの移行、新規の.NET MAUI開発を切り分けて依頼することが重要です。MicrosoftによるXamarin SDKとXamarin.Formsのサポートは2024年5月1日に終了しているため、発注先の「Xamarin対応」という表示だけで判断すると、将来のOS・SDK対応や脆弱性対応まで担保できない可能性があります。

この記事では、営業・CRM・MA連携を含む業務アプリを想定し、発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の比較方法、見積書の読み方を順に解説します。既存Xamarinアプリを短期保守する場合と、.NET MAUIへ移行する場合の判断材料も整理しますので、開発会社へ相談する前の社内準備に活用できます。

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

Xamarinのシステムを発注する前に全体像を整理します

Xamarinのシステム発注前に構成を整理するイメージ

Xamarinのシステムは、スマートフォンやタブレットのアプリだけを指すとは限りません。一般的には、モバイルアプリ、業務API、データベース、管理画面、認証、クラウド、CRM・MA・ERPとの連携、通知や監視までを含む業務システムとして捉える必要があります。発注範囲をアプリ画面だけに限定すると、後から連携や運用費が追加され、予算と納期がずれやすくなります。

アプリ以外に何を発注範囲へ含めるか決めます

最低限、モバイルアプリ、API、データベース、管理画面、認証の5領域を分けて考えます。営業向けであれば、顧客情報、案件ステータス、訪問予定、活動履歴、商品情報、写真添付、承認、プッシュ通知などが候補になります。CRMやMAと連携する場合は、どちらを正とするか、同期の頻度、エラー時の再送、重複データの扱いも決めます。位置情報、カメラ、バーコード、Bluetooth、オフライン入力を使う場合は、OS固有の実装と実機テストも発注範囲に含めます。

既存保守・移行・新規開発を分けて相談します

既存アプリがある場合は、まずXamarin.FormsやXamarin.Android、Xamarin.iOSの種類、対象OS、画面数、利用中のNuGetパッケージ、カスタムレンダラー、ネイティブコード、ローカルDB、プッシュ通知、ストア証明書、CI/CDを一覧化します。そのうえで、短期保守、段階的な.NET MAUI移行、作り直しを比較します。新規案件は、C#・.NET資産を生かせる.NET MAUIを第一候補にしつつ、ネイティブ開発やほかのクロスプラットフォーム技術も要件に応じて比較するのが現実的です。

発注形態はシステムの不確実性と社内体制で選びます

システム開発の発注形態を比較するイメージ

発注形態は、開発会社に一括で任せるかどうかだけで決まりません。要件が固まっているか、社内にプロダクト責任者がいるか、現場の受入テストを誰が行うか、開発後の保守を自社で担えるかによって適した形が変わります。Xamarinのシステムでは、既存資産の診断を先に外注し、その結果をもとに移行や再構築を別契約にする進め方も有効です。

一括請負は要件と成果物を固定できる案件に向きます

一括請負は、要件定義書や基本設計をもとに、決められた成果物を納期までに完成させてもらう形です。画面、API、連携仕様、テスト、導入までの範囲を固定しやすいため、社内の管理負荷を下げやすい点がメリットです。一方で、契約後に「現場で使いにくいので仕様を変えたい」となった場合は、変更管理と追加費用の調整が必要です。業務フローが固まっていない場合は、いきなり本開発を請負にせず、要件定義やPoCを先行させます。

準委任・ラボ型は変化が多い案件に向きます

準委任契約やラボ型開発は、一定期間・一定の体制で開発会社と協力し、優先順位を変えながら機能を作る形です。オフライン同期や現場入力の検証など、実機を触って初めて課題が見える案件に向きます。毎週の意思決定を行えるプロダクトオーナーを発注者側に置き、バックログ、受入条件、稼働時間、成果物、品質基準を合意しておく必要があります。人数を確保するだけで成果が自動的に出るわけではないため、マネジメントの担当者を曖昧にしないことが重要です。

診断・要件定義・開発を分割してリスクを抑えます

判断に迷う場合は、最初に現行資産の診断と要件定義だけを発注し、その成果物を確認してから本開発を決めます。診断では、ビルド環境の再現、依存パッケージの確認、対象OSの整理、ストア公開可否、主要画面の実機確認、移行難所の洗い出しを行います。要件定義では、営業現場の5つのシナリオ、つまりログイン、顧客検索、活動登録、写真添付、オフライン復帰を実際の端末で検証します。この分割は初期契約が増える一方、根拠の薄い一括見積もりを避けやすくなります。

RFPと要件整理では「機能」より業務シナリオを先に書きます

RFPとシステム要件を整理するイメージ

RFPは、開発会社へ提案と見積もりを依頼する資料です。分厚い機能一覧を作ることが目的ではなく、何の業務を、誰が、どの端末で、どのデータを使い、どの状態にしたいのかを同じ条件で伝えることが目的です。要件が曖昧なまま複数社へ声をかけると、各社の前提がばらばらになり、価格だけを比較できなくなります。

現場の一日を業務シナリオとして記述します

「顧客を登録する」だけでは、必要な要件が分かりません。「営業担当が訪問先で電波の弱い場所から顧客を検索し、担当者の変更履歴を確認し、写真を3枚添付して次回訪問日を登録する」のように、利用者、場所、通信状況、入力項目、完了条件を含めて書きます。入力に何秒かかるか、片手操作が必要か、必須項目を後で補完できるか、登録失敗時にデータを失わないかも確認します。NotebookLMの営業・CRM調査で示された、現場の入力負荷と例外を先に把握するという知見を、RFPの中心に置きます。

機能要件・非機能要件・移行条件を分けます

機能要件には、ログイン、多要素認証、顧客・案件・活動履歴の登録と検索、権限別メニュー、ファイル閲覧、通知、承認、オフライン入力などを記載します。非機能要件には、対応OSと端末、同時利用者数、応答時間、稼働時間、バックアップ、監査ログ、障害時の復旧目標、セキュリティ試験、アプリストアの審査対応を記載します。既存システムからデータを移す場合は、移行対象、重複の扱い、文字コード、欠損データ、切替日、旧アプリの停止方法まで分けて整理します。

RFPに成果物と提案依頼事項を明記します

提案を依頼する際は、要件定義書、画面一覧、画面遷移図、API連携一覧、データ項目、権限表、端末一覧、希望スケジュール、予算の考え方、社内の担当範囲を示します。開発会社には、想定体制、工程別の工数、前提条件、除外範囲、リスク、代替案、保守体制、ソースコードと設計書の納品方法を回答してもらいます。Xamarin対応の意味も、既存Xamarinの保守、Xamarinから.NET MAUIへの移行、新規.NET MAUI、バックエンドやCRM連携のどこを指すのか分けて質問します。

契約形態と責任分界を先に合意します

システム開発契約と責任分界を確認するイメージ

システム開発では、契約書の種類だけでなく、どの成果を誰がいつ確認するかが重要です。要件定義、設計、開発、テスト、移行、保守を同じ契約にまとめる場合でも、工程ごとの完了条件と変更手続きを明確にします。特にサポート終了後のXamarinでは、OSやストアの仕様変更に起因する対応を、開発会社の責任か、別途改修か、発注者の判断かに分けておく必要があります。

検収条件と変更管理を契約書に落とし込みます

検収条件は「動作すること」ではなく、画面やAPIごとの受入条件で定義します。たとえば、許可された権限で顧客を検索できること、通信断から復帰したときに重複登録が起きないこと、指定端末で写真を保存できること、エラーメッセージが利用者に分かることなどです。仕様変更は、影響範囲、追加工数、納期、費用、承認者を記録し、口頭だけで進めないようにします。これにより、低い初期見積もりの後に追加費用が膨らむリスクを抑えやすくなります。

ソースコード・データ・アカウントの所有者を決めます

納品物には、ソースコード、設計書、API仕様、テスト仕様書と結果、移行仕様書、CI/CD設定、インフラ構成、運用手順、証明書の管理方法を含めます。リポジトリ、クラウド、アプリストア、ドメイン、監視、通知サービスのアカウントを開発会社だけが保有すると、契約終了時に引き継げなくなる可能性があります。発注者の組織で管理するアカウントを用意し、委託先へ必要な権限だけを付与する方法が安全です。第三者SDKのライセンス、OSSの脆弱性対応、生成物の著作権や利用権も確認します。

保守範囲とSLAを開発契約から分けて確認します

保守契約では、問い合わせ窓口、受付時間、障害の優先度、一次回答時間、復旧目標、OS・SDK更新、ストア審査、脆弱性対応、バックアップ、軽微な改修の扱いを定義します。既存Xamarinの保守を依頼する場合は、Microsoftのサポート終了を理由に対応不可となる条件や、対応可能な対象OSを確認します。.NET MAUIへ移行する場合は、移行後の不具合と新機能追加の優先順位を分けます。保守費用は開発費と別に見積もり、クラウドやMDM、外部サービスの料金も別項目にします。

Xamarinのシステム発注費用は300万円から数千万円まで幅があります

システム開発費用を見積もるイメージ

Xamarin固有の2026年標準価格表はないため、費用は画面数だけで決まりません。アプリ、API、管理画面、CRM・MA連携、権限、オフライン同期、データ移行、端末検証、セキュリティ、保守をどこまで含むかで変わります。以下は、2025年に公開された一般的なモバイルアプリの費用目安と、リサーチノートに整理した業務システムの相場を組み合わせた推定レンジです。個別案件の確定金額ではありません。

規模別の費用レンジを前提条件付きで見ます

技術検証やPoCであれば、ログイン、主要1〜3画面、API接続、実機確認を含めて100万〜300万円程度が一つの目安です。小規模な社内業務アプリで顧客・案件検索、活動登録、通知、簡易管理画面まで含める場合は、300万〜800万円程度が目安になります。CRM・MA連携、権限、オフライン同期、履歴、管理画面、総合テストまで含む中規模案件は、800万〜1,500万円程度を見込みます。複数拠点、基幹連携、MDM、監査ログ、データ移行、性能試験まで含む案件は、1,500万〜5,000万円以上になる可能性があります。

一般的なモバイルアプリについて、GMOおみせアプリが2025年に公開した目安では、簡易アプリが30万〜100万円、小規模が100万〜300万円、中規模が300万〜800万円、大規模が800万〜2,000万円以上とされています(出典: GMOおみせアプリ、2025年)。業務システムでは、アプリ以外のAPIや権限、連携、運用が加わるため、この数字をそのままXamarinの発注額とせず、必要なバックエンドとテストの分を加えて考えます。

.NET MAUI移行費は既存資産の難しさで変わります

既存Xamarinから.NET MAUIへ移行する場合は、画面数よりも、カスタムレンダラー、サードパーティSDK、プッシュ通知、ローカルDB、認証、ネイティブコード、CI/CD、ストア署名を確認します。軽い数画面の移行で300万〜800万円程度、業務アプリの標準的な移行で800万〜2,000万円程度、40〜50画面級で再設計やデータ移行を含める場合は2,000万円を超える可能性がある、という推定レンジで相談を始めます。自動移行ツールは変換を助けますが、実機での画面差分、SDK差分、データ移行、回帰テストまで自動化するものではありません。

Microsoftの公式サポートポリシーでは、2026年7月時点で.NET 10はLTSとしてアクティブで、サポート終了日は2028年11月14日と示されています(出典: Microsoft「.NET Support Policy」、2026年7月更新)。新規開発や移行では、こうした現行サポート期間を確認し、Xamarinを延命する場合も移行準備の費用と期限を別に見積もります。

保守・クラウド・端末費用を初期費用と分けます

初期開発費だけでなく、運用開始後の費用を見積もります。保守・改修は初期開発費の年10〜20%程度を一つの検討目安にしつつ、実際には問い合わせ量、OS更新、障害対応、機能追加で変動します。クラウドのAPI、データベース、ファイル保管、監視、ログ、通知、MDM、アプリストアのアカウント、検証端末、外部SDKの料金は別項目にします。JMASの過去のXamarin・Azure資料には、プロトタイプ120万円以上、アプリ開発90万円以上、Azure環境構築30万円以上、アプリ保守月6万円以上、Azure月額2万円以上という価格例がありますが、過去資料の事例であり、2026年の見積もりとして断定しません。

委託先はXamarin対応の一言ではなく対応領域で選びます

システム開発会社を比較するイメージ

2026年の委託先選定では、過去のXamarin実績だけでなく、現行OSに対応できるか、.NET MAUIへの移行を実機で経験しているか、バックエンドやCRM・MA連携まで設計できるかを確認します。歴史的なXamarin実績は技術の蓄積を示しますが、現在もXamarinの新規開発を推奨しているとは限りません。候補会社には、既存保守、移行、新規.NET MAUIのどれを提案するのかを明確にしてもらいます。

技術力は実機・連携・保守の証拠で確認します

提案時には、対象OSと端末の一覧、主要な画面の実機デモ、通信断からの復帰、カメラやBluetoothなどOS固有機能、APIエラー時の挙動を確認します。バックエンドでは、認証、権限、データ同期、監査ログ、CRM・MA連携のエラー処理を質問します。さらに、アプリストア審査、証明書更新、第三者SDKの脆弱性対応、障害時のログ調査を誰が担うかを確認します。公開事例の画面数や会社規模より、今回の業務シナリオに近い証拠があるかを重視します。

体制とコミュニケーションの実効性を見ます

見積書に記載された人数だけでなく、要件定義の責任者、アプリ担当、API担当、インフラ担当、テスト担当、保守窓口が誰かを確認します。海外拠点やオフショアを利用する場合は、日本語での要件定義、時差、品質管理、データの保管場所、再委託、障害時のエスカレーションを確認します。候補会社の担当者と、現場利用者、情報システム部門、データ管理者が同席する短いワークショップを行うと、会議での理解力や質問の質も比較できます。

見積比較は合計金額より前提と除外範囲を確認します

複数社の見積もりは、要件定義、設計、アプリ実装、API・管理画面、連携、データ移行、テスト、導入、保守に分けて横並びにします。最安値の会社が、管理画面や受入テスト、ストア申請、障害対応を除外していないかを確認します。逆に、高い見積もりでも、実機検証、性能試験、運用設計、移行リハーサルまで含まれていれば、総額では合理的な場合があります。工数、単価、期間、体制、前提条件、除外項目、追加費用の条件を一枚にまとめて比較します。

価格差が大きい場合は、単価の差より「機能の解釈」「品質基準」「発注者側の作業」が違っている可能性があります。たとえば、顧客マスタのクレンジングを発注者が行う見積もりと、委託先が行う見積もりでは、同じ画面数でも費用は一致しません。見積比較の前に、同じ業務シナリオ、同じ端末、同じ対象データ、同じ受入条件を渡し、差分の理由を説明してもらいます。

発注後は小さく検証してから本開発へ進みます

システム開発を段階的に進めるイメージ

発注した後も、開発会社へ丸投げしてはいけません。発注者は業務上の優先順位、利用者の代表、データの正しさ、受入判断を担います。委託先は技術設計、実装、テスト、課題管理を担います。両者の役割を分けたうえで、短いサイクルで実機を確認し、利用者の意見を仕様へ反映します。

MVPで現場の入力負荷と同期を検証します

最初からAI予測や複雑な分析機能を盛り込まず、ログイン、顧客検索、活動登録、写真添付、オフライン復帰の5シナリオをMVPで検証します。営業担当に実際の端末を渡し、入力時間、必須項目の多さ、電波が戻った後の同期、重複登録、写真の容量、エラー表示を確認します。利用者が毎日使えることを確かめてから、通知、承認、分析、CRM・MA連携を広げます。マスタの表記揺れや重複を直さずにAI機能を追加しても、誤ったデータを増やすだけになりやすいです。

テスト・ストア公開・教育を納品工程に含めます

テストは開発会社の機能テストだけで終えず、実機、OSの組み合わせ、通信状態、権限、データ量、端末紛失、アップデート、復旧を確認します。既存アプリからの移行では、主要業務が旧版と同じ結果になる回帰テストを行います。アプリストアの申請情報、証明書、プライバシー表示、利用規約、問い合わせ窓口も準備します。リリース後は、利用者向けマニュアル、管理者教育、問い合わせの分類、ログの見方、障害時の連絡順を引き継ぎます。

認証・権限・端末紛失を非機能要件にします

顧客情報や営業履歴を扱うアプリでは、最小権限、多要素認証、通信の暗号化、監査ログ、端末紛失時のアカウント失効、バックアップ、委託先管理を要件化します。認証はOAuth 2.0、OpenID Connect、Microsoft Entra IDなどを検討し、アクセストークンをアプリへ平文で保存しない設計にします。.NET MAUIのSecureStorageは、AndroidではKeyStoreを使い、iOSではKeychainを使って値を保護しますが、Androidのバックアップ復元やiCloud Keychainの同期など、プラットフォーム差分も確認が必要です(出典: Microsoft Learn「Secure storage – .NET MAUI」、2026年3月更新)。

モバイルアプリの検証項目には、OWASP MASVSをチェックリストとして使えます。MASVSはストレージ、暗号、認証・認可、ネットワーク、プラットフォーム連携、コード品質、耐タンパー性、プライバシーを対象にしています(出典: OWASP Mobile Application Security Verification Standard、2026年確認)。開発会社へは、どの項目を対象とし、どのテスト結果を納品するかをRFPと契約書に記載します。

よくある質問(FAQ)

Xamarinのシステム発注に関するよくある質問のイメージ

Xamarinのシステムを発注するときは、技術選定だけでなく、既存資産、現場業務、契約、費用、保守を同時に確認する必要があります。ここでは、相談時に特に質問されやすい点をまとめます。

2026年にXamarinで新規システムを開発しても問題ありませんか?

原則として、新規開発はXamarinではなく、後継の.NET MAUIを中心に比較することをおすすめします。MicrosoftのXamarinサポートは2024年5月1日に終了しているため、Xamarinで新規に作る場合は、将来のOS・SDK対応、脆弱性対応、ストア審査対応を自社と委託先で引き受ける必要があります。既存資産の短期保守など、Xamarinを残す合理的な理由がある場合は、移行時期と予算を同時に決めます。

Xamarinの業務アプリ開発費用はいくらですか?

技術検証は100万〜300万円程度、小規模な社内業務アプリは300万〜800万円程度、CRM・MA連携を含む中規模案件は800万〜1,500万円程度、複数拠点や基幹連携を含む大規模案件は1,500万〜5,000万円以上が一つの推定レンジです。ただし、Xamarin固有の標準価格ではなく、アプリ、API、管理画面、連携、移行、テストを含む範囲で変動します。見積もりでは初期費用と保守・クラウド・端末のランニング費用を分けて確認します。

開発会社へ見積もりを依頼するとき何を渡せばよいですか?

業務シナリオ、利用者と権限、対象端末とOS、画面一覧、連携先、データ量、オフライン要件、希望時期、予算の考え方、社内で担える作業を渡します。既存アプリがあれば、ソースコード、ビルド手順、依存パッケージ、ストア情報、障害履歴も提示します。開発会社には、Xamarin保守、.NET MAUI移行、新規.NET MAUI、バックエンド、CRM・MA連携のどこまでが提案範囲か、除外範囲と保守条件を分けて回答してもらいます。

既存Xamarinアプリは移行と作り直しのどちらがよいですか?

画面数だけで決めず、依存パッケージ、カスタムレンダラー、ネイティブコード、ローカルDB、認証、通知、データ移行、テスト資産を診断して判断します。共通化された画面と業務ロジックが多く、現行業務を維持したい場合は移行が候補になります。技術的負債が大きい、業務自体を変える、OS固有機能を大きく追加する場合は、要件を整理して.NET MAUIやネイティブで作り直す方が長期的に安全な場合があります。まず診断と主要シナリオのPoCを発注します。

まとめ

Xamarinのシステム発注を成功させるまとめのイメージ

Xamarinのシステムを発注・外注するときは、まず「既存Xamarinの保守」「.NET MAUIへの移行」「新規.NET MAUI開発」のどれを相談しているのかを明確にします。Xamarinのサポート終了後は、対応会社の実績年だけでなく、現行OS・SDK、実機検証、バックエンド、CRM・MA連携、セキュリティ、保守を含めて判断することが重要です。

発注形態は、要件が固まっている部分を請負にし、変化が多い部分を準委任や段階発注に分けると整理しやすくなります。RFPでは機能一覧だけでなく、現場の業務シナリオ、通信断、写真添付、権限、データ同期、移行条件、成果物を記載します。見積比較では合計金額だけでなく、前提、除外、受入条件、保守とランニング費用を横並びにし、納品後も自社で運用できる契約と体制を選びます。

最初から本番規模を一括発注せず、診断やPoCで主要シナリオを実機検証することが、費用と納期の不確実性を下げる近道です。社内の利用者と開発会社が同じ業務課題を見ながら、必要な機能と不要な機能を決めることで、使われ続けるシステムへ近づけます。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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