モール型ECシステム開発の発注/外注/依頼/委託方法について

モール型ECシステムの発注は、事業モデル、要件、契約、開発、運用の順に進めると、責任分界を保ちながら公開できます。

各段階で決めることを、見出しに沿って説明します。全体像は、モール型ECシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・モール型ECシステム開発の完全ガイド

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

発注前に知っておきたいモール型ECシステムの全体像

モール型ECシステムは、1つのEC基盤に複数のショップ、ブランド、事業者が参加して商品を販売する仕組みです。

購入者向けの画面に加えて、運営者と出店者の管理機能も検討が必要になります。

運営者・出店者・購入者の三者による要件の分け方

モールの要件は利用者ごとに異なるため、三者の機能を分けて整理します。

• 運営者：出店申請、審査、契約と利用規約を扱います。店舗停止、売上分析、問い合わせ管理、違反商品の監視も担当します。
• 出店者：商品登録と在庫・受注の管理を行います。配送登録、売上確認、精算書の閲覧も含みます。
• 購入者：共通会員IDと店舗横断の検索・カートを用意します。送料の表示、注文分割、返品・キャンセルの分かりやすさも要件になります。

三者の要件を混ぜると、運営者の管理画面が後回しになり、公開後の手作業が増えかねません。

テナント型とマーケットプレイス型の違い

店舗の運営を出店者と運営者のどちらが担うかで、方式が変わります。

• テナント型：楽天型に近い方式で、出店者ごとに店舗ページを持ち、商品登録や受注管理を行います。
• マーケットプレイス型：Amazon型に近い方式です。出品者が商品情報を登録し、運営者が販売体験や受注をまとめて管理します。

GMOクラウドECの公式説明では、テナント型、マーケットプレイス型、複数ブランドの一元管理方式が紹介されています。

方式を選ぶ際は、在庫保有者、発送者、店舗ごとの世界観を先に決めておくと、機能と発注先を絞り込めます。

自社モール構築と楽天・Amazon出店の発注対象の違い

楽天やAmazonの既存モールを利用する場合と、自社で基盤を構築する場合では、発注対象が異なります。

• 大手モールへの出店：契約、店舗設定、商品登録、運用代行などを外注します。
• 自社モールの構築：プラットフォームそのものが発注対象です。

自社モールでは、集客と出店者の獲得を自社の責任で設計します。さらに、不正対策、顧客データの利用、手数料設計、問い合わせ対応も自社で担います。

出店支援の見積もりを開発予算に使うと、金額も期間も大きく見誤ります。

モール型ECシステムの発注形態の選び方

標準機能で検証するなら、SaaSやパッケージが候補になります。

独自性や既存業務との連携を重視するならクラウド・ヘッドレス、独自の精算や業務モデルがあるならフルスクラッチが候補です。

方式は、自由度の高さで選ぶより、3年から5年後の機能と社内の維持体制を基準に決めます。

SaaS・パッケージ・クラウド・スクラッチの比較

方式ごとの違いは、初期費用、独自機能、連携、保守責任に表れます。選ぶ際は、各方式の特徴を次のとおり見ます。

• SaaS・ASP：標準機能の範囲に収まるなら、短期間かつ低い初期費用で始められます。
• オープンソース・パッケージ：標準機能を土台に、業務へ拡張できる方式です。
• クラウド・ヘッドレス：ECの中核を画面から切り離し、API連携がしやすい構成です。
• フルスクラッチ：自由度は高い一方で、開発後の保守責任も負うことになります。

SaaSでは、複雑な審査、独自の売上分配、返品責任、特殊な在庫引当が、追加開発や運用変更になる場合があります。

パッケージは、柔軟性と初期費用のバランスを取りやすい方式です。

クラウドやヘッドレス型は、ERP、WMS、POSと連携しやすいうえ、CRMやMAとの接続も容易です。

ブランド追加やアプリ展開にも適しています。

フルスクラッチでは、脆弱性対応、更新、障害復旧に加えて、開発者の確保も必要になります。

