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

Mendixのシステム開発は、業務をそのまま画面化するのではなく、要件整理から定着までを短い反復で進めるローコード開発です。成功のポイントは、作る速さだけでなく、データ・連携・権限・運用を最初から一つの計画に含めることです。

「Mendixならすぐに安く作れるのか」「どの順番で進めれば失敗しないのか」「開発会社から出てきた見積りの何を確認すればよいのか」と悩む方も多いのではないでしょうか。この記事では、Mendixのシステムを導入する流れを、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分け、判断基準、費用の見方、見積り時のチェック項目まで具体的に解説します。

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

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

Mendixは、Siemens傘下のMendixが提供するエンタープライズ向けローコード・アプリケーション開発プラットフォームです。画面を素早く作るだけではなく、業務部門とIT部門が同じモデルを見ながら、設計、検証、リリース、改善を繰り返せる点に特徴があります。

開発者はMendix Studio Proで、業務データの構造を表すドメインモデル、Webやモバイルの画面、サーバー側の処理を表すMicroflow、端末やブラウザ側で動くNanoflowを組み立てます。申請・承認のような人手の流れはワークフローで表現し、REST、OData、SOAP、データベース、SAPなどの外部サービスとも連携できます。作成したモデルはMendix Runtime上で動作し、Mendix Cloud、AWSやAzure上のKubernetes、SAP Business Technology Platform、オンプレミスなどに配置できます。

この構造から分かるように、Mendixのシステム開発ではプログラムの記述量が減っても、業務ルールやデータの意味を決める作業はなくなりません。特に、同じ顧客や製品を複数のシステムで管理している場合は、画面より先にデータの正本、更新権限、連携失敗時の扱いを決める必要があります。

Mendixが特に力を発揮しやすいのは、申請・承認、営業支援、保守・フィールドサービス、在庫・物流、製造現場のモバイルアプリ、顧客・従業員ポータル、レガシーシステムの段階的な刷新です。既存の基幹システムを残しながら、利用者が困っている周辺業務を先に改善し、APIで疎結合に連携する進め方は、全社を一度に置き換えるよりもリスクを抑えやすいです。

一方で、業務が標準化されていて変更も少ない場合は、SaaSやパッケージの方が短期間で運用を始められる可能性があります。Mendixを選ぶ基準は「ローコードだから安い」ではなく、業務の変化に合わせて自社で改善したいか、複数のシステムや部門をつなぐ必要があるか、内製チームを育てられるかで判断することが大切です。

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

進め方は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分けると、抜け漏れを管理しやすくなります。Mendixでは画面を先に試作できますが、試作の結果をそのまま本番仕様にせず、各フェーズの終了条件を決めてから次へ進むことが重要です。

最初に、Mendixで何を作るかではなく、誰のどの作業を、どの指標まで改善するかを決めます。現行業務を担当者へのヒアリングと画面・帳票の棚卸しで可視化し、利用者、処理件数、承認者、データの発生元、例外処理、権限、外部システム、法令・社内規程を整理します。

要件整理のチェックリストは、「対象業務と対象外業務が分かれているか」「処理時間や入力ミスなどのKPIを測れるか」「誰が最終承認者か」「マスタの正本はどこか」「API停止時に業務を継続できるか」「個人情報や監査ログの保存期間が決まっているか」です。ここで回答できない項目は、未決事項として責任者と決定期限を記録します。

次に、Mendix、SaaS・パッケージ、既存システムの改修、フルスクラッチのどこを選ぶかを比較します。定型的で差別化の少ない業務は標準機能に寄せ、部門ごとの判断や現場の変化が多い領域をMendixで作るFit to Standardの考え方が、スコープを膨らませにくいです。

配置先も早い段階で候補を絞ります。Mendix Cloudは導入しやすい一方、プライベートクラウドや自社運用を求める場合はMendix on Kubernetes、Mendix on Azure、SAP BTP、サーバーベースの構成を比較します。Mendix公式ドキュメントでは配置先ごとに利用できる機能や運用画面が異なると説明されているため、ネットワーク分離、データ保管地域、バックアップ、監視、障害対応の責任分界を要件として確認します（出典: Mendix公式「Deploying Apps」、2026年7月更新）。

