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

Mendixのシステム開発は、要件整理、範囲と配置先の選定、小さな検証、テスト、段階的な稼働、定着の順に進めると、業務改善につながります。

各フェーズで何を決めるかを押さえておくと、抜け漏れを防ぎやすくなります。

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

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

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

Mendixは、Siemens傘下で提供される企業向けのローコード・アプリケーション開発基盤です。業務部門とIT部門が同じモデルを使い、設計・検証・リリース・改善を繰り返せます。

Studio ProからRuntimeまでの一連の流れ

Mendix Studio Proで業務アプリのモデルや画面を作り、処理・連携と配置先を設計します。

• モデルと画面：ドメインモデルと、Web・モバイル画面の作成。
• 処理：サーバー側はMicroflow、端末・ブラウザ側はNanoflowで組み立て、Mendix Runtime上で動作させます。
• 業務フロー・連携：申請と承認をワークフローにし、REST、OData、SOAP、DB、SAPなどと連携します。
• クラウド配置：Mendix Cloudや、AWS・Azure上のKubernetesを選べます。
• その他の配置：SAP Business Technology Platformやオンプレミスも候補です。

プログラムの記述量が減っても、業務ルールやデータの意味を決める作業は残ります。同じ顧客や製品を複数のシステムで扱う場合は、画面より先にデータの正本と更新権限を決めておきます。さらに、連携に失敗したときの扱いも、あらかじめ定めておく必要があります。

周辺業務の段階的な改善への向き方

Mendixの活用領域や導入方法は、業務の状態と改善方針に合わせて選びます。

• 活用領域：申請・承認、営業支援、保守、フィールドサービス、在庫・物流、製造現場のモバイルアプリ、顧客・従業員ポータル。
• 段階的な改善：レガシーシステムは残したまま、周辺業務をAPIで疎結合に連携します。全社一括の置き換えより、リスクを抑えやすくなります。
• SaaS・パッケージ：業務が標準化されていて変更も少なければ、短期間で運用を始められる可能性があります。
• Mendixの選定：業務の変化に合わせた自社改善、複数システムや部門の連携、内製チームの育成が判断材料になります。

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

全体を、要件整理から選定、設計・開発、テストを経て稼働と定着へ進む6つのフェーズに分けると、抜け漏れを管理しやすくなります。画面を先に試作しても、それを本番仕様にはしません。各フェーズの終了条件を決めてから、次のフェーズへ進みます。

1. 要件整理：業務課題と成功条件の決定

Mendixで作るものより先に、誰のどの作業を、どの指標まで改善するかを決めておきます。そのうえで、担当者へのヒアリングや画面・帳票の一覧化によって、現行業務を洗い出します。

利用者、承認者、データの発生元を整理しておくと、業務の流れが見えてきます。処理件数や例外処理、権限も押さえます。さらに、外部システムと法令・社内規程も確かめます。

要件の確認では、対象業務と対象外業務をはっきりさせます。KPIには処理時間や入力ミスなどを使い、最終承認者とマスタの正本も明らかにします。

• 業務継続：API停止時の継続方法を決めます。
• 情報管理：個人情報や監査ログの保存期間。

未回答の項目は未決事項として記録し、責任者と決定期限を決めておきます。

2. 選定：Mendixで作る範囲と配置先の決定

開発手段は、業務の特徴を見て選びます。定型的で差別化の少ない業務は標準機能に寄せ、部門ごとの判断や変化が多い領域をMendixで作ります。この進め方はFit to Standardと呼ばれ、範囲を膨らませにくい考え方です。

• Mendix：業務の変化に合わせた改善や内製の検討。
• SaaS・パッケージ：標準化された業務の候補。
• 既存改修・フルスクラッチ：他方式との比較対象。

Mendix Cloudは導入しやすい一方で、プライベートクラウドや自社運用なら、配置先を比べて決めます。候補は、Mendix on KubernetesとMendix on Azureです。ほかに、SAP BTPやサーバーベースもあります。

公式資料によると、配置先によって使える機能や運用画面が異なります。確認するのは、ネットワーク分離とデータ保管地域です。加えて、バックアップ、監視、障害対応について、どこまでを誰が受け持つかを確かめます（出典: Mendix公式「Deploying Apps」、2026年7月更新）。

3. 設計・開発：モデルと連携の小規模な検証

画面の見た目より先に、ドメインモデルと連携の要点を整理します。

