MVVMのシステム開発の完全ガイド - ブログ

MVVMのシステムは、端末や画面の状態、業務ルールの複雑さで、構成と開発範囲が変わります。要件に合った設計にしておくと、保守と改修で役立ちます。

MVVMは製品名ではなく、アプリケーションの設計パターンです。仕組み、開発の進め方、費用、会社選びを順に見ていきます。各テーマの詳細は関連記事でも確認できます。

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

MVVMのシステムの仕組み

役割を層ごとに分けると、画面変更の影響範囲を整理できます。

MVVMのシステムは、画面表示、画面状態の管理、データや業務ルールを分けて構築します。

画面の変更が多い場合、複数の端末に展開する場合、テストや内製化を重視する場合に向いています。

Model・View・ViewModelの役割

MVVMでは、画面、画面状態、データと業務ルールの担当を分けます。担当が分かれていると、どこを直すとどこに影響するかを追えます。

Model：データと、計算や判定といった業務ルールを受け持ちます。
View：入力欄、一覧、ボタンなど、利用者が目にする画面です。
ViewModel：データを画面向けに整え、検索や保存をCommandで受けて、状態を管理する役です。

実務では、Repository、Use Case、APIクライアント、DBアクセスなどにも層を分けます。

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

品質を保つには、責務を定める設計方針に、テスト、認証、監視、運用ルールを組み合わせる必要があります。分離だけで品質が決まるわけではないためです。

MVVMのメリットと注意点

MVVMの利点と注意点は、変更の範囲と責務の置き方にかかわります。

画面変更：画面を変えても、業務ロジックへの影響が広がりにくいです。
テスト・再利用：ViewModelを単体でテストでき、ModelやAPIを別の画面でも使い回せます。
責務の分離：ViewModelが大きくなりすぎるのを避け、画面状態と操作の調整を受け持たせます。

たとえば在庫一覧をデスクトップからタブレットへ変えても、在庫引当条件や権限判定をModelに保てば、業務ルールを作り直さずに済みます。

重要な業務ルールをUse Caseなどへ移す基準は、採用時に決めておきます。

画面ごとに担当を分けやすいことも、チーム開発の利点です。

ポイント

画面の変更が多いか、複数の端末に広げるかが、MVVMを選ぶ目安になります。役割の分け方とメリット・注意点もあわせて見て、採否を決めます。

MVVMのシステムの種類

MVVM自体には製品の種類がありません。そのため、端末、UIフレームワーク、バックエンドとの接続方法から構成を整理します。

業務システムでは、利用する端末に応じて、次のような構成が候補になります。

Windows業務端末：高機能なクライアントを組みます。
Android・iOS：現場で使うモバイルアプリです。
クロスプラットフォーム：複数OS向けに、共通のコードを活用する構成です。

Windows業務端末とWPF・.NET

Windows端末では、業務要件と将来の端末展開に応じて技術を選びます。

技術候補：複雑な入力や帳票、機器連携があるなら、C#、WPF、XAML、.NETが候補です。
画面状態：WPFはデータバインディングやテンプレートを使い、入力・検索・保存中や通信エラーをViewModelで管理できます。
段階移行：既存アプリを、受注登録や在庫照会など画面単位で段階的に移せます。

技術の選び方は、Windowsだけでよいのか、将来タブレットやスマートフォンへ広げるのかで変わります。

専用機器のドライバー、オフライン運用、社内ネットワーク、印刷環境も、あわせて確かめます。

UIフレームワークを比べる表より先に、利用端末と周辺機器を早めに確認します。

UIフレームワークの比較表だけでは判断できないため、PoCで操作感と通信状態を検証します。

Android・iOSのモバイルアプリ

現場点検、配送、営業、保守、店舗業務などのモバイルアプリにもMVVMを適用できます。

Android：Kotlinで書き、Jetpack ViewModelとStateFlowで状態を扱います。画面はJetpack ComposeかXMLです。
iOS：Swiftで書き、画面はSwiftUIかUIKitで組みます。
端末機能：写真、位置情報、プッシュ通知、バーコード、通信断時の一時保存を扱う層を、別に設計します。

Android公式でも、ViewModelで画面単位のUI状態を管理する考え方と、一方向のデータフローが示されています（出典: Android Developers「UI layer」、2026年確認）。この考え方はMVVMと相性がよく、Loading、Empty、Error、Retry、保存完了などの状態を明示できます。

ViewModelにContextなど、画面のライフサイクルへ強く依存する処理を持たせると、テストやメモリ管理で問題が起きることがあります。

.NET MAUIなどのクロスプラットフォーム

複数OSに対応できるという理由だけで、クロスプラットフォームを選ぶのは避けます。