設計では、画面の見た目より先にドメインモデルを設計します。顧客、申請、明細、承認、担当組織などのエンティティと関連、必須項目、状態遷移、重複防止を決めたうえで、権限モデルと画面を作ります。MicroflowとNanoflowの使い分け、同期・非同期の連携、エラー時の再送や利用者への通知も設計書に残します。

4〜8週間程度のPoCでは、代表画面だけでなく、認証、主要API、権限、データ登録、連携失敗、通信遅延、監査ログまでを一つの業務シナリオで通します。正常系のデモが動くことだけを成功条件にせず、「業務担当者が自分の言葉で受入条件を説明できること」「性能とセキュリティの未解決事項が一覧化されていること」を終了条件にします。

テストは、Mendixが自動的に品質を保証してくれる工程ではありません。単体相当のロジック確認、画面間の結合確認、API連携テスト、権限テスト、性能テスト、脆弱性確認、利用者受入テストを分け、各テストの担当者と合格基準を明確にします。

特に見落としやすいのは、異常系とデータ移行です。連携先がタイムアウトしたときに二重登録されないか、承認者が退職したときに申請が止まらないか、権限を外した後も古い画面やAPIにアクセスできないか、旧データの文字コード・日付・コード体系が変換できるかを確認します。移行は本番前に少なくとも一度リハーサルを行い、件数照合と業務担当者によるサンプル確認まで完了させます。

稼働前には、リリース判定会議で未解決の不具合、移行結果、バックアップ、監視、問い合わせ窓口、切り戻し条件を確認します。特に、Mendix Cloudや各クラウド環境で誰がデプロイを承認するか、環境変数や接続情報をどのように管理するか、障害時にMendix・開発会社・社内ITのどこへ連絡するかを決めておくことが重要です。

本番切り替えは、利用者が少ない時間に一度に実施する方法だけが正解ではありません。部門や拠点を限定した段階稼働、旧システムとの並行運用、機能ごとのリリースを比較し、業務停止の許容時間とデータ二重入力の負担から方式を選びます。Mendix公式のMendix Cloudではバックアップや監視、高可用性などの機能がプランによって異なるため、契約内容と社内運用を分けて確認します（出典: Mendix公式「Mendix Cloud」、2026年7月更新）。

稼働はゴールではなく、現場で使われて初めて成果が出ます。操作研修だけで終わらせず、役割ごとの業務シナリオ、問い合わせの受付方法、操作マニュアル、短い動画、よくあるエラーの解決方法を用意します。利用率、処理時間、差し戻し率、紙やExcelの併用件数などをKPIとして、稼働後30日、60日、90日で確認します。

内製化を目指す場合は、Mendix認定開発者を増やすだけでなく、業務部門のプロダクトオーナー、ITのアーキテクト、運用担当者の役割を分けます。開発会社からは、モデル、設計書、テスト仕様、環境設定、CI/CD手順、障害対応履歴、バックログを引き継ぎ、契約終了後に別会社や自社へ保守を移せる状態を作ります。AI支援で生成したロジックを使う場合も、権限、性能、例外処理、保守性を人がレビューする運用が必要です。

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

Mendixの費用は、プラットフォームのライセンス、クラウドやインフラ、要件整理・開発、外部連携、データ移行、テスト、教育、保守に分けて考えます。ローコードで実装工数が減っても、業務整理、データ品質、非機能要件、利用者の合意形成に必要な工数まで消えるわけではありません。

2026年8月に確認したMendix公式Pricingでは、Freeは月額0ユーロ、StandardはOne Appで月額918ユーロから、Unlimited Appsで月額2,295ユーロから、Premiumは要見積りと表示されています。One AppとUnlimited Appsはプラットフォームの技術機能に違いがなく、1つの大きなアプリから始めるか、複数アプリのポートフォリオを作るかで選びます（出典: Mendix公式Pricing、2026年8月確認）。