一括委託・伴走支援・段階発注の使い分け

一括委託、伴走支援、段階発注は、要件の確定度と、社内に残したいノウハウに応じて選びます。

• 一括委託：要件定義から公開までを、1社にまとめて任せます。
• 伴走支援：発注側と開発会社が共同で要件を整理する形です。
• 段階発注：事業モデル整理、業務フロー、概算見積もり、MVPの範囲を先に依頼し、その成果を見て本開発へ進みます。

一括委託は窓口を一本化できる一方、要件が曖昧なまま契約すると、変更費用や追加期間が膨らみます。

伴走支援は社内にノウハウを残せるため、内製化やベンダー交代にも向きます。

出店者数や注文量を読みにくい新規モールでは、数店舗、主要カテゴリ、標準決済に絞って検証すると効果的です。

分割発注では、成果物の所有権、API仕様、テスト環境、保守窓口を最初の契約に記しておきます。そのため、後続の会社が参加できる状態を保てます。

RFPと要件整理の準備範囲

RFPは、開発会社に提案と見積もりを求める依頼書です。

完璧な仕様書までは要りませんが、各社に同じ前提を渡すことが欠かせません。

RFPには、事業目的、対象ユーザー、現状業務、必須機能を前提としてそろえます。

制約や希望時期、予算の考え方、提案事項も書き添えます。

前提が異なると、価格差の理由を判断できません。

事業モデルと業務フローの整理

事業モデルと業務フローは、誰が責任を持つか、収益をどう得るかを先にそろえてから、RFPに書きます。前提がそろわないと、各社の見積もりを比べられません。RFPで決めておく点は、役割、収益、工程です。

• 役割：誰が出店し、在庫、代金、配送、返品を担うかを決めます。
• 収益：収益源には、販売手数料、月額出店料、広告料、サブスクリプションがあります。
• 工程：申請、審査、登録、承認の担当と例外を決めます。受注から精算まで、発送、キャンセル、返品、売上確定の担当と例外も決めます。

複数店舗の商品を一つにまとめて見せながら、裏側で注文を分割する場合があります。その場合は、送料、決済、在庫引当、部分キャンセル、発送通知、返金の処理単位を決めておく必要があります。

通常の単店舗ECの機能一覧では抜けやすい要件です。そこで、注文例を3件から5件ほどRFPに添えておくと、各社が同じ前提で見積もれます。

モール固有の機能の必須・希望・将来の分類

モール固有の機能は、必須、希望、将来の優先度で分けておくと、初期開発を抑えつつ、将来の拡張も含めて提案してもらえます。

• 必須：テナント登録・審査、店舗別権限、商品承認、価格・在庫、共通会員。横断検索、複数店舗カート、注文分割、決済、配送、返品。手数料計算、精算書、監査ログ。
• 希望：ポイント、クーポン、レビュー、ランキング、レコメンド。広告枠、LINEやメール配信、店舗受取。
• 将来：海外展開、BtoB価格、複数ブランド統合、AIによる商品情報作成や問い合わせ対応。

出店者の既存の販売・在庫システムとのAPI連携も、検討の対象になります。

運営者向けには、売上やGMV、出店者別のKPIに加えて、欠品、違反商品、不正注文の監視が必要です。

RFPに入れる非機能要件とセキュリティ

規模、稼働、復旧、権限、監視などの条件は、性能と安全性の見積もりに直接関わります。RFPには、次のとおり記します。

• 規模・性能：テナント、商品、アクセス、通常時と繁忙期の注文数。
• 運用：稼働時間、復旧目標、バックアップ、監視、ログ保存期間などを取り決めます。
• 安全対策：権限分離、管理画面の多要素認証、脆弱性診断、WAF、障害時の連絡体制。

テナント間でデータが混ざると、重大な事故につながります。そのため、他店舗の商品、注文、顧客情報を閲覧できないことを、テストの条件にします。

カード情報は自社で保持しない方式を優先し、決済代行会社とは、どこまでを誰が受け持つかを確かめます。

