この記事でわかること
「まずは今の業務が回ればいい」と割り切って構築したBtoB-ECが、3〜5年後に再構築を強いられる。そのパターンは決まっています。価格ロジックの破綻・基幹連携の後付け限界・権限設計の硬直化——この3つです。本記事では、再構築コストを回避するための拡張性設計の考え方と、実際に機能する設計判断の軸を解説します。
なぜBtoB-ECに拡張性設計が必要なのか
BtoB-ECはBtoC-ECと根本的に構造が違います。BtoCは商品・価格・顧客がシンプルです。BtoBは違う。
- 顧客ごとに単価が異なる
- 数量・時期・取引区分で価格が変わる
- 与信・支払条件・承認フローが顧客ごとに存在する
- 基幹システム（ERP/在庫管理）と必ず連携が発生する
導入時は「今の取引先50社が使えればいい」と設計しても、事業が動けば必ず変化します。取引先が100社になる。価格パターンが増える。EDI連携の要望が来る。新しい商材カテゴリが増える。
BtoCのプラットフォームが「スケールすれば勝手に広がる」設計なのに対して、BtoBは”複雑化する”のが正常な成長です。この複雑化に耐えられない設計が、再構築の温床になります。
「将来の機能を全部作る」ことではありません。「将来の複雑化に対してゼロから作り直さずに対応できる余地を残す」設計です。
再構築に追い込まれる3つの典型パターン
当社がリプレイス相談を受けるケースを分析すると、原因はほぼ以下の3つに収束します。
① 価格ロジックの破綻
構築時は「A社は定価の80%、B社は定価の75%」程度のシンプルな設定でした。ところが2〜3年後にこうなります。
- 顧客別マスタ単価（得意先コードで管理）
- 数量ブレイクによる段階単価（100個以上は○%引き）
- 期間指定のキャンペーン価格（期日を過ぎたら自動で戻る）
- 商品グループ×顧客グループのマトリクス割引
- 営業が個別交渉した特例単価（ERP側にしか存在しない）
標準機能の割引設定で「頑張って運用で対応」し続けた結果、Excelで手動補正→担当者依存→退職で引き継ぎ不能、というパターンは珍しくありません。
② 基幹連携の後付け限界
小規模スタートの場合、最初はCSV取込で何とかなります。受注→手動でERP入力、在庫→夜間CSV更新。これで1日100件なら回ります。
では1日500件になったら？リアルタイムの在庫反映が必要になったら？取引先から「EDI対応してほしい」と言われたら？
API連携を「前提」にした設計と「後付け」にした設計では、対応コストが根本的に違います。後付けの場合、EC側・ERP側の双方に大規模改修が必要になり、場合によってはECシステム自体の入れ替えを余儀なくされます。
③ 権限設計の硬直化
取引先が50社程度の時は「全担当者が全商品を注文できる」でも問題ありませんでした。しかし事業が拡大すると：
- 支店・部署ごとに発注権限を分けたい
- 一定金額以上は上長承認フローを通したい
- 特定商材は特定の担当者しか発注できない設定にしたい
- 代理店経由の取引先はカタログ閲覧のみで発注不可にしたい
権限設計を「管理者か一般ユーザーか」の2択で作ってしまうと、これらに対応できません。ロール設計に柔軟性がないシステムは、取引先の組織変化に追随できなくなります。
拡張性を確保する5つの設計判断
「拡張性のある設計」を具体化すると、以下の5点に集約されます。すべてを初期から実装する必要はありませんが、これらを「追加できる構造か」を確認してから構築するか否かを判断してください。
| 設計ポイント | 初期段階で確保すべきこと | 確保できていない場合のリスク |
|---|---|---|
| ① 価格ロジックの柔軟性 | 顧客別・数量別・期間別の価格パターンを追加できるデータ構造 | 価格変更のたびに開発費が発生。Excelで補正する運用が定着する |
| ② データ正規化 | 商品・顧客・注文データを正規化した構造。外部連携に耐えるスキーマ設計 | データが汚いと分析も外部連携も後から困難。移行コストが膨大になる |
| ③ API連携の前提化 | REST APIまたはWebhookで外部システムと疎結合で連携できる設計 | CSV運用の限界が来たとき、双方のシステム改修が必要になる |
| ④ ロール設計の余白 | 権限をロール（役割）で管理し、ロールを動的に追加・編集できる構造 | 取引先の組織変化・新規取引形態への対応が毎回開発案件になる |
| ⑤ 段階拡張の設計思想 | 初期は必要最小限でも、将来の追加が既存データ・処理を壊さない構造 | 追加機能が「継ぎはぎ」になり、一定規模で全体の整合性が取れなくなる |
BtoB-EC設計の方向性について、無料で相談できます
「今の要件でどこまで考えるべきか」「このベンダーの設計方針は大丈夫か」——そうした設計判断の壁打ちも承っています。押し売りは一切ありません。
「拡張前提にするとコストが高い」は本当か
よく言われます。ただし、これは「比較対象をどこに置くか」で答えが変わります。
| 比較軸 | 拡張性を考慮しない設計 | 拡張性を考慮した設計 |
|---|---|---|
| 初期構築費用 | 低め（標準機能中心） | やや高め（設計・カスタマイズに費用が乗る） |
| 2〜3年後の改修費用 | 高い（根本的な構造変更が必要） | 低め（追加・拡張で対応できる） |
| 再構築リスク | 高い（3〜5年で再構築を強いられるケースあり） | 低い |
| 運用コスト（業務負荷） | 高い（Excelや手作業による補完が増える） | 低め（自動化・連携で補完作業が減る） |
| 5年トータルコスト | 拡張性を考慮した設計の方が低くなるケースが多い | |
再構築コストには以下がすべて含まれます。
- 再設計・再開発費用（初期構築費用と同等以上になることが多い）
- データ移行費用（運用中のデータをクリーニングして移行する工数）
- 取引先への再アナウンス・再トレーニングコスト
- 新旧システム並行稼働期間の業務負荷
- 移行期間中のシステム停止リスク
これらを合計すると、初期構築コストの1.5〜3倍になるケースを何件も見てきました（推測値。案件の複雑さにより大きく異なります）。
ベンダー選定で確認すべき3つの質問
拡張性の高い設計ができるかどうかは、ベンダーの設計思想で大きく変わります。提案を受ける際に、以下を確認してください。
- 1
「価格ロジックが将来複雑化した場合、追加費用なく対応できますか?」
「その都度対応します」という答えは要注意。「こういう構造で設計するのでこの範囲は追加費用なく対応できます」と答えられるベンダーは設計を考えている証拠です。
- 2
「基幹システムとのAPI連携を前提にしていますか? CSVとAPIでどちらを推奨しますか?」
規模や予算によってCSVで十分なケースもあります。ただし「将来APIに移行する場合に追加で何が必要か」を答えられるかが重要です。移行コストを見積もれないベンダーは設計を考えていません。
- 3
「3年後に取引先が2倍・商品数が3倍になった場合の想定をしていますか?」
「はい、大丈夫です」だけでは不十分。「どういう設計をするから大丈夫なのか」を具体的に説明できるかを確認してください。
これらの質問に対して明確に答えられないベンダーは、拡張性よりも「まずリリースする」ことを優先する設計思想の可能性があります。
当社はBtoB-EC構築において、初回ヒアリングで「3年後の受注件数・取引先数・価格パターン数の想定」を必ず確認します。その想定値に基づいてデータ構造・API設計・権限設計の方針を決めるためです。現状に最適化した設計ではなく、成長に耐えられる設計を最初から選択します。
あわせて読まれています
よくある質問
小規模スタート（取引先30社以下）でも拡張性設計は必要ですか？
規模より「事業の成長見込み」で判断してください。3年後も30社程度で安定的に推移する事業なら、現状に最適化した設計で十分です。一方、事業拡大・新商材追加・取引先の組織変化が見込まれる場合は、初期段階から拡張性を意識した設計が後のコスト回避につながります。「将来を考える必要があるかどうか」はヒアリングで判断できます。まずご相談ください。
EC-CUBEを使えば拡張性は担保されますか？
EC-CUBEはオープンソースのため、原則としてカスタマイズの自由度が高く、拡張性のある設計を実現しやすいプラットフォームです。ただし「EC-CUBEを使えば自動的に拡張性が担保される」わけではありません。EC-CUBEの上で何をどう設計するかがすべてです。価格ロジックの持ち方・テーブル設計・APIの設計はEC-CUBE自体ではなく実装するベンダーの判断によって決まります。
SaaS型（futureshop、BカートなどのクラウドEC）は拡張性に限界がありますか？
あります。SaaS型はプラットフォームが提供する機能の範囲内でのカスタマイズに限られます。価格ロジックの複雑化・独自の権限設計・基幹システムとの深い連携が必要になった時点で、SaaSの標準機能では対応できないケースが出てきます。SaaSの限界についてはこちらの記事で詳しく解説しています。
既存のBtoB-ECを再構築せずに拡張性を改善することはできますか？
現状のシステムによります。データ構造の根幹（価格テーブルの持ち方や顧客管理の設計）に問題がある場合は、部分改修では対応できず再構築が現実的な選択肢になります。一方、APIの追加や権限ロールの追加程度であれば、既存システムへの追加対応で解決できるケースもあります。現状のシステムを診断した上で、再構築が必要かどうかを判断するセカンドオピニオンをご利用ください。
BtoB-EC設計の方向性、今のシステムの限界——まず無料で診断します
「うちのシステムは3年後に耐えられるか」「今のベンダーの提案は拡張性を考えているか」——こうした判断に迷っている場合、セカンドオピニオンとしてご活用ください。構築提案は一切せず、現状診断と設計方針のアドバイスに特化した相談も承っています。
投稿者プロフィール
- CEO
- 株式会社サンクユー 代表取締役CEO。
基幹システムとECをつなぎ、受発注業務の最適化を支援する専門家。
関西大学卒業後、東証プライム上場のゼネコンにて人事総務を経験。
その後システムベンダーへ転職し、IBM AS/400環境における金融・物流・販売管理・経理・人事など、企業の基幹業務を支えるシステム開発に従事する。
プログラマからプロジェクトマネージャーまでを経験し、台湾・台北駐在として銀行システム構築プロジェクトにも参画。
この経験を通じて、「システムの質は要件定義の質に比例する」という思想を確立。
業務理解を起点としたシステム設計を強みとする。
その後、クレジット決済代行会社にて、決済システムの再構築や銀行連携、ECサイト構築を担当。
あわせて組織改革にも携わり、20名から60名規模への組織拡大を実現（退任時：常務取締役）。
2008年に株式会社サンクユーを創業、2010年に法人化。
現在は、基幹システムとECの両領域に精通した知見を活かし、BtoB企業における受発注業務のデジタル化・効率化を支援。
特に、FAX・電話・メールなどアナログ業務のEC化や、基幹システムとの連携を前提とした業務設計を得意とする。
単なるECサイト構築にとどまらず、業務フローの整理・要件定義・システム設計まで一貫して関与し、「現場で使われる仕組み」を実現することを重視している。
NTTレゾナント「goo Search Solution」にてEC関連コラムを執筆。
ECマーケティングレポート | goo Search Solution
■趣味・関心領域
BMW / WRC / ロードバイク / RIZIN / UFC / 大相撲
David Bowie / blur / MUSE / The Rolling Stones / XTC
機動戦士ガンダム（富野由悠季）
ベルセルク / 頭文字D / 進撃の巨人 / ジョジョの奇妙な冒険 / あしたのジョー
Mission: Impossible / Memento / ワイルド・スピード / ソナチネ
LOST / Game of Thrones / FRINGE / The Mentalist
上岡龍太郎 / ダウンタウン