技術候補：.NET MAUI、Flutter、React Nativeなどを比較の対象にします。
共通化：ModelやViewModelを、OSをまたいで共有できます。
個別実装：端末固有のUIや通知、Bluetooth、カメラ、バックグラウンド処理を、OSごとに作る場合があります。

共通化する処理と、OSごとに作る処理は、分けて考えます。

Microsoft Learnの企業向け資料も、UI、表示ロジック、エンティティの分離と、個別の開発・テストを扱っています（出典: Microsoft Learn「Introduction to .NET MAUI」、2026年確認）。

将来のOSアップデートや人材の採用も考慮し、5年程度の運用を想定して選びます。

ポイント

利用する端末がWindowsか、スマートフォンか、複数OSかで、構成の候補が変わります。端末を先に決めると、技術の候補を絞り込めます。

MVVMのシステム開発の進め方

MVPで代表業務を確かめてから、設計と実装へつなげます。

開発では、業務目的と画面状態を明らかにしてから設計します。

正常系だけでなく、権限不足、通信断、重複送信、入力途中の離脱、データ競合も洗い出しておくと、後戻りを減らせます。

要件定義とMVPの範囲

まずは、誰が、いつ、どの端末で、どの業務を行うのかを整理します。

現行業務：Excel、紙帳票、既存システム、手作業の例外処理を、今の運用から洗い出します。
優先度とRFP：Must、Should、Nice to haveの優先度を付けたRFP。対象は画面から性能目標までです。
MVP検証：代表業務で、入力時間やエラー率、通信断からの復旧、権限設定を確かめ、MVVMの採否を決めます。

簡易RFPにまとめておくと、複数の見積もりを比べやすくなります。また、MVPでは全社の機能を一度に搭載せず、在庫照会と入出庫登録だけを先に作る例もあります。

画面の状態が単純なら別の構成も候補になり、状態の遷移が多く将来横展開するなら、MVVMを検討します。

アーキテクチャと画面状態の設計

設計では、各層の境界と、画面ごとの状態や確認に使う資料を決めます。層の境界には、Repository、Use Case、DB、監視も含め、どこで分けるかを定めます。

層の境界：View、ViewModel、Model、API、認証認可の境目を決めます。
画面状態：初期表示、読み込み、成功、データなしを含め、画面ごとの状態を洗い出します。入力・通信エラーや再試行、保存中・完了、権限不足も対象です。
設計資料：画面・状態遷移図、API仕様、権限表、データモデル、エラーコードを、レビューの対象にします。

ViewModelからSQLを直接呼ぶと、テストやデータソースを変える際の負担が増えます。このため、この形は避けます。

デザインだけを先に確定すると、業務例外が後から加わったときに、画面とViewModelを作り直すことがあります。そこで、利用者の操作と業務ルールを同じレビューで扱い、設計書とテスト観点をつなげます。

実装・テスト・移行・リリース

実装から納品までは、共通機能、テスト、移行、運用の引き継ぎを、この順に進めます。

実装：共通部品、入力検証、認証、ログ、API連携を用意したうえで、画面ごとにViewとViewModelを作ります。
テスト：ViewModelの単体テストと、実端末に近いUIテストで、動作を確かめます。
移行・納品：データ移行と切り戻しを準備し、設計書、コード、環境、運用手順を渡します。

単体テストでは、検索条件による状態の変化、保存の成功と失敗、再試行、権限エラーを確かめます。

UIテストでは、タップやキーボード、画面の回転、画面サイズ、通信状態、アクセシビリティを見ます。

既存システムからの移行では、データ変換、並行稼働、切り戻し、利用者教育も対象になります。

特に在庫や受注では、夜間の移行、差分の同期、旧画面との整合性、障害時の連絡先を決めておきます。

納品物には、ソースコード、テストコード、設計書、運用手順を含めます。CI/CD設定、Infrastructure as Code、依存ライブラリ一覧も、あわせて渡します。

ポイント

要件定義でMVPの範囲を決め、代表業務で採否を判断してから設計に進みます。状態遷移が多く、将来の横展開を予定するなら、MVVMを検討します。

MVVMのシステム開発費用の相場

画面数や連携範囲が広がる規模ほど、見積もり幅も大きくなります。

MVVMに固有の定価はありません。費用は、画面数、端末数、API・既存システム連携、データ移行で変わります。さらに、セキュリティ、テスト、運用保守の範囲によっても決まります。

2026年版の公開相場では、小規模は100万〜300万円、中規模は500万〜1,000万円、大規模は1,000万円〜数千万円以上です。人月単価は60万〜200万円程度と整理されています（出典: 2026年版「システム開発の費用・相場」公開記事、2026年7月）。これは一般的なシステムの目安で、MVVMだけの料金ではありません。

▶ 詳細はこちら：MVVMのシステム開発の見積相場や費用/コスト/値段について

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

