基幹システム標準化でつまずきやすい「EDIカスタマイズ問題」 ～ 現場要望を否定せず、標準化を成立させる処方箋 ～

基幹システム刷新（ERP更改）の話が動き出すと、必ずといっていいほど表面化する論点があります。
「これまで現場の要望で入れてきたカスタマイズを、標準化の名の下に削れるのか」という問題です。

当事者からすれば、そのカスタマイズは"便利機能"ではありません。業務の前提として運用が定着し、帳票やマスタ運用、チェック手順まで含めて一体化しています。つまり、機能を外すことは業務を壊すことに等しいことになります。
一方で、刷新を担う側から見れば、カスタマイズはパッケージのバージョンアップや保守を重くし、将来コストの増加につながりますので、両者の主張はどちらも正しいです。

本記事では、この衝突が特に起きやすい「EDI連携」を題材に、現場要望を否定せずに標準化を成立させるための、実務的な対応方針を解説します。

カスタマイズを"悪者"にしないための前提整理

近年の基幹システムは、パッケージ製品を中心に構成するのが一般的です。標準機能を活用するほど、将来のバージョンアップや法改正対応を取り込みやすいです。
しかし、カスタマイズが増えるほど、そのメリットは相殺されます。バージョンアップ時の影響調査・改修・テストが膨らみ、「更新できない基幹」へ近づいていきます。

ここで重要なのは、カスタマイズを"なくす"か"残す"かの二択ではないことです。現実解は次の形になりやすいです。

* 基幹（ERP）は標準機能中心に寄せる（Fit-to-Standard）
* 業務上必要で、標準機能では吸収しにくい差異は、別システムへ切り出す（周辺化する）

標準化を「機能の削減」と捉えると反発を招きます。標準化の本質は「責務の整理」によって将来コストを制御し、変更に強い構成へ再設計することです。

なぜEDIは"基幹カスタマイズ沼"になりやすいのか

EDIは、取引先とデータ連携するための仕組みであり、実務上は次のような処理の集合体です。

通信プロトコルの対応: 相手先が対応している通信プロトコルで通信する
データ形式の調整: データ形式を相手先に合わせる（例: CSV、文字コードUTF-8 等）
データレイアウトの調整: データのレイアウトを相手先に合わせる（項目、桁、並び順 等）
データ内容の調整: データの中身を相手先に合わせる（コード体系、区分値 等）
個別処理: 取引先固有事情に合わせた個別処理（コード読み替え、管理情報付加 等）
整合性チェック: マスタを用いたデータの整合性チェック

ここで起きがちな構図は以下になります。

> EDI（連携基盤）が「通信・変換」を担い、基幹が「業務処理」を担う──はずが、
> 取引先差異が基幹側に入り込み、結果として基幹が"取引先別仕様の集合体"になる。

EDIの機能の中で基幹システムに入り込みやすいのは、データ内容の調整と個別処理です。
これらは実業務に直結するため、業務担当が日頃操作する画面を持つ基幹システムや業務システムに実装されやすいです。
システム的には最適ではありませんが、通常時はそこまで問題になりません。
しかし、これらの機能が基幹システム側にあると、業務担当がメンテナンスしているため、システム担当はシステムのリプレイス時に問題に直面します。

取引先固有の差異は、増えることはあっても減ることはありません。基幹に差異が入り込めば入り込むほど、将来の更新コストと運用負荷が上がり、標準化の意義が薄れていきます。

加えて近年は、既存のEDIに加えてAPI連携も併用するなど、B2B連携が"複線化"しやすいです。だからこそ、基幹の中に取引先差異を溜める設計は、後から効いてきます。

対応方針の要点: 責務分界を"文章で"固定する

EDI課題への対応方針をコラムとして一言でまとめるなら、次の結論に尽きます。

「基幹は社内標準IF（社内共通フォーマット）を守り、取引先差異はEDI（連携基盤）側で吸収する」

社内標準IFとは、社内で統一した入出力の決めごと（項目・桁・コード体系など）です。より厳密には、社内共通データモデル（カノニカル）を定義して、取引先側の多様性を"外側"で受け止める発想です。

