返品交換管理システムの発注は、業務範囲の整理、連携要件の確定、段階的な導入の順で進めます。この順で進めると、受付から返金までの処理の改善につながります。
発注形態の選び方から、要件と契約、費用、委託先の比較まで順に見ていきます。
▼全体ガイドの記事
・EC・通販業向け返品交換管理システム開発の完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
EC・通販業向け返品交換管理システムの発注・外注の範囲
外注とは、返品業務のルールと連携要件を整理したうえで、業務の一部または全部をSaaS提供会社やEC開発会社などへ委託することです。委託先には、物流会社やシステムインテグレーターも含まれます。特に大切なのは、返品の判断と処理結果を次の業務へ渡す仕組みを発注に含めることです。
問い合わせ管理との違い
問い合わせ管理は、顧客との連絡内容を記録するものです。一方、返品交換管理システムは、注文情報や返品可否も業務の状態として扱います。
返送状況と検品結果を管理し、在庫の状態から交換品の引当、返金方法まで扱います。判定には、商品カテゴリや購入日、状態を使います。返品理由も含め、これらを使って判定をあとから再現できる点も違いです。
発注範囲の決め方
発注範囲は、返品処理の状態がどう移るかを整理して決めます。そうしておくと、対象業務の漏れを防げます。
- 対象範囲：顧客の申請画面だけにするか、返品後の社内処理まで含めるか
- 社内処理：承認、倉庫検品、在庫戻し、交換出荷、返金、会計連携を対象に含める
- 返品の前半工程：申請、本人確認、対象判定、承認、返送、入荷、検品の順
- 返品の後半工程：再販・B品・廃棄・修理への振り分け、交換または返金、顧客通知、分析へ進む流れ
発注書には、画面一覧に加えて、各状態の入口と出口、担当者、連携先を書いておきます。例外時の扱いも書き添えます。
発注形態の選び方（SaaS・パッケージ・物流委託・スクラッチ）
発注形態は、返品件数だけでなく、既存システムとの接続数や独自ルールの複雑さをもとに決めます。社内に運用担当者がいるかどうかも、判断の材料になります。
早く導入したい場合は返品特化SaaSが、標準機能と拡張性の両方を重視する場合はECパッケージやOMSへの追加開発が有力です。また、倉庫作業の負担を減らしたい場合は、物流会社や3PLへの委託が考えられます。さらに、複数ブランドや拠点の独自業務を統合する場合は、スクラッチ開発も候補になります。
SaaSを発注する場合の向き不向き
申請ポータルや返品理由の収集、ステータス通知を短期間で始めたい企業には、SaaSが向いています。基本的な返品・交換・返金の流れも利用できます。自社でサーバーを持たず、アップデートや一般的な障害対応をサービス側に任せられる点も利点です。
独自の返品期限やブランド別の承認階層、複雑な差額決済が標準外だと、追加開発や運用上の回避策が必要です。特殊な倉庫処理や会計仕訳が標準外の場合も、同じように判断します。
パッケージ拡張とスクラッチ開発の使い分け
方式を選ぶときは、既存データをどこまで活用できるかと、複数の業務をどこまで横断するかを比べます。
- 既存データ：返品機能を切り出す前に、受注・在庫・顧客データをどこまで使えるか
- 標準モデル：注文・在庫モデルを使った追加開発は、ゼロから作るよりデータの整合を保ちやすい場合があります。
- スクラッチ開発：複数の販売先や海外拠点、倉庫を横断し、定期購入、ギフト、修理品も含めてブランド別ルールを共通基盤にまとめる場合の候補です。
物流会社への返品業務の委託
受付、集荷、入荷、検品、再入庫、代替品発送までを物流会社や3PLへ委託する方法があります。倉庫スタッフの作業負荷を下げたい場合に有効です。
一方で、返品結果をEC・OMS・会計へ戻す連携の責任が曖昧になりやすい点には、注意が必要です。
返品受付番号や検品結果コード、在庫区分などは、データ項目として合意しておきます。返金可否や写真の保管、例外時の連絡期限も同じ項目に含めておくと、連携のずれを減らせます。
発注前のRFPと要件の整理
RFPは、開発会社から同じ前提で提案と見積を受けるための依頼書です。機能一覧に加えて、現状業務や解決したい指標も記載します。
連携対象やデータ量などの前提に加え、運用体制や制約条件、提案してほしい内容も含めます。例外処理を後回しにすると、見積の条件がそろわず、差が大きくなります。そのため、通常ケースと例外ケースを分けてRFPに書いておくのが安全です。
現状フローとKPIの書き出し
現状の業務と処理状況をつかむために、フローとKPIを書き出します。
- 現状フロー：注文から返金・会計までを図にし、申請、担当者確認、倉庫連絡、検品登録の流れを残す
- 業務規模：月間注文数、返品率、交換率、返品ピーク、SKU数などを数字で残す。チャネル数や倉庫数も含めます。
- 処理時間：交換品の出荷方法と、1件あたりのCS対応時間、受付から承認までの時間
- 処理日数：返品品が在庫へ戻るまでの日数と、返金完了までの日数を基準値として残す
- 問い合わせ件数：現状の件数
商品・注文・顧客・在庫・返品理由の定義のすり合わせ
システム同士の連携で食い違いが起きないように、データ項目と状態の定義をそろえておきます。
- コードの統一：表記の違いによる連携問題を防ぐため、商品コード、注文番号、明細番号、倉庫コードの一覧を作ります。
- 状態と正本：返品理由、検品結果、返金ステータス、在庫区分をそろえたうえで、どのシステムを正とするかの決定
- 返金状態：「返金済み」と「返金依頼済み」を同じ完了扱いにすると、二重返金の原因になります。
- 返品理由：サイズ、イメージ違い、不良、誤配送、配送中破損などの選択肢と補足欄を設け、商品改善にも生かします。
RFPに含める項目
RFPには、まず背景と目的、対象業務、利用者と権限を書きます。次に、チャネルや画面、業務ルールなどを示し、外部連携と移行データも含めます。さらに、性能やセキュリティ、運用保守の条件も必要です。
納期や予算の考え方、提案依頼事項も書いておきます。外部連携は「ECと連携」とだけでは相手先が伝わらないため、自社EC、楽天市場、Yahoo!ショッピング、Amazonを挙げます。OMS、WMS、配送会社、決済代行、会計システムも列挙します。
各連携について、API、Webhook、CSV、手動登録のどれを想定するかを示します。そのうえで、標準機能、追加開発、運用で補う範囲を分けて回答してもらいます。
契約形態の選び方：請負・準委任・SaaS利用契約
契約は、成果物と仕様がどこまで確定しているか、要件変更がどれくらい起きそうか、発注者がどこまで意思決定に加わるかで選びます。返品業務は、現場ヒアリングで例外が見つかりやすい領域です。そのため、すべてを一つの固定価格契約にまとめるより、要件定義と開発を分ける方式が合う場合もあります。
契約名よりも中身を確かめ、成果物や検収、変更管理、責任分界、知的財産、保守範囲を見ます。
請負契約が向く範囲
請負契約は、合意した仕様どおりにシステムや機能を納品し、検収を受ける形に向いています。
申請画面や管理画面、定義済みのAPI連携、テスト仕様書などは、完成条件を明確にできます。納品物と検収基準も、具体的に決めておけます。
返品可否のルールが未整理のまま契約すると、仕様変更のたびに追加費用と納期延長が生じます。そのため、要件定義の成果物を先に検収する段階設計が安全です。
準委任契約とSaaS利用契約の確認点
準委任とSaaSでは、契約上の責任や確認事項が違います。
- 準委任の用途：要件整理や業務分析、設計支援、アジャイル開発、プロジェクト管理など、専門家の作業や知見を受けたい場合に使います。
- 準委任の管理：成果物の完成を一方的に保証する契約ではないため、作業内容や稼働時間、会議体、報告物、品質確認の方法を定めます。
- SaaSの料金・運用：月額料金、初期設定費、従量課金、データ保管期間、障害時のSLAの水準
- SaaSの契約条件：解約時のデータ返却、再委託先、個人情報の取扱い、API仕様変更の通知期間
契約書での責任分界の明文化
返品受付の一次窓口や承認判断、返送案内、検品を、担当者ごとに表にします。在庫更新、返金、顧客通知、障害時の手動処理も、同じ表に加えます。
担当者は、発注者、開発会社、SaaS事業者、倉庫会社のいずれかです。決済情報を保持するか、決済代行会社に委ねるかも、契約と設計でそろえます。
IPAは、ECサイトの外部委託について、セキュリティ要件や運用時の対応、脆弱性診断、インシデント対応を契約で確認する考え方を示しています（出典：IPA「ECサイト構築・運用セキュリティガイドライン」、2023年公開、2026年8月確認）。
発注からリリースまでの進め方
発注後は、工程ごとに確認しながら段階的に進めます。
- 要件定義
- 設計・開発
- テスト
- データ移行
- 利用者への教育
- 段階リリース
業務部門やCS、物流、経理、情報システム、外部倉庫など、多くの部門が関わります。定例会に一部門だけが参加すると、承認ルールや会計処理の抜けが見つかることがあります。そのため、意思決定者と現場代表を先に決め、仕様変更の承認ルートも最初に用意しておきます。
要件定義での業務ルールの決定
返品を一貫して処理できるように、判断基準と、人が確認する範囲を決めておきます。
- 返品条件：返品期限や送料負担、セール品・衛生用品の扱い、未使用・開封済み、不良品の証跡
- 注文・返金：ギフト、定期購入、部分返金、差額交換、ストアクレジットの扱いと、高額返金の承認者
- 承認範囲：自動判定と人の承認を分ける。AIや自動ルールを使う場合でも、高額返金、規約外対応、在庫不足の交換は人が確認します。
- 本人確認：確認に失敗した申請は、人が確認する設計にします。
設計・開発での双方向連携の検証
画面や接続先の設計に加え、連携時の例外処理も検証の対象にします。
- 画面と通知：顧客向け申請ポータル、管理画面、倉庫向け画面、通知の具体化
- 接続と記録：API、Webhook、CSV入出力、権限、操作ログの定義
- 双方向連携：注文取込に加えて、返品承認や交換注文、在庫区分、返金結果をEC・OMS・WMS・決済・会計へ書き戻す連携を検証します。
- 例外処理：通信失敗、Webhook重複、APIタイムアウト、在庫引当後のキャンセル、返金済みデータの再送を、設計書とテストに含めます。
テスト・移行・段階リリースの実施
テスト、移行、実証運用の順に確かめ、結果を見ながら進めます。
- 返品・交換や複数チャネルの例外ケースを、実データに近い形でテストします。
- 移行前に注文・顧客・商品・在庫・返品履歴の対応表を作り、データの重複と欠損を検査します。
- 全ブランドを一度に切り替えず、1ブランド・1チャネル・1倉庫などで90日程度の実証運用を行います。処理時間や誤判定率を見て対象を広げます。
テストでは、サイズ交換や色違い交換、欠品、複数商品の一部返品、返品期限切れを検証します。配送中破損や開封済み、返金先不一致も、テストの対象です。モール注文や定期購入、ギフト、倉庫の検品差異も確認します。
EC・通販業向け返品交換管理システムの費用相場
返品専用のスクラッチ開発には、公表された統一価格がありません。費用は、対象チャネルや倉庫数、決済方式によって変わり、連携API、データ移行、監査要件でも差が出ます。
ここに示すのは、2026年8月時点の公開料金と、類似するEC・受注・WMS連携システムの開発規模をもとにした企画段階の目安です。確定見積ではないため、RFPの予算枠を考える材料として使います。
SaaS導入と初期設定の相場
公開料金にはサービスごとの違いがあるため、初期設定費と利用中の費用を分けて見積もります。
- 初期設定に含める作業：返品ポリシー、通知文、権限、CSVやAPIの初期接続、テスト、運用教育
- 利用中の費用：月額、従量、配送費、決済手数料を分けて試算します。
- 繁忙期の試算：申請件数に応じた月次費用と、最大費用の目安
Recustomerの返品・交換・注文キャンセル関連では、Basicプランの基本利用料金が月額16,500円（税込）からの事例があり、返品申請の従量課金は1,000円からの事例もあります。この料金例は、SUPER STUDIO「ecforceとRecustomerのAPI連携」発表（2025年確認）によるものです。契約内容や対象機能、連携先によって異なるため、共通の相場とはいえません。
ヤマト運輸の返品・交換サポートは、初期費用が55,000円から、月額固定費が11,000円、利用料が55円／データ（税込）です。受付フォーム構築費と宅急便運賃は別途見積もりです（出典：ヤマト運輸「返品・交換サポートサービスの利用料金」、2026年8月確認）。
SaaS導入の初期設定費は、計画上の幅として10万円から100万円程度を見ておきます。
既存ECへの追加開発と業務システム開発の相場
追加開発と業務システムでは、連携範囲や対象業務に応じて期間と費用が変わります。
- 既存ECへの追加：返品ポータル、管理画面、限定的な在庫・配送・決済連携なら3か月から6か月、300万円から1,000万円程度が目安です。
- 追加開発の価格差：標準APIの1チャネル・1倉庫なら下側、複数モール・独自カート・複数返金方法なら上側になりやすいです。
- 業務システムの範囲：OMS、WMS、決済、会計との連携に加え、検品、再入庫、移行、監査ログを含みます。
- 業務システムの目安：上記の範囲では、6か月から12か月、1,000万円から3,000万円程度で検討されることがあります。
見積書での費用の分け方
見積項目は、開発、移行・品質、運用、利用料に分けて比較します。
- 開発：要件定義、UX・画面設計、バックエンド開発、API連携
- 移行・品質：データ移行、テスト、セキュリティ診断
- 運用：インフラ、運用教育、保守
- 利用料：SaaS利用料、配送費、決済手数料
「連携一式」「保守一式」「移行一式」の項目には、対象データ件数、接続先、作業時間、成果物、障害時の対応を質問します。総額だけで安い受付フォームと高い業務システムを比べると、後工程の手作業や追加費用を見落とすおそれがあります。
返品交換管理システムの委託先の選び方
委託先は、企業規模や知名度よりも、返品処理のどの工程まで支援できるかで選びます。候補には、返品特化SaaS、ECやOMSの実装会社、物流・WMS連携会社、スクラッチ開発を得意とするSIerがあります。商品・注文・在庫・決済の連携経験、例外ルールの設計力、リリース後の運用支援を、同じ質問票で確かめます。
業務工程ごとの実績の確認
委託先の実績は、画面の制作数よりも、返品業務のどこまで対応してきたかで見ます。
- 導入工程：返品受付から返金・在庫復帰まで手がけた事例の有無を見ます。ECサイトの制作件数だけで判断しないようにします。
- 導入規模と体制：対象チャネル、月間申請件数、倉庫数、EC・OMS・WMS・決済との連携、導入期間、運用体制
- 導入効果：導入後に改善したKPIの実績
Recustomerは、返品・交換・キャンセルの自動化とecforceとのAPI連携を案内しています。コマースメディアのHENPIN Proは複数販売チャネルと物流連携を掲げ、ヤマト運輸は受付と配送網を組み合わせたサービスを提供しています。各社は得意領域も責任範囲も異なるため、支援範囲の異なる候補として比べます。
技術と運用体制の確認項目
技術要件と運用体制は、委託先に確認します。
- 技術対策：API認証やWebhook再送、エラー通知、在庫の排他、二重返金防止などの仕組み。データ暗号化、権限分離、監査ログの扱い
- 継続性：バックアップや復旧目標、脆弱性診断、障害時の連絡先と一次切り分け、手動処理への切り替え
- 運用体制：月次改善会議、仕様変更の通知、担当者の退職や再委託への備え
経済産業省は2025年3月改訂のガイドラインで、EC加盟店に脆弱性対策、EMV 3-Dセキュア、不正ログイン対策を求めています（出典：経済産業省「クレジットカード・セキュリティガイドライン改訂」、2025年3月、2026年8月確認）。
返金機能を含むため、費用に加えて、決済情報を処理する場所も委託先と確かめます。
自社に合う支援範囲の見極め
返品件数や連携範囲、社内要件に応じて、必要な支援先を選びます。
- 申請・通知から始める：月間返品件数が少なく、まず受付と連絡の仕組みを整えたい企業は、SaaSで効果を測る方法が現実的です。
- 倉庫業務まで設計する：複数モールの受注をまとめる場合は、EC・OMS・WMSに詳しい会社が候補になります。
- 基幹や会計と連携する：複数ブランドの規約や監査要件が強い場合は、業務分析ができるSIerや開発会社が候補です。
候補先には、標準機能と個別開発、運用で残る業務を示してもらい、社内の負担も含めて判断します。
見積の比較ポイント
最安値を選ぶ前に、各社が同じ範囲を見積もっているかをそろえます。機能や連携、移行、テスト、セキュリティ、教育を横並びで比べます。
保守や従量費、配送費、将来の追加開発も比べます。返金と在庫の整合、倉庫への指示、失敗時の再処理は、金額と品質の両方を左右します。
同じ前提での3社程度への依頼
候補をRFPの依頼先として3社程度に絞り、同じ質問に答えてもらいます。候補が多すぎると、比較が難しくなります。
概算見積や前提条件、対象外の範囲を尋ねます。さらに、開発日程や体制、類似実績、リスクも確かめます。発注者側の作業と追加費用の条件も、同じ質問票に入れておきます。
提案説明には、営業だけでなく、要件定義や開発、連携、保守の各責任者にも加わってもらいます。そうすると、契約後の体制を確かめやすくなります。
見積差が出たときに確認する質問
見積金額に差が出たら、その理由を確かめ、前提が曖昧な項目を明らかにします。
- 価格差の理由：金額差が出たら、なぜ安いのか、なぜ高いのかを機能単位で尋ねます。
- 安くなる条件：標準機能の利用、API連携がなくCSVで連携する構成、発注者側での移行作業は、安くなる理由になり得ます。
- 高くなる条件：保守や診断を含む見積は、高くなる場合があります。
- 一式の確認：連携先やテスト範囲が曖昧な場合は、採用前に前提条件を書面にしておきます。
選定時に避けたいリスク
返品受付だけを自動化して、倉庫と会計を別のExcelに残すと、業務が分断されます。返品理由が自由記述のままだと、分析に使いにくくなります。
規約とシステム判定が一致しない状態や、無承認での返金自動実行は避けます。カスタマイズが過ぎて、特定の担当者しか運用できない事態も起こり得ます。
操作マニュアルや管理者権限、ログ確認、手動復旧、データ出力の方法を、納品物に含めます。担当者が代わっても業務を続けられる状態にします。
発注時の法務とセキュリティの確認事項
返品交換管理では、氏名や住所、注文履歴を扱います。配送状況や返金先、問い合わせ内容、商品写真なども対象になります。
利用目的、保管期間、アクセス権限、再委託、国外移転を確かめます。削除やバックアップ、事故時の報告期限も確認します。カード情報は可能な限り自社で保持せず、決済代行会社のトークンや返金APIを利用する設計にします。
返品特約とシステム判定の一致
通信販売では、返品可否や期間、条件、送料負担などの返品特約を、顧客に分かりやすく表示する必要があります。
消費者庁は、インターネット通信販売の最終確認画面でも申込み内容を容易に確認・訂正できる表示を求めています（出典：消費者庁「特定商取引法ガイド 通信販売広告Q&A」、2026年8月確認）。
商品ページ、注文画面、最終確認画面、返品申請画面、メールの文言を、社内規約と照合します。システムの判定条件も、同じ照合の対象に含めます。
委託先に求めるセキュリティ要件
委託先に求める対策や運用時の確認事項、RFPへの記載事項を、順に整理します。
- アクセス管理：管理画面への多要素認証や最小権限、操作ログ、IP制限の設定、APIトークンの発行・保管・更新・失効の手順
- 運用時の対策：脆弱性診断、パッチ適用、バックアップと復旧テスト、障害通知、開発環境での個人情報マスキング
- RFPへの記載：「セキュリティ対応」の一語で済ませず、対象範囲、実施時期、報告書、是正期限を書き込みます。
IPAのガイドラインは、構築時の脆弱性対策、運用時のソフトウェア更新、ログ確認、バックアップについて整理しています。
よくある質問
発注・外注時の疑問は、費用だけでなく、導入範囲や契約、データ連携、運用体制の面から考えます。
返品件数が少なくてもシステムを発注できますか？
発注できます。返品件数が少ない場合は、初期開発を行うより、SaaSの標準機能や申請・通知・CSV連携から始める方法が適しています。
返品率や対応時間、返金完了日数、問い合わせ削減などを測り、効果が確認できたら倉庫や会計との連携を追加します。
RFPは専門家に作成してもらうべきですか？
社内で整理できる範囲と、外部に支援を頼む範囲を分けて考えます。
- 自社で作成：現状フローと課題を社内で整理できるなら、最初のRFPは自社で書けます。
- 要件定義を依頼：データ定義、APIの責任分界、非機能要件、検収条件の整理が難しければ、発注者側の支援会社へ依頼できます。
- 候補先へ同じ資料：開発会社に有利な仕様だけに偏らないよう、複数の候補へ同じ内容を渡します。
- 第三者レビュー：外部の目で見直す方法も有効です。
返品業務の外注とシステム開発の外注は同じ会社に依頼できますか？
同じ会社に依頼できる場合もありますが、得意領域は会社によって異なります。SaaS会社はソフトウェア、物流会社は集荷・検品・出荷に強い傾向があります。
SIerは、複数システムの統合や業務設計に強い傾向があります。まとめて依頼する場合は、障害やデータ不整合時の窓口と責任分界を契約で定めます。再委託先を含めた体制図も確かめます。
開発費用を抑えるにはどうすればよいですか？
対象チャネルと倉庫を絞り、標準SaaSや既存ECのAPIを使うことが基本になります。返品理由やステータスの定義を、あらかじめそろえておくことも欠かせません。
不要な画面を減らすことに加えて、手作業で残す業務を明らかにし、将来の追加開発も見込んだデータ設計にします。
初期費用のほか、月額や従量、配送、保守の費用も含めます。担当者の作業時間や障害時の損失も入れて、総保有コストで比べます。
まとめ
発注では、申請フォームだけでなく、返品の判断から返送、検品までを含めて考えます。在庫、交換、返金、会計、分析まで、一つの業務フローとして定義します。
SaaS、パッケージ拡張、物流委託、スクラッチ開発は、独自ルール、連携数、返品件数、倉庫体制、社内の運用能力で使い分けます。
発注を成功させる要点
発注前には、状態遷移やKPI、データ定義、連携先、例外ルールをRFPに盛り込みます。
見積は、要件定義や開発、連携、移行、テストに分けて比べます。セキュリティや保守、SaaSや配送の従量費も分け、3社程度へ同じ条件で依頼します。
契約では、成果物と検収、変更管理を明文化します。障害対応やセキュリティ、データ返却、再委託、運用責任もあわせて書き込みます。
小さな実証運用による改善
小規模な実証運用で効果を測り、その結果を返品業務や商品改善に生かします。
- 対象を絞って試す：全業務を最初から作り込まず、1チャネルや1倉庫などの範囲で実証します。
- 処理の効果を測る：受付から返金までの時間、問い合わせ削減率、交換転換率、在庫復帰日数、誤判定率、1件あたりの処理コスト
- 改善に反映する：返品理由を商品説明、サイズ表、梱包、品質の改善へ戻す循環を作ります。
▼全体ガイドの記事
・EC・通販業向け返品交換管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。