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

MVVMのシステム開発を外注するときは、まず業務と端末を整理し、要件と契約を固めます。そのうえで、一部を小さく検証してから段階的に開発すると、変更の影響を抑えやすくなります。

発注形態、要件と契約、費用相場、委託先の選定、進行手順の順に見ていきます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

MVVMのシステム開発を外注する前に知っておきたい全体像

発注前に、画面だけを作るのか、業務システム全体を構築するのかを分けておきます。

MVVMでView、ViewModel、Modelを分けても、認証やAPI、DB、クラウド、移行、監視は自動では整いません。

外注の対象は画面だけでなく業務の仕組み全体

画面の見た目だけでなく、顧客・商品・受注・在庫のデータや業務ルールも発注範囲に含めます。

APIや認証認可、帳票などの仕組みも対象になります。通知、監査ログ、バックアップも含めて考えます。

在庫一覧を例にすると、在庫数の定義、同時更新、権限、通信復旧後の再送を先に決めておく必要があります。これらが曖昧なままだと、画面が完成しても業務で使えない場合があります。

MVVMの採用効果の評価（テストと保守まで含む）

Microsoft Learnは、MVVMがUIと業務・表示ロジックを分離し、テスト、保守、再利用をしやすくすると説明しています（出典: Microsoft Learn「Model-View-ViewModel – .NET」、2026年確認）。

ただし、ViewModelに画面処理、業務ルール、DBアクセスを集めて巨大化すると、分離の利点が失われます。そのため、設計とテストの進め方も委託先に確認します。

評価するときは、納品後の活用方法と維持管理の範囲も見ておきます。

• 納品物：設計書、画面遷移図、状態一覧、API仕様、環境設定
• 保守の準備：ソース、ViewModel単体テスト、依存ライブラリ一覧、運用手順

採用効果は、初期費用に加えて、画面追加、OS・SDK更新、障害時の引き継ぎまで含めて判断します。

外注と相性がよい案件・慎重に判断する案件

外注が向くかどうかは、社内人材、画面要件、業務運用の確度で判断します。

• 専門人材が不足：WPF、Kotlin、Swift、.NET MAUIなどの知見を補えます。
• 複雑な画面状態：複数端末への展開も見据え、設計経験とテスト体制を確かめます。
• 業務が未確定：本開発を一括で発注せず、優先順位を整理します。

業務理解と技術設計を並行したい場合や、短期間でMVPを検証したい場合も、外注が候補になります。

代表的な一業務をPoCやMVPとして切り出し、操作性や通信断、権限、データ整合性を試します。そのうえで本開発に進むと、要件変更の影響を抑えやすくなります。

MVVMのシステムを外注する発注形態

標準業務はSaaSやパッケージに寄せ、専用画面や機器連携だけを開発する方法があります。

専用アプリの設計にはMVVMを適用し、スクラッチ開発や段階刷新と組み合わせます。

SaaS・パッケージを使い専用部分だけを外注する方法

標準業務と独自業務の境界を分けると、初期範囲や保守負担を調整しやすくなります。

• 標準業務：会計、勤怠、販売管理などを、SaaSやパッケージで対応します。
• 専用機能：現場入力、専用端末、機器連携、独自承認画面をアプリとして作ります。

専用アプリはMVVMで作り、すべてをスクラッチで作る場合より初期範囲を絞れます。また、標準機能を使う範囲では、保守負担も小さく抑えられます。

パッケージとAPIでつなぐ場合は、連携の頻度、エラー時の再送、マスターの正、認証、API制限をRFPに書いておきます。

カスタマイズ費用と仕様変更のリスクも比べておきます。標準機能に無理に手を加えると、専用開発より高くなる場合があります。

スクラッチ開発で業務に合わせて作る方法

スクラッチ開発では、業務に合わせて一から作るぶん、前提を先に固めておく必要があります。

• 業務上の制約：独自ルール、特殊機器、複雑な入力、オフライン、独自操作。
• 技術構成：対象端末に合わせて選びます。
• 開発範囲：将来の端末と今回の契約対象を分けて決めます。

Windows業務端末ではC#・WPF・XAML・.NETが候補です。

AndroidではKotlin・Jetpack ViewModel・StateFlow、iOSではSwift・SwiftUIなどが候補になります。

