MVVMのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

MVVMのシステム開発は、画面表示・画面状態・データや業務ルールを分離し、変更しやすくテストしやすい業務アプリを段階的に作る進め方が重要です。

販売管理、在庫管理、現場点検、顧客管理などでMVVMを採用する場合、技術用語だけを先に決めてもプロジェクトは成功しません。この記事では、MVVMのシステム開発を検討している担当者に向けて、全体像、6つのフェーズ、費用相場、見積書の確認ポイント、稼働後の定着方法までを、実務で使える判断基準とチェック項目に沿って解説します。

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

MVVMのシステム開発の全体像

MVVMは製品名や業務パッケージの名称ではなく、Model・View・ViewModelに責務を分けるアプリケーション設計パターンです。したがって「MVVMを導入すれば自動的に高品質になる」と考えるのではなく、画面状態が複雑な業務を、どの範囲まで分離して管理すると将来の変更やテストに効果があるかを判断する必要があります。

Modelは顧客、商品、受注、在庫などのデータと業務ルール、APIやデータベースへのアクセスを担当します。実務ではViewModelからデータベースへ直接接続せず、RepositoryやUse Caseなどの層を挟むと、データ取得先の変更や単体テストがしやすくなります。ViewはWPFのXAML、AndroidのComposeやXML、iOSのSwiftUIやUIKitなど、見た目と入力部品を担当します。ViewModelは画面に表示する状態を整形し、検索、保存、承認といった操作をCommandやイベントとして受け取ります。

たとえば在庫登録画面なら、Viewは商品コードや数量の入力欄を表示し、ViewModelは「読み込み中」「入力エラー」「保存可能」「保存失敗」といった状態を管理します。Model側は在庫数の整合性、更新者、更新日時、同時更新の扱いを判断します。この分担を設計書に明記すると、画面担当者が業務ルールを独自実装したり、ViewModelが巨大化したりするリスクを抑えられます。

MVVMと相性がよいのは、入力、検索、一覧、承認、同期、エラー表示など、画面の状態変化が多い業務アプリです。販売管理や在庫管理のように、利用者の権限によって表示や操作可否が変わるシステム、またはWindows端末とモバイル端末へ段階展開するシステムでは、画面と状態を分ける効果が出やすくなります。Microsoft LearnもMVVMをデータバインディング、プロパティ変更通知、コマンドと組み合わせる設計として説明しており、画面と非UIコードの疎結合が主な狙いです（出典: Microsoft Learn「Model-View-ViewModel – .NET」、2026年確認）。

一方、画面が数枚しかない短期の試作や、表示するだけの単純な管理画面では、MVVMのための抽象化がかえって負担になる場合があります。また、ViewModelへSQL、認証、複雑な計算、画面遷移をすべて詰め込むと、名前だけMVVMで中身は密結合という状態になります。採用可否は流行ではなく、画面数、状態の種類、将来の改修頻度、複数OS対応、テストや内製化の必要性で決めます。

MVVMのシステム開発はどのように進めますか？

MVVMのシステム開発は、要件整理、技術・製品選定、設計開発、テスト、稼働、定着の6フェーズで進めると、技術選定が先行して業務課題から離れることを防げます。各フェーズの終了条件を「資料ができた」ではなく「次の判断に必要な不確実性が減った」と定義することがポイントです。

最初に現行のExcel、紙帳票、メール、既存システム、例外処理を集め、誰が、いつ、何を入力し、どのデータを正とするかを確認します。要望をそのまま画面一覧に変換せず、業務上の目的、利用者、権限、入力項目、出力、連携先、保存期間、失敗時の復旧方法まで整理します。Must、Should、Nice to haveに分け、最初のMVPでは代表業務を1つか2つに絞ると、MVVMの状態設計を早い段階で検証できます。

要件整理のチェック項目は、画面数と画面ごとの状態数、同時利用者数、端末とOS、オフラインの有無、外部API、認証方式、権限、監査ログ、データ移行、障害時の運用です。特に「保存ボタンを押した後に通信が切れた場合」「承認中に別の人が更新した場合」「権限が途中で変わった場合」を業務担当者と確認します。この結果を画面遷移図、状態一覧、業務ルール一覧、非機能要件、受入条件に落とし込むと、後の見積もりが安定します。

