Mendixのシステム開発の発注/外注/依頼/委託方法について

Mendixのシステム開発を発注・外注するなら、ローコードによる開発速度だけでなく、要件整理、外部連携、データ移行、運用設計まで含めて委託範囲を決めることが重要です。Mendixは短期間で業務アプリを形にしやすい一方、業務を理解した発注者と認定人材を含む開発チームの協働が成否を左右します。

この記事では、Mendixのシステムを外注するときの発注形態、RFPと要件の整理方法、契約形態、費用相場、委託先の選び方、見積書の比較ポイントを順番に解説します。PoCから本番運用、内製化や別会社への移管まで見据え、価格だけで発注先を決めないための実務的な判断軸を整理します。

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

Mendixのシステムを発注・外注する前に知るべき全体像

Mendixのシステムは、画面だけを短時間で作るサービスではありません。ドメインモデル、画面、MicroflowやNanoflowによる処理、ワークフロー、認証・権限、API連携、データベース、テスト、デプロイ、監視を一つの開発基盤で扱う業務アプリケーションプラットフォームです。したがって発注時は、プログラムの作成量ではなく、業務成果と運用責任の単位で委託内容を定義します。

ローコードは、定型的な画面やデータ処理をモデルで組み立てられるため、実装の反復を減らしやすい点が魅力です。しかし、利用部門へのヒアリング、業務ルールの整理、データ項目の定義、既存システムとの接続、権限設計、例外処理、性能試験は別途必要です。コードを書く時間が短くなっても、何を作るべきかを決める時間や、作ったものを現場で使える状態にする時間まで自動的に消えるわけではありません。

外注先から「2か月で作れます」と提案された場合も、画面の試作品までなのか、API連携・データ移行・受入テスト・本番監視まで含むのかを分けて確認します。Mendix公式の導入事例には、2名のコンサルタントが他システム連携と400機能ポイントを含むアプリを8週間で構築した例がありますが、これは発注者の意思決定、対象業務、体制、既存連携の条件がそろった個別事例です（出典: Mendix公式「Dutch Railways Automates Incident Registration System」）。

Mendixのシステムを外注しやすいのは、申請・承認、営業支援、保守・フィールドサービス、在庫・物流、顧客・従業員ポータル、現場モバイルなど、業務の流れと利用者が比較的定義しやすい領域です。既存の基幹システムを残し、周辺の業務をMendixで追加する構成なら、全社刷新より小さく始められます。レガシー画面を段階的に置き換える場合も、対象業務を一つずつ区切ると効果を測りやすくなります。

一方で、会計・販売・生産の中核を一度に置き換える案件、複雑な計算や大量データを扱う案件、高い可用性や厳格な監査が必要な案件は、最初から本番全体を発注しない方法が安全です。代表画面、認証、主要API、データ量、権限エラー、連携失敗を含むPoCを先に実施し、Mendixで持つ領域とパッケージや既存基幹に残す領域を判断します。

発注形態はどれがよい？PoC・一括請負・段階委託の選び方

発注形態は、要件の確かさ、社内にいるMendix人材、納期の固定度、発注者が負うリスクの許容度で決めます。初めてMendixを使う企業や、既存データ・連携仕様が不明な企業は、いきなり全機能を一括発注するより、検証と本開発を分けるほうが適しています。

PoCでは、4〜8週間程度を一つの計画上の目安として、主要画面、ドメインモデル、ログイン、代表的なAPI連携、権限、データ移行の一部を検証します。成果物は動く画面だけではなく、実現できた範囲、未解決の制約、本番に必要なインフラ、概算工数、次工程の受入基準まで含めます。正常系だけを確認すると、本番でAPIが遅い、連携データが欠ける、利用者の権限が広すぎるといった問題を見逃すためです。

PoCを本開発の値引き交渉だけに使うと、検証の目的がぼやけます。PoCの終了条件として「代表業務を利用部門が操作できる」「既存認証でログインできる」「APIエラー時の再送方法が決まる」「データ移行の品質を測れる」など、判定可能な項目を置きます。終了後に継続・設計変更・中止のどれを選ぶかも、発注前に合意しておくと予算を管理しやすくなります。