経済産業省の「クレジットカード・セキュリティガイドライン」5.0版では、EC加盟店の不正利用対策としてEMV 3-Dセキュア導入が示されています。

2026年時点の決済要件として、確認が必要です（出典：経済産業省「クレジットカード・セキュリティガイドライン」5.0版、2024年）。

購入・閲覧履歴を出店者へ共有する場合は、利用目的、第三者提供、委託、記録、安全管理を、法務と一緒に整理します。

個人情報保護委員会の通則ガイドラインは、2026年6月に一部改正されました。そのため、契約前に最新版を確認します（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年改正）。

モール型EC開発の契約形態（請負と準委任）の使い分け

契約形態は、要件の確定度と成果物の明確さで選びます。

要件定義や業務整理は準委任、仕様と検収条件が固まった開発は請負が候補になります。

全工程を一つの契約にまとめず、要件定義は準委任、本開発は請負、公開後の保守は別契約にする方法もあります。

請負契約と準委任契約の違い

契約の違いは、完成責任を負うか、作業や推進を依頼するかにあります。工程の性質に応じて、条件を決めておきます。

• 請負：成果物を完成させ、検収を受けることが中心になります。
• 準委任：専門作業やプロジェクトの推進を依頼する契約です。

請負では、画面、API、バッチ、帳票、エラー処理を定義します。テスト結果と操作マニュアルも含めます。

準委任では、稼働時間、担当者、会議体、報告内容、意思決定方法を決めます。

検収・変更管理・知的財産の条件

検収の条件と変更の承認手順を契約に書いておくと、想定外の追加費用や納期変更を防ぎやすくなります。契約では、受入条件、変更管理、責任分界の扱いを決めておきます。

• 受入条件：正常系に加えて、店舗横断注文、部分返品、精算差異、在庫不足を確認するシナリオです。決済失敗、権限違反、繁忙期負荷も含みます。
• 変更管理：追加費用・納期の承認者を決め、軽微な修正を保守範囲に含めるかを定めます。
• 責任分界：発注者の判断やデータ提供の遅れを、どちらの責任として扱うかです。

ソースコード、設計書、API仕様、テストコード、データモデル、デザイン素材について、帰属と利用範囲を確認します。なお、別の会社へ切り替える可能性があるなら、引き継ぎ資料とデータも納品対象に含めます。

第三者サービスやオープンソースのライセンス表示、生成AIを使った成果物の扱いは、契約担当者と開発会社に確認します。

公開後の保守・SLA・運用分担の契約

公開後の業務とシステム保守を誰が担うかを決めます。運用代行の有無によって、必要な機能と月額費用が変わります。

• 業務運営：出店審査、商品承認、問い合わせ、違反対応。売上確定、精算、キャンペーン設定。
• システム保守：障害受付、復旧目標、営業時間外対応、計画保守、パッチ期限を、SLAや手順書に記します。
• 出店者の増減：アカウント発行、退店時のデータ保持、売上確定後の返金、規約違反による販売停止。
• 責任分界：業務判断は発注者、技術調査と改修は委託先が担います。

モール型ECシステムの費用相場と開発期間の目安

モール型ECシステムの公的な平均価格は確認できません。

本記事の金額は、公開EC開発相場とGMOクラウドECの目安を組み合わせた推定です。

標準機能中心なら初期数百万円から、大規模なカスタマイズや基幹連携は数千万円規模です（出典：GMOクラウドEC「モール型ECサイト構築」、2026年確認）。

実際の費用は、テナント数、商品数、注文量、決済・精算方式、既存システム数で変わります。そのため、数字は予算取りのレンジとして扱い、RFPで見積もりの精度を高めます。

構築方式別の初期費用レンジの目安

初期費用は、方式と機能範囲によって変わります。目安の幅を比べるときは、月額費用や手数料も合わせて見ます。