• データモデル：顧客、申請、明細、承認と担当組織の関連、必須項目と状態遷移、重複防止を決めます。
• 処理・連携：権限、画面、MicroflowとNanoflow、同期と非同期の設計。
• PoC：4〜8週間程度で代表画面を使い、認証、API、権限、登録を試します。
• 異常系：連携失敗、通信遅延、監査ログを、一つの業務シナリオで確かめます。

エラー時の再送方法と利用者への通知も、設計書に残しておきます。

終了条件には、業務担当者が受入条件を説明できることと、性能・セキュリティの未解決事項が一覧になっていることを入れます。正常系のデモが動くだけでは、この条件を満たしたとはいえません。

4. テスト：データ・権限・例外の本番に近い条件での確認

Mendixが品質を自動的に保証するわけではありません。そのため、テストごとに担当者と合格基準を決めておきます。

• 機能確認：ロジックと画面との結合を確かめます。
• 連携・権限：API連携とアクセス制御を試します。
• 品質・受入：性能、脆弱性、利用者による受入の確認。

異常系では、連携先がタイムアウトしたときに二重登録されないかを確かめます。承認者が退職したあとも、申請が止まらないかを見ます。

権限を外したあとに、古い画面やAPIへアクセスできないかも確認します。旧データの文字コードや日付、コード体系を変換できるかも、あわせて検証します。

移行は、本番前に少なくとも一度はリハーサルします。件数の照合と、業務担当者によるサンプル確認まで終えておきます。

5. 稼働：切り替え手順と運用責任の決定

稼働前には、リリース判定を行い、切り替えと運用の準備を進めます。

• リリース判定：不具合、移行結果、バックアップ、監視、窓口、切り戻し条件の確認。
• 権限・接続情報：デプロイ承認者と、環境変数・接続情報の管理方法を決めておきます。
• 障害対応：Mendix、開発会社、社内ITの連絡先。
• 切り替え：一斉、部門・拠点限定の段階稼働、旧システム併用、機能別の各方式を比べます。

切り替え方式は、業務停止の許容時間とデータ二重入力の負担を見て選びます。一度に切り替える方法が、常に合うとは限りません。

Mendix Cloudのバックアップや監視、高可用性は、プランによって違います。そのため、契約で決まる範囲と社内の運用を分けて確認します（出典: Mendix公式「Mendix Cloud」、2026年7月更新）。

6. 定着：内製化と改善サイクルの設計

稼働後に現場で使われてはじめて成果が出るため、利用支援と改善の体制を作ります。

• 利用支援：業務シナリオ、問い合わせ方法、マニュアル、動画、エラー解決方法の整備。
• 効果測定：利用率、処理時間、差し戻し率、紙・Excel併用件数をKPIとして追います。
• 内製・引き継ぎ：役割を分けたうえで、成果物と運用記録を引き継ぎます。
• AI支援の確認：生成されたロジックの、人によるレビュー。

KPIは、稼働後30日、60日、90日の節目で確認します。内製化を進めるには、Mendix認定開発者を増やし、プロダクトオーナー、ITアーキテクト、運用担当者の役割を分けます。

AI支援で生成したロジックは、人が見直します。見るのは、権限と性能です。例外処理と保守性も対象になります。

開発会社からは、モデル、設計書、テスト仕様を引き継ぎます。加えて、環境設定とCI/CD手順、障害対応履歴、バックログも対象にします。契約が終わったあとも、別の会社や自社で保守を続けられるように、整えておきます。

Mendixのシステム開発にかかる費用相場

費用は、ライセンス、クラウド・インフラ、要件整理・開発に分けて考えます。外部連携とデータ移行も、別の費目として見ます。テストと教育、保守も、それぞれ見積もりに入れます。ローコードでも、業務整理とデータ品質の工数は残ります。非機能要件や合意形成にかかる工数も、なくなるわけではありません。

公式ライセンスのプランと配置先の分け方

2026年8月確認のMendix公式Pricingでは、Freeは月額0ユーロです。Standardは、One Appが月額918ユーロから、Unlimited Appsが月額2,295ユーロからです。Premiumは要見積りです（出典: Mendix公式Pricing、2026年8月確認）。

• アプリ数：One AppとUnlimited Appsで、技術機能は同じです。
• 選定：大きなアプリ1つから始めるか、複数アプリのポートフォリオを作るかによって選びます。
• 見積り：ライセンスとクラウド・インフラを、分けて記載します。

表示価格は、契約条件や地域、利用規模によって変わります。そのため、そのまま日本円の予算に置き換えないようにします。