業務の優先順位が見えている場合は、MVPを第1段階として発注し、利用後の改善を第2段階以降に分けます。第1段階では、最も頻度が高く効果を測りやすい業務に絞り、利用者数、処理時間、紙やExcelの削減量、承認の滞留時間などをKPIにします。Mendix公式事例では、DSM-Firmenichが150以上のアプリを提供し、新規アプリの開発期間を平均8〜10週間と紹介していますが、こうした速度は、既存の開発標準、体制、再利用部品、意思決定の仕組みが整った結果です（出典: Mendix公式「Accelerate App Delivery at Scale with Mendix and AWS」）。

発注者は、スプリントごとに優先順位を決めるプロダクトオーナーを置きます。外注先に業務判断まで丸ごと渡すと、完成してから「現場では使えない」と分かりやすいためです。利用部門、情報システム部門、セキュリティ担当、経理・法務などを必要なタイミングで参加させ、短いサイクルで画面と業務ルールを確認します。

社内に業務知識を持つ人がいるなら、外注先には最初の設計・実装だけでなく、Mendix Studio Proの教育、レビュー、開発標準、リリース手順、障害対応の引き継ぎまで依頼します。逆に、社内に開発・運用の時間を確保できない場合は、受託開発と保守を中心に契約し、社内は意思決定と業務受入に集中します。どちらが正解かではなく、運用開始後に誰がモデルを変更し、誰が障害を切り分けるかで体制を決めます。

内製化を目指す場合は、納品物にアプリだけを含めないことが大切です。ドメインモデルの設計意図、Microflowの例外処理、API仕様、権限マトリクス、テストケース、環境設定、バックアップ方法、バージョンアップ方針、問い合わせ履歴も成果物に含めます。社内の担当者が一人だけ理解している状態は、担当者の異動時に新たなロックインになるためです。

RFPと要件整理の進め方｜Mendixの外注範囲を明確にする

RFPは、機能の一覧を渡して価格を聞く書類ではありません。なぜ開発するのか、誰が使うのか、既存業務のどこを変えるのか、どのシステムとつなぐのか、どの品質を本番の合格とするのかを、候補会社が同じ前提で見積もれるようにする資料です。要件が曖昧なまま比較すると、安い会社が要件を含めていないだけという事態が起こります。

RFPの冒頭には、システム名よりも業務課題を書きます。たとえば「申請を電子化する」だけではなく、「申請から承認まで平均何日かかっている」「差し戻し理由を追跡できない」「現場が外出先で登録できない」といった現状を記します。対象部門、拠点、利用者の役割、同時利用の見込み、処理件数、繁忙期、達成したいKPIまで整理すると、候補会社は画面数だけでなく必要な性能や運用を考えられます。

現行業務は、業務フロー、帳票・Excel、データ項目、承認ルール、例外処理の五つに分けると整理しやすくなります。特に「通常は上長承認だが、金額が一定以上なら部長承認」「通信できない現場では一時保存する」といった例外を先に書き出します。これらが後から追加されると、モデルや権限、テストの作り直しが発生し、Mendixの短期開発の利点が小さくなります。

外部連携は、システム名だけでなく、方式、方向、頻度、データ量、エラー時の扱い、担当者を記載します。SAP、販売管理、会計、顧客管理、認証基盤、既存データベースなどとつなぐ場合は、APIが利用できるか、仕様書を提供できるか、テスト環境があるか、連携元と連携先のどちらが改修を担当するかを決めます。Mendix側の実装費だけを比較し、相手システムの改修費や接続試験を除外すると、後から予算が膨らみます。

非機能要件には、可用性、応答時間、同時利用者数、バックアップ、復旧目標、ログ保存期間、暗号化、脆弱性対応、監査、データ保管地域、社内ネットワークとの接続を含めます。Mendix公式ドキュメントでは、Mendix Cloud、SAP BTP、Kubernetes、Docker、Azure、オンプレミスなど複数の配備先が案内されていますが、配備先によって利用できる機能や運用責任が異なります（出典: Mendix公式「Deploying Apps」、2025年7月更新）。「クラウドで動けばよい」ではなく、発注前に責任分界を決めます。

