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

MVVMのシステム開発は、要件整理、方式選定、設計開発、テスト、稼働、定着の6つのフェーズで進みます。

この順で進めると、技術選定が業務課題から離れるのを防げるため、変更しやすい業務アプリにつながります。

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

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

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

MVVMは、Model・View・ViewModelに責務を分ける設計パターンです。製品名や業務パッケージのことではありません。

品質は、導入するだけで自動的に高まるわけではありません。画面状態が複雑な業務を、どこまで分離するかの判断で左右されます。そのため、将来の変更やテストに効果がある範囲を見極めて設計することが大切です。

Model・View・ViewModelの役割分担

開発会社は、Model・View・ViewModelに責務を分けたうえで、各層の役割を設計書に明記します。

• Model：顧客、商品、受注、在庫などのデータと業務ルール、APIやDBへのアクセス。
• View：画面表示と入力部品。例はWPFのXAML、AndroidのComposeやXML、iOSのSwiftUIやUIKitです。
• ViewModel：表示状態を整え、検索、保存、承認などの操作をCommandやイベントとして受け取る役目です。

ViewModelからDBへ直接つなげず、RepositoryやUse Caseを挟みます。取得先の変更や単体テストを進めやすくするためです。

たとえば在庫登録画面では、Viewが商品コードや数量を表示し、ViewModelが読み込み中や入力エラーの状態を管理します。在庫数の整合性や更新者、更新日時、同時更新の判断は、Modelが受け持ちます。

役割を設計書に明記しておくと、画面担当者による業務ルールの独自実装やViewModelの肥大化を抑えられます。

向いている業務と向いていない業務の見分け方

MVVMを使うかどうかは、画面状態の複雑さと将来の変更を見て判断します。

• 適する業務：入力、検索、一覧、承認、同期、エラー表示など、状態の変化が多いアプリです。
• 分離の効果が出やすい例：権限で表示や操作が変わる販売・在庫管理や、Windowsとモバイルへ段階展開するシステムです。
• 負担になりうる例：数画面だけの短期試作や表示だけの管理画面では、抽象化が負担になる場合があります。
• 採用判断：画面数、状態、改修頻度、複数OS、テストや内製化の必要性を見て決めます。

Microsoft Learnは、MVVMをデータバインディング、プロパティ変更通知、コマンドと組み合わせる設計だと説明しています（出典: Microsoft Learn「Model-View-ViewModel – .NET」、2026年確認）。

MVVMの主な狙いは、画面と非UIコードを疎結合にすることです。ただし、ViewModelへSQL、認証、複雑な計算、画面遷移を詰め込むと、名前だけMVVMで中身は密結合になります。

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

各フェーズは、要件整理から始め、技術・製品選定、設計開発へと進みます。要件整理を先に進めてから方式を選ぶ順序なら、技術選定が先行して業務課題から離れるのを防げます。次に、テスト、稼働、定着の順に続きます。各フェーズの終了条件は、資料の完成ではなく、次の判断に必要な不確実性が減ったかどうかです。

要件整理による業務・画面・状態の洗い出し

発注側と開発会社は、まず、誰がいつ何を入力し、どのデータを正とするかを確かめます。

• 集める資料：現行のExcel、紙帳票、メール、既存システム、例外処理。
• 整理する要件：業務目的、利用者、権限、入力・出力、連携先、保存期間、失敗時の復旧方法。
• 優先順位：Must、Should、Nice to haveへの振り分け。
• 確認項目：画面数と画面ごとの状態数、同時利用者数、端末・OS、オフライン、API、認証、権限、監査ログ、移行、障害運用。

最初のMVPでは、代表業務を1つか2つに絞ります。そうすると、MVVMの状態設計を早く検証できます。

保存後に通信が切れた場合、承認中に他の人が更新した場合、権限が途中で変わった場合は、業務担当者と一緒に確かめておきます。

要件整理の結果は、画面遷移図や状態一覧として文書にまとめます。業務ルール一覧、非機能要件、受入条件も同じ文書に書いておくと、後の見積もりが安定します。

端末・アーキテクチャ・発注方式の選定

端末やOSに合わせて技術候補を比べ、業務に必要な機能を確かめます。

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