スクラッチは自由度が高い反面、要件定義と画面設計を一から決める必要があります。さらに、APIの設計と移行の方法を決めておく必要があります。テストの進め方と運用設計も、あらかじめ決めておきます。

OSが増えるほど、実機テストや配布方法も増えます。

既存システムの画面単位・業務単位の段階移行

既存のWindowsやAndroidアプリを刷新する場合は、受注登録、在庫照会、現場点検など、業務単位で移行するほうが安全です。データ整合性、並行稼働期間、切り戻し、利用者教育も、契約範囲に含めます。

既存DBを使うのか、APIを新設するのか、Modelの業務ルールを再利用するのかを決めます。画面だけを作り直して古い業務ロジックが残ると、MVVMの効果は限られてしまいます。

移行対象と残置対象を図にまとめ、各段階の完了条件を明確にします。

MVVMの外注でRFPと要件を整理する方法

RFPは、同じ条件で提案と見積もりを比べるための基準です。完璧な仕様書までは不要ですが、対象業務、利用者、端末、画面数、連携先を具体化します。さらに、納期、予算上限、納品物、保守条件も書いておきます。

業務要件の書き方（利用者と成果から）

業務要件では、利用者と業務の流れを整理し、画面設計に必要な情報をそろえます。

• 業務フロー：誰が、いつ、どこで何を完了するかを記載します。
• 画面一覧：画面、操作、データ、権限、帳票、通知と状態を整理します。

販売管理では見積・受注・出荷・請求、在庫管理では入庫・引当・出庫・棚卸の流れを示します。

現行のExcelや紙帳票、既存画面、例外処理を並べ、Must、Should、Nice to haveに分けると、MVPの範囲が見えてきます。

入力項目や検索条件、参照・更新データに加えて、承認に応じたボタンの変化、同時編集、途中離脱、通信断、重複送信も示します。そうすると、設計やテストの工数に反映できます。

RFPに含める非機能要件と画面状態

RFPには、性能・運用・安全性や現場利用の条件も含めて書き、提案の範囲をそろえます。

• 性能・運用：利用者数、同時接続数、応答・稼働時間、バックアップ、復旧目標。
• 端末・安全性：OS、画面サイズ、オフライン、アクセシビリティ、ログ保存期間、暗号化、脆弱性。
• 画面状態：初期表示、読込、成功、データなし、入力・通信エラー、再試行、保存、権限不足。

現場アプリでは、電波の弱い場所や端末の紛失、バッテリーの低下、カメラ、バーコードリーダーも確認します。

Android公式は、ViewModelが画面単位のUI状態を管理し、UIイベントを受けて状態を更新する一方向データフローを説明しています（出典: Android Developers「UI layer」、2026年確認）。

画面の状態を明記しておくと、正常画面だけの提案と、異常系まで含む提案を区別できます。

納品物と受け入れ基準の決め方

納品範囲と受け入れ基準を先に定め、実行ファイル以外に必要な資料も確認します。

• 設計・品質資料：ソース、設計書、画面遷移図、API仕様、データモデル、テスト仕様と結果。
• 開発・運用資料：CI/CD、IaC、環境変数、OSS・ライセンス、操作・障害・バックアップ復旧手順。
• 受け入れ基準：権限、二重登録防止、応答時間、主要ViewModelの単体テストなど。

受け入れ基準は、合否を判定できる形で書きます。たとえば、権限のない利用者は登録できないことを基準にします。基準が曖昧なままだと、納品時に認識のずれが生じやすくなります。

MVVMのシステム外注で選ぶ契約形態と責任分担

要件が固まった工程では請負を、要件整理やアジャイル開発では委任・準委任を使う方法があります。要件定義と設計は準委任、開発とテストは請負、保守は別契約にする形もあります。契約名だけで決めず、成果物、作業範囲、検収、変更手続き、責任範囲を確かめます。

請負と準委任の使い分け

要件の確度と開発中の変更可能性を見て、工程ごとの契約を選びます。

• 請負：成果物を完成・検収する契約で、要件が固まった開発に向きます。
• 準委任：作業や技術支援を受け、優先順位を調整しながら進める工程に合います。

請負では、画面一覧、API、端末、テスト範囲が固まると、納期と成果物をまとめて管理しやすくなります。