• SaaS・ASP：小規模な数店舗の商品集約検証では、初期0円から300万円程度、月額5万円から50万円程度。決済・販売手数料も加わります。
• パッケージ拡張：500万円から3,000万円程度。
• クラウド・ヘッドレス：複数の基幹連携を含む場合、初期300万円から数千万円。
• 複雑なクラウド・ヘッドレス：1,000万円から5,000万円超になる場合があります。
• フルスクラッチ：独自の精算、審査、配送、会員統合を中核資産として作る場合、3,000万円から2億円程度。

公開価格のあるサービスでも、実装、連携、導入支援は別見積もりになることがあります。

また、大規模なBtoB・BtoC統合や高負荷対応では、2億円から数億円になる可能性があります。上記は要件に基づく推定で、固定価格ではありません。

モール固有機能と連携で分ける費用の内訳

モールの見積もりでは、ECの基本機能とモール固有機能、導入作業の範囲を分けて確認します。

• 構築：要件、業務設計、UI・UX、画面が含まれます。会員、商品、注文、決済も入ります。
• モール固有：テナント管理、承認、注文分割、手数料、精算、監査。
• 導入：外部連携、移行、テスト、セキュリティ、教育、公開支援。

単店舗ECと異なり、テナント権限、商品承認、店舗別売上、返金、精算書が必要です。これらをまとめてEC機能として見積もると、比較しにくくなります。

運用費には、クラウド利用料、ライセンス、決済手数料を含めます。監視・WAF、保守、脆弱性診断も、運用費として見込みます。

さらに、バックアップ、追加開発、出店者サポートを加えます。CS、審査担当者、販促費も、忘れずに入れておきます。

Shopify Japanの公開試算では、中規模ECの5年TCOが約1億8,300万円という例が示されています。そのため、初期費用だけでなく運用費も含めて考えます（出典：Shopify Japan「フルスクラッチとは｜EC開発の費用・期間・パッケージ比較」、2026年確認）。

自社モールでは、出店者を集める営業・審査コストと、売上増加時の問い合わせ・精算コストも、5年TCOに入れます。

MVPと本格構築の開発期間の目安

期間は方式と要件によって異なります。要件定義やデータ移行を含むかどうかは、提案ごとに確認します。

• SaaS：標準フローで数店舗を試す場合は、1か月から3か月程度。
• パッケージ拡張：4か月から12か月程度。
• クラウド・スクラッチ：基幹連携や複雑な精算を含む場合は、6か月から18か月程度。
• 大規模案件：多数のテナント、複数国、複数ブランド、厳格な監査・可用性要件がある場合、12か月から24か月以上になる可能性があります。

GMOクラウドECのFAQでも、最短4か月から1年程度を目安として示しています。要件定義や移行期間を含むかは、提案ごとに確認します（出典：GMOクラウドEC「モール型ECサイト構築」、2026年確認）。

モール型ECの委託先選定と見積比較の観点

委託先は、知名度や総額と合わせて、類似事例の機能、導入後の運用者、トラブル時の支援範囲を確認して選びます。

自社に近いモール事例の機能単位での確認

EC-CUBE公式事例では、Diezonが店舗別管理画面や店舗受取に対応するデリバリーモールを開発しています。同社は、マルチテナント型の中古トレーディングカードECも手がけました。

具体的な実装事例は、自社の業務フローと照らし合わせて見ます。確認するのは、次の観点です。

• 業務：テナント型か出品型か、在庫、注文分割、返品、売上分配。
• 規模：出店者数、商品数、権限、ピーク負荷。
• 連携：配送、決済代行、基幹システムとの接続。

あわせて、たとえば食品、医薬品、地域産品、中古品、BtoBなど、自社に近い業界の画面やデータフローも見ます。

提案書では、「標準機能」「設定」「追加開発」「運用」「対象外」を分けて記してもらいます。

GMOクラウドECはERP、WMS、POS、CRM、MAとのAPI連携を訴求しています。EC-CUBEもテナント型とマーケットプレイス型の事例を公開しています。

連携方式と再送、マスタの正本、保守体制も確認します。

見積もりの前提と含まれない費用のそろえ方

見積もりの前提をそろえると、価格差の理由を判断できます。比べるのは、規模、連携、移行、テスト、保守の条件です。

