BtoB-ECの改修費用が毎年膨らむ会社に共通する構造問題|改修サイクルを断ち切る視点

この記事でわかること
BtoB-ECを導入して1〜2年、「また改修費用が発生した」という状況が続いていませんか。再構築を迫られるほどではないが、毎年数十万〜数百万円の改修予算が消えていく。この「じわじわしたコスト出血」は、個々の改修内容の問題ではなく、設計の構造問題です。本記事では、改修が止まらない根本原因と、そのサイクルを断ち切るための視点を整理します。

「想定内の改修」と「設計不足による改修」は別物

改修がゼロになることはありません。事業が変われば、システムも変わります。これは正常です。

問題は、その改修の性質です。

「毎年改修費用が発生している」という会社の多くは、2番目と3番目の改修が大半を占めています。これらは個々の改修の問題ではなく、初期設計の構造問題が繰り返し表面化しているものです。

改修が止まらない6つの構造パターン

① 価格ロジックを「その都度対応」にした

最も多いパターンです。導入時は「顧客別の掛率設定ができれば十分」という判断で設計した価格管理が、事業の成長とともに追いつかなくなります。

具体的な経過としてこういうことが起きます。

1. 当初：顧客A社は80%、B社は75%という掛率管理で運用開始
2. 半年後：「数量が多い場合はさらに5%引きにしたい」→価格プラグイン追加（改修①）
3. 1年後：「期間限定のキャンペーン価格を設定したい」→改修②
4. 2年後：「営業が交渉した特例単価をECに反映したい」→基幹との価格連携が必要に（改修③、工数大）
5. 3年後：価格の複雑化が管理限界に達し、価格テーブルの再設計が必要になる（大規模改修）

各改修は「その時の課題に対応する」ものですが、根本の問題は初期設計で価格ロジックの複雑化を前提にしていなかったことです。将来の価格パターン増加を想定したデータ構造で始めていれば、②③は追加設定で対応でき、改修費用が発生しなかった可能性があります。

② 例外処理を運用でカバーし続けた

「ロット割れは電話で確認」「分納は担当者が手動で処理」「特別値引きはメールで申請」——導入時にこうした運用ルールを作った場合、それは時限爆弾です。

頻出例外を運用でカバーし続けると、以下のコストが積み上がります。

• 人的コスト：担当者の処理時間が毎日発生し続ける
• 引き継ぎコスト：担当者が変わるたびに「暗黙のルール」の伝達が必要になる
• ミスコスト：手作業の増加に比例してミスが増え、取引先からのクレームが増える
• 後付けシステム化コスト：限界が来た時点でシステム化する改修費用が発生する。初期から設計するより割高になる

③ 基幹連携をCSV運用で固定した

スタート時はCSV連携で十分なケースは多い。問題は「CSV連携で固定してしまう」ことです。

CSV運用のまま注文件数が増えると、以下が発生します。

• CSV加工・インポート作業の工数が注文数に比例して増える
• インポートのタイムラグで在庫誤差が増え、欠品注文のキャンセル対応が増える
• 取引先から「リアルタイムの在庫確認がしたい」という要望が来る
• API連携への移行を検討するが、EC側・ERP側の双方に大規模改修が必要になる

最後の「API連携への移行改修」が高コストになる理由は、EC側のデータ構造がCSV前提で作られているためです。最初から「CSV連携で始めるが、将来API連携に移行できる構造」で設計しておけば、移行コストを大幅に圧縮できます。

④ 標準機能に無理に合わせた

「カスタマイズ費用を抑えるため、標準機能でできる範囲で設計する」という判断は合理的に見えます。ただしBtoB特有の要件を標準機能に無理に合わせると、後から歪みが出ます。

典型的な歪みの例です。

• 顧客別価格を「会員グループ」で管理した結果、グループが乱立して管理不能になる
• 商品バリエーションを標準の商品複製で対応した結果、商品マスタが数倍に膨れ上がる
• 承認フローをメモ欄や管理画面のステータスで代替した結果、処理のトレーサビリティがなくなる

これらはいずれも「今は動いている」状態ですが、規模が拡大した時点で構造ごと作り直す改修が必要になります。初期のカスタマイズ費用をケチった結果、後から数倍のコストで対応することになります。

⑤ 権限・ロール設計を後回しにした

導入時の取引先数が少ない場合、「管理者と一般ユーザーの2種類で十分」という判断になりがちです。しかし事業が拡大すると権限の粒度が足りなくなります。

• 支店・部署ごとに発注権限を分けたい
• 特定商材は特定の担当者しか発注できない設定にしたい
• 一定金額以上の発注は上長承認フローを通したい
• 代理店経由の取引先は閲覧のみ・発注不可にしたい

権限設計を2択で実装してしまうと、これらへの対応がすべて「追加改修」になります。ロール設計に柔軟性を持たせておくだけで防げる改修です。

⑥ 設計工程を省いて開発を急いだ

「とにかく早くリリースしたい」という要求に応えるため、受注構造の整理・価格ロジックの棚卸し・例外処理の分類を省略して開発に入るケースがあります。

この場合、設計で整理されなかった問題がすべて「仕様変更」という形で開発中・リリース後に出てきます。

改修費用の「見えにくいコスト」

改修費用として計上されるのは開発費用だけです。ただし実際のコストはそれだけではありません。

開発費用だけで計算すると「年間100万円の改修費用」でも、上記を含めると実質的なコストは2〜3倍になっているケースが少なくありません（推測値。状況により異なります）。

改修サイクルを断ち切る3つの視点

改修が積み上がっている状態から抜け出すには、個々の改修に対応し続けるのではなく、構造問題を診断して手を打つ必要があります。

1. 1

   改修の「種類」を分類する

   過去1〜2年の改修履歴を「想定内の拡張」「構造変更を伴う改修」「運用補完のシステム化」に分類してみてください。後者2つが多い場合は、構造問題を疑うべきです。改修の内容ではなく種類を把握することで、どこに根本原因があるかが見えてきます。

2. 2

   「改修予算」の使い方を変える

   毎年の改修予算を個々の改修対応に使い続けると、構造問題は解決されません。ある時点で「今年の改修予算を構造改善に使う」という判断が必要になります。100万円を小さな改修10件に使い続けるより、設計を見直す1件の投資に使う方が、翌年以降の改修費用を下げる可能性があります。

3. 3

   現状の設計の「どこが根本問題か」を診断する

   自社だけでは判断が難しい場合、セカンドオピニオンを活用してください。現行ベンダーは改修で収益を得ている立場でもあるため、「構造問題がある」とは言いにくい面があります。第三者の視点で「どこを直せば改修が減るか」を診断することで、改修サイクルを断ち切る具体的な手が見えてきます。

あわせて読まれています