成果物は、アプリ本体だけでなく、要件定義書、画面・帳票一覧、ドメインモデル、権限設計、API仕様、データ移行設計、テスト計画・結果、操作マニュアル、運用設計、監視設定、リリース手順、ソースやモデルの引き渡し方法まで明記します。Mendixでは見た目の画面が似ていても、モデルの構造や再利用部品の品質によって将来の改修費が変わります。そのため、設計意図を説明する資料も重要な納品物です。

受入基準は「問題なく動く」ではなく、具体的なシナリオで書きます。たとえば、通常申請、差し戻し、代理承認、権限外アクセス、APIタイムアウト、二重送信、データ移行後の件数照合、バックアップからの復旧などです。発注者がいつまでに何を確認し、未達の場合の修正と再テストをどう扱うかまで合意すれば、納品直前の認識違いを減らせます。

契約形態の選び方｜準委任・請負・保守をどう分けるか

Mendixの発注では、要件が固まっている工程と、利用者の反応を見ながら変える工程を同じ契約にしないことが大切です。PoCや要件整理は準委任、本番機能のうち仕様と受入条件が固まった範囲は請負、リリース後の問い合わせや改善は保守契約と分けると、変更の責任と費用を整理しやすくなります。実際の契約は案件の法務・調達ルールに合わせ、専門家の確認を受けます。

準委任は、業務や画面を一緒に検討しながら、専門家の作業や助言を依頼したいときに向きます。PoC、現行調査、アーキテクチャ検討、MVPのバックログ作成、アジャイル開発の初期段階では、作業内容が変化しやすいためです。契約書や個別発注書では、担当者、作業時間、会議体、報告物、品質確認、再委託、秘密保持、情報セキュリティ、知的財産の扱いを明確にします。

準委任でも品質管理が不要になるわけではありません。スプリントごとのデモ、レビュー記録、課題一覧、意思決定ログ、未完了事項を残し、どの範囲が次の発注に含まれるかを確認します。作業時間だけを管理すると、不要な画面を作り続ける可能性があるため、KPIやユーザーストーリーと結び付けて進捗を評価します。

請負は、完成させる対象、仕様、納期、検査方法、受入基準が明確な範囲に向きます。たとえば、定義済みの申請機能、画面・帳票一式、合意済みのAPI連携、テストと本番リリースなどです。ただし、業務ルールや連携仕様が未確定のまま一括請負にすると、変更が追加費用・納期延長として現れやすくなります。請負にする場合は、前提条件、除外事項、変更管理、瑕疵への対応、再委託の有無を確認します。

特に確認したいのは、Mendixのモデルやアプリ資産を誰が利用できるかです。ソースコードだけでなく、アプリモデル、設計書、テスト仕様、環境設定、CI/CD定義、運用手順、翻案や二次的利用の権利、契約終了後の別会社への移管条件を契約に記載します。サービス提供者が変わっても自社が業務を継続できる状態を、納品と契約の両面から作ります。

保守では、問い合わせ窓口、受付時間、障害の重要度、一次回答と復旧の目標、監視、バックアップ、脆弱性対応、Mendixのバージョンアップ、外部APIの仕様変更、軽微な改善の月間上限を決めます。保守費に含まれない大規模改修、データ修復、クラウド基盤の変更、夜間対応を別項目にすると、毎月の費用と突発費用を分けて管理できます。

契約期間が終わるときの移管も保守の一部として考えます。アカウント、リポジトリ、環境、証明書、バックアップ、監視設定、問い合わせ履歴の返却・削除、移管支援の時間単価、秘密情報の取り扱いを確認します。Mendix公式のセキュリティ情報にはISO/IEC 27001:2022、27017、27018、27701、SOC 1・SOC 2 Type IIなどが掲載されていますが、プラットフォームの認証だけで自社アプリの設計・運用責任がなくなるわけではありません（出典: Mendix公式「Enterprise Security – Compliance」、2026年確認）。

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