• Windows：C#、WPF、XAML、.NETが候補です。
• Android・iOS：各OS向けのネイティブ開発技術の比較。
• 複数OS：.NET MAUI、Flutter、React Nativeも候補です。
• 先行検証：バーコード、カメラ、Bluetooth、プリンター、オフライン同期など、端末固有機能を先に試します。
• Fit to Standard：標準業務はパッケージやSaaSに寄せ、専用端末や競争優位の操作だけを開発します。

WPFは、データバインディングや入力検証、並べ替え、フィルタリングを備えています。特に、キーボード操作や大量一覧に向いています。

Androidでは、Kotlin、Jetpack ViewModel、StateFlow、ComposeかXMLを比べます。iOSでは、Swift、SwiftUIまたはUIKitを比べます。

選ぶときは、状態を保持するクラスや、RepositoryやUse Caseの扱いを確かめます。DIとテストコード、CIの実行方法も見ます。

先行する状態設計と、画面・業務ロジックの実装

状態設計では、画面ごとに状態と操作、その後の表示を対応づけます。

• 状態：入力エラー、通信中、再試行、空データ、権限不足、保存完了。
• 遷移の記録：状態を変えるイベント、遷移後の表示、呼び出すUse Caseを、画面ごとの表にまとめます。
• 責務分担：Viewは見た目、業務ルールはModelまたはUse Case、ViewModelは画面状態の変換と操作の仲介を担います。
• 実装検証：代表画面を薄い縦切りでつなぎ、実機や実データに近い条件で確かめます。

状態とイベントの表があると、実装者と業務担当者が同じ対象を見ながら確認できます。

在庫検索を例にすると、画面からRepositoryまでをつなぎ、操作感を確かめます。APIや認証、ログ、単体テストは、フェーズ4で扱います。

共通部品は、2画面以上で仕様を確認してから切り出します。禁止する実装は、レビューの基準に明記しておきます。

ViewModel単体テストから業務シナリオテストまでの実施

MVVMの効果は、画面を人がクリックするテストだけでは十分に確かめられません。

• ViewModel単体：入力検証、保存条件、権限、通信失敗、再試行、二重送信の確認。
• 結合・実機：画面連携、API、業務シナリオ、性能、セキュリティ、バックアップと復旧。
• 受入シナリオ：在庫不足、期限切れ、通信断、同一伝票の同時更新、権限外アクセス。
• 合格条件：重要業務のシナリオ、性能目標、ログ、監視、操作教育を含めます。

RepositoryやAPIをモックに差し替えると、画面を表示せずに状態遷移を検証できます。

AI生成コードやOSSは、ライセンスと脆弱性、入力検証、秘密情報の混入を、人が確認します。

小さな稼働による移行・監視・復旧の確認

全社一斉の切り替えより、対象部門や代表拠点を選んで始めるパイロット運用のほうが安全です。

• データ移行：件数、変換、重複、欠損、旧システムとの照合、切り戻し条件と責任者を決めます。
• 運用監視：ログイン、権限、APIエラー、処理時間、同期失敗、端末の更新状況を見ます。障害時の確認先は、手順書に記します。
• セキュリティ：最小権限、暗号化、監査ログ、バックアップを、脆弱性対応期限や委託先への連絡手順とあわせて、要件と契約に含めます。

セキュリティは、MVVMの責務分離とは別に設計します。

IPAの「情報セキュリティ10大脅威 2025」では、組織向けの脅威として、ランサム攻撃、委託先などを狙う攻撃、脆弱性を突く攻撃が上位です（出典: IPA、2025年）。

利用状況を見ながらの業務とコードの定着

稼働しただけでは定着とはいえません。利用状況を見ながら、業務とコードを継続して改善します。

• 利用上の課題：旧Excelへ戻る理由を、操作、入力項目、速度、権限、業務ルールに分けます。
• 改善指標：問い合わせ、未完了申請、同期エラー、利用率、差し戻し、処理時間を、月次で見ます。
• 保守範囲：OS・SDK更新、脆弱性、障害、クラウド費、法改正、端末交換、データ修正の対象を定めます。
• 引き継ぎ：ソース、設計書、テスト、CI/CD、IaC、依存一覧、管理者アカウントの条件を納品物に含めます。