Windows専用の高機能な業務端末なら、C#、WPF、XAML、.NETが候補になります。WPFはデータバインディング、入力検証、並べ替え、フィルタリングなどを備えるため、キーボード操作や大量一覧を扱う業務に向きます。AndroidならKotlin、Jetpack ViewModel、StateFlow、ComposeまたはXML、iOSならSwift、SwiftUIまたはUIKitを比較します。複数OSを一体運用する場合は.NET MAUI、Flutter、React Nativeも候補ですが、バーコード、カメラ、Bluetooth、プリンター、オフライン同期など端末固有機能の検証を先に行います。

Android公式は、画面単位のUI状態をViewModelが管理し、UIからイベントを受けて状態を更新する一方向データフローを推奨しています（出典: Android Developers「UI layer | App architecture」、2026年確認）。選定では「MVVMに対応していますか」と聞くだけでなく、画面状態をどのクラスが保持するか、RepositoryやUse Caseを置くか、DIをどう行うか、テストコードとCIをどう実行するかを確認します。パッケージやSaaSに寄せられる標準業務は寄せ、専用端末や競争優位となる操作だけをスクラッチで作るFit to Standardも有効です。

設計では、画面仕様だけでなく、ViewModelが公開するプロパティ、Command、入力エラー、通信中、再試行、空データ、権限不足、保存完了などの状態を定義します。画面ごとに「状態」「状態を変えるイベント」「遷移後の表示」「呼び出すUse Case」を表にすれば、実装者と業務担当者が同じ対象を確認できます。Viewは見た目に集中させ、業務ルールはModel側またはUse Case側へ置き、ViewModelは画面向けの状態変換と操作の仲介に限定します。

開発は、代表画面の薄い縦切りで始めます。たとえば在庫検索について、画面、ViewModel、Repository、API、認証、ログ、単体テストを一通りつなぎ、実機や実データに近い条件で操作感を確かめます。共通部品は一度に作り込みすぎず、2画面以上で同じ仕様が確認できたものから抽出します。ViewModelに何でも集約する、画面から直接APIを呼ぶ、コードビハインドに業務判定を書くといった実装は、レビューの禁止事項として明文化します。

MVVMの効果を確認するには、画面を人がクリックするテストだけでは不十分です。まずViewModel単体テストで、入力値の検証、保存可能条件、権限による操作可否、通信失敗時の状態、再試行、二重送信防止を確認します。RepositoryやAPIはモックに差し替え、画面を表示しなくても状態遷移を検証できるようにします。その後、ViewとViewModelのバインディング、APIとの結合、複数画面の業務シナリオ、実機、性能、セキュリティ、バックアップと復旧を確認します。

受入テストのシナリオは、通常操作だけでなく、在庫が不足する、期限切れのデータを開く、通信が途中で切れる、同じ伝票を二人が更新する、権限のない利用者がURLやAPIを直接呼ぶ、といった失敗系を含めます。合格条件は「不具合がない」ではなく、重要業務のシナリオ、性能目標、ログ、監視、操作教育を含めて決めます。AIが生成したコードやOSSを使う場合も、ライセンス、脆弱性、入力検証、秘密情報の混入を人がレビューします。

本稼働では、いきなり全社へ切り替えるのではなく、対象部門や代表拠点を選んだパイロット運用が安全です。移行対象データの件数、変換ルール、重複、欠損、旧システムとの照合方法を決め、切り戻し条件と責任者を明記します。ログイン、権限、APIエラー、処理時間、同期失敗、端末更新状況を監視し、障害時にどこを見れば原因を追えるかを運用手順書にします。

セキュリティはMVVMの責務分離とは別に設計する必要があります。IPAの「情報セキュリティ10大脅威 2025」では、組織向けの脅威としてランサム攻撃、サプライチェーンや委託先を狙った攻撃、脆弱性を突いた攻撃が上位に挙げられています（出典: IPA、2025年）。最小権限、暗号化、監査ログ、バックアップ、脆弱性対応期限、委託先への連絡手順を、非機能要件と契約に含めます。