表示価格は契約条件や地域、利用規模で変わるため、そのまま日本円の予算に置き換えないことが安全です。また、StandardやPremiumでは必要なコンピュートリソースがライセンス料金に含まれないと公式FAQに記載されています。Mendix Cloud、専用クラウド、AWS・AzureのKubernetes、SAP BTP、オンプレミスでは、インフラ費用と運用担当の範囲が変わるため、ライセンスとクラウドを別項目で見積もります。

日本向けのMendix開発費に一律の公開価格はないため、以下は一般的な業務システム相場とMendixの連携・移行・教育工数を組み合わせた計画用の推定レンジです。発注先の見積りを代替する金額ではなく、予算の抜けを見つけるための目安として使用します。

申請・台帳・現場アプリなどのPoCや小規模アプリは、300万〜800万円程度、期間は1〜2か月が一つの目安です。複数のロール、ワークフロー、既存DBやSaaSとのAPI連携、データ移行、受入テストまで含む部門業務アプリは、800万〜2,000万円程度、3〜6か月を計画します。SAPなどとの多数連携、高可用性、監査ログ、性能試験、全社展開を含む基幹周辺システムは、2,000万円〜1億円以上、6〜12か月以上になる可能性があります。

期間については、Mendix公式事例でMammoetがSAPの25以上のODataサービスと連携する現場作業アプリを8週間で構築した例や、DSM-Firmenichが新規アプリを平均8〜10週間で開発している例が紹介されています。ただし、これらは成功事例であり、既存API、意思決定の速さ、対象範囲、利用者参加などの前提があります。短納期の数字だけを納期保証として引用しないことが大切です（出典: Mendix公式顧客事例・公開資料）。

ランニングコストには、ライセンス、クラウドのコンピュート・データベース・ストレージ、監視、バックアップ、サポート、障害対応、軽微な改修、バージョンアップ、教育が含まれます。一般的な業務システムの参考値として、保守運用を初期開発費の年15〜25％、または月15万〜80万円程度と置く場合がありますが、Mendixの契約・クラウド・サポート費を含むかどうかで大きく変わります。

見積りでは「保守一式」とまとめず、月間の問い合わせ時間、障害の受付時間、緊急対応、改修の人日、定例会、監視、バックアップ確認、プラットフォーム更新への対応を分けます。利用者数やアプリ数が増えたときのライセンス変更条件も確認し、3年間の総保有コストで比較することが重要です。

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

見積りの安さだけを比べると、後から連携、移行、テスト、教育が追加されやすいです。RFPや相談資料には、対象業務、利用者数、画面・帳票、ロール、外部システム、データ件数、非機能、希望時期、成果物、保守範囲を記載し、同じ条件で複数社に確認します。

要件定義、基本設計、環境構築、モデル・画面開発、連携、データ移行、テスト、リリース、教育、保守の工程ごとに、作業内容、担当、期間、成果物、前提条件を確認します。一般的な業務システムの参考配分として、要件定義10〜12％、設計・環境構築22〜24％、実装48〜50％、テスト15〜17％という見方がありますが、Mendixでは実装以外の比率が高くなる案件もあります。

特に「画面数」だけで工数を算出した見積りには注意します。1画面でも、複雑な権限、状態遷移、一覧検索、ファイル処理、外部API、監査ログがあれば難易度は上がります。見積りの前提に、API仕様が確定しているか、データ移行元の品質が確認済みか、利用者がレビューに参加するかまで記載されているかを確認します。

開発会社を選ぶときは、Mendix認定者数だけでなく、対象業界とアプリ種別の実績、PoCから本番への移行経験、SAPや認証基盤との連携、データ移行、性能・セキュリティ試験、運用・保守、内製化支援を同じ質問で比較します。担当予定者が提案時だけでなく、本番まで参加するかも確認します。

提案時のチェック項目は、「業務担当者を含むスプリントを提案しているか」「未決事項をリスクとして開示しているか」「モデルや設計書などの成果物を引き渡すか」「再委託先を把握できるか」「契約終了後に保守を移管できるか」「障害時の一次窓口と復旧目標が明確か」です。実績の社名や期間だけではなく、自社と似たデータ量・連携数・規制要件での対応方法を聞きます。