新機能では、画面だけでなく、ViewModelの状態とテストを更新範囲に含めます。ログやマニュアルも、そこに加えます。

管理者アカウントの引き継ぎ条件を定めておくと、担当者やベンダーへの依存を抑えられます。

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

MVVMに固有の定額料金はありません。

費用は、画面数や業務の複雑さ、端末数で決まります。連携やデータ移行、セキュリティなどの範囲も、費用に影響します。

次に示すのは、公開されている一般的な業務システム相場とリサーチノートをもとにした推定レンジです。

ただし、MVVMを採用した場合の公定価格ではありません。要件が固まるほど、同じ条件で比べやすくなります。

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

次に示す金額と期間は、要件によって変わる推定レンジです。

公開されている相場では、小規模は100万〜300万円、中規模は500万〜1,000万円です（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年確認）。

• 小規模PoC・MVP：1業務・1OSで150万〜400万円程度、1〜3か月。
• 小規模アプリ：5〜15画面で300万〜800万円程度、3〜6か月程度。
• 中規模案件：15〜40画面の部門利用で800万〜2,000万円程度、6〜10か月程度。外部API、権限、監査ログを含む想定です。
• 全社案件：複数OS、基幹連携、データ移行を伴う場合は2,000万円〜1億円以上、10か月〜2年以上になる場合があります。

人月単価は60万〜200万円程度と幅があり、金額を比べるときは単価と工数の両方を確かめます。

状態設計、共通部品、ViewModel単体テストを先に進めるぶん、UIだけを短期で実装する案件と比べると、フロントエンドの工程が増える可能性があります。

画面数や将来の改修が多い案件では、その工程を後の手戻りを抑えるための投資として評価します。

見積書の設計・テスト・移行・保守の分け方

見積もりは、総額だけでなく、初期工程、工程配分、継続費用に分けて比べます。

• 初期工程：要件整理、方式・UI設計、ViewModelと業務ロジックの実装、API・DB、単体・結合・総合テスト、移行、教育、稼働支援。
• 工程配分：要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度。
• 継続費用：クラウド、ストア・証明書、監視、端末、ライセンス、バックアップ、保守、更新、脆弱性対応。
• 保守条件：開発費の年間15〜25%程度が目安という整理があり、対応時間、月間作業、改善、繰越、SLAの確認。

配分は、案件ごとの事情で変わります。テストが極端に少ない場合は、受入後の追加費用や品質リスクを確かめます。

パッケージやSaaSを採用する場合も、専用アプリとの連携部分と追加開発費は、別に見積もります。

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

良い見積もりは、単に安いものではなく、作るものと作らないものが読み取れるものです。

また、品質や時期、変更時の判断者や条件も、見積もりから分かるようにしておくことが大切です。提案を依頼する前に簡易RFPを作り、候補会社に同じ前提を渡すと、価格差を比べやすくなります。

画面数だけでなく、状態・連携・非機能要件のRFPへの記載

簡易RFPには、見積もりや納品条件を左右する前提を書きます。

• 業務・利用条件：課題、利用者数、権限、画面、状態、端末、OS、API、外部機器、既存DB。
• 非機能・計画：移行件数、オフライン、認証、監査ログ、性能、バックアップ、納期、予算枠。
• 納品物：実行ファイル、ソース、設計書、API・DB仕様、テスト計画・結果・コード、CI/CD、IaC、環境変数管理、OSS・依存一覧、運用マニュアル。
• 契約事項：著作権、利用許諾、第三者ライブラリの制約、生成AIコードのレビュー責任。

たとえば、画面数が10でも、一覧の絞り込みだけの画面と、複数の入力状態・承認分岐・外部機器を持つ画面では工数が異なります。

見積もりは、「画面数×単価」だけの形を避け、画面ごとの状態と連携を示してもらいます。

会社比較で見るMVVMの説明力と業務理解

候補会社には、MVVMの採用実績だけでなく、どの画面にどの責務分離を適用したかを説明してもらいます。