稼働しただけでは定着とはいえません。利用者が旧Excelへ戻る理由を、操作の難しさ、入力項目の多さ、処理速度、権限設定、業務ルールの不一致に分けて集めます。問い合わせ件数、未完了の申請、同期エラー、利用率、入力の差し戻し、処理時間などの指標を決め、月次で改善します。新機能を追加する際は、画面だけでなくViewModelの状態、テスト、ログ、マニュアルの更新も変更範囲に含めます。

保守契約では、OSやSDKの更新、脆弱性修正、障害対応、クラウド費、法改正、端末交換、データ修正のどこまで含むかを明確にします。ソースコードだけでなく、設計書、テストコード、CI/CD設定、IaC、依存ライブラリ一覧、管理者アカウントの引き継ぎ条件も納品物に含めると、特定の担当者やベンダーに依存しにくくなります。

MVVMのシステム開発の費用相場とコストの内訳

MVVMに固有の定額料金はなく、費用は画面数、業務の複雑さ、端末数、APIや既存システムとの連携、データ移行、セキュリティ、テスト、保守の範囲で決まります。以下は公開されている一般的な業務システム相場とリサーチノートをもとにした推定レンジであり、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年以上になる場合があります。

公開相場の整理でも、業務システムは小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上、人月単価60万〜200万円程度という幅が示されています（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年確認）。MVVMでは状態設計、共通部品、ViewModel単体テストが先行するため、UIだけを短期実装する案件よりフロントエンド工程が増える可能性があります。ただし、画面数や将来の改修が多い案件では、後の手戻りを抑えるための投資として評価します。

費用を比較する際は、総額だけでなく要件整理、方式設計、UI設計、ViewModelと業務ロジックの実装、API・DB、単体テスト、結合・総合テスト、データ移行、教育、稼働支援を分けます。リサーチノートでは、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度という工程配分が検算材料として示されています。案件固有の事情で変動しますが、テストが極端に少ない見積もりは、受入後の追加費用や品質リスクを確認するきっかけになります。

初期費用以外には、クラウド利用料、ストアや証明書、監視、端末、ライセンス、バックアップ、保守、OS・SDK更新、脆弱性対応が発生します。保守費は開発費の年間15〜25%程度を目安にする整理がありますが、障害対応の時間帯、月の作業時間、改善開発の扱い、未使用時間の繰越、SLAを契約ごとに確認します。パッケージやSaaSを採用する場合も、MVVMで作る専用アプリとの連携部分や追加開発費を別に見積もります。

MVVMのシステム開発で見積もりを取る際のポイント

良い見積もりは、単に安い見積もりではありません。何を作るか、何を作らないか、どの品質をいつ確認するか、変更が起きたときに誰がどの条件で判断するかが読み取れる見積もりです。提案依頼の前に簡易RFPを作り、候補会社へ同じ前提を渡すと、価格差の理由を比較しやすくなります。

RFPには、対象業務と解決したい課題、利用者数、権限、画面一覧、主要な状態、端末とOS、API・外部機器、既存DB、移行件数、オフライン要件、認証、監査ログ、性能目標、バックアップ、納期、予算枠を記載します。画面数が10でも、一覧の絞り込みだけの画面と、複数の入力状態・承認分岐・外部機器を持つ画面では工数が異なります。「画面数×単価」だけの見積もりを避け、画面ごとの状態と連携を出してもらいます。

納品物は、実行ファイルだけでなく、ソースコード、設計書、API仕様、DB定義、テスト計画と結果、テストコード、CI/CD、IaC、環境変数の管理方法、OSSと依存ライブラリの一覧、操作・運用マニュアルまで確認します。著作権や利用許諾、第三者ライブラリの制約、生成AIを使ったコードのレビュー責任も、契約前に整理します。

候補会社には、MVVMの採用実績だけでなく、どの画面にどの責務分離を適用したかを説明してもらいます。WPFのWindows業務端末、KotlinのAndroidアプリ、SwiftUIのiOSアプリ、.NET MAUIなど、対象OSに近い実績を確認し、API、認証、クラウド、監視、機器連携まで担当できるかを見ます。業務理解の確認では、現場の例外処理や月末処理、権限、既存データの正しさについて、初回提案で具体的な質問が出る会社を評価します。