業務ルールの変更が多いと、請負では変更のたびに追加契約を結ぶ調整が重くなります。PoC、要件定義、レガシー調査、アジャイル開発では、準委任も候補になります。

準委任は、時間の投入だけで成果を保証する契約ではありません。そのため、週次レビュー、スプリント成果、品質基準、課題管理、終了条件を定めておきます。

知的財産権・再委託・ソースコードの扱い

契約では、資産の利用権と再委託時の管理条件を文章で明確にします。

• 成果物の権利：ソース、テスト、設計書、CI/CD、インフラ定義、移行スクリプト。
• 既存資産：共通ライブラリ、OSS、外部サービスの利用条件。
• 再委託：委託先、個人データ、秘密保持、脆弱性、事故報告、監査権限を定めます。

自社や別の会社でも改修できるように、成果物の利用権と引き渡し条件を契約に明記します。

個人情報保護委員会のガイドラインは、再委託先や取扱方法の事前報告・承認と定期監査を望ましいとしています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

契約に入れるセキュリティと保守の責任分界

管理対象ごとに、担当者と運用時の対応範囲を責任分界表にまとめます。

• 管理対象：認証基盤、クラウド、端末、アプリ、API、DB、監視。
• 運用対応：脆弱性、緊急パッチ、OS・SDK更新、ログ保管、バックアップ。
• 障害対応：一次対応、復旧目標、休日対応の担当を決めます。

IPA「情報セキュリティ10大脅威 2026」の組織向け2位は「サプライチェーンや委託先を狙った攻撃」です（出典: IPA「情報セキュリティ10大脅威 2026」、2026年）。そこで、委託先を含めた状況の把握と責任範囲の明確化が欠かせません。

2026年3月に経済産業省などが公表したサイバーインフラ事業者向けガイドラインも踏まえ、開発コード、依存ライブラリ、クラウドへのアクセスを管理します。

MVVMのシステム開発を外注する費用相場と見積もりの内訳

MVVMそのものに利用料や公定価格はありません。費用は、要件定義、画面設計、ViewModel・Modelの工数を中心に、次の工程の工数を積み上げて決まります。

• API・DB連携：画面と業務データをつなぐ作業にかかる工数
• テスト：ViewModel単体からUIまでの確認にかかる工数
• 移行：既存のデータや業務を移す作業にかかる工数
• クラウド：クラウド環境の構築や利用にかかる工数
• 保守の工数：開発後の修正や対応にかかる工数

2026年公開の一般的な相場は、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上です。

人月単価は60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場」、2026年）。

規模別に見た初期費用と期間の目安

初期費用と期間は、画面数や対象業務、運用要件によって変わります。次に示すのは、規模別の推定レンジです。

• PoC・MVP：1業務・1OSなら150万〜400万円、1〜3か月程度。
• 小規模：5〜15画面なら300万〜800万円、3〜6か月程度。
• 部門利用：15〜40画面なら800万〜2,000万円、6〜10か月程度。
• 全社・複数OS：2,000万円〜1億円以上、10か月〜2年以上の場合があります。

PoC・MVPの場合は、ログイン、主要な登録・検索、簡単な一覧、APIモック、代表的なViewModel単体テストを想定します。実データの移行や本番運用は含みません。

小規模でも、権限、入力検証、CSV、帳票、外部API、異常系テストが増えると、金額は上限側に寄ります。

部門利用の目安は、既存連携や監査ログを含む場合です。

全社利用の範囲には、基幹連携、データ移行、冗長化、厳しいSLAが含まれる場合があります。

この金額は、MVVMの採用料金ではなく、業務や非機能要件を含むシステム全体の幅です。同じ画面数でも、状態の複雑さや連携の難易度によって変わります。

見積書の工程別・成果物別の費用確認

見積書では、工程と成果物ごとの内訳を確認し、一式表記になっている作業範囲も明らかにします。

• 工程：企画・要件定義、基本設計、画面・詳細設計、View・ViewModel、Model・API・DB。
• 後工程：テスト、移行、リリース支援の範囲と成果物。
• 配分目安：要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%。

「開発一式」や「テスト一式」と書かれている場合は、画面数、ケース数、人日を尋ねます。

あわせて、状態設計、Repository・Use Caseの分離、モック単体、実機UIテストも確かめます。