公式FAQによると、StandardやPremiumでは、必要なコンピュートリソースがライセンス料金に含まれません。

インフラ費用と運用担当の範囲は、配置先によって変わります。配置先には、Mendix Cloudや専用クラウドがあります。AWS・AzureのKubernetesやSAP BTP、オンプレミスも候補になります。

規模別の開発費の計画レンジ

日本向けのMendix開発費に、一律の公開価格はありません。下の金額は、一般的な業務システムの相場に連携・移行・教育の工数を加えた、計画用の推定レンジです。

発注先の見積りの代わりにはなりません。予算の抜けに気づくための目安として使います。

• PoC・小規模アプリ：300万〜800万円程度で、期間の目安は1〜2か月です。
• 部門業務アプリ：800万〜2,000万円程度で、3〜6か月を見込みます。
• 基幹周辺システム：2,000万円〜1億円以上で、6〜12か月以上かかる可能性があります。

PoC・小規模アプリには、申請、台帳、現場アプリなどが含まれます。部門業務アプリでは、複数ロールとワークフローを想定します。さらに、既存DB・SaaSとのAPI連携、データ移行、受入テストも含めます。

基幹周辺システムのレンジは、SAPなどとの多数連携や全社展開を含む場合の目安です。そこには、高可用性、監査ログ、性能試験も含みます。

Mendix公式事例では、MammoetがSAPの25以上のODataサービスと連携する現場作業アプリを8週間で構築しています。また、DSM-Firmenichは新規アプリを平均8〜10週間で開発する事例として紹介されています。

これらは成功事例で、既存APIや意思決定の速さといった前提があります。対象範囲や利用者の参加も、条件に含まれます。そのため、短納期の数字を納期保証として引用しないようにします（出典: Mendix公式顧客事例・公開資料）。

保守・運用費の年次管理

ランニングコストは、ライセンスやインフラに加えて、保守・運用支援の費目ごとに考えます。

• 基盤：ライセンス、コンピュート、DB、ストレージ、監視、バックアップ。
• 保守：サポート、障害対応、軽微な改修、バージョンアップ。
• 運用支援：教育など、契約に含める範囲。

一般的な業務システムの参考値では、保守運用費を初期開発費の年15〜25％、または月15万〜80万円程度と置く場合があります。ただし、Mendixの契約、クラウド、サポート費を含むかどうかで、額は大きく変わります。

見積りでは「保守一式」とせず、項目ごとに分けて書いてもらいます。項目には、問い合わせ時間と障害受付、緊急対応、改修人日が含まれます。定例会や監視は、個別の項目として扱います。バックアップ確認と更新対応も、別々に挙げてもらいます。

利用者数やアプリ数が増えたときの条件も確認し、3年間の総保有コストで比べます。

Mendixの見積りを取る際のポイント

安さだけで比べると、連携や移行が後から追加されやすくなります。テストや教育も、後から加わることがあります。そのため、RFPや相談資料には、対象業務と利用者数を書きます。画面・帳票、ロール、外部システムも、あわせて記載します。

データ件数や非機能、希望時期もそろえます。さらに、成果物と保守範囲も同じ条件にして、複数社に確認します。

工程と成果物の分解の確認

見積りでは、工程、成果物、前提条件を照合し、画面数以外の難易度も確かめます。たとえば、1画面でも複雑な権限や状態遷移があれば、工数は上がります。

• 工程：要件定義と基本設計、環境構築、開発と連携、移行とテスト、リリース、教育と保守の区分。
• 見積り条件：作業、担当、期間、成果物、前提を工程ごとに確認します。
• 難易度：権限、状態遷移、検索、ファイル処理、API、監査ログを見ます。
• 前提の確認：API仕様、移行元データ、利用者レビューの状況。

一般的な業務システムの参考配分は、要件定義が10〜12％、設計と環境構築が22〜24％です。実装は48〜50％、テストは15〜17％です。ただし、Mendixでは実装以外の比率が高い案件もあります。

開発会社の認定と実務体制

認定者数だけでなく、同種案件の経験と本番までの体制を比べます。

• 実績：対象業界・アプリ種別、PoCから本番への移行経験。
• 技術対応：SAP・認証連携、移行、性能・セキュリティ試験。
• 支援体制：運用・保守、内製化支援、担当者の本番参加。
• 契約後：成果物、再委託、保守移管、窓口、復旧目標。