追加費用の主な原因は、要件の後出し、外部APIの仕様変更、データ移行の不備、権限設計のやり直し、受入テストの遅れ、現場教育の不足です。これらを「発生したら協議する」とだけ書かず、変更管理の手順、影響分析の単位、承認者、予備工数、追加単価を契約書や提案書に記載します。

また、Mendixのプラットフォーム認証と、自社アプリの法令・社内規程への適合は分けて考えます。Mendix公式はISO/IEC 27001:2022、27017、27018、27701やSOC 1・SOC 2 Type IIなどを案内していますが、アプリ側のロール設計、ログ保存、個人情報の取り扱い、委託先管理まで自動的に満たすわけではありません（出典: Mendix公式「Enterprise Security – Compliance」、2026年8月確認）。自社の監査部門やセキュリティ部門のレビュー工数も、見積りの前提に含めます。

よくある質問（FAQ）

Mendixの導入を検討すると、「本当に短期間で作れるのか」「無料版を本番で使えるのか」「大規模な業務システムに使えるのか」という疑問が出てきます。ここでは、判断を誤りやすい質問に直接回答します。

小さなMVPや既存APIを使える業務アプリであれば、短期間で検証しやすいです。ただし、要件整理、データ移行、権限、性能、監査、利用者教育まで含めた本番稼働の期間は、画面数だけでは決まりません。公式事例の8週間や40日という数字は、範囲と体制が整った案件の実績として参照し、自社案件の納期保証にはしないことが安全です。

無料プランは、デモ、プロトタイプ、小規模な個人利用を試す入口として使えます。Mendix公式の説明では、Freeは無償で設計・開発・デプロイを試せますが、スリープ、リソース、運用情報、サポート、可用性などに制限があります。業務停止が許容できない本番システムでは、必要なユーザー数、環境数、バックアップ、監視、SLAを満たす有償プランと運用体制を比較します。

連携できますが、接続できることと安全に業務運用できることは別です。SAPのOData、REST、SOAP、既存データベースなどを候補に、認証方式、データの正本、更新頻度、エラー時の再送、トランザクション、監査ログを設計します。基幹そのものを一度に置き換えるより、申請、ポータル、現場作業などの周辺領域から始め、連携品質を確認しながら拡張する方がリスクを抑えやすいです。

移管は可能ですが、契約とドキュメントの準備が必要です。ソースコードだけでなく、ドメインモデル、MicroflowやNanoflow、設計書、テスト仕様、環境設定、CI/CD、バックアップ、障害履歴、ライセンス契約、再委託条件の引き渡し範囲を定めます。契約終了時に必要なアカウントや権限を移せるか、別会社がMendix認定や運用経験を持つかも、発注時に確認します。

まとめ

Mendixのシステム開発は、画面を素早く作ることだけを目的にせず、要件整理から運用改善までを業務担当者と反復する取り組みです。要件整理でKPI・データ・権限・連携を決め、選定でMendixの範囲と配置先を絞り、設計・開発では小さなPoCとMVPで検証します。その後、異常系と移行を含むテスト、責任分界を決めた稼働、KPIを見ながらの定着へ進みます。

第一に、改善したい業務と成果指標が明確かを確認します。第二に、既存システムとの連携、データ移行、セキュリティ、クラウド配置を含めた本番条件で検証できるかを確認します。第三に、ライセンス、インフラ、開発、教育、保守、移管を含む3年間の費用と、社内の意思決定・利用者参加の体制を確認します。

最初から全社の基幹システムを置き換えるのではなく、現場の負担が大きく、利用者がレビューに参加でき、既存APIやデータを使える業務を一つ選びます。PoCで技術だけでなく、意思決定の速さ、データ品質、運用責任、現場の受容性まで確かめ、その結果を次のアプリや全社展開の計画に反映することが、Mendixを定着させる現実的な進め方です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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