この比率は固定の正解ではありません。そのため、案件に応じた配分の理由を、提案会社に説明してもらいます。

開発後の保守・クラウド費用の別枠確認

初期開発費とは分けて、開発後にかかる費用も見積もっておきます。

• 運用費：サーバー・DB・ログ監視、外部API、認証、端末、配布、バックアップ、診断。
• 保守費：開発費の年間15〜25%程度が目安ですが、条件によって変わります。
• 引き継ぎ：自社運用なら支援期間と技術支援単価も含めます。

OS・SDKの更新、障害対応、改修費も発生します。これらは、対応時間や対象範囲、SLA、追加開発の単価によって変わるため、割合だけで決めることはできません。

初期費用が安い会社が有利とは限りません。初年度の費用と3〜5年程度の運用費を分けて比べます。

テスト、移行、監視、文書、教育が別料金になる場合もあります。

MVVMの委託先を選び見積もりを比較するポイント

委託先は、業務や端末に近い実績、設計の説明、テストと保守の体制で選びます。

候補を3〜5社程度に絞ったうえで、同じRFPをもとに、提案範囲、前提、除外事項、体制、日程、費用を比べます。

公開実績の確認範囲（対象OS・業務・連携）

Windows、Android、iOS、クロスプラットフォームのうち、どれに対応してきたかを確認します。

加えて、販売・在庫・受発注の理解と、APIの担当経験も尋ねます。ほかに、次の担当経験も確かめます。

• クラウドの担当経験：クラウド環境の設計や運用に関わった実績があるか
• 認証の担当経験：ログインや権限の仕組みを作った実績があるか
• 機器の担当経験：専用端末や周辺機器と連携した実績があるか
• オフラインの担当経験：通信が切れても業務を続けられる仕組みを作った実績があるか
• 移行の担当経験：既存システムから新しいシステムへ切り替えた実績があるか

公開実績が自社の案件と異なる場合は、設計をそのまま適用できるとは限りません。そこで、ViewModelの責務、Repository・Use Caseの分離、状態管理、単体テスト、レビュー方法を聞いておきます。また、技術用語だけでなく、実際の画面や業務フローに置き換えて説明できるかも判断材料になります。

前提条件をそろえた見積もりの比較

各社の前提条件をそろえておくと、見積金額の差が生じた理由を比べやすくなります。

• 比較軸：画面数、利用者数、OS、外部連携数、移行、テスト、納品物、保守期間、クラウド、ライセンス、交通費、消費税。
• 価格差：差が大きい場合は、要件の不足や不要な作業があるかを確かめます。
• 前提・除外事項：API提供、発注者側の移行・端末準備、ストア申請対象外など。見落とすと追加費用が発生します。

質問への回答が、提案書や見積書に反映されているかも確かめます。

技術選定とPoCによる小さな検証

技術選定では、業務条件を比べたうえで、不確実性の高い部分をPoCで確かめます。

• 選定条件：端末、人材、機器、性能、オフライン、将来のOS更新。
• PoCの対象：ログイン、一覧、登録、通信エラー、再試行、権限違い。
• 確認成果：実機操作、性能、状態遷移、テスト、残課題、量産時の見積条件。

候補には、WPF、Android、iOS、.NET MAUI、Flutter、React Nativeなどがあります。共通コードだけで決めず、採用理由を提案書に書いてもらいます。

カメラ、Bluetooth、通知、バックグラウンド処理では、個別実装が増える場合があります。PoCを本開発の成果物と混同せず、本開発へ移行する判断基準を定めておきます。

MVVMの発注からリリースまでを失敗なく進める手順

発注者側にも、業務の意思決定者とレビュー担当を置いておきます。画面の状態や権限、業務ルール、例外処理には、現場の判断が欠かせません。

定例会議と変更管理のルール

定例会議、課題管理、仕様変更の記録方法を決めて、納期と品質を一緒に管理します。

• 週次会議：画面数だけでなく、未決要件、状態遷移、テスト、障害、リスク、次週の判断事項を共有。
• 課題管理：担当者、期限、影響、対応方針を記録し、口頭要望を機能追加にしません。
• 変更承認：内容、理由、費用、納期、テスト影響、契約上の扱いを記録。

仕様変更は、納期と品質を見ながら優先度を調整します。たとえば、低優先の画面を後ろ倒しにして、異常系の品質を守る判断もあります。