• 規模・画面：テナント、商品、接続数、端末、ブラウザ。
• 機能・連携：決済、配送会社、連携先、移行データ。
• 品質・運用：テスト範囲、保守期間、教育、診断。

安い見積もりでは、要件定義、デザイン、移行、脆弱性診断、負荷試験、運用教育が含まれていない場合があります。

各社の費目は、要件定義、設計、開発、連携、移行で分けて見ます。

テスト、公開支援、保守も分けて、追加費用の条件を確認します。

ライセンス、クラウド、決済、監視は別欄にします。

サポート、交通費、外部サービスも別欄にしたうえで、5年総額と年度別支払計画で比べます。

提案の品質とプロジェクト管理力の評価

提案の実現性は、要件の理解、代替案、リスクへの対応から判断します。評価では、次の点を確認します。

• 計画：工程表、体制、担当者の経験、未決事項への対応。
• 要員：PM、業務設計者、テックリード、安全・運用担当。
• 連携：決済、物流、基幹担当を含む会議体と意思決定ルール。

未決事項に期限と判断材料を示す会社は、不確実性を扱う力があります。一方で、機能を無制限に約束し、移行やテストを短縮する提案は、追加費用につながる可能性があります。

契約後も同じ担当者が続くかを確認します。

複数の企業をつなぐモールでは、技術力に加えて調整力も成果を左右します。

モール型ECシステムを発注して公開するまでの進め方

発注は、事業モデル、要件、提案比較、契約、テスト、移行を経て公開します。

工程ごとの完了条件を決めておくと、運用設計の抜けを防げます。

企画・RFP・提案比較による発注条件の固め方

企画では、公開時に実現する事業範囲と、目的を測るKPIを定めます。

KPIには、GMV、出店者数、購入者数、購入率を含めます。リピート率、平均注文額、継続率、精算時間なども設定します。

あわせて、テナント型かマーケットプレイス型か、MVPのカテゴリや出店者数、既存システム、予算、希望公開日も整理します。

RFPを3社から5社程度に配る場合は、回答様式を統一します。各社に同じ条件を示したうえで比べます。

• 提案内容：必須機能、追加開発、標準機能の制約。
• 計画・費用：体制、工程、初期・月額費用、5年TCO。
• 根拠：類似事例、想定リスク。

提案の時点で、購入者画面に加えて、審査、承認、注文分割、精算差異、退店処理も見せてもらいます。

設計・開発・テストでの業務シナリオの使い方

注文分割や精算の例外まで扱えるよう、データ設計とテストシナリオを結び付けて整理します。

• データ：商品、店舗、会員、注文のIDと正本。決済、在庫、手数料、精算のIDと正本。
• 管理画面：購入者、運営者、出店者の画面と権限、承認履歴、操作ログ。
• テスト工程：単機能、結合、総合、受入、負荷、脆弱性診断。
• 業務確認：店舗横断注文、部分キャンセル、送料再計算、部分返金。
• 運用確認：手数料端数、精算差異、権限外アクセス、移行・復旧訓練。

APIでは、失敗、重複、タイムアウト、再送、在庫差異の扱いを定義します。

注文テストでは、片方だけのキャンセルも試します。また、出店者データの移行リハーサルと障害復旧訓練は、公開前に行います。

データ移行・教育・段階公開によるリスクの抑え方

データの正確さと運用開始後の混乱を抑えるため、移行、教育、段階公開を進めます。公開までに、次の準備を行います。

1. 移行対象として、商品、画像、価格、在庫、店舗を洗い出します。会員、注文、ポイント、クーポン、出店者情報も対象です。
2. 移行対象外と変換ルールの決定、商品コード・会員IDの対応表の作成。
3. 移行データの件数と金額の突合。
4. 本番データをテストで使う場合は、マスキングとアクセス権を設定します。
5. 運営者・出店者の研修、FAQ、窓口、障害告知テンプレートの準備。
6. 社内店舗や協力的な数店舗で先行公開し、注文、配送、精算、返品を確認します。