この方針を成立させるために、責務分界を明確にしておきます。実務上の推奨は次の通りです。

基幹（ERP）が担うべきもの

* 一般に基幹であるべき機能（受注、出荷、請求、在庫、会計など）
* 自社業態に応じた固有の必須機能（競争力の源泉、コア業務）
* 業務妥当性の判断（与信、引当、締め、会計整合など）

EDI（連携基盤）が担うべきもの

* 業界標準（EDI標準）への対応
* 取引先ごとの差異の吸収（プロトコル、フォーマット、レイアウト、個別ルール）
* 送受信の監視、再送、追跡、障害切り分けといった運用機能
* フォーマット改定への追随、段階切替、併用期間の管理（変更管理）

ポイントは、方針を"雰囲気"で合意しないことです。後で揉めないように、仕分け基準を文章として明文化します。要件定義に入る前に、この一手間が効いてきます。

なお最近は、「ERPの中核を直接改変せず、アップグレード可能性を損なわない」という考え方を、クリーンコアと呼ぶことがあります。EDI差異を外側に寄せる方針は、この考え方とも整合します。

「基幹を基本機能に戻す」ための現実的な手順

では、すでにカスタマイズされた基幹が稼働している状態から、どうやって基本機能中心へ戻していくかについて、取引先連携（EDI）を例に、手順を整理します。

1. 基本方針をまとめる

仕分けの基準を決めるため、責務分界の文章化から始めます。
「基幹は何を守るのか」「EDIは何を吸収するのか」を、例外条件も含めて定義します。

2. 基幹システムの機能を一覧化する

仕様書（機能仕様、画面仕様、スキーマ定義、運用マニュアル等）を洗い出し、一覧化します。
このとき、機能一覧だけでは足りません。EDIはデータ連携ですので、画面・機能に加えて、データベース（テーブル/項目）やIF（入出力）も一覧に含めるのが実務的です。

そして一覧に「ERP/EDI区分」の列を追加し、仕分けの器を整えます。

3. 一覧を仕分ける（基幹で担う/EDIで担う）

基本方針に照らし、仕様書を読み込みながらコメント付きで仕分けます。
仕分けは、個人作業で終わらせず、関係者レビューで固めます。ここが要件定義の地盤になります。

4. 概算費用を算出する（予算策定のため）

仕分け一覧に対し、各機能の複雑さを定義します。CRUD図などを用いて、関連データの多さ・依存関係を数値化し、類似実績から概算に落とします。
自社実績がない場合は、実績を持つベンダーに依頼して算出しますが、ベンダーの開発力・ノウハウ前提である点は明記しておきます。

なお、EDI領域は「開発」よりも「取引先との相互接続試験」「段階切替」「併用期間の運用」が支配的になることがあります。概算段階では、ここを別枠・レンジで扱う判断が合理的です。

標準化を"絵に描いた餅"にしないための注意点

最後に、EDIを標準化する際に現場で詰まりやすいポイントを挙げておきます。

* 取引先差異はなくならない: 差異を基幹に入れるほど、将来コストは確実に増えます
* 変換（コード読み替え）は統制が必要: 変換定義は、誰が・いつ・何を変えたかが追える形で管理します。改定が重なるほど、定義の整合や説明責任が課題になりやすいです
* 運用機能の作り込み: 追跡・再送・障害切り分けの仕組みは後付けしにくく、業務の安定性に直結します
* 要件定義で仕分けの妥当性を検証する: 単純な積み上げだけでなく、機能間の関連性まで精査します

まとめ: 標準化とは「削ること」ではなく「分けること」

基幹システムの標準化は、現場の要望を切り捨てる活動ではありません。
必要な機能を、将来にわたって維持しやすい場所へ"移す"活動です。

EDI連携は、取引先差異が避けられない領域です。だからこそ、基幹を社内標準IFに保ち、差異はEDI（連携基盤）側で吸収するという責務分界が効きます。
この分界を方針として文章化し、機能・データ・IFを棚卸して仕分けます。そこから概算をつくり、要件定義で妥当性を詰めていきます。この順序が、標準化を実装に落とす最短距離になります。

2026年2月13日公開
※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。