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

ebisumartのシステム発注は、まず業務とデータを洗い出し、次に発注形態と責任範囲を決めて、最後に要件・費用・委託先を比べる順に進みます。

この記事は、次の順に解説します。全体像は、ebisumartのシステム開発の完全ガイドもご覧ください。

• 発注形態の選び方
• RFP・要件整理で決める項目
• 契約形態とebisumartのシステム費用相場
• 委託先と見積書の比較ポイント

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

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

ebisumartのシステムを発注・外注するときの全体像

ebisumartは、商品・会員・受注・在庫・決済・販促を扱うクラウド型のEC基盤です。業務フローやデータ連携も含むため、発注では作るものだけでなく、担当範囲も決めておく必要があります。

ebisumartが担う領域とCRM・MAの違い

ebisumartは、商品登録、注文、在庫引当、決済、出荷、返品を処理するEC基盤です。さらに、会員属性や購買履歴も蓄積できます。

CRM・MAとの連携範囲を決めるには、役割とデータ管理を分けて考えます。

• CRM・MAの役割：営業案件管理、メール配信、複数チャネル分析を担います。
• 外部製品との分担：営業活動や高度な配信を外部CRM・MAに任せる設計も候補になります。
• データの正：会員ID、商品コード、注文番号、同意・配信停止情報のそれぞれの管理元

データの正を決めないまま連携すると、重複顧客や誤配信が起きやすくなります。そこで、担当部署が必要とするデータと利用目的を、RFPに記載しておきます。

標準・オプション・独自開発の三層

発注範囲は、標準機能、公式オプションや既存アプリ・API連携、個別カスタマイズの三つに分けます。機能の置き場所を先に決めておくと、発注対象を洗い出しやすくなります。

• 標準機能：商品や会員の基本管理
• オプション・連携：POSや基幹とのデータ連携
• 個別カスタマイズ：独自の承認フローや複雑な価格計算

独自仕様を増やすと業務に合わせやすい一方で、開発・テスト・保守の費用が増えます。標準機能が更新されたときの影響も確かめる必要があります。また、2026年3月時点の公式機能一覧には、POSや一元管理システムとの連携機能も案内されています。

既存機能で代替できる部分は個別開発を避け、初期費用と将来のTCOを抑えます。

発注形態の選び方

発注形態は、自社のEC・IT担当者が持つ時間、技術、業務知識に照らして選びます。選択肢は、提供元への直接相談、開発会社への委託、自社主導の複数社体制の三つで、責任範囲と調整コストを比べて判断します。

提供元への直接発注

提供元へ直接相談すると、標準機能や料金、公式オプション、更新方針を確かめやすい点が利点です。

直接相談では、相手の適性と、担当範囲や契約の形を確かめます。

• 相談先としての適性：初回検討や導入可否を早く判断する場面に向きます。
• 対応範囲：基幹業務や社内調整まで一社で担うとは限らず、デザイン、移行、連携、教育の担当範囲
• 契約と実装：紹介パートナーが実装する場合は、契約主体、見積会社、障害窓口、再委託を明確にしておく必要があります。

公式パートナー制度には、ソリューション、アプリケーション、OEM、アウトソースなどの区分があります。ただし、掲載区分だけで対応力は判断できないため、実際の担当範囲を確かめます。

公式パートナー・開発会社への外注

開発会社や公式パートナーには、要件定義、画面制作、移行、API連携、テスト、運用支援をまとめて任せられます。この方法は、BtoB ECや複数ブランドの案件に適しています。

さらに、店舗在庫、会員ランク、基幹・WMS連携を伴う案件にも適しています。そのうえで、同規模・同業種の実績を確かめ、商品と受注のデータモデルについて質問します。

顧客と在庫のデータモデルや、連携エラー時の運用も、あわせて確認します。また、リリース後の保守担当や、見積前の要件定義を有償で誰が担うかを確かめておきます。

自社主導と外部委託の組み合わせ

自社主導と外部委託を組み合わせるときは、社内に知識を残すことと、調整の負担が増えることの両方を見ておきます。