• 技術実績：どの画面にMVVMを適用したか、対象OSに近い実績があるか確認します。
• 対応範囲：API、認証、クラウド、監視、機器連携まで担当できるか見ます。
• 業務理解：例外処理、月末処理、権限、既存データの正しさを質問するか確認します。
• 比較項目：要件整理とレビュー、テスト、障害窓口、ソース引き渡し、SLA、他社移行条件を比べます。

技術名は、WPF、Kotlin、SwiftUI、.NET MAUIなど、具体的な名前で挙げてもらいます。

提案書の用語だけでなく、状態遷移図やテスト例、失敗時の設計や引き継ぎ方法を見ます。

安すぎる見積もりと変更管理のリスクの確認

価格だけでなく、追加費用や段階移行の条件も確かめます。

• 内訳不足：要件整理、テスト、移行、教育が一式で少額なら、追加費用の有無を確認します。
• 作り込み過多：全機能を初回から作る提案は、未使用機能への投資になる場合があります。
• 変更管理：MVP、後回し機能、追加単価、承認者、納期への影響を、契約や計画に記載します。
• 段階移行：WindowsやAndroid刷新は全置換せず、画面・業務単位の移行、DB・API共存、切り戻し期間を確認します。

現場の手順やマスタ管理が変わると定着しない場合があります。そのため、移行計画と教育費を削らないことが大切です。

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

MVVMの開発でよく聞かれるのは、採用の可否、費用、既存システムからの移行です。

発注前に判断しやすいよう、各質問の答えを先に示します。

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

MVVMを採用しただけで、初期費用が安くなるとは限りません。

• 初期工数：責務分離、状態設計、テストコードの分だけ増える可能性があります。
• 改修・多端末：画面数が多く、改修や複数端末展開があれば、変更範囲を抑えやすくなります。
• 小規模開発：短期の小規模画面では、MVVMの範囲を絞る方が合理的な場合もあります。

MVVMはWebシステムや業務システムにも使えますか？

使えます。ただし、MVVMはフロントエンドの設計パターンです。

MVVMは、Webシステム全体の構成やバックエンド方式までは決めません。

• 適用先：ブラウザ側の状態管理や入力処理に使います。
• 別途設計：API、認証、DB、監視、権限を個別に設計します。
• 複数OS展開：共通APIと業務ルールの分界を先に定めます。

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

移行できますが、全画面を一度に置き換える必要はありません。

• 着手範囲：DB・APIを保ち、利用・変更頻度が高い画面からViewとViewModelを分けます。
• 移行準備：テストを加えながら進め、画面内の業務ルールを先に洗い出します。
• 結果確認：旧画面と新画面の結果を比較する期間を設けます。

ViewModelに業務ロジックを書いても問題ありませんか？

画面表示に必要な状態変換や入力値の整形は、ViewModelに置けます。

• 分ける業務ルール：在庫引当、価格計算、承認権限、会計期間の判定など。
• 配置先：Model側やUse Case側です。
• 分離のサイン：ViewModelが巨大化してテストしにくくなった状態です。

画面単位の状態と業務上の正しさを分けておくと、別画面やバッチでも同じルールを使えます。

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

MVVMを適用する範囲と目的の決定

目的は、Model、View、ViewModelに分けることではなく、保守できる構造にすることです。

• 適用範囲：画面数、状態の複雑さ、複数端末、改修頻度、内製化の必要性で決めます。
• 進行：業務と例外を整理し、端末・構成・発注方式を選んで状態設計と開発へ進みます。
• 検証・稼働：単体、結合、実機、性能、セキュリティを確認したうえで、移行・監視・教育・改善に入ります。
• 費用：画面、連携、移行、テスト、保守の内訳と金額幅で比べます。

画面状態を整理し、業務ルールを適切な層に置いたうえで、テストと運用を続けられる形にします。

発注後のテスト・納品・保守まで含めた成功条件

テスト、納品、保守までの成功条件を、見積もりと契約に反映します。

• 契約条件：状態遷移図と受入条件、テストコードやソース、設計書、CI/CD、依存一覧、保守分界。
• 会社選び：業務例外や現場環境を理解し、稼働後も伴走する会社がMVVMの効果を長く活かす近道です。

▼全体ガイドの記事
・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を創業。