先行公開後は、対象を広げていきます。その際、商品・在庫・注文データを整え、将来連携できる基盤にしておきます。

2026年は、生成AI、API、MCP、Agentic Commerceへの対応が注目されています。

矢野経済研究所の推計では、2025年度の国内ECプラットフォーム市場は2,397億5,000万円です（出典：矢野経済研究所「ECプラットフォーム市場に関する調査を実施（2026年）」）。

需要の中心は、新規構築だけでなく、既存ECのリニューアルや機能高度化へ移っています。

よくある質問

発注では、費用に加えて、標準機能の範囲と自社で担う業務が論点になります。相談前によく確認される質問に答えます。

モール型ECシステムの発注予算はいくら用意すればよいですか？

必要な初期予算は、SaaSで数店舗を試すのか、独自の大規模モールを作るのかで大きく変わります。下の4つの方式を比べると、初期費用の幅が見えてきます。

• SaaS：標準機能で数店舗を検証する場合、初期0円から300万円程度。
• パッケージ拡張：500万円から3,000万円程度の初期費用。
• エンタープライズ：基幹連携を含む場合、数千万円規模。
• 独自の大規模モール：3,000万円から数億円まで幅があります。

ここに示すのは、テナント数、注文量、精算、連携、セキュリティ、運用範囲で変わる、見積もり前のレンジです。公的な平均価格ではありません。

初期費用のほかに、5年間の保守、クラウド、決済、運用人件費も確認します。

最初はSaaSで始めて後からスクラッチへ移行できますか？

移行は可能ですが、商品、店舗、会員、注文のIDとAPIを意識して設計します。

在庫、決済、精算のIDとAPIも意識します。

SaaS固有のデータ形式や契約に依存していると、移行時の作り直しが増えます。そのため、外部連携、データ出力、権限、ログ、移行条件を、契約前に確認しておきます。

モール開発会社を選ぶときに必ず聞くべきことは何ですか？

類似事例、出店者管理、精算、ERP・WMS・POS連携を確認します。

安全対策、障害対応、運用体制、5年TCO、担当者の経験まで聞きます。

標準機能、追加開発、対象外、月額費用、追加費用の条件を分けてもらいます。また、提案、開発、保守の担当者が同じ前提を共有するかも確認します。

セキュリティ要件は開発会社に任せてよいですか？

委託先には基本対策の提案を求めます。一方で、利用目的、データ共有、保存期間、障害判断、法務対応は、事業者が決めます。

RFPには、権限分離、多要素認証、WAF、ログ、バックアップ、診断を記します。カード情報の非保持、EMV 3-Dセキュア、不正ログイン対策も含めます。

誰が設定、監視、報告するかは、契約で定めます。

まとめ

発注では、購入者向け画面より先に、運営者、出店者、購入者の業務と責任を整理します。

そのうえで、方式を選び、RFPには商品、注文、決済、在庫を記します。精算、連携、安全対策も書き込みます。

業務と5年TCOによる判断の仕方

小規模なSaaS導入の初期費用は0円から300万円程度です。パッケージ拡張は500万円から3,000万円程度で、基幹連携を含む場合は数千万円規模になります。独自の大規模モールは、3,000万円から数億円まで幅があります。

これは公開情報に基づく見積もり前の範囲で、金額を約束するものではありません。

比べるときは、保守、クラウド、決済、監視を含む5年TCOで見ます。加えて、追加開発、審査、CS、精算担当も対象に入れます。

最初の相談で持参する業務フローと質問票

相談の前に、資料をそろえておきます。

• 業務フロー：出店申請から精算までの流れと、注文例。
• 既存システム：想定テナントと商品の情報を、資料にまとめます。
• 注文量と希望時期：数字で示しておきます。
• 予算と運用体制：あわせて用意します。

提案では、事例、標準機能と追加開発、契約を確認します。検収、保守、安全対策、データ移行・返却についても確認します。

小さなMVPから始め、データを見て拡張すると、発注リスクを抑えられます。

▼全体ガイドの記事
・モール型ECシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【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を創業。