• 社内主導：IT担当者が要件と優先順位を持ち、設計・開発や専門連携は外部に任せます。
• 役割分担：片手間では意思決定が遅れるため、責任者と外注先をRACIのような表で一覧にしておきます。
• 複数社体制：全体調整が難しくなるため、全体設計と受入テストの責任者を自社に置く必要があります。

業務知識が社内に残るので、ベンダーを替えるときの引き継ぎにも役立ちます。EC基盤と基幹連携、デザインと移行、保守は、複数社に分けて任せることもできます。

複数社体制では、受注データの食い違い、障害原因の特定、仕様変更の承認が難しくなりがちです。

ebisumartのシステム発注を成功させる進め方

発注では、見積を依頼する前に、自社の業務とデータを洗い出すことが出発点です。画面を検討する前に、受注から出荷、返品、返金までの業務シナリオを書き出すと、必要な機能と連携が見えてきます。

現状業務と移行データの棚卸し

棚卸しでは、通常の業務項目と例外の両方を確かめ、移行するデータの範囲を決めます。

• 業務項目：商品、カテゴリ、規格、価格、在庫、顧客を洗い出します。法人、会員権限、受注、決済、配送も対象です。返品、ポイント、クーポンも含みます。
• 手作業の工程：ExcelやFAXで補う業務も対象にします。
• BtoBの条件：企業別価格、掛け率、注文承認、請求先、納品先、親子会員を分けて整理します。

例外や繁忙期の滞りを担当者に聞くと、通常の流れにない要件も拾えます。なお、移行データは、すべて新システムに入れるとは限りません。

重複会員、表記揺れ、退会者、古い価格、廃番商品、保存義務のある受注履歴は、分けて扱います。そのうえで、移行対象、保持期間、削除ルールを決めます。クレンジングの担当が曖昧だと、修正工数が増え、納期と費用が膨らみます。

サンプルデータを早期に渡し、移行リハーサルを見積に含めておきます。

連携方式と責任分界の設計

連携設計では、API仕様、同期の要件、処理の責任範囲、納品物を定めます。

• API仕様：認証情報の保管、APIバージョン、取得・更新方向、差分同期を定めます。
• 障害制御：レート制限、タイムアウト、再送、重複防止、監視方法を記載します。
• 処理方式：CSVや夜間バッチで足りる処理をリアルタイムAPIにせず、費用と障害リスクを抑えます。
• 責任分界：標準機能の不具合は提供元、個別開発は開発会社、連携先のデータ欠損は連携担当を一次窓口にします。

ebisumartのデータアクセスAPIはREST形式で、商品・会員情報などへOAuth認証でアクセスします。また、設計書、API仕様、項目マッピング、エラー一覧も納品物に含めます。

テスト・教育・段階リリースの発注範囲

テストや教育、移行も発注範囲に含めます。業務シナリオと受入条件を決めてから、本番準備に進みます。

• 業務テスト：商品登録、注文、決済、在庫、出荷を一連で確認します。キャンセル、返品、返金、ポイント付与も対象です。
• 追加の受入条件：繁忙期の負荷、API再送、決済失敗、外部停止時の復旧も受入条件に含めます。
• 本番準備：担当者教育とマニュアルを用意し、一部商品やブランドで並行稼働させます。

BtoBでは、取引先別価格、注文承認、管理者権限別の操作もテスト対象です。全ブランドを一度に移行せず、移行データと受注結果を照合してから段階的に広げる方法もあります。

標準更新が続くため、リリース前後のテスト担当を契約と運用計画に明記します。

RFP・要件整理で決める項目

RFPは、機能の一覧だけでなく、背景、目的、対象業務を記載する発注資料です。課題、予算、希望時期も書き添えます。連携先やデータ量、セキュリティも示すと、各社の見積を同じ前提で比べられます。納品物と保守方針も含めます。

RFPに必ず入れる基本項目

RFPには、事業規模や構成、業務要件、連携条件を分けて記載します。