MVVMの方針を変える場合は、将来の保守とテストへの影響も確かめます。

完了条件に含めるテスト・移行・引き継ぎ

完了条件には、品質確認、リリース準備、引き継ぎの各工程を含めます。

1. ViewModel単体、API結合、UIのテストを行います。
2. 通信復旧後の再送、端末紛失、アカウント停止を試験し、移行リハーサル、バックアップ復旧、監視、問い合わせ窓口、教育、切り戻しを確認します。
3. 環境構築、テスト、障害調査、リリース手順を発注者が再現できる状態で引き継ぎます。

権限、性能、セキュリティのテストも含めます。画面の状態では、Loading、Empty、Errorの各状態を確認します。さらに、再試行や保存中、二重送信の状態と、タイムアウト時の動作も確かめます。

引き継ぎでは、ソースと設計書もあわせて渡します。

AI生成コードとOSSの確認担当

契約時に、AI支援ツールやOSSの利用条件、レビュー担当、保守時の管理者を決めておきます。

• AI利用：可否、機密情報、生成コードレビュー、ライセンス、脆弱性、テスト責任。
• OSS・外部ライブラリ：名称、版、ライセンス、脆弱性、更新担当、利用終了時の影響。

2026年時点では、AI支援ツールでコードやテストの案を作る開発も想定されます。ただし、AIを使うだけで納期や費用が自動的に下がるとは限らず、レビューと受け入れの工数が必要になります。

利用しているツールを発注者が把握できていないと、保守会社の変更やOS更新時に、調査費用が生じやすくなります。

よくある質問（FAQ）

費用、契約、納品物、保守の範囲など、発注前によくある疑問に回答します。

MVVMを採用すると開発費用は必ず高くなりますか？

必ず高くなるとは限りません。ただし、初期工程では、責務の分割や画面状態の設計、テストコードの作成に工数が必要です。

画面数が多く、将来の改修や複数端末への展開がある案件では、変更の影響を抑えやすくなります。そのうえで、保守を含む総費用で判断します。

MVVMの外注は請負契約と準委任契約のどちらがよいですか？

要件と成果物が固まった開発・テストは請負、要件定義やPoC、優先順位を変えながら進める開発は準委任が候補です。

工程ごとに契約を分ける方法もあります。その場合も、契約名よりも、成果物、検収、作業範囲、変更手続き、責任分界を確かめることが大切です。

MVVMに対応できる開発会社は何を基準に選べばよいですか？

技術名だけでなく、自社に近い業務、端末、連携、オフライン要件での経験を確かめます。あわせて、設計、テスト、保守を具体的に説明できる会社が候補になります。

ソースや設計書の引き渡し、再委託の条件を確かめ、同じRFPで比べられる見積もりを受け取ります。

既存のMVCやレガシーアプリをMVVMへ移行できますか？

移行は可能ですが、全部を一度に置き換えるより、業務や画面単位で段階的に移行するほうが安全です。そのため、既存DB、機器、業務ルール、並行稼働、移行、切り戻しを調査します。

Viewだけでなく、ViewModel、Model、APIの責務をどこまで整理するかを決めます。代表的な業務でPoCを行うと、難易度と費用を把握できます。

まとめ

MVVMの発注は、業務、端末、画面状態、成果物を整理してから始めます。技術名だけで委託先を選ばず、標準業務をSaaSやパッケージでまかなう案と、専用開発や既存システムの段階移行を比べます。

RFP・契約・納品物のそろえ方

RFPには、業務フロー、画面、状態遷移、端末、API、移行を記載します。さらに、非機能要件、テスト、納品物、保守も盛り込みます。

契約では、検収、変更管理、知的財産権、再委託、セキュリティ、責任分界を定めます。見積もりは、工程、成果物、前提、除外事項をそろえたうえで、初期費用と運用費を分けます。

設計・テスト・保守を一体で考えるMVVMの効果

MVVMは品質を自動的に保証するものではありませんが、画面表示、状態、業務ルール、データアクセスを整理し、テストと変更管理を行うための土台になります。

発注者の業務知識と委託先の設計・開発力を組み合わせ、PoCや段階移行で不確実性を減らしていくと、長く使えるシステムにつながります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【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を創業。