比較表には、要件整理の担当者、設計レビューの方法、ViewModel単体テストの範囲、実機テスト、障害対応の窓口、ソースコードの引き渡し、保守のSLA、別会社へ移行するときの条件を並べます。MVVMという単語が提案書にあるかより、状態遷移図、テスト例、失敗時の設計、引き継ぎ方法を見せられるかが重要です。

要件整理、テスト、移行、教育が「一式」でほとんど計上されていない場合は、安く見えても後から追加費用になりやすくなります。逆に、すべての機能を初回から作り込む提案も、使われない機能へ投資するリスクがあります。MVPの範囲、後回しにする機能、追加の単価、変更要求の承認者、納期への影響を契約書やプロジェクト計画に記載します。

レガシーなWindowsアプリやAndroidアプリを刷新する場合は、全置換を前提にせず、画面単位または業務単位で段階移行できるかを検討します。既存DBをそのまま使うのか、APIを介して新旧画面を共存させるのか、切り戻し期間をどれだけ設けるのかを確認します。技術的にMVVMへ移行できても、現場の操作手順やマスタ管理が変われば定着しないため、移行計画と教育費を削らないことが重要です。

MVVMのシステム開発でよくある質問

MVVMのシステム開発では、採用すべきか、費用が下がるか、既存システムから移行できるかという質問が多くなります。ここでは、発注前に判断しやすいように結論を先に回答します。

MVVMを採用しただけで初期費用が安くなるわけではありません。責務分離、状態設計、テストコードの分だけ先行工数が増える可能性がありますが、画面数が多く将来の改修や複数端末展開がある場合は、変更範囲を抑えやすくなります。短期の小規模画面なら、MVVMの範囲を絞る方が合理的な場合もあります。

使えます。ただしMVVMはフロントエンドの設計パターンであり、Webシステム全体の構成やバックエンドの方式を自動的に決めるものではありません。ブラウザ側の状態管理や入力処理に適用し、API、認証、データベース、監視、権限は別途設計します。Web、Windows、Android、iOSへ同じ業務を展開する場合は、共通APIと業務ルールの分界を先に定義します。

移行できますが、全画面を一度に置き換える必要はありません。既存DBやAPIを維持しながら、利用頻度が高く変更の多い画面からViewとViewModelを分け、テストを追加していく段階移行が現実的です。既存の業務ルールが画面コードへ混在している場合は、先にルールを棚卸しし、旧画面と新画面の結果を比較する期間を設けます。

画面表示に必要な状態変換や入力値の整形はViewModelに置けますが、在庫引当、価格計算、承認権限、会計期間の判定など、画面をまたいで再利用する業務ルールはModel側やUse Case側へ分けることを推奨します。ViewModelが巨大化してテストしにくくなったら、責務を分けるサインです。画面単位の状態と業務上の正しさを分離すると、別の画面やバッチからも同じルールを使いやすくなります。

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

MVVMのシステム開発は、Model、View、ViewModelに分けること自体が目的ではありません。画面状態を整理し、業務ルールを適切な層へ置き、テストと運用を継続できる構造にすることが目的です。採用前には、画面数、状態の複雑さ、複数端末展開、改修頻度、内製化の必要性を確認し、MVVMを適用する範囲を決めます。

進行は、要件整理で業務と例外を洗い出し、端末・アーキテクチャ・発注方式を選定し、状態設計を先に行ってから設計開発へ進みます。その後、ViewModel単体テスト、APIや画面の結合テスト、実機・性能・セキュリティテストを行い、パイロット稼働、データ移行、監視、教育、継続改善へつなげます。費用はMVVMという名前で判断せず、画面・連携・移行・テスト・保守の内訳とレンジで比較します。

発注時は、状態遷移図、受入条件、テストコード、ソースコード、設計書、CI/CD、依存ライブラリ、保守分界を見積もりと契約へ反映します。技術の説明だけでなく、自社の業務例外や現場の利用環境を理解し、稼働後の改善まで伴走できる開発会社を選ぶことが、MVVMの効果を長く活かす近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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