• 事業目的・業態：導入目的、対象サイト、BtoC・BtoB・D2Cの区分を記載します。
• 規模：商品点数、会員数、月間・繁忙期の注文数、売上規模を記載します。
• 現行環境：現行システム、リプレース理由、希望公開時期を明記します。
• 業務要件：商品、会員、受注、在庫、価格を整理します。ポイント、クーポン、決済、配送も含めます。

現状維持、改善、廃止する作業を分けておくと、過剰なカスタマイズを防げます。外部連携は、システム名だけでなく、データと運用条件も整理します。

たとえば、連携データ、方向、頻度、件数、エラー時の業務、担当会社を記載します。特に、基幹連携は、商品マスタの送信元や受注の返却先、在庫を何分ごとに同期するかで設計と費用が変わります。

CRM・MAとの連携では、配信対象と同意・停止情報の管理元も明記します。

必須・希望・将来構想の切り分け

優先度と評価基準は、分けて決めます。初回に要件を詰め込みすぎると、会員移行やテストが後回しになり、重要業務が不安定になることがあります。

• 必須：稼働初日に必要な要件です。
• 希望：予算と納期が合えば取り入れたい要件です。
• 将来構想：後の拡張候補です。売上や効率に直結する要件を優先し、細かなデザインや一部自動化は段階導入にできます。
• 評価基準：価格、適合度、同業実績、移行、連携を採点します。体制、保守、セキュリティ、提案の具体性も採点の対象です。

価格に40点、機能や保守に10点を配ると、最安案に引っ張られることがあります。そこで、自社の失敗リスクが大きい項目に高い配点を置くと、相見積もりを判断に活用できます。

個人情報・カード情報・セキュリティ条件の明文化

RFPには、情報の扱い、アクセス制御、保管、委託先、終了時の処理を明記します。

• 情報管理：会員、注文、配送先、問い合わせ履歴のアクセス権限とログ保管を定めます。
• アクセス・保全：IP制限、2段階認証、バックアップ、障害連絡を記載します。
• 委託と終了時：再委託、データ返却・消去を定めます。
• カード情報：決済代行会社へ渡すかEC側に保持するかで責任分界が変わります。

見積を比べるには、「セキュリティ対応」の中身を具体的な項目で示してもらう必要があります。たとえば、公式説明では、クラウド環境や管理者ID・パスワード認証が案内されています。

公式説明には、IP制限、ファイアウォール、DDoS対策、不正侵入検知、SSL、HSTSなども含まれます。

ただし、公式ページは標準機能を前提にしています。カスタマイズ、外部Apps、再委託先の対策は別途確かめ、契約書と設計書に記載します。

契約形態とebisumartのシステム費用相場

費用は、初期構築費だけでなく総額で比べます。総額には、利用料金、基本・カスタマイズ保守、外部サービス、移行が含まれます。さらに、テスト、教育、稼働後の改善も含めます。

契約は、成果物を納品する作業、相談しながら進める作業、稼働後の保守に分けて考えます。

請負・準委任・保守契約の使い分け

作業の性質に応じて、請負、準委任、保守の契約範囲を使い分けます。

• 請負：仕様と受入条件を確定し、成果物を納品する部分で検討します。
• 準委任：要件定義、調査、技術支援など、完成品として結果を保証しにくい作業で検討します。
• 保守：標準・カスタマイズ保守、監視、問い合わせ、障害対応、改善開発を分けます。

契約類型や責任は案件ごとに異なるため、法務担当者や専門家の確認が必要です。特に保守契約では、月額に含む時間、対応時間帯、緊急度別の初動、修正と追加開発の境界を確かめます。

契約の終了時には、設計書、ソース、APIキー、運用アカウント、データをどの形式で返すかも決めます。

公式料金を基準にした費用レンジ

商品点数やデザイン、決済、移行、連携数、カスタマイズ量で費用は変わります。複雑な構成では、オムニチャネル、複数ブランド、独自受注・在庫、会員移行、複数連携も考慮します。

公式料金ページの最低目安を基準に、企画予算を置きます（出典：株式会社インターファクトリー「EBISUMART 料金プラン」）。また、月商1,000万円の公式例は、標準機能とポイント・検索・レコメンドのカスタマイズを含み、導入500万円・月額30万円です。