Mendixの費用は、ライセンス、クラウド・インフラ、要件定義、設計・環境構築、実装、連携、データ移行、テスト、教育、保守を分けて考えます。ライセンス価格だけで開発総額を判断すると、委託費や本番運用費を見落とします。以下の金額は公開情報と一般的な業務システム相場から作った計画用の推定レンジであり、正式な見積りではありません。

2026年8月時点でMendix公式Pricingページに表示される開始価格は、Freeが月額0ユーロ、StandardがOne Appで月額918ユーロから、Unlimited Appsで月額2,295ユーロからです。Premiumは要見積りです。StandardとPremiumでは、必要なコンピュートリソースがライセンス価格に含まれず、選んだクラウドや構成に応じて別途費用が発生すると説明されています（出典: Mendix公式「Mendix Pricing」、2026年8月確認）。為替、アプリ数、利用規模、可用性、契約条件で実際の金額は変わるため、日本円への機械的な換算で予算を確定しません。

Freeは試作や小規模アプリの検証に使えますが、公式説明では、サポートや稼働保証を求める場合は有料プランへの変更が必要です。本番で使うなら、ライセンス、クラウド、データベース、監視、バックアップ、ネットワーク、認証、サポートのどこまで含むかを契約書と見積書で確認します。Azureなど自社クラウドに配備する場合は、AKS、データベース、ネットワーク、ストレージ、監視などのリソースが自社契約に発生する可能性もあります。

PoCや小さな申請・台帳・現場アプリなら、画面数、権限、簡単な外部連携、利用者テストまでを前提に、開発委託費は300万〜800万円、期間は1〜2か月程度が計画上の目安です。ライセンス、クラウド、教育、社内側の工数は別に見積もります。短い期間でも、認証や例外処理を省いてよいという意味ではありません。

部門業務アプリで複数ロール、ワークフロー、既存データベースやSaaSとの連携、データ移行、受入テストまで含める場合は、800万〜2,000万円、3〜6か月程度を一つの検討レンジにします。基幹周辺の全社展開、高可用性、SAPなどとの多数連携、監査ログ、性能試験、冗長化、運用設計、教育まで含める場合は、2,000万円〜1億円以上、6〜12か月以上になる可能性があります。いずれもMendix固有の定価ではなく、一般的な業務システムの相場とMendix案件の要件を踏まえた推定です。

人月単価を使う見積りでは、PMが90万〜150万円、設計SEが65万〜110万円、実装担当が50万〜90万円、テスターが45万〜80万円程度という参考値があります。Mendixは実装のコード量を減らせても、業務設計、データモデル、連携、権限、テスト、運用設計の工数をなくしません。見積書は要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度という一般的な工程比率を参考に、工程ごとの人数と期間が説明されているか確認します。

保守運用は、一般的な業務システムの参考として、初期開発費の年15〜25%、または月15万〜80万円程度を計画に置く方法があります。ただし、Mendixのライセンス、クラウド、サポート、監視、障害対応、改善の範囲は契約ごとに異なります。海外拠点を含む24時間対応、厳しい復旧目標、大量データのバックアップ、頻繁な改善を含めると、このレンジを超える可能性があります。

見積依頼時には、初期費用だけでなく、1年目と2年目以降の総保有コストを出してもらいます。ライセンスの増減条件、ユーザー数やアプリ数の単位、クラウドの従量費、環境数、バージョンアップ、追加API、問い合わせ時間、教育、内製化支援、契約終了時の移管費を同じ表に並べると、会社間の比較がしやすくなります。

委託先の選定ポイント｜Mendix開発会社を比較する方法

委託先は、Mendixを扱える会社というだけでなく、対象業界の業務知識、連携・移行の経験、アジャイルでの意思決定、保守体制、内製化や移管の支援力で比較します。Mendix公式パートナーディレクトリに掲載されているかは確認材料の一つですが、認定者数だけでは自社案件の品質を判断できません。候補会社には同じRFPを渡し、同じ質問と同じデモ課題で比べます。

