EDI連携の刷新を考える企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、取引先仕様と社内業務を両方見て連携設計することを重視して進め方を整理します。
この記事では、基幹システムの再構築に合わせてEDI連携を見直す際のポイントを整理します。レガシーEDIからの移行を控えている担当者と、取引先対応の方針を決めたい経営層に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
EDI連携は「社内の仕組み」ではなく「取引先との約束」
EDI連携が他のシステム連携と根本的に異なるのは、社内だけでは仕様を決められない点です。取引先ごとのフォーマット、通信プロトコル、送受信のタイミングはすべて相手との取り決めであり、変更には取引先の理解と協力が必要です。基幹システムの再構築を機にEDIを見直す場合、社内の計画だけでなく、取引先への説明とスケジュール調整を計画の中に組み込むことが不可欠です。
レガシーEDIからの移行は「いつ動くか」ではなく「いつ止まるか」で考える
全銀TCP/IPやJCA手順などのレガシーEDIは、通信インフラの終了や機器の保守切れという外部制約で、いずれ使えなくなります。インターネットEDIや流通BMS、Web-EDIへの移行は選択ではなく時間の問題であり、いつ動くかではなく、いつ止まるかから逆算して計画を立てるべきテーマです。基幹の再構築と重なるなら、合わせて移行するのが最も効率的です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、基幹の再構築とEDIの移行を別々のプロジェクトとして進め、切替タイミングがずれることです。基幹は新システムに切り替わったのにEDIは旧環境のまま、あるいはその逆。この不整合は、受注データの取り込みエラーや出荷指示の二重処理を引き起こします。
また、主要取引先のEDI移行スケジュールを確認しないまま自社の計画を立て、取引先側の準備が間に合わずに二重運用が長引くケースも多発します。EDIの切替は自社都合だけでは決められないことを前提に、早い段階で取引先への意向確認を始めることが重要です。
取引先ごとの個別仕様が多い場合、新EDI基盤への移行で仕様を標準化しようとしても、一部の取引先が旧方式を使い続けることがあります。すべてを一斉に移行するのではなく、取引先ごとの移行ステップを個別に計画する現実的な進め方が必要です。
自社で確認できるチェックポイント
EDI連携の見直しを検討する前に、次の点を確認しておくと、計画の精度が上がります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
EDI連携ならではの棚卸しポイント
基本のチェックリストに加えて、EDI接続している取引先の一覧と通信方式、各取引先のフォーマット（標準かカスタムか）、レガシーEDI機器の保守期限、主要取引先のEDI移行計画の把握状況、そしてEDIの運用を担当できる人数を確認してください。取引先数が多い場合は、取引金額上位の10〜20社から優先的に対応するのが現実的な進め方です。
EDI方式の選択肢としては、インターネットEDI（JX手順・ebMS等）、流通BMS、Web-EDI（取引先がブラウザで操作する方式）があり、取引先の規模と技術力によって適切な方式が変わります。大手取引先にはインターネットEDI、中小の取引先にはWeb-EDIという使い分けが一般的です。
EDI移行では、テスト期間を十分に確保することが取引先との信頼を守る条件です。本番データを使った接続テストを取引先と一緒に行い、双方で送受信の正常性を確認する。この手間を惜しむと、本番運用で伝票の欠損やフォーマットの不一致が発覚し、取引先への信頼を損なうことになります。
延命・部分改善で対応できるケース
EDI連携の課題は、基幹の全面再構築を待たずに解決できる場合があります。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
たとえば、レガシーEDI機器の更新だけが急務なら、EDI変換サービスやクラウドEDIサービスの利用で、基幹側に大きな改修なしに対応できることがあります。数百万円規模で通信基盤だけを刷新し、基幹側の連携部分は最小限の改修にとどめる方法です。
ただし、この場合もフォーマット変換のルールと取引先との取り決めは個別に確認が必要です。基盤を変えてもデータの中身の仕様は残るため、見た目のシンプルさに騙されないことが重要です。
費用の目安は、クラウドEDIサービスへの切替なら数百万円・3〜6か月、EDI基盤の構築と複数取引先への対応を含めると1,000万円前後、基幹再構築と一体で取引先管理まで作り込む場合は全体の要件に含めて設計します。取引先の数と個別仕様の多さが費用の変動要因であり、標準化を進めるほどコストは下がります。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
次のような状況であれば、EDI単体の改善ではなく基幹の再構築とあわせて設計すべきです。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージの中にはEDI連携機能を標準搭載しているものがあり、パッケージ移行がEDI刷新への最短ルートになることがあります。対応しているプロトコルと取引先フォーマットの柔軟性を選定時に確認してください。
周辺開発で補うケース
基幹本体はそのまま残し、EDI変換・通信をミドルウェアやクラウドサービスで周辺に持たせる構成は、本体への影響を最小に抑えつつ通信基盤を刷新できる定石です。
スクラッチ再構築が向くケース
基幹をスクラッチで再構築する場合は、受注データの取込から出荷データの送信までを一貫した設計で組み込めるため、EDI連携の効率が最も高くなります。取引先マスタと連携設定をデータベースで管理する設計にすれば、取引先の追加や方式変更にも柔軟に対応できます。
マクティズムの見解
マクティズムの見解として、EDI連携を基幹システム再構築で見直すポイントでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、取引先仕様と社内業務を両方見て連携設計することを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
EDIの相談では、技術的な移行よりも取引先との調整に時間がかかるケースがほとんどです。私たちは、取引先への説明資料の作成や、移行テストの段取りまで含めてご支援しています。EDIは社内のシステムである以上に、取引先との信頼関係の上に成り立つ仕組みです。相手への敬意を持った移行こそが、最も確実な進め方だと考えています。
相談前に準備しておく情報
EDI連携の相談では、接続先の取引先リストと通信方式、レガシー機器の保守期限、取引先側の移行計画の把握状況、個別仕様がある取引先の数が分かると、初回から具体的な計画の話ができます。取引先のEDI担当者の連絡先一覧があると、後工程がスムーズになります。
実務では、現行調査で取引先ごとの連携仕様を一覧化し、開発前診断で標準化できる範囲と個別対応が必要な範囲を仕分けたうえで、取引先への案内スケジュールを含めた移行計画をおすすめしています。
EDI連携が整理されると、受注入力の自動化率が上がり、手入力のミスと残業が減るという即効性のある改善が得られます。地味なテーマに見えますが、受発注の最前線で日々の業務負荷に直結する領域であり、投資対効果は非常に高い分野です。
取引先との電子的なつながりを整備することは、自社の業務効率だけでなく、取引先への対応力という営業上の競争力にもなります。EDIの刷新は守りの投資であると同時に、信頼を深める攻めの一手でもあるのです。
検討は、取引先と方式の棚卸し、レガシー機器の期限確認、取引先への意向打診、方式の選定、取引先ごとの移行ステップ計画、の順で進めてください。社外を巻き込む分だけ、早めに動き始めることが最大のポイントです。
移行後も、しばらくは旧方式との並行運用期間を設けるのが安全です。新方式で問題が起きた際に旧方式へ即座に切り戻せる備えがあれば、取引先を巻き込んだトラブルを最小限に抑えられます。並行運用の終了判定基準も、事前に取引先と合意しておくことをおすすめします。
EDIの運用ノウハウは属人化しやすい領域です。移行を機に、取引先ごとの接続設定やフォーマット仕様を文書化し、担当者が交代しても引き継げる状態を作ることも忘れないでください。仕組みの刷新と知識の文書化を同時に行えるのが、移行プロジェクトの好機です。
EDIの移行が完了すると、受注データの自動取り込み率が上がり、手入力によるミスと残業が目に見えて減ります。この効果は取引先の数が多いほど大きくなるため、対応先を広げていくモチベーションにもなります。
取引先とのつながりを大切にする姿勢が、EDIという仕組みの根底にあることを忘れずにいてください。
EDI移行は技術よりも段取り。早く動き始めた企業ほど、余裕を持って移行を完了しています。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。EDIの場合、接続先の取引先リストとレガシー機器の期限が分かれば十分に相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。EDI基盤の刷新を先行して行い、基幹の再構築は後から検討する進め方も可能です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。パッケージの標準EDI機能が自社の取引先に対応できるかも、選定時に一緒に確認します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。クラウドEDIサービスの活用で数百万円から対応できるケースがあります。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。取引先との調整も含めて、移行計画全体を一緒に設計します。