• 公式最低目安：従量課金・固定料金とも初期300万円から、月額25万円程度からです。
• 月額の構成：基本保守、カスタマイズ機能保守、オプション、アクセス費用です。
• 標準機能中心：初期300万〜800万円、月額25万〜50万円程度が企画段階の目安です。
• 1〜3連携やBtoB要件：初期800万〜3,000万円、月額40万〜100万円程度を想定します。
• 複雑な構成：オムニチャネル等を含む場合、初期3,000万円〜2億円超、月額80万〜650万円程度まで広がります。

この金額は企画段階の目安で、確定した見積額ではありません。

月商5,000万円の例では、基幹・POS連携やオムニチャネルを含み、導入3,000万円・月額80万円です。一方、月商5億円の例では、独自開発、WMS・アプリ・会計・MA連携を含み、導入2億円・月額650万円です（出典：株式会社インターファクトリー「EBISUMART 料金プラン」）。

レベニューシェアと開発期間の比較

レベニューシェアと固定料金は、費用条件と開発期間を分けて比較します。

• レベニューシェア：公式料金は初期1,000万円から、月商の2.5％からです。
• 変動条件：対象売上、最低利用料、料率、契約期間、返品・キャンセル、解約精算を試算します。
• 開発期間：標準機能中心は1〜3か月、連携やBtoB要件を含む場合は3〜6か月が一般的な想定です。
• 大規模構成：複数連携・大規模移行・オムニチャネルは6〜12か月以上を想定します。

初期費用を抑えられる場合がある一方で、売上成長時は支払額が増えます。月商が変動する企業は、固定料金との損益分岐を複数パターンで比べます。

公式には一律の標準期間は示されていません。そのため、見積には要件定義、設計、開発を含め、次の作業も入れます。

• データ整理
• 結合・負荷・セキュリティテスト
• 受入
• 教育
• 並行稼働

委託先と見積書の比較ポイント

委託先は、知名度や提示金額よりも、業務の中身で判断します。確認するのは、公式パートナーかどうか、同業・同規模の実績、現行システムの理解、移行・テストの対応力、稼働後の保守です。

導入事例には、スクウェア・エニックスの公式通販、レノボ・ジャパンのサブスクリプション、第一園芸のオンラインショップなどがあります。また、導入事例はBtoC、D2C、基幹連携、定期・複雑な受注など、幅広い構成です（出典：株式会社インターファクトリー「業界別・導入事例」）。

業務と成果物で見る実績

実績確認では、業務との近さ、成果物、保守時の連絡体制を見ます。

• 業務実績：商品・価格・在庫連携、会員統合、店舗受取を見ます。法人権限、定期販売、返品・返金、基幹連携も確かめます。
• 成果物：要件定義書、画面・API設計書、移行計画、テスト仕様書、運用マニュアルのサンプル
• 保守体制：受付時間、開発への連絡条件、再委託先の担当、個人情報へのアクセス、事故連絡、終了時の引き継ぎを確かめます。

宣伝文句の「24時間対応」より、受付から開発担当へつなぐまでの流れを具体的に確かめます。また、個人情報保護委員会のガイドラインも、委託先の選定、契約、監査、安全管理措置の確認を重視しています（出典：個人情報保護委員会「個人情報保護法ガイドライン（通則編）」）。

同じ単位にそろえた見積書の比較

見積比較では、作業範囲、単価の前提、変更条件をそろえます。

• 作業範囲：要件定義、デザイン、標準設定・改修、API・CSV・バッチを分けます。データクレンジング・移行リハ、テスト、教育、リリース、保守、外部費も分けます。
• 見積条件：工数、人月、単価、期間、前提、除外事項を確認します。
• 提案案：必須要件、予算抑制、将来拡張の3案を求め、標準機能案と独自開発案を分けます。

条件が不足した見積は、安く見えても追加請求につながる可能性があります。そのため、変更の定義、承認方法、単価、納期への影響、仕様凍結時期を、見積の段階で確かめておきます。

初期費用より稼働後の総コスト