初期費用と期間は、画面数や連携範囲によって変わります。次に挙げる金額は、推定のレンジです。

PoC・MVP：1業務・1OSで画面数が少ない場合、150万〜400万円、1〜3か月程度です。
小規模：5〜15画面なら、300万〜800万円、3〜6か月程度です。
部門利用：15〜40画面で、API・権限・監査ログを含む場合は、800万〜2,000万円、6〜10か月程度です。
全社・複数OS：基幹連携、移行、冗長化を含むと、2,000万円〜1億円以上、10か月〜2年以上の場合があります。

上記は、公開相場とMVVMの設計・テスト作業を組み合わせた推定です。金額は画面数のほか、入力項目、状態遷移、オフライン、外部機器で変わります。同時利用者数や監査要件も、金額に影響します。

見積書では、要件定義、設計、環境構築、実装、テストを分けて示してもらいます。移行、教育、保守も別にし、含まれない作業も確かめます。

費用の内訳とランニングコスト

初期費用と運用費の主な項目を分けて見積もります。

企画・設計：要件定義と企画、画面設計とUX、アーキテクチャ設計、環境構築。
開発・導入：View・ViewModelの実装、API・DB連携、テスト、データ移行、教育。
運用費：クラウド、監視、ログ保管、バックアップ、端末管理、OS・SDK更新。
保守：脆弱性・障害・法改正対応、追加開発を含みます。

MVVMでは、状態設計、共通部品、ViewModelの単体テスト、モックには、先行の工数がかかります。そのため、画面制作だけの見積もりと比べると、フロント側の工数が増える場合があります。一方で、後の変更や回帰テストの負担は抑えられます。

保守費を開発費の年間15〜25%とする見積もりもあります。これは契約範囲による実務上の目安です。

契約書では、24時間・休日対応と復旧時間、問い合わせ窓口を確かめます。保守費を左右するのは、軽微な改修をどこまで含めるかと、役割分担の線引きです。

軽微改修の上限
開発会社と自社の分担

ポイント

費用は画面数、端末数、連携範囲で大きく変わるため、見積もりは規模と含まれる作業をそろえて比べます。初期費用と運用費は、分けて見ます。

MVVMの開発会社・ベンダーの選び方

会社を比べるときは、「MVVMに対応できます」という言葉より、自社の業務、端末、連携、運用に合う設計を説明できるかを確かめます。業務システムでは、UIフレームワークの知識に加えて、認証認可、API、データ移行、監査ログ、障害対応、保守の引き継ぎまで考えられるかが重要です。

実績の確認：MVVMの単語ではなく適用範囲

MVVMというキーワードより、自社に近い条件で、実装と運用の実績があるかを確認します。

適用条件：Windows、Android、iOS、複数OS、既存刷新、外部機器の実績を見ます。
案件範囲：画面数、利用者数、オフライン、認証方式、API連携を、質問の項目に含めます。
運用体制：テスト体制と、リリース後の保守期間です。
テスト実績：ViewModel単体、UI、API結合、負荷、脆弱性診断の範囲を見て、画面実装と運用開発を分けて考えます。

公開されている事例と提案の内容がつながっているかも見ます。また、可能であれば、過去案件の画面遷移図やテスト方針を、匿名化したうえで見せてもらいます。

技術提案とプロジェクト管理の評価

提案では、技術設計、要件の不確実さ、体制と管理方法を確かめます。技術設計では、テスト戦略、CI/CD、監視、移行まで含めて見ます。

技術設計：View・ViewModel・Modelの境界、API・認証方式、状態管理、エラー処理を見ます。
不確実な要件：PoC、追加調査、仕様確定の条件が分かれているかを確かめます。
体制と管理：担当役割、レビュー頻度、課題・変更の管理、意思決定者、リリース判定基準、納品物。

自社の課題を聞く前に特定のフレームワークを勧めてくる場合や、テスト・移行・教育をひとまとめの「一式」とする見積もりには注意します。

体制の役割には、プロジェクトマネージャー、業務担当、UI設計、フロントエンドがあります。さらに、バックエンド、インフラ、テスト担当もあります。

納品物には、設計書、ソース、テストコード、環境定義、依存ライブラリ、運用手順を明記します。

セキュリティと契約・保守の分界

MVVMで画面と業務ロジックを分けても、認証・認可、暗号化、ログ、バックアップ、脆弱性対応は自動では実現しません。

技術対策：認証・認可、暗号化、ログ、バックアップ、脆弱性対応の方針を決めます。
開発時の管理：委託先、サプライチェーン、脆弱性の悪用、生成AIの情報管理を扱います。
権利と納品物：著作権・利用許諾、OSS、ソースコード、テストデータの扱いを決めます。
環境と責任：クラウド、ドメイン、証明書、CI/CDと、障害時にどこまでを誰が受け持つかを明記します。
脆弱性対応：受付、連絡期限、パッチ適用、委託先管理、事故報告までを取り決めておきます。