提案では、業務担当者を含むスプリントの計画を確かめます。未決事項の開示と、モデル・設計書の引き渡しも確認し、再委託先も把握します。

担当予定者が、提案時だけでなく本番まで参加するかも確認します。

自社に近いデータ量や連携数、規制要件への対応方法を聞きます。社名や期間だけで判断しないようにします。

追加費用が出やすいリスクへの事前対応

追加費用につながる原因を洗い出し、その対応方法を契約や見積りに反映します。

• 要件・連携：要件の後出し、外部APIの仕様変更。
• 品質・定着：移行不備、権限再設計、受入遅延、現場教育の不足。

「発生したら協議する」で済ませず、契約書や提案書に、変更管理の方法と影響分析の単位を書きます。承認者、予備工数、追加単価も記載します。

Mendix公式は、ISO/IEC 27001:2022や27017、27018、27701を案内しています。SOC 1・SOC 2 Type IIなども挙げられています（出典: Mendix公式「Enterprise Security – Compliance」、2026年8月確認）。

プラットフォームの認証と、自社アプリの法令・社内規程への適合は、分けて考えます。ロールやログ、個人情報の扱いも、自動的に満たされるわけではありません。委託先についても、自動では満たされません。

自社の監査部門やセキュリティ部門のレビュー工数も、見積りの前提に含めます。

よくある質問（FAQ）

Mendixの導入では、開発期間、無料プランの本番利用、基幹システムとの連携が、よく疑問に挙がります。

Mendixなら本当に短期間でシステムを開発できますか？

検証期間と本番稼働までの期間は、分けて考えます。

• 短期検証：小さなMVPや、既存APIを使える業務アプリなら、短期間で検証しやすいです。
• 本番稼働：期間は、画面数のほか、要件整理・データ移行、権限・性能・監査、利用者教育にも左右されます。
• 公式事例：8週間や40日は、範囲と体制が整った案件の実績で、自社案件の納期保証にはなりません。

Mendixの無料プランを本番システムに使えますか？

無料プランは、デモやプロトタイプ、小規模な個人利用を試す入口になります。公式説明によると、Freeでは無償で設計・開発・デプロイを試せます。

ただし、スリープやリソースに制限があります。運用情報、サポート、可用性の面にも制限があります。業務停止を許容できない本番では、必要なユーザー数や環境数を満たす有償プランを比べます。運用体制も合わせて、バックアップや監視、SLAを確認します。

Mendixは基幹システムやSAPと連携できますか？

連携できますが、接続できることと安全に業務運用できることは別です。候補は、SAPのODataや、REST、SOAPです。既存データベースも候補になります。

認証方式、データの正本、更新頻度を設計します。エラー時の再送、トランザクション、監査ログも設計に含めます。

基幹を一度に置き換えるより、申請、ポータル、現場作業などの周辺領域から始める方が、リスクを抑えやすくなります。

Mendixは将来、別の会社や自社に保守を移管できますか？

移管は可能ですが、契約とドキュメントの準備が必要です。引き渡しの対象は、ソースコードのほか、ドメインモデルとMicroflow・Nanoflowを定めます。設計書とテスト仕様も含め、環境設定とCI/CDも対象に入れます。

バックアップや障害履歴、ライセンス契約も整理します。再委託条件も、あわせて確認します。契約が終わるときに、必要なアカウントや権限を移せるかを確かめます。移管先にMendix認定や運用経験があるかも、発注時に確認します。

まとめ

Mendixの開発は、業務担当者と要件整理から運用改善までを反復する取り組みです。まずKPIとデータ、権限、連携を定め、小さなPoCやMVPで確かめます。

その後は、異常系と移行を含むテスト、責任分界を決めた稼働、KPIを使った定着へと進みます。

着手前に確認したい3つの項目

Mendixの導入前に、業務、本番環境、運用体制の準備状況を確かめます。

• 業務と指標：改善対象と成果指標が明確か。
• 本番条件：連携、移行、セキュリティ、配置先を検証できるか。
• 費用と体制：3年間の費用と、社内の意思決定や利用者参加を確認します。

最初に選ぶ小さな業務

全社の基幹システムを一度に置き換えず、現場の負担が大きく、利用者がレビューに参加でき、既存APIやデータを使える業務を一つ選びます。

PoCでは技術の確認に加えて、意思決定の速さやデータ品質を確かめます。運用責任と現場の受容性も、あわせて見ます。その結果を、次のアプリや全社展開の計画に反映します。それが、定着につながる現実的な進め方です。

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

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