総コストには、初期費用のほか、月額・従量費、障害対応、運用教育なども含めます。特に、これらが別料金なら、数年単位の費用が高くなることがあります。

• 継続費用：月額保守、アクセス費用、外部API、決済手数料、追加連携を確認します。
• 運用費用：障害対応、繁忙期の負荷対策、担当者教育が別料金か確かめます。
• 将来費用：初期・1年目・3年目のTCOを試算し、アクセス数、売上、会員数の増加時も確認します。
• 更新予定：標準機能の追加予定があれば、提供時期と適用条件を確かめ、個別開発を急がず時期を判断します。

2025年から2026年にかけて、定期販売、reCAPTCHA、問い合わせ返信、決済連携などの更新予定や導入事例が公開されています。ただし、更新予定は変わる可能性があるため、契約時点の対象範囲、カスタマイズ保守、テスト責任を文書化します（出典：株式会社インターファクトリー「EBISUMART 機能アップデート予定」および最新情報）。

よくある質問（FAQ）

発注時によくある疑問を取り上げます。FAQの回答は契約条件にせず、自社の規模や業務に合わせて、RFPと個別見積で具体化します。

ebisumartのシステム発注費用はいくらですか？

公式の最低目安は初期導入300万円、月額25万円程度からです。標準機能中心か、基幹・POS・WMS・MA連携や独自カスタマイズを含むかで変わるため、300万円を予算の上限と考えないことが大切です。

公式料金例では、月商5,000万円規模は導入3,000万円・月額80万円、月商5億円規模は導入2億円・月額650万円です。

フルスクラッチ開発とebisumartはどちらが良いですか？

独自業務が多く基盤仕様も自由に決めたい企業には、フルスクラッチが候補です。EC標準機能を使い、競争力に直結する部分だけを拡張する企業には、ebisumartの標準・連携・カスタマイズの組み合わせが適します。

どちらを選ぶかは、初期費用だけでなく、更新、保守、障害対応、将来の開発体制も比べて判断します。

RFPが未完成でも開発会社へ相談できますか？

相談できます。複数社で比べる場合は、背景、目的、課題、対象業務を整理します。さらに、連携先、データ量、希望時期、予算の考え方を伝えると、提案の精度が上がります。

要件定義を依頼する場合、その作業が有償か、成果物は何か、完了後に本開発を断れるかを確かめます。未完成の要件を理由に、比較できない一括見積を受け入れないことも重要です。

CRM・MAとの連携はebisumartだけで完結しますか？

ebisumartはECの会員・購買・受注データを扱う基盤です。営業案件管理や高度なマーケティング配信は、別の製品と組み合わせる場合があります。

CRM・MAを使う場合は、会員属性、購入履歴、キャンペーン反応、同意・配信停止情報を連携し、データの正と利用目的を決めます。そのうえで、API、CSV、バッチのどれを使うかを選び、エラー時の再送担当も設計します。

まとめ

発注前に業務とデータを洗い出し、標準機能、オプション・連携、独自開発を切り分けます。提供元、公式パートナー、自社主導の複数社体制から、技術力と調整力に合う発注形態を選びます。

発注前に確認するチェックポイント

RFPには、目的とKPI、対象業務、連携先、移行範囲を記載します。データ量は、商品、会員、受注、在庫のそれぞれで示します。さらに、必須・希望・将来構想、セキュリティ、成果物、保守条件も書き添えます。

見積は、要件定義、開発、移行、テストを分けます。教育、外部費用、月額保守も分けたうえで、初期・1年目・3年目のTCOで比べます。

契約では、標準とカスタマイズの責任分界や再委託、変更管理を確認します。さらに、障害対応、更新時のテスト責任、終了時のデータ返却も押さえます。

作り込む量より投資範囲の切り分け

成否を分けるのは、標準機能に業務を合わせる範囲と、競争力のある独自要件に投資する範囲を、どう切り分けるかです。費用や機能だけで決めず、運用定着、データ品質、保守体制まで含めて委託先を選ぶと、稼働後にExcelや手作業へ戻るリスクを抑えられます。

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

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