実績を聞くときは、「Mendixの導入実績がありますか」だけで終わらせません。自社と近い業界か、利用者数と拠点数はどの程度か、SAP・認証・会計など何と連携したか、データ移行を誰が担当したか、PoCから本番まで何か月かかったか、稼働後の障害や改善をどう支援しているかを聞きます。可能なら、営業資料だけでなく担当予定者が参加する場で、設計判断と失敗からの改善方法を説明してもらいます。

公開事例の数字も、納期保証として扱わないことが重要です。Siemensの財務部門では、中規模アプリを40日で開発した事例が紹介されていますが、対象業務、チーム、既存の開発環境、利用者テストの条件があります（出典: Mendix公式「Mendix Enables Siemens Finance Teams to Develop Their Own Applications」）。候補会社には、自社案件なら何が同じで何が違うのか、短縮できる工程と短縮できない工程を分けて説明してもらいます。

提案時は、プロジェクトマネージャー、業務設計者、Mendix開発者、連携担当、テスター、保守責任者の氏名または役割を確認します。認定者が営業説明だけに参加し、実装は経験の浅い別チームや再委託先が担当する場合もあるためです。再委託の範囲、所在地、情報アクセス、障害時の連絡経路、担当者交代のルールをRFP回答に含めます。

保守では、平日の日中だけでよいのか、休日や夜間の重大障害に対応するのかを決めます。初動時間、復旧目標、暫定対応と恒久対応の区別、月次レポート、監視アラートの扱い、Mendixのバージョンアップ検証、外部サービスの変更管理を確認します。価格が低い提案ほど、何が含まれず、追加時にいくらかかるのかを具体的に聞くことが大切です。

外注を続ける前提でも、発注者がアプリの構造と費用を把握できる状態にします。候補会社には、社内研修、ペア開発、レビュー、運用引き継ぎ、ドキュメント整備、認定取得支援の有無を聞きます。特に、軽微な画面変更や権限変更を社内で実施できるのか、どの変更は委託先に依頼すべきかを線引きします。

契約終了時に、別会社が引き継げる成果物と権利があることも選定基準です。モデル、リポジトリ、環境設定、APIキーの管理方法、テストデータ、障害履歴、バックアップ、ライセンス契約の名義、第三者コンポーネントの利用条件を確認します。引き渡しができない理由を「Mendixなので仕方がない」と説明する会社には、契約上の根拠と代替案を求めます。

見積書を比較するときのチェックポイント

見積書は合計金額の安い順に並べるのではなく、同じ範囲で比較できる状態に整えます。工程、作業内容、成果物、担当人数、期間、前提条件、除外事項、追加単価、ライセンス・クラウド費用、保守費を横並びにします。特に「要件定義一式」「開発一式」「テスト一式」のような一式表記が多い場合は、作業の境界を質問します。

候補会社ごとに、要件定義に含む会議回数、設計レビューの回数、画面・帳票数、API本数、データ移行の対象、テストデータ作成、性能試験、脆弱性診断、利用者教育、本番立ち会いを確認します。A社はデータ移行を含み、B社は発注者担当、という差があれば、金額の大小だけでなく発注者側の負担も含めて評価します。

除外事項は、費用を増やすための隠れた条件ではなく、前提を明らかにするための重要な情報です。既存APIの提供、マスタデータの整備、ネットワーク開通、アカウント発行、端末調達、移行リハーサル、現場立ち会いなど、発注者が用意するものを一覧化します。除外事項が多い場合は、発注者側の工数と外注先への追加発注を別予算に置きます。

Mendixのシステム開発は、画面を見て現場の要望が変わりやすい開発です。見積書には、要件変更の判定方法、追加見積りの回答期限、スプリント内で吸収できる変更、納期に影響する変更、連携先の仕様変更、データ移行の品質不備の責任分担を記載します。変更を一切認めない契約よりも、変更のルールを先に作った契約のほうが、実態に合った運営をしやすくなります。

