Mendixの発注は、業務課題と要件を整理するところから始めます。PoCで不確実な点を確かめ、契約範囲と運用体制を決めて委託すると、追加費用や運用リスクを抑えやすくなります。
その後は、発注形態を決め、RFPと契約を整えたうえで、委託先と見積書を比べる順です。
▼全体ガイドの記事
・Mendixのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Mendixの発注・外注前に知るべき全体像
Mendixは、画面を短時間で作るだけのサービスではなく、業務アプリの基盤です。ドメインモデルや画面に加えて、処理やワークフロー、認証・権限も作り込む対象になります。
業務アプリの作り込みには、API連携やデータベース、テスト、デプロイ、監視まで含まれます。そのため、発注時はプログラム量ではなく、業務成果と運用責任を単位に委託範囲を決めます。
「ローコードだから安い」とは限らない理由
ローコードは、画面や定型処理をモデルで組み立てることで、実装の繰り返しを減らしやすい方法です。
- 業務設計：ヒアリングや業務ルール、データ項目の整理
- システム対応：既存連携や権限、例外処理、性能試験への対応
- 委託範囲：「2か月」にAPI連携、データ移行、受入テスト、本番監視が含まれるかの確認
実装が速くても、業務を決めて現場で使える状態にする時間は、そのまま必要です。
Mendix公式事例には、2名のコンサルタントが、他システム連携と400機能ポイントを含むアプリを8週間で構築した例があります（出典: Mendix公式「Dutch Railways Automates Incident Registration System」）。
この事例は、発注者の意思決定、対象業務、体制、既存連携の条件がそろった個別事例である点に注意が必要です。
発注しやすい業務と慎重に検証すべき業務
業務の流れと利用者を定義しやすい領域は、対象を区切ると外注に出しやすい分野です。
- 申請・承認：業務の流れを定義しやすい領域
- 営業・保守：営業支援や保守・フィールドサービスでの利用
- 在庫・物流：対象業務を段階に分けて切り出せる
- ポータル・現場モバイル：顧客・従業員向けや現場での利用
既存基幹を残して周辺業務を追加すれば、全社刷新より小さく始められます。
レガシー画面も一つずつ置き換えると、効果を測りやすくなります。
中核業務を一括で置き換える案件や、複雑な計算、大量データ、高可用性や厳格な監査が必要な案件は、まずPoCで検証します。
PoCでは、代表画面と認証、主要APIを中心に、データ量や権限エラー、連携失敗を確かめます。その結果をもとに、Mendixと既存基幹などの担当領域を判断します。
発注形態の選び方｜PoC・一括請負・段階委託
発注形態は、要件の確かさや社内人材の有無で決めます。納期の固定度や発注者が負うリスクも、判断材料になります。初めて使う企業や、既存データ・連携仕様が不明な企業には、検証と本開発を分ける方法が適しています。
不確実性が大きい場合のPoC
PoCは、4〜8週間程度を計画上の目安として、主要画面、モデル、ログイン、API、権限、データ移行の一部を検証します。
成果物には、実現範囲と未解決の制約、本番インフラ、概算工数を含め、さらに次工程の受入基準も含めます。
正常系の動作だけを見ると、API遅延や連携データの欠落、過剰な権限などを見逃すおそれがあります。
PoCを値引き交渉だけに使うと、検証目的がぼやけてしまいます。そのため、判定できる終了条件を先に決めておきます。
- 業務操作：利用部門が代表業務を操作できること
- 認証：既存認証でのログイン
- API：エラー時の再送方法の確定
- 移行品質：データ移行の品質の測定
PoCの終了後に、継続、設計変更、中止のどれを選ぶかも発注前に合意しておくと、予算を管理しやすくなります。
MVPの段階的な委託と現場判断の迅速化
MVP（Minimum Viable Product）は、利用後の改善を次の段階に分けて進める方法です。
- 第1段階：頻度が高く、効果を測りやすい業務への絞り込み
- KPI：利用者数、処理時間、紙・Excel削減量、承認滞留時間の指標
Mendix公式事例では、DSM-Firmenichが150以上のアプリを提供しており、新規アプリの平均開発期間は8〜10週間と紹介されています（出典: Mendix公式「Accelerate App Delivery at Scale with Mendix and AWS」）。
この速度には、既存の開発標準や体制、再利用部品、意思決定の仕組みが関係しています。そこで、発注者はプロダクトオーナーを置き、スプリントごとに優先順位を決めます。また、利用部門や情報システム、セキュリティ、経理・法務も、必要な時点で参加します。
業務判断をすべて外注先に任せきると、完成後に現場で使えないおそれがあります。そのため、短いサイクルで画面と業務ルールを確認していきます。
内製化支援と受託開発の組み合わせ
外注先との分担は、社内の知識と開発・運用に使える時間に応じて決めます。
- 内製化支援：初期設計・実装、Mendix Studio Pro教育、レビュー、標準、リリース、障害対応
- 受託開発：社内時間が限られる場合に、意思決定と業務受入へ社内の力を集中させる
- 引継ぎ成果物：モデル設計、Microflow例外、API、権限、テスト、環境設定
- 運用資料：バックアップ、更新方針、問い合わせ履歴も対象
運用開始後に誰がモデルを変更し、誰が障害を切り分けるかで、体制を決めます。
担当者一人だけが中身を理解している状態では、その人の異動時にロックインが生まれます。
RFPと要件整理の進め方｜Mendixの外注範囲の明確化
RFPは、候補会社が同じ前提で見積もれるようにするための資料です。開発理由や利用者、変える業務、連携先、本番品質を示します。
要件が曖昧なまま比べると、安く見える提案に、必要な範囲が含まれていないことがあります。
業務課題・利用者・KPIの記載
RFPには、システム名だけでなく、業務の現状と達成したいことも記載します。
- 課題：「申請を電子化」に加え、承認日数や差し戻し理由
- 利用条件：部門・拠点、役割、同時利用、件数、繁忙期の提示
- KPI：達成指標を定めて、性能や運用を見積もれるようにする
現行業務は、業務フロー、帳票・Excel、データ項目、承認ルール、例外処理の五つに分けて整理します。
特に、「通常は上長承認だが、金額が一定以上なら部長承認」のような例外は、一つずつ記録します。
「通信できない現場では一時保存する」といった処理も、先に書き出しておきます。というのも、例外が後から加わると、モデル、権限、テストの修正が必要になり、短期開発の利点が小さくなります。
連携・データ・非機能要件の別紙による具体化
連携と非機能の条件は、作業範囲と運用責任を見積もれる粒度で示しておきます。
- 連携仕様：方式、方向、頻度、データ量、エラー対応、担当者の明記
- 接続対象：SAP、販売管理、会計、顧客管理、認証基盤、既存DBなど
- 接続条件：API、仕様書、試験環境、接続先の改修担当
- 非機能：可用性、応答、同時利用、バックアップ、復旧、ログ
- 安全・配置：暗号化、脆弱性、監査、保管地域、接続、配備先
Mendix側の実装費だけを比べて、相手側の改修費や接続試験を除くと、後から予算が膨らみます。
配備先には、Mendix Cloud、SAP BTP、Kubernetes、Docker、Azure、オンプレミスがあります（出典: Mendix公式「Deploying Apps」、2025年7月更新）。
配備先によって機能や運用責任が異なるため、どこまでを誰が受け持つかを決めます。
RFPに入れる成果物と受入基準
納品物と受入基準は、アプリ完成後に確認する範囲まで具体的に示します。
- 設計・移行：要件、画面・帳票、モデル、権限、API、移行設計
- 運用資料：テスト結果、設計意図、手順、監視、リリース、引渡し方法
- 受入試験：通常申請、差し戻し、代理承認、権限外、APIタイムアウトの各ケース
- 移行・復旧：二重送信、件数照合、バックアップからの復旧
モデル構造や再利用部品の品質は、将来の改修費に影響します。そのため、発注者がいつまでに何を確認するか、未達のときの修正と再テストも、あらかじめ合意しておきます。
契約形態の選び方｜準委任・請負・保守の分け方
要件が固まった工程と、利用者の反応を見て変える工程とでは、契約を分けます。目安としては、PoCや要件整理は準委任、仕様と受入条件が固まった機能は請負、運用後は保守契約です。
実際の契約は、案件の法務・調達ルールに合わせて、専門家の確認を受けます。
準委任契約が向くケース
作業内容が変わりやすい調査や検討では、専門家の作業や助言を依頼する準委任が向きます。
- 対象工程：PoC、現行調査、構成検討、MVPのバックログ作成、アジャイル開発初期
- 作業条件：担当者、時間、会議、報告物、品質確認の取り決め
- 契約条件：再委託、秘密保持、情報保護、知的財産の明記
準委任でも品質管理は必要なので、スプリントごとのデモやレビュー記録を残しておきます。
課題一覧や意思決定ログ、未完了事項を記録し、そのうえで次の発注範囲を確認します。
作業時間だけで管理すると、不要な画面を作り続けるおそれがあります。そこで、KPIやユーザーストーリーと結び付けて、進捗を評価します。
請負契約が向くケース
請負は、対象や仕様、納期、検査方法、受入基準が明確な範囲に適しています。定義済みの申請機能や画面・帳票一式、合意済みのAPI連携などが例です。仕様と受入条件が明確であれば、テストや本番リリースも対象にできます。
- 対象範囲：仕様、成果物、受入条件が固まった機能の契約
- 納品物：ソース、モデル、設計・テスト仕様、環境、CI/CD定義、運用手順
- 権利・移管：翻案や二次利用の権利、契約後の他社移管条件
未確定の要件を含めると、変更時に追加費用や納期調整が起こりがちです。そのため、前提条件や除外事項、変更管理、瑕疵への対応、再委託の有無を確認します。
モデルやアプリ資産を、誰が利用できるかも確認します。提供者が変わっても業務を続けられる状態に、納品物と契約を整えます。
保守契約で決める項目
保守の範囲と費用を定めて、毎月の費用と突発の費用を分けて管理します。
- 対応条件：窓口、受付時間、障害の重要度、一次回答と復旧の目標
- 運用範囲：監視、バックアップ、脆弱性対応、Mendix更新、外部API変更の扱い
- 改善・追加費用：軽微な改善の月間上限。大規模改修やデータ修復などは別項目に分ける
- 契約終了時：アカウント、リポジトリ、環境、証明書、バックアップ、監視設定の引継ぎ方法
- 移管条件：問い合わせ履歴の返却・削除、支援の時間単価、秘密情報の扱い
認証情報は、Mendix公式の「Enterprise Security – Compliance」（2026年確認）に掲載されています。その掲載内容には、ISO/IEC 27001:2022、27017、27018、27701、SOC 1・SOC 2 Type IIが含まれます。ただし、プラットフォームの認証があっても、自社アプリの設計・運用責任は残ります。
Mendixのシステム開発費用相場とコストの内訳
Mendixの費用は、ライセンス、クラウド・インフラ、開発の工程に分けて考えます。開発の工程は、要件定義、設計・環境構築、実装に分かれます。
さらに、連携、データ移行、テスト、教育、保守も別に見ておく必要があります。総額を判断するには、ライセンス価格に加えて、開発委託費や本番運用費も見ることが欠かせません。
以下の数値は、公開情報と一般的な業務システム相場から作った計画用の推定レンジです。正式な見積りではありません。
公式料金とクラウド費用の切り分け
2026年8月時点の公式開始価格は、Freeが月額0ユーロです。Standardでは、One Appが月額918ユーロから、Unlimited Appsは月額2,295ユーロからです。
Premiumは要見積りです。さらに、StandardとPremiumでは、必要なコンピュートリソースがライセンスに含まれません。そのため、選んだクラウドや構成に応じて、別途費用が発生します（出典: Mendix公式「Mendix Pricing」、2026年8月確認）。
- 価格変動：為替、アプリ数、規模、可用性、契約条件によって実額が変わる
- Free：試作や小規模検証向け。サポートや稼働保証は、有料プランが必要になる
- 本番範囲：ライセンス、DB、監視、バックアップ、ネットワーク、認証、サポートの確認
- 自社クラウド：Azureなどでは、AKSやDB、ネットワーク、ストレージ、監視が自社契約で発生することがあります。
ユーロの金額は、日本円へ機械的に換算しただけでは、予算として確定できません。
開発規模別の計画用レンジ
開発費と期間は、規模や含める機能、工程によって変わります。
- 小規模：PoCや申請・台帳・現場アプリの場合、300万〜800万円で、1〜2か月程度
- 部門アプリ：連携や移行を含む場合、800万〜2,000万円で、3〜6か月程度
- 全社・基幹周辺：2,000万円〜1億円以上で、6〜12か月以上になる場合もある
短期間で済む案件でも、認証や例外処理は省けません。これらは、Mendixの定価ではなく、一般的な業務システム相場と案件要件を踏まえた推定です。
小規模の場合は、画面数や権限、簡単な連携、利用者テストが前提になります。
ライセンスやクラウド、教育、社内側の工数は、別に見積もります。
部門アプリには、複数ロールやワークフロー、既存DB・SaaS連携、移行、受入テストが含まれます。
全社展開では、高可用性やSAP等との多数連携、監査ログ、性能試験、冗長化、運用設計、教育が含まれる場合があります。
人月単価の参考値は、PMが90万〜150万円、設計SEが65万〜110万円、実装担当が50万〜90万円、テスターが45万〜80万円程度です。
Mendixでコード量を減らせても、業務設計、データモデル、連携、権限、テスト、運用設計の工数は必要です。
一般的な工程比率の目安は、要件定義が10〜12%、設計・環境構築が22〜24%程度です。また、実装は48〜50%、テストは15〜17%程度です。見積書では、工程ごとの人数と期間が、この比率に沿って説明されているかを確認します。
保守・運用費の初期費用との切り分けと予算化
保守・運用費は、初期開発費とは分けて予算化します。
- 費用の目安：初期開発費の年15〜25%、または月15万〜80万円程度
- 契約範囲：ライセンス、クラウド、支援、監視、障害対応、改善の範囲
見積依頼では、初期費用に加えて、1年目と2年目以降の総保有コストを出してもらいます。海外拠点を含む24時間対応や厳しい復旧目標、大量データのバックアップ、頻繁な改善がある場合は、このレンジを超える可能性があります。
ライセンスの増減や、ユーザー・アプリ数の単位、従量費、環境数といった条件を、見積りに並べてもらいます。さらに、更新や追加API、問い合わせ、教育、内製化支援、移管費も、費用として示してもらいます。
委託先の選定ポイント｜Mendix開発会社の比較方法
委託先は、業務知識や連携・移行経験、意思決定を中心に比べます。保守や内製化・移管支援も、同じ基準で確認します。公式パートナーディレクトリや認定者数だけでは、品質は判断できません。
同じRFP、質問、デモ課題を各社に提示すると、提案の前提がそろい、比べやすくなります。
案件条件に基づく実績の確認
実績は、自社案件との条件の違いを見て評価します。
- 案件条件：業界、利用者数、拠点、SAP・認証・会計などの連携先の確認
- 実施範囲：データ移行の担当と、PoCから本番までの期間を尋ねる
- 稼働後支援：障害や改善への支援、設計判断の関わり方
Siemensの財務部門では、中規模アプリを40日で開発した事例があります。出典は、Mendix公式「Mendix Enables Siemens Finance Teams to Develop Their Own Applications」です。事例を見るときは、対象業務、チーム、既存の開発環境、利用者テストの条件も確認します。
自社案件と何が同じで何が違うのかを、担当予定者に説明してもらいます。そのうえで、短縮できる工程とできない工程、設計判断や失敗後の改善方法も尋ねます。
担当チームと保守体制の確認
提案の段階で、開発から保守までの担当者と体制を確認します。
- 担当役割：PM、業務設計、開発、連携、テスト、保守責任者
- 再委託：範囲、所在地、情報へのアクセス、連絡経路、交代ルールの取り決め
- 保守対応：平日日中・夜間休日の範囲、初動、復旧目標、暫定・恒久対応
- 継続運用：月次報告、監視アラート、Mendix更新の検証、外部サービス変更
認定者が営業説明だけに加わり、実装は経験の浅い別チームや再委託先が担う場合もあります。そのため、障害時の連絡経路や担当者交代のルールも、RFPへの回答に含めてもらいます。
低価格の提案では、含まれない作業と、追加時の費用を具体的に尋ねます。
内製化と別会社への移管の可否
内製化支援と契約終了時の移管条件を、候補会社に確認します。
- 支援内容：研修、ペア開発、レビュー、運用の引継ぎ、文書整備、認定取得支援
- 変更の分担：軽微な画面・権限変更などで、社内対応と委託範囲を線引きすること
- 引継ぎ成果物：モデル、リポジトリ、環境設定、APIキー、テストデータ、障害履歴、バックアップ
- 権利・契約条件：ライセンス契約の名義、第三者部品の利用条件、成果物の権利の確認
引き渡せないものがあれば、契約上の根拠と代替案を求めます。
見積書の比較時のチェックポイント
見積書は、合計額の安さよりも、同じ範囲をそろえて比べます。工程や作業、成果物、人数、期間を並べて、前提や除外、追加単価を確かめます。ライセンス、クラウド、保守も並べて見ます。
「要件定義一式」「開発一式」「テスト一式」といった記載が多い場合は、作業の境界を質問します。
工程・成果物・除外事項の一致
工程と成果物を同じ条件にそろえて、候補各社の作業範囲を照合します。
- 設計：要件定義の会議・レビュー回数、画面・帳票・API数の確認
- 移行・試験：移行対象、テストデータ作成、性能・脆弱性試験の範囲をそろえる
- 導入支援：利用者教育と本番立ち会いの有無
除外事項は、前提の確認に使います。たとえば、既存APIの提供やマスタデータの整備を前提として確認します。
ネットワーク開通やアカウント発行、端末調達の担当も確認します。移行リハーサルや現場立ち会いなど、発注者が用意するものは一覧にします。
移行を、ある会社は含み、別の会社は発注者の担当とする場合は、発注者の工数も評価します。除外が多いときは、発注者の工数と追加発注を別予算に置きます。
変更・リスク・追加費用の扱い
画面を見て要望が変わることがあるため、変更と追加費用の手続きを事前に決めます。
- 変更手続き：変更の判定方法と、追加見積りの回答期限
- 納期への影響：スプリント内の変更と、納期に響く変更の区別
- 責任分担：連携先仕様の変更、移行データの品質不備の扱い
リスク一覧には、権限漏れやAPI障害、データ重複、性能不足、バックアップ失敗、環境差異を含めます。教育不足や担当交代、ライセンス変更、ロックインも対象に含めます。そのうえで、リスクごとに発生条件や兆候、予防策、担当、予備費や予備期間を定めます。
初年度と継続費用の総額による判断
初年度と3年程度の継続費用を、項目ごとに比べます。
- 導入費：開発、教育、テスト、移行、クラウド、監視、保守を含めた費用
- 将来費：追加アプリや利用者増加、更新、契約終了時の移管にかかる費用
- 見積り区分：確定範囲、変動範囲、判断待ち、第三者費用の区分け
公式Pricingでは、One AppとUnlimited Appsの違いは機能ではなく、アプリ構成に応じて選ぶものとされています。複数アプリを予定する場合は、単一アプリと全体の見積りを依頼します。
委託先は、総額の見通しや品質、現場定着、将来の変更可能性を合わせて決めます。
よくある質問（FAQ）
発注前に多く寄せられる、開発期間、内製化、既存連携、ライセンスの質問を取り上げます。
Mendixのシステム開発は何か月で完成しますか？
小さなPoCや申請アプリは1〜2か月、複数API連携の部門アプリは3〜6か月が目安です。
基幹周辺や高可用性、多数連携を含む案件は、6〜12か月以上が目安です。ただし、8週間や40日の公式事例は、納期を保証するものではありません。
期間は、要件、連携、移行、受入テストを含む工程表で判断します。
自社でMendixを開発できない場合は外注すべきですか？
最初から完全に内製化する必要はありません。PoCや設計、初期実装、開発標準、教育は、外部に依頼できます。
社内担当者もレビューと運用に加わり、モデルやテスト、手順を引き継げる契約にしておけば、段階的に内製化できます。
MendixのシステムはSAPや既存データベースと連携できますか？
REST、OData、SOAP、データベース接続などが検討対象になります。可否は、API、認証、ネットワークの条件で決まります。データ量や頻度、再送の扱い、既存側の改修可否も、あわせて判断の対象になります。
RFPには、データの方向、時期、件数、品質を定義したうえで、連携元の担当会社も含めて見積りを依頼します。
Mendixの無料プランだけで本番運用できますか？
無料プランは、学習やデモ、試作、小規模アプリの検証向けです。公式Pricingでは、Freeには本番稼働保証や製品サポートがないと説明されています。
Free Appにも、規模や稼働時間の制限があります。そのため、本番利用では、可用性やサポート、バックアップ、利用者規模、クラウド費用を確認します。有料プランは、開発・運用費と合わせて判断します。
まとめ
発注前に業務課題とKPIを整理し、Mendixで作る領域と既存基幹・SaaSに残す領域を分けます。
不確実性が大きい場合は、4〜8週間程度のPoCで画面や認証、API、権限、データ、性能を確認し、その結果を本開発に反映します。
RFPには、連携や移行、非機能の条件を含めます。成果物と受入の基準に加えて、保守、内製化、移管まで指定します。費用は、初年度と継続費用で比べます。
委託先は、業務知識や連携・移行経験、チームで選びます。さらに、変更管理や障害対応、権利、移管可能性も確かめます。
同じRFPで工程や前提、除外事項をそろえれば、各社の提案を比べやすくなります。追加費用と運用リスクも、そのぶん抑えられます。
▼全体ガイドの記事
・Mendixのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。