IPAの「情報セキュリティ10大脅威2026」は、2025年の事故や攻撃の状況をもとに、約250名の専門家や実務担当者による審議と投票で脅威を決めています（出典: IPA「情報セキュリティ10大脅威2026」、2026年）。

経済産業省が2026年3月に公開した、サイバーインフラ事業者向けのガイドラインも参照し、脆弱性受付、連絡期限、パッチ適用、委託先管理、インシデント報告を確認します（出典: 経済産業省「サイバーインフラ事業者に求められる役割等に関するガイドライン」、2026年）。

▶ 詳細はこちら：MVVMのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：MVVMのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：MVVMのシステム開発の発注/外注/依頼/委託方法について

ポイント

MVVMという言葉の有無より、自社に近い実績があるか、設計を説明できるか、保守の分界を契約で示せるかで比べます。判断に迷うときは、過去案件の画面遷移図を見せてもらえるかも目安になります。

よくある質問

MVVMのシステムを検討する際に、よく寄せられる質問とその答えです。採用の前に、自社の画面状態、端末、データ連携、将来の改修、開発体制に当てはめて確かめましょう。

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

MVVMを採用しただけで初期費用が安くなるわけではありません。責務分離、共通化、テストコード整備には、先行の工数が必要です。

画面数だけで短期の見積もりを比べると、高く見える場合があります。一方で、画面変更や複数端末への展開、回帰テスト、内製化を予定するシステムでは、後工程の手戻りを減らし、総保有コストを抑えられる可能性があります。

WebシステムでもMVVMは使えますか？

Webでも、画面、画面状態、データ・業務ロジックを分けるMVVMの考え方を使えます。たとえば、フロントエンドの枠組みや状態管理ライブラリで、ViewとViewModel相当の役割を設けます。

APIやドメイン層は、Model側に整理します。ただし、Webではチームによって、MVVMという名称を厳密には使わない場合もあります。そこで、責務、データフロー、テスト範囲を確かめます。

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

移行はできます。ただ、全画面を一度に置き換えるより、画面単位か業務単位で段階的に移す方法が安全です。

既存の業務ルール、DB、外部機器、帳票、例外処理を調べたうえで、APIやアダプターを挟み、新旧の画面を共存させます。

代表的な画面で、性能、操作性、データの整合性、切り戻しを確かめてから対象を広げると、業務停止のリスクを抑えられます。

ViewModelに業務ロジックを書いてもよいですか？

責務は、処理が画面だけに関わるか、複数の画面で共有されるかで分けます。

画面処理：表示用の状態の変換や、入力操作の調整はViewModelに置けます。
共有する業務ルール：Model、Use Case、ドメイン層などに置きます。

ViewModelに受注金額の計算、在庫引当、権限判定、DBアクセスまで持たせると、再利用や単体テストが難しくなります。

したがって、責務の境界はコードレビューで確かめ、ViewModelの大きさや依存数も続けて見直します。

まとめ

MVVMを採用するかどうかは、技術名だけで決めず、業務の複雑さと将来の変更を基準にします。

ここまでの内容を、発注前に確かめる判断軸と準備項目に絞ります。

MVVMを採用する判断軸

画面状態の複雑さ、将来の端末展開、テスト・内製化の必要性、業務ルールの変更頻度を、判断の基準にします。

単純な入力フォームでは、過剰な設計になることがあります。一方で、複数の状態や権限、非同期処理、オフライン、継続的な改修がある場合は、設計への投資を活かしやすくなります。

最初に整理するべき情報

MVVMは、Model・View・ViewModelに責務を分けて、画面と業務ロジックのつながりを弱める設計パターンです。発注の前には、要件を一覧にしておきます。

業務・利用：対象業務、利用者と権限、画面数、端末、オフライン。
技術・移行：外部API、既存DB、データ移行、必要なテスト。
引き継ぎ・保守：納品物と保守範囲を明らかにします。

情報が揃えば、適用範囲と費用の要因をそろえて、複数の会社を比べられます。MVVMは、画面変更、テスト、複数端末、段階移行に強みがあります。ただし、採用するだけで品質や費用が改善するわけではありません。

まず、現行業務と端末を整理し、MVPで代表的な画面状態を検証します。その後、WPF・.NET、Android・iOS、.NET MAUIなどを比べます。

見積もりは、API、認証、データ移行、テスト、監視、保守を含めて取ります。会社は、自社に近い実績、設計の説明力、テストと納品物、契約と保守の分界で比べます。

▼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を創業。