リスク一覧には、権限漏れ、API障害、データ重複、性能不足、バックアップ失敗、環境差異、現場教育不足、担当者交代、ライセンス条件の変更、ベンダーロックインを入れます。各リスクに対して、発生条件、早期兆候、予防策、発生時の担当、予備費や予備期間を置きます。見積りが安くても、リスクの記載や対策がない提案は、将来の追加費用が見えにくい提案です。

比較の最後は、初年度総額と3年程度の継続費用を見ます。ライセンスの開始価格だけでなく、開発、教育、テスト、移行、クラウド、監視、保守、追加アプリ、ユーザー増加、バージョンアップ、契約終了時の移管までを含めます。Mendix公式Pricingページでも、One AppとUnlimited Appsは技術的な機能差ではなく、アプリ構成に応じて選ぶ考え方が示されています。将来複数アプリを作るなら、1本だけの見積りと全体ポートフォリオの見積りを両方出してもらいます。

候補会社に最終提案を依頼するときは、「本見積り」と「変動しうる仮見積り」を分けてもらいます。確定した範囲、検証が必要な範囲、発注者の判断待ち、第三者サービスの費用を色分けし、予算承認者が不確実性を理解できるようにします。安さではなく、総額の見通し、成果物の品質、現場定着、将来の変更可能性を合わせて委託先を決定します。

よくある質問（FAQ）

Mendixのシステム発注では、開発期間、内製化、既存システムとの連携、ライセンス費用について質問を受けます。最後に、発注前に特に確認されやすい点をまとめます。

小さなPoCや申請アプリなら1〜2か月、複数API連携を含む部門アプリなら3〜6か月、基幹周辺や高可用性・多数連携を含む案件なら6〜12か月以上が計画上の目安です。Mendix公式事例には8週間や40日での開発例がありますが、対象範囲や体制が異なるため、そのまま納期保証にはできません。要件、連携、データ移行、受入テストを含む工程表で判断します。

最初から完全内製にする必要はありません。Mendixに詳しい会社へPoC、設計、最初の実装、開発標準、教育を依頼し、社内担当者がレビューと運用に参加する段階的な方法があります。社内に業務判断をする担当者を置き、モデル、テスト、運用手順を引き継げる契約にすると、外注先への依存を抑えながら内製化を進められます。

REST、OData、SOAP、データベース接続などを使った連携を検討できます。実現可否は、対象システムのAPI、認証、ネットワーク、データ量、更新頻度、エラー時の再送、既存側の改修可否で決まります。RFPでは「SAPと連携」とだけ書かず、どのデータをどちら向きに、いつ、何件、どの品質で連携するかを定義し、連携元の担当会社も含めて見積りを依頼します。

無料プランは、学習、デモ、プロトタイプ、小規模アプリの検証に向く位置付けです。公式Pricingページでは、Freeには本番の稼働保証や製品サポートがなく、Free Appには規模や稼働時間などの制限があると説明されています。本番業務で使う場合は、必要な可用性、サポート、バックアップ、ユーザー規模、クラウド費用を確認し、有料プランと開発・運用費を合わせて判断します。

まとめ

Mendixのシステムを発注・外注するときは、まず業務課題とKPIを整理し、Mendixで作る領域と既存の基幹・SaaSに残す領域を分けます。不確実性が大きい場合は、4〜8週間程度のPoCで主要画面、認証、API、権限、データ、性能を検証し、その結果を本開発の範囲と見積りに反映します。

RFPでは、機能だけでなく、連携、データ移行、非機能、成果物、受入基準、保守、内製化、契約終了後の移管まで指定します。費用は、公式料金のライセンス、クラウド・インフラ、開発委託費、教育、保守を分け、初年度と継続費用の総額で比べます。Mendix公式の短期開発事例は参考になりますが、自社の前提条件を説明できる提案かどうかを確認することが重要です。

委託先は、認定者数や合計金額だけでなく、業務知識、連携・移行の経験、担当チーム、変更管理、障害対応、成果物の権利、別会社への移管可能性で選びます。複数社に同じRFPを渡して工程・前提・除外事項を揃えて比